Reviewed-by: Ray Ni
> -Original Message-
> From: Gao, Zhichao
> Sent: Wednesday, June 26, 2019 1:32 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Laszlo
> Ersek ; Gao, Liming
> Subject: [PATCH v3] UefiCpuPkg/MpInitLib: MicrocodeDetect: Ensure
> checked range is valid
>
>
> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, June 19, 2019 1:51 PM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Laszlo Ersek
> Subject: [Patch 2/2] UefiCpuPkg/PiSmmCpuDxeSmm: Enable MM MP
> Protocol.
>
> Add MM Mp Protocol in PiSmmCpuDxeSmm driver.
>
> Cc: Ray Ni
> Cc:
Thanks Jiewen. I'll add it with a few code style corrections.
Anyone else has any comments?
Regards,
Jian
> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, June 25, 2019 10:09 PM
> To: Wang, Jian J ; devel@edk2.groups.io
> Cc: Zhang, Chao B ; Hernandez Beltran, Jorge
> ; Han,
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1934
0x0 MicrocodeBegin MicrocodeEntry MicrocodeEnd 0x
|--|---|---|---|
valid TotalSize
TotalSize is only valid between 0 and (MicrocodeEnd -
Some Linux servers do not have BC installed,so errors occur.
So the judgment was changed to avoid this error.
Cc: Bob Feng
Cc: Liming Gao
Signed-off-by: Zhiju.Fan
---
Change "\<" to "<" and add as two "[]"
edksetup.sh | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
From: Zhang, Chao B
Sent: Wednesday, June 26, 2019 9:59 AM
To: devel@edk2.groups.io; Gao, Liming ; Dong, Eric
; Gao, Zhichao
Cc: Ni, Ray ; Laszlo Ersek
Subject: RE: [edk2-devel] [PATCH V2] UefiCpuPkg/MpInitLib: MicrocodeDetect:
Ensure checked range is valid
Hi All:
Is that patch to fix
Reviewed-by : Chao Zhang
-Original Message-
From: Xu, Wei6
Sent: Tuesday, June 25, 2019 2:51 PM
To: devel@edk2.groups.io
Cc: Wang, Jian J ; Wu, Hao A ;
Zhang, Chao B
Subject: [edk2-devel][Patch] MdeModulePkg/CapsuleApp: Enhance Capsule-On-Disk
related functions.
BZ:
Series reviewed by : Chao Zhang
-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Xu, Wei6
Sent: Tuesday, June 25, 2019 2:54 PM
To: devel@edk2.groups.io
Cc: Wang, Jian J ; Wu, Hao A ;
Kinney, Michael D ; Gao, Liming
; Zhang, Chao B
Subject:
Shenglei:
See my comments.
Thanks
Liming
>-Original Message-
>From: Zhang, Shenglei
>Sent: Friday, June 21, 2019 9:27 AM
>To: devel@edk2.groups.io
>Cc: Feng, Bob C ; Gao, Liming
>Subject: [edk2-platform patch 6/6] Silicon\Tools: Add top level Makefile and
>GNUMakefile
>
>Add FitGen
Shenglei:
The patch is good to me. Reviewed-by: Liming Gao
Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Zhang, Shenglei
>Sent: Friday, June 21, 2019 9:27 AM
>To: devel@edk2.groups.io
>Cc: Feng, Bob C ; Gao, Liming
>Subject:
Hi All:
Is that patch to fix potential overflow in MicroCodeEntryPoint + TotalSize?
Is there a clearer way to check it? Like MAX_ADDRESS - TotalSize <=
MicroCodeEntryPoint.
And I suggest to add check before doing MicrroCodeEntryPoint + TotalSize.
From: devel@edk2.groups.io
> > @@ -170,6 +170,7 @@ MicrocodeDetect (
> > /// Check overflow and whether TotalSize is aligned with 4 bytes.
> > ///
> > if ( ((UINTN)MicrocodeEntryPoint + TotalSize) > MicrocodeEnd ||
> > + ((UINTN)MicrocodeEntryPoint + TotalSize) < (UINTN)
> > +
> -Original Message-
> From: Xu, Wei6
> Sent: Tuesday, June 25, 2019 2:54 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Kinney, Michael D; Gao, Liming; Zhang, Chao B
> Subject: [edk2-devel][Patch 0/6] Implement Capsule On Disk.
Not directly related with the series, this is
Hi Jason:
The behavior is defined in PFP spec v0.51 Chapter 8. 2 ACPI measuring
points don’t comply with PFP spec. All ACPI DATA for EV_POST_CODE must be
measured before fixup.
Tks for pointing it.
From: Yao, Jiewen
Sent: Wednesday, June 26, 2019 12:08 AM
To: devel@edk2.groups.io;
Zhichao:
One generic comment, the commit message doesn't need to include V1, V2. It is
just the change description.
Thanks
Liming
>-Original Message-
>From: Dong, Eric
>Sent: Wednesday, June 26, 2019 8:48 AM
>To: Gao, Zhichao ; devel@edk2.groups.io
>Cc: Ni, Ray ; Laszlo Ersek ; Gao,
HI Eric,
I think of the comments as blow:
Check overflow and whether TotalSize is aligned with 4 bytes. ==>
Check whether (MicrocodeEntryPoint + TotalSize) is in the microcode data range
and
whether TotalSize is aligned with 4 bytes.
This is the first check of the microcode data and TotalSize
Hi Jason
Would you mind to help us to file a Bugzilla - https://bugzilla.tianocore.org/
for tracking purpose?
Thank you
Yao Jiewen
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Yao,
Jiewen
Sent: Wednesday, June 26, 2019 12:08 AM
To: devel@edk2.groups.io;
Zhiju:
Please verify this script for
edk2-platforms\Platform\Intel\Vlv2TbltDevicePkg\PlatformSetupDxe directory with
-b and -u option. Seemly, the generated uni file is wrong.
And, please verify this tool -h option, its help message is not same to the
one in script.
Last on
Hi Zhichao,
Reviewed-by: Eric Dong
It's better to add some comments in the code to explain the change which make
the code easy to be understood.
Thanks,
Eric
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, June 25, 2019 11:16 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric
Reviewed-by: Liming Gao
>-Original Message-
>From: Fan, ZhijuX
>Sent: Friday, June 21, 2019 6:04 PM
>To: devel@edk2.groups.io
>Cc: Gao, Liming ; Feng, Bob C
>; Ard Biesheuvel ; Leif
>Lindholm ; Kinney, Michael D
>
>Subject: [edk2-platform patch 1/2 V2] Platform/Intel:Add GenBiosId into
> -Original Message-
> From: Albecki, Mateusz
> Sent: Tuesday, June 25, 2019 5:44 PM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz; Wu, Hao A
> Subject: [PATCH v2] MdeModulePkg/UfsPassThruDxe: Fix unaligned data
> transfer handling
>
> REF:
Reviewed-by: Ankit Sinha
-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Agyeman,
Prince
Sent: Friday, June 14, 2019 1:01 PM
To: devel@edk2.groups.io
Cc: Gao, Liming ; Wei, David Y ;
Kubacki, Michael A ; Desimone, Nathaniel L
; Chiu, Chasel
On 06/25/19 16:10, David Woodhouse wrote:
> On Tue, 2019-06-25 at 15:29 +0200, Laszlo Ersek wrote:
>> (2) You removed the NULL-initialization altogether,
>
> Well yeah, you told me the EDK-II coding standards forbid the common
> defensive coding technique used in the language called "C", of
>
Reviewed-by: Ashley DeSimone
-Original Message-
From: Desimone, Nathaniel L
Sent: Monday, June 24, 2019 11:30 PM
To: devel@edk2.groups.io
Cc: Desimone, Ashley E ; Pandya, Puja
Subject: [PATCH] [staging/EdkRepo-Manifest]: Initial commit of manifests for
EdkRepo
Cc: Ashley E DeSimone
Thanks Jason.
I think we should NOT measure TPM2 table *after* ACPI table patch.
The measurement should happen *before* ACPI table patch.
Hi Chao
Do you agree on that?
Thank you
Yao Jiewen
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
jason.spottsw...@hpe.com
Sent:
Tcg2Smm.c has a function "UpdateHID to create the ACPI HID for the TPM. This
function uses the TPM vendor ID combined with the firmware version number to
create the ACPI HID. The use of the TPM firmware version is not specified in
any spec from the TCG or otherwise that I have been able to
Jiewen:
Thanks
Liming
> -Original Message-
> From: Yao, Jiewen
> Sent: Tuesday, June 25, 2019 10:15 PM
> To: Gao, Liming ; devel@edk2.groups.io; Zhang, Shenglei
> ; ard.biesheu...@linaro.org;
> leif.lindh...@linaro.org
> Cc: Feng, Bob C
> Subject: RE: [edk2-devel] [edk2-platform patch
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1934
V1:
Originally, the checksum part would done before verfiy the microcode
data. Which meas the checksum would be done for a meaningless data.
It would cause a incorrect TotalSize (the size of microcode data),
then incorrect checksum and
I mean you need a PCI device with a UEFI driver that implements FMP to test
this. Our Solarflare driver currently does, so I can test this, I've sent two
of our NICs to Peter Jones @ RedHat (If you are interested, I can get you a
sample of our adapter along with drivers).
Once you have your
*Reminder:* TianoCore Design / Bug Triage - EMEA
*When:* Wednesday, 26 June 2019, 8:00am to 9:00am, (GMT-07:00) America/Los
Angeles
*Where:* https://zoom.us/j/695893389
View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=489077 )
*Organizer:* Stephano Cetola
On 6/24/19 9:13 PM, Laszlo Ersek wrote:
> Port the [LibraryClasses], [PcdsFixedAtBuild] and [Components] settings
> that are related to NETWORK_TLS_ENABLE from OvmfPkg to ArmVirtPkg.
> ArmVirtXen is not modified because it doesn't include the edk2 network
> stack.
>
> (This change is now simpler
Hi Tomas,
On 6/24/19 5:53 PM, Tomas Pilar (tpilar) wrote:
> Switching to this library enables capsule support for FMP devices.
> This will allow testing of FMP for PCI devices using OVMF and PCI
> passthrough as well as software parts of the FMP API.
>
> Simple tests show that a capsule with an
Thanks Liming.
I would treat that as *a general help request* to validate the BaseTool update
on ARM/AARCH64 Linux OS.
If we can have Ard or any other ARM person to help validate a new base tool
patch, that will be great.
In this case, it is about the new added FCE or FMMT.
In the future,
Sorry, I must have cherry-picked this commit without the changes I made after
v1 review and send it out as v2. It would explain why I still have those typos
and there is no reordering. V4 will have it fixed.
> -Original Message-
> From: Wu, Hao A
> Sent: Monday, June 24, 2019 10:15 AM
>
Replies inline
> -Original Message-
> From: Wu, Hao A
> Sent: Monday, June 24, 2019 10:46 AM
> To: Albecki, Mateusz ; devel@edk2.groups.io
> Subject: RE: [PATCH v3 2/2] MdeModulePkg/SdMmcHcDxe: Implement
> revision 3 of SdMmcOverrideProtocol
>
> > -Original Message-
> > From: Wu,
On Tue, 2019-06-25 at 15:29 +0200, Laszlo Ersek wrote:
> (2) You removed the NULL-initialization altogether,
Well yeah, you told me the EDK-II coding standards forbid the common
defensive coding technique used in the language called "C", of
initialising the variable where it's declared. I wasn't
Thanks Jian. Comment below:
1) My previous comment 8 is NOT addressed.
Please add assert for "StoredHashFvPpi->FvNumber".
if (!EFI_ERROR(Status) && StoredHashFvPpi != NULL &&
StoredHashFvPpi->FvNumber > 0) {
With that fixed, reviewed-by: jiewen@intel.com
Thank you
Yao Jiewen
>
Jiewen:
For FCE/FMMT C tools, I only compile them on X64 Linux OS. I don't compile
them on ARM or AARCH64 Linux OS for ARM native build. Now, edk2 BaseTools C
tools top level Makefile supports ARM, AARCH64, IA32 and X64. If they don't
pass build on ARM native Linux OS, this change will bring
Hi,
> -Original Message-
> From: Laszlo Ersek
> Sent: 25 June 2019 13:22
> To: Gary Lin ; Guillaume Gardet
>
> Cc: devel@edk2.groups.io; ard.biesheu...@linaro.org; Julien Grall
>
> Subject: Re: [edk2-devel] [PATCH] ArmVirtPkg: handle
> NETWORK_TLS_ENABLE in ArmVirtQemu*
>
> On
Please address the feedback from Leif.
With email address fixed, reviewed-by: jiewen@intel.com.
> -Original Message-
> From: Desai, Imran
> Sent: Tuesday, June 25, 2019 2:14 AM
> To: Yao, Jiewen ; Leif Lindholm
> ; devel@edk2.groups.io
> Cc: Zhang, Chao B ; Wang, Jian J
>
>
On 06/25/19 13:48, David Woodhouse wrote:
> Mostly, this is only necessary for devices that the CSM might have
> native support for, such as VirtIO and NVMe; PciBusDxe will already
> degrade devices to 32-bit if they have an OpROM.
>
> However, there doesn't seem to be a generic way of requesting
On 06/25/19 13:48, David Woodhouse wrote:
> I know, I said it was Someone Else's Problem. But it annoyed me.
>
> My initial thought was to look for VIRTIO_DEVICE_PROTOCOL on the same
> handle but I don't think I can do that if I can't rely on VirtIO being
> present in the build. This will do.
>
On 06/25/19 13:48, David Woodhouse wrote:
> No longer call all NVMe & VirtIO devices just "Harddisk". Admittedly,
> VirtIO disks are now just called 'Misc Device' instead, but at least
> that is now Someone Else's Problem™.
>
> Signed-off-by: David Woodhouse
> ---
>
On Tue, 2019-06-25 at 01:50 +0200, Laszlo Ersek wrote:
> (1) Side request -- can you please set the "xfuncname" knob so that the
> diff hunk headers (@@) reflect the section name being modified?
>
> It's explained at
>
I know, I said it was Someone Else's Problem. But it annoyed me.
My initial thought was to look for VIRTIO_DEVICE_PROTOCOL on the same
handle but I don't think I can do that if I can't rely on VirtIO being
present in the build. This will do.
Signed-off-by: David Woodhouse
---
This is hard-coded in the IntThunk structure, and the additional entries
will be needed for other devices like VirtIO and NVMe disks. So admit
that they exist.
Signed-off-by: David Woodhouse
Acked-by: Laszlo Ersek
---
OvmfPkg/Csm/LegacyBiosDxe/LegacyBios.c | 7 ---
1 file changed, 4
No longer call all NVMe & VirtIO devices just "Harddisk". Admittedly,
VirtIO disks are now just called 'Misc Device' instead, but at least
that is now Someone Else's Problem™.
Signed-off-by: David Woodhouse
---
OvmfPkg/Csm/LegacyBiosDxe/LegacyBbs.c | 47 -
Mostly, this is only necessary for devices that the CSM might have
native support for, such as VirtIO and NVMe; PciBusDxe will already
degrade devices to 32-bit if they have an OpROM.
However, there doesn't seem to be a generic way of requesting PciBusDxe
to downgrade specific devices.
There's
QemuVideoDxe installs its own legacy INT 10h handler for the benefit of
systems like Windows 2008r2 which attempt to use INT 10h even when booted
via EFI.
This interacts extremely badly with a CSM actually attempting to install
a real video BIOS.
The last thing done before invoking a legacy
Iterate over the available block devices in much the same way as
BdsLibEnumerateAllBootOption() does, but limiting to those devices
which are PCI-backed, which can be represented in the BbsTable.
One day we might need to extend the BbsTable to allow us to distinguish
between different NVMe
On Tue, 2019-06-25 at 09:56 +, Ni, Ray wrote:
> David,
> Thanks for pointing that patch.
>
> Now I understand it.
> Normally it's the CSM16 code that builds the boot descriptions for legacy
> boot options
> and LegacyBootManagerLib consumes that boot descriptions.
>
> But in your case,
On 06/25/19 10:50, Ard Biesheuvel wrote:
> On Mon, 24 Jun 2019 at 21:13, Laszlo Ersek wrote:
>>
>> Port the [LibraryClasses], [PcdsFixedAtBuild] and [Components] settings
>> that are related to NETWORK_TLS_ENABLE from OvmfPkg to ArmVirtPkg.
>> ArmVirtXen is not modified because it doesn't include
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1855
UniTool is one python script to generate UQI (Universal Question
Identifier) unicode string for HII question PROMPT string. UQI
string can be used to identify each HII question.
The scripts function will sync up UQI definitions with uni files
On 06/25/19 09:06, Ni, Ray wrote:
> Can you obtain the description from the NV storage?
No, nothing carries persistent (data-like) description for these
devices. IIUC we just want to reuse the description generator logic (=
code) from UefiBootManagerLib, with some customization.
Thanks
Laszlo
>
On 06/25/19 12:24, Laszlo Ersek wrote:
> if (Wrapper = NULL) {
> return EFI_OUT_OF_RESOURCES;
> }
Clearly, I meant "Wrapper == NULL" above :)
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#42805):
On 06/25/19 04:15, Dong, Eric wrote:
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Laszlo Ersek
>> Sent: Friday, June 21, 2019 12:45 AM
>> To: devel@edk2.groups.io; Dong, Eric
>> Cc: Ni, Ray
>> Subject: Re: [edk2-devel] [Patch 2/2]
David,
Thanks for pointing that patch.
Now I understand it.
Normally it's the CSM16 code that builds the boot descriptions for legacy boot
options
and LegacyBootManagerLib consumes that boot descriptions.
But in your case, LegacyBios driver builds the boot descriptions for VirtIo
devices and
Fixed the review comments from v1. Test info is the same as on v1. UFS
enumeration is passing and I can see LUs enumerated in efi shell.
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Albecki, Mateusz
> Sent: Tuesday, June 25, 2019 11:44 AM
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1341
Since UFS specification requirs the data buffer specified
in PRDT to be DWORD aligned in size we had a code in
UfsInitUtpPrdt that aligned the data buffer by rounding down
the buffer size to DWORD boundary. This meant that for SCSI
commands
On Tue, 2019-06-25 at 09:15 +, Ni, Ray wrote:
> But I still need to understand why the *GetBootOption() API is needed.
> Because for quite a long time since the MdeModulePkg/Bds was added, there is
> no
> such requirement.
It's for CSM, because otherwise all the legacy boot targets other
David,
That will cause confusion to caller of *GetBootOption().
Because two behaviors will be seen:
1. BdsDxe calls this API to get a platform customized name for a certain option.
2. Another module calls this API to get a "Misc" name for a certain option
because
it doesn't link to
Laszlo,
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Tuesday, June 25, 2019 3:54 AM
> To: Wang, Jian J ; devel@edk2.groups.io;
> dw...@infradead.org; Lu, XiaoyuX
> Cc: Ye, Ting ; Richard Levitte
> Subject: Re:
On Mon, 24 Jun 2019 at 21:13, Laszlo Ersek wrote:
>
> Port the [LibraryClasses], [PcdsFixedAtBuild] and [Components] settings
> that are related to NETWORK_TLS_ENABLE from OvmfPkg to ArmVirtPkg.
> ArmVirtXen is not modified because it doesn't include the edk2 network
> stack.
>
> (This change is
On Tue, 2019-06-25 at 08:06 +, Ni, Ray wrote:
> The *Register* API was invented to handle the situation that platform wants
> to have a special name for certain boot options.
> I think you can use that.
Except didn't I just agree to stop calling those registered handlers
from the exported
The *Register* API was invented to handle the situation that platform wants
to have a special name for certain boot options.
I think you can use that.
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of David
> Woodhouse
> Sent: Tuesday, June 25, 2019 3:40 PM
> To: Ni, Ray ;
Hello all,
For this RFC patch, so far it has received the below feedbacks:
* Ack tag from Laszlo:
https://edk2.groups.io/g/devel/message/42381
* Reviewed-by tag from Ray (PcAtChipsetPkg maintainer):
https://edk2.groups.io/g/devel/message/42793
* Linux Kernel soft hangs if 8259 PIC is not
Reviewed-by: Ray Ni
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#42793): https://edk2.groups.io/g/devel/message/42793
Mute This Topic: https://groups.io/mt/31806937/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe:
On Tue, 2019-06-25 at 02:00 +, Ni, Ray wrote:
> David,
> I am afraid it will cause issues when exposing
> EfiBootManagerGetBootDescription().
> If you check the implementation, this API visits
> mPlatformBootDescriptionHandlers.
> mPlatformBootDescriptionHandlers is modified by another
On Tue, 2019-06-25 at 01:44 +, Ni, Ray wrote:
> Can EfiBootManagerRegisterBootDescriptionHandler() be used to extend the
> support for VirtIO
> in PlatformBootManagerLib?
Potentially although those are handled differently and not prefixed
with "UEFI " (or "Legacy " after my patch
On Tue, 2019-06-25 at 00:08 +0200, Laszlo Ersek wrote:
> > But we could consider that a second step. If I make the LegacyBm code
> > just call the existing (but renamed) EfiBootManagerGetBootDescription()
> > then all the horrid special cases and the specification work that's
> > required to fix
The library DxeDeferImageLoadLib supports UID feature and
it is conflicted with the driver SecurityStubDxe. And the UID
feature is dropped. So DxeDeferImageLoadLib should be removed.
Cc: Zailiang Sun
Cc: Yi Qian
Signed-off-by: Shenglei Zhang
---
Can you obtain the description from the NV storage?
> -Original Message-
> From: David Woodhouse
> Sent: Tuesday, June 25, 2019 2:06 PM
> To: Laszlo Ersek ; devel@edk2.groups.io;
> jljus...@gmail.com; af...@apple.com; Paolo Bonzini
> Cc: Ni, Ray
> Subject: Re: [edk2-devel] [PATCH 1/2]
Reviewed-by: Jian J Wang
> -Original Message-
> From: Gao, Zhichao
> Sent: Monday, June 17, 2019 3:54 PM
> To: Ni, Ray ; devel@edk2.groups.io; Yao, Jiewen
> ; Zhang, Shenglei
> Cc: Bret Barkelew ; Zhang, Chao B
> ; Wang, Jian J ; Gao, Liming
> ; Sean Brogan ; Michael
> Turner ; Leif
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
This module provides PPI to load Capsule On Disk temp relocation file
from Root Directory file system, retrieve the capsules from the temp
file and create capsule hobs for these capsules.
Cc: Jian J
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, June 25, 2019 11:23 AM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star
> Subject: [PATCH] MdeModulePkg/CapsulePei: Add memory pointer check
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1935
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
If Capsule On Disk mode, call Capsule On Disk Load PPI to load
capsules. When it fails, still goes to Firmware Update boot path.
BDS will clear corresponding indicator and reboot later on.
Cc: Jian J
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
Set EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit of
"OsIndicationsSupported" variable to indicate the Capsule On
Disk is supported or not, according to PcdCapsuleOnDiskSupport.
Cc: Jian J
This patch set implements Capsule On Disk feature.
Please refer to the following wiki for the introduction of Capsule On Disk:
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-on-Disk-Introducation
Cc: Jian J Wang
Cc: Hao A Wu
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Chao B
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1840
1. Introduce an internal header file to put definitions in it.
2. Add missing '\n' in usage.
3. Fix the dead loop of CapsuleApp -L.
4. Fix the bug that CapsuleApp -OD cannot perform capsules in sub-
folder.
5. Optimize the handling for
Cc: Ashley E DeSimone
Cc: Puja Pandya
Signed-off-by: Nate DeSimone
---
CiIndex.xml | 7 ++
.../edkrepo-manifest-review-template.txt | 7 ++
Templates/edkrepo-review-template.txt | 7 ++
.../IntelMinPlatformManifest.xml | 86
80 matches
Mail list logo
