https://bugzilla.tianocore.org/show_bug.cgi?id=945
Based on content from the following branch
https://github.com/Microsoft/MS_UEFI/tree/share/beta/CapsuleTools
Command line unit tests for python modules available from following branch:
We can consider capsule update path is a special S3 path. :)
Both capsule update path and S3 path have the attribute that the memory content
at previous boot are reserved.
Thanks,
Star
-Original Message-
From: Kinney, Michael D
Sent: Wednesday, May 30, 2018 12:09 AM
To: Yao, Jiewen ;
From: "Kinney, Michael D"
https://bugzilla.tianocore.org/show_bug.cgi?id=922
Based on content from the following branch:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport/MsCapsuleUpdatePkg
The FmpDxe directory contains 2 INF files. FmpDxe.inf
is a DXE driver that is used in a
From: "Kinney, Michael D"
https://bugzilla.tianocore.org/show_bug.cgi?id=922
Based on content from the following branch:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport/MsCapsuleUpdatePkg
Create FmpDevicePkg with library classes and PCDs used to
customize the behavior of a
https://bugzilla.tianocore.org/show_bug.cgi?id=922
Changes in V3
=
* Change CheckLowestSupportedVersion() to LowestSupportedVersionCheckRequired()
* Change LockFmpDeviceAtLockEventGuid() to
LockFmpDeviceAtLockEventGuidRequired()
* Set EDKII_FIRMWARE_MANAGEMENT_PROGRESS_PROTOCOL
From: "Kinney, Michael D"
https://bugzilla.tianocore.org/show_bug.cgi?id=922
Based on content from the following branch:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport/MsCapsuleUpdatePkg
Adds a DSC file that is used to verify that all of the
FmpDevicePkg libraries and
From: Liming Gao
V2:
add version,description,copyright.
add flag -v,-q,--append-extensions,--override-extensions,--debug.
-q will omit default output,-v and --debug are not implemented.
add default file extensions.
support input of file path.
support muliple input path.
simplify comment.
change
On 05/29/18 07:04, Liming Gao wrote:
> Fix VS warning C4244: 'function': conversion from 'UINT32' to 'UINT16',
> possible loss of data.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao
> Cc: Laszlo Ersek
> ---
>
Hi Liming,
On 05/29/18 07:25, Gao, Liming wrote:
> Laszlo:
> OvmfPkgIa32.fdf, OvmfPkgX64.fdf and OvmfPkgIa32X64.fdf are almost same. I
> suggest to use the single FDF for them. If so, this change is only made once.
>
> For X64 only module in FDF, we can use below style to include it.
>
>
Laszlo:
Yes. Combine FDF into single one can be done later.
Thanks
Liming
>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Tuesday, May 29, 2018 3:26 PM
>To: Gao, Liming ; edk2-devel-01 de...@lists.01.org>
>Cc: Justen, Jordan L ; Gary Lin ;
>Ard Biesheuvel
On 05/28/18 20:49, Laszlo Ersek wrote:
> Almost exactly two years after commit 2f7b34b20842f, we've grown out the
> 10MB DXEFV:
>
>> build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -b NOOPT -t GCC48 \
>> -D SMM_REQUIRE -D SECURE_BOOT_ENABLE -D TLS_ENABLE -D E1000_ENABLE \
>> -D
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Guo Mang
---
.../Include/Guid/PttPTPInstanceGuid.h | 25 +
Vlv2TbltDevicePkg/Include/Protocol/ExitPmAuth.h| 25 +
.../PlatformBootManagerLib/PlatformBootManager.c | 1070
On 28 May 2018 at 16:40, Ard Biesheuvel wrote:
> At the moment, FirmwarePerformanceTableDataDxe or DxeCorePerformanceLib
> are unusable on systems such as AMD Seattle, because they unconditionally
> attempt to allocate memory below 4 GB, and ASSERT() if this fails. On AMD
> Seattle, no 32-bit
On 25 May 2018 at 08:15, Michael D Kinney wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=801
>
> Based on content from:
>
> https://github.com/Microsoft/MS_UEFI/blob/share/MsCapsuleSupport/MsCapsuleUpdatePkg/Include/Library/DisplayUpdateProgressLib.h
>
On 29 May 2018 at 11:51, Ard Biesheuvel wrote:
> On 25 May 2018 at 08:15, Michael D Kinney wrote:
>> https://bugzilla.tianocore.org/show_bug.cgi?id=801
>>
>> Based on content from:
>>
>>
Hello Liming,
On 29 May 2018 at 15:05, Gao, Liming wrote:
> Do you try to find this one [edk2] [edk2-platforms Patch v4 0/6] Add
> DisplayUpdateProgressLib to platforms?
>
No, I am trying to locate the patch that actually invokes the new
PerformFlashWriteWithProgress() function when processing
Do you try to find this one [edk2] [edk2-platforms Patch v4 0/6] Add
DisplayUpdateProgressLib to platforms?
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Tuesday, May 29, 2018 8:43 PM
> To: Kinney, Michael D
> Cc:
Check the return value of HiiGetBrowserData() before calling
HiiSetBrowserData(). HiiGetBrowserData() failed to retrieve NV data during
action EFI_BROWSER_ACTION_RETRIEVE. If NV data is invalid, stop sending it to
form browser.
Contributed-under: TianoCore Contribution Agreement 1.1
On 29 May 2018 at 11:51, Ard Biesheuvel wrote:
> On 29 May 2018 at 11:51, Ard Biesheuvel wrote:
>> On 25 May 2018 at 08:15, Michael D Kinney wrote:
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=801
>>>
>>> Based on content from:
>>>
>>>
Ard,
I broke the series up into multiple series.
I can send out the 4th one this morning so
you can see the one that uses it. It is a
repeat of content that was shared in a single
series earlier. I deferred it so we can get
all the platform updates done first so there
are no build breaks.
> On May 28, 2018, at 10:17 PM, Abhishek Singh wrote:
>
> Thanks, Jiewen and Star. I was able to figure out that smrr was preventing me
> from accessing the contents of smram. It seems to me that this violates the
> EFI_MM_ACCESS_PROTOCOL protocol. I have talked to the edk2-platform
>
I am not sure the purpose of using Variable to store SMRAM.
But if you just want to know the content, you can allocate a normal DRAM
buffer, and just save the buffer address and length in the UEFI variable.
That will save much variable size.
Later, you can write a UEFI Shell app to read the
Jiewen,
I see what you mean. It is not the submitting of
capsules you are referring to. It is the processing
if capsules in the PEI phase that depends on some
things being setup in DXE phase and DXE phase needs
to know if PEI is in IA32 mode.
So I agree that the commit message could add
From: "Kinney, Michael D"
https://bugzilla.tianocore.org/show_bug.cgi?id=801
Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport
* Change Update_Image_Progress() to UpdateImageProcess()
* Call DisplayUpdateProgressLib from
https://bugzilla.tianocore.org/show_bug.cgi?id=801
Based on content from:
https://github.com/Microsoft/MS_UEFI/blob/share/MsCapsuleSupport/MsCapsuleUpdatePkg/Include/Library/DisplayUpdateProgressLib.h
From: "Kinney, Michael D"
https://bugzilla.tianocore.org/show_bug.cgi?id=801
Use PlatformFlashWriteWithProgress() instead of PlatformFLashWrite()
so the user can be informed of the progress as a capsule is used
to update a firmware image in a firmware device.
Cc: Jiewen Yao
Signed-off-by:
On 29 May 2018 at 18:09, Kinney, Michael D wrote:
> Jiewen,
>
> I see what you mean. It is not the submitting of
> capsules you are referring to. It is the processing
> if capsules in the PEI phase that depends on some
> things being setup in DXE phase and DXE phase needs
> to know if PEI is in
Thanks.
I guess we need it even for X64 PEI/X64 DXE case, because a platform may only
allocates 4G even in X64 PEI.
BTW, I don't mind if you want to use a separate patch to handle capsule case.
Current API is good enough and I do not want to block the check-in. :-)
I like this simple solution.
Maybe " be accessible by PEI after a warm reboot or S3" ?
We may want to consider Capsule Update case.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng,
> Star
> Sent: Monday, May 28, 2018 6:37 PM
> To: Ard Biesheuvel ;
Mike
Please refer to
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/CapsuleRuntimeDxe/X64/SaveLongModeContext.c
It uses AllocateReservedMemoryBelow4G() for the context accessed in PEI.
Thank you
Yao Jiewen
> -Original Message-
> From: Kinney, Michael D
> Sent:
30 matches
Mail list logo
