[edk2] Reconfiguring the PEI blob for the Overdrive1000 (AMD A1100)
Hi, I recently got an ARM64 SoftIron Overdrive 1000 box which uses AMD's Opteron A1100, and while it's nice having most of the platform firmware be open source, the part I'm missing is the PEI, which is implemented in a binary blob. Apparently that is generated via a tool called the AMD Firmware Development Kit, but I can't find any reference to it outside of the edk2. Is there any way a user outside of AMD can get the Firmware Development Kit, or somehow else reconfigure the PEI binary? I'm asking because some work I'm starting out on has changes for the PEI, and while I could use Qemu it would be nice to also develop on real hardware. Thanks. Rebecca ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3] BaseTools/GCC ARM/AARCH64: Force disable PIE
Reviewed-by: Liming Gao >-Original Message- >From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >Sent: Thursday, June 01, 2017 1:31 AM >To: dann frazier ; Gao, Liming ; >Zhu, Yonghong >Cc: edk2-devel@lists.01.org ; Leif Lindholm > >Subject: Re: [PATCH v3] BaseTools/GCC ARM/AARCH64: Force disable PIE > >On 31 May 2017 at 16:57, dann frazier wrote: >> v3: >> * Drop -static, no longer needed after: >> 00b00cc5 BaseTools/Scripts: discard .gnu.hash section in GCC builds >> v2: >> * Replace -no-pie w/ -static for compat with GCC 4.9 >> >> After Debian's toolchain switched to PIE by default, our edk2 builds began >> to fail to build (GCC49 w/ gcc 6.3). This patch fixes the build by forcing >> off PIE for both ARM and AARCH64 builds. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: dann frazier > >Hi Dan, > >This looks fine to me, although I only just spotted that ARM now uses >-fno-pie only, whereas AARCH64 uses -fno-pic -fno-pie. I'd prefer to >have the two aligned, but I can fix that up when committing. > >Liming, Yonghong: any objections? If not, I will go ahead and merge it >(with -fno-pic added for ARM as well) > >Thanks, >Ard. > > >> --- >> BaseTools/Conf/tools_def.template | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/BaseTools/Conf/tools_def.template >b/BaseTools/Conf/tools_def.template >> index 4b1b7b548c..f68c836bca 100755 >> --- a/BaseTools/Conf/tools_def.template >> +++ b/BaseTools/Conf/tools_def.template >> @@ -4339,9 +4339,9 @@ DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort- >wchar -fno-builtin -fno-stri >> DEFINE GCC_IA32_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -m32 - >malign-double -freorder-blocks -freorder-blocks-and-partition -O2 -mno- >stack-arg-probe >> DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red- >zone -Wno-address -mno-stack-arg-probe >> DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -minline-int- >divide-min-latency >> -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle- >endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections - >fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft >> +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle- >endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections - >fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft >-fno-pie >> DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access >> -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle- >endian -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections >-fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic >> +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle- >endian -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections >-fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic - >fno-pie >> DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align >> DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie >> DEFINE GCC_DLINK2_FLAGS_COMMON = -Wl,-- >script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds >> -- >> 2.11.0 >> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform
There may also be some PCI terminology differences. The EDK II implements the PI Specifications. Latest PI version: http://www.uefi.org/sites/default/files/resources/PI%201.5.zip Volume 5 - Chapter 10 PCI Host Bridge provides the terminology that is used for the EDK II implementation. Specifically, Section 10.4 provides a discussion of the following example PCI Architectures: * Desktop system with 1 PCI root bridge * Server system with 4 PCI root bridges * Server system with 2 PCI segments * Server system with 2 PCI host buses One additional element I have noticed, is the difference between a HW description of the platform's PCI subsystem, and the SW view of the platform's PCI subsystem. Mike -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Johnson, Brian (EXL - Eagan) Sent: Wednesday, May 31, 2017 8:02 AM To: Bill Paul ; edk2-de...@ml01.01.org Cc: edk2-de...@ml01.01.org; Vladimir Olovyannikov ; Ard Biesheuvel Subject: Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Bill Paul Sent: Tuesday, May 30, 2017 12:34 PM To: edk2-de...@ml01.01.org Cc: edk2-de...@ml01.01.org; Vladimir Olovyannikov ; Ard Biesheuvel Subject: Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform Of all the gin joints in all the towns in all the world, Vladimir Olovyannikov had to walk into mine at 09:49:16 on Tuesday 30 May 2017 and say: > > -Original Message- > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > Sent: May-30-17 9:35 AM > > To: Vladimir Olovyannikov > > Cc: edk2-devel@lists.01.org > > Subject: Re: Using a generic PciHostBridgeDxe driver for a > > multi-PCIe-domain platform > > > > On 30 May 2017 at 16:23, Vladimir Olovyannikov > > > > wrote: > > > Hi, > > > > > > I've started PCIe stack implementation design for an armv8 aarch64 > > > platform. > > > The platform's PCIe represents several host bridges, and each > > > hostbridge has one rootbridge. > > > They do not share any resources between each other. > > > Looking into the PciHostBridgeDxe implementation I can see that it > > > supports only one hostbridge, and there is a comment: > > > // Most systems in the world including complex servers have only > > > one Host Bridge. > > > > > > So in my case should I create my own PciHostBridgeDxe driver > > > supporting multiple hostbridges and do not use the Industry > > > standard > > > > driver? > > > > > I am very new to it, and will appreciate any help or idea. > > > > As far as I can tell, PciHostBridgeLib allows you to return an > > arbitrary number of PCI host bridges, each with their own segment > > number. I haven't tried it myself, but it is worth a try whether > > returning an array of all host bridges on your platform works as > > expected. > > Thank you Ard, > Right, but PciHostBridgeDxe seems to work with one hostbridge. > I am confused that > > // Make sure all root bridges share the same ResourceAssigned value > > The rootbridges are independent on the platform, and should not share > anything. Or am I missing anything? > Anyway, I will try to return multiple hostbridges in the PciHostBridgeLib. This may be an Intel-ism. Note that for PCIe, I typically refer to "host bridges" as root complexes. On PowerPC SoCs that I've worked with (e.g. Freescale/NXP MPC8548, P2020, P4080, T4240) there are often several root complexes. A typical board design may have several PCIe slots where each slot is connected to one root complex in the SoC. Each root complex is therefore the parent of a separate "segment" which has its own unique bus/dev/func space. Each root complex has its own bank of registers to control it, including a separate set of configuration space access registers. This means you can have multiple PCIe trees each with its own bus0/dev0/func0 root. There can therefore be several devices with the same bus/dev/func tuple, but which reside on separate segments. The ARMv8 board you're working with is probably set up the same way. I've only worked with ARM Cortex-A boards and those have all had just one PCIe root complex, but it stands to reason those that have multiple root complexes would follow the same pattern as the PPC devices. Intel systems can (and often do) also have multiple PCIe root complexes, however for the sake of backwards compatibility, they all end up sharing the same configuration space access registers (0xCF8/0xCFC or memory mapped extended config space) and share a single unified bus/dev/func tree. Note that the tree is not always contiguous. For example, I've seen one Intel board where there was a special PCIe device on bus 128. In the ACPI tables, there were two PCI "segments" described, the second of which corresponded to bus 128. There was no switch or bridge to connect bus 128 to the tree r
Re: [edk2] [staging/cadence-aarch64 PATCH]: CadencePkg: Add package for Cadence hardware IP support.
On 26 May 2017 at 13:43, Scott Telford wrote: > Add CadencePkg, which includes support for the Cadence Configurable > System Platform (CSP) with a single ARM Cortex-A53, NIC-400 and > GIC-500. Also include driver libraries for the Cadence PCIe Root Port > and Cadence UART. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Scott Telford Hi Scott, Could you please split this up? One patch per module/library/dsc+fdf etc? -- Ard. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3] BaseTools/GCC ARM/AARCH64: Force disable PIE
On 31 May 2017 at 16:57, dann frazier wrote: > v3: > * Drop -static, no longer needed after: > 00b00cc5 BaseTools/Scripts: discard .gnu.hash section in GCC builds > v2: > * Replace -no-pie w/ -static for compat with GCC 4.9 > > After Debian's toolchain switched to PIE by default, our edk2 builds began > to fail to build (GCC49 w/ gcc 6.3). This patch fixes the build by forcing > off PIE for both ARM and AARCH64 builds. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: dann frazier Hi Dan, This looks fine to me, although I only just spotted that ARM now uses -fno-pie only, whereas AARCH64 uses -fno-pic -fno-pie. I'd prefer to have the two aligned, but I can fix that up when committing. Liming, Yonghong: any objections? If not, I will go ahead and merge it (with -fno-pic added for ARM as well) Thanks, Ard. > --- > BaseTools/Conf/tools_def.template | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/BaseTools/Conf/tools_def.template > b/BaseTools/Conf/tools_def.template > index 4b1b7b548c..f68c836bca 100755 > --- a/BaseTools/Conf/tools_def.template > +++ b/BaseTools/Conf/tools_def.template > @@ -4339,9 +4339,9 @@ DEFINE GCC_ALL_CC_FLAGS= -g -Os > -fshort-wchar -fno-builtin -fno-stri > DEFINE GCC_IA32_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -m32 > -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 > -mno-stack-arg-probe > DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone > -Wno-address -mno-stack-arg-probe > DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) > -minline-int-divide-min-latency > -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian > -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections > -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft > +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian > -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections > -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft > -fno-pie > DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access > -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian > -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections > -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic > +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian > -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections > -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie > DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align > DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie > DEFINE GCC_DLINK2_FLAGS_COMMON = > -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds > -- > 2.11.0 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3] BaseTools/GCC ARM/AARCH64: Force disable PIE
v3: * Drop -static, no longer needed after: 00b00cc5 BaseTools/Scripts: discard .gnu.hash section in GCC builds v2: * Replace -no-pie w/ -static for compat with GCC 4.9 After Debian's toolchain switched to PIE by default, our edk2 builds began to fail to build (GCC49 w/ gcc 6.3). This patch fixes the build by forcing off PIE for both ARM and AARCH64 builds. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: dann frazier --- BaseTools/Conf/tools_def.template | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 4b1b7b548c..f68c836bca 100755 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -4339,9 +4339,9 @@ DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-builtin -fno-stri DEFINE GCC_IA32_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) -m32 -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 -mno-stack-arg-probe DEFINE GCC_X64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mno-red-zone -Wno-address -mno-stack-arg-probe DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -minline-int-divide-min-latency -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -mabi=aapcs -fno-short-enums -funsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft -fno-pie DEFINE GCC_ARM_CC_XIPFLAGS = -mno-unaligned-access -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mlittle-endian -fno-short-enums -fverbose-asm -funsigned-char -ffunction-sections -fdata-sections -Wno-address -fno-asynchronous-unwind-tables -fno-pic -fno-pie DEFINE GCC_AARCH64_CC_XIPFLAGS = -mstrict-align DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie DEFINE GCC_DLINK2_FLAGS_COMMON = -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Unmount and mount a mass storage from shell
Thanks Jaben, I will test this... Thanks a lot for the help... Regards, Keshava On Wed, May 31, 2017, 9:23 PM Carsey, Jaben wrote: > Keshava, > > After you remove and replug it, I think you need to do "connect -r" to > recursively reconnect drivers, then do the "map -r" to generate a new > mapping. > > Reconnecting drivers is standard user behavior after plug in a USB > device. It is not expected to happen automatically. > > -Jaben > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > GN Keshava > > Sent: Tuesday, May 30, 2017 8:35 PM > > To: Carsey, Jaben ; edk2-devel@lists.01.org > > Subject: Re: [edk2] Unmount and mount a mass storage from shell > > Importance: High > > > > Hi Jaben, > > > > Thanks a lot for your input. > > > > As I have mentioned in previous mail, I'm facing an issue now, that, If I > > reconnect my client device, the mass storage is not able to mount again > > automatically. > > Here is few more details. Expecting some help on this : > > > > I connect the the client device to UEFI host. I get the mass storage > > successfully. (device is listed as Mass storage in devices command) > > The client device also has serial CDC functionality (It is Linux CDC > > gadget, which will enumerate as both Mass storage (FAT32) and CDC serial > > com port). > > To use serial port, I have developed a custom serial driver. I use VID > PID > > of the device in this custom driver to bind the driver to the device. I > > load this driver, and I get serial port (It is listed in sermode command) > > Now I refresh the mapping using map -r. Still I get the mass storage of > > device, and I'm able to access it correctly. > > Now I disconnect the client from host (UEFI) by unplugging the device. > > When I connect the device again, I'm not able to get Mass storage if i > run > > map -r. But serial port will start to work fine again. > > > > If I run devices command, it is not shown as mass storage. but as linux > > gadget. > > Now if I use disconnect command, and followed by connect command to this > > device with mass storage driver, I'm able to mount the mass storage and > use > > it. > > The issue is present if I load my serial driver, which uses device's VID > > PID. If I unload this driver and do the unplug-plug, I'm able to get mass > > storage automatically.. > > > > What could be the issue? Is there any way to solve this? > > > > (sorry for long post, it's difficult to explain otherwise) > > > > Thanks again. > > Regards, > > Keshava > > > > On Tue, 30 May 2017 at 20:56 Carsey, Jaben > > wrote: > > > > > I think that you will always need to inform the UEFI Shell of the > change. > > > It is not designed to automatically do detection of > > added/removed/changed > > > devices. > > > > > > > > > > > > I think that your solution to use the code from mount makes the most > > sense. > > > > > > > > > > > > -Jaben > > > > > > > > > > > > *From:* GN Keshava [mailto:keshava...@gmail.com] > > > *Sent:* Thursday, May 25, 2017 11:02 PM > > > *To:* Carsey, Jaben ; edk2-devel@lists.01.org > > > *Subject:* Re: [edk2] Unmount and mount a mass storage from shell > > > *Importance:* High > > > > > > > > > > > > Hi Jaben, Thanks a lot for input. My necessity for unmount-mount is > that, > > > the USB client is a Linux storage gadget, which needs to be remounted > to > > > get the updated/new files created by Linux. Anyhow, now I'm doing this > > > programmatically by copying mount command code from older shell. :) > > > > > > > > > > > > One more issue is that, after Linux updates some file (on client side, > > > Linux will mount the same partition, save some file, and then umount > the > > > partition. Then if i remount the partition on Host side, when host is > > > windows, i will get updated files) I will manually remove and connect > the > > > cable (MS device), UEFI is not able to detect the MS itself. (This > issue > > > observed, regardless of remount. This issue is not there on windows 10 > > > host). > > > > > > Can you give some pointers on this? > > > > > > > > > > > > Thanks a lot, Jaben. > > > > > > > > > > > > Regards, > > > > > > Keshava > > > > > > > > > > > > On Thu, 25 May 2017 at 21:26 Carsey, Jaben > > wrote: > > > > > > You can "disconnect" the driver > > > You can do "map -d" to delete a mapping > > > > > > I am unsure what your goals are for mount/unmount > > > > > > -Jaben > > > > > > > -Original Message- > > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > Of > > > > GN Keshava > > > > Sent: Wednesday, May 24, 2017 10:59 PM > > > > To: edk2-devel@lists.01.org > > > > Subject: [edk2] Unmount and mount a mass storage from shell > > > > Importance: High > > > > > > > > How can I unmount and mount a mass storage fs from UEFI shell? > > > > > > > > In older EFI shells, I can do with "mount" command. But it just does > > > > "mapping" in newer shell. It doesn't actually remounting the device. > > > > > >
Re: [edk2] Unmount and mount a mass storage from shell
Keshava, After you remove and replug it, I think you need to do "connect -r" to recursively reconnect drivers, then do the "map -r" to generate a new mapping. Reconnecting drivers is standard user behavior after plug in a USB device. It is not expected to happen automatically. -Jaben > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > GN Keshava > Sent: Tuesday, May 30, 2017 8:35 PM > To: Carsey, Jaben ; edk2-devel@lists.01.org > Subject: Re: [edk2] Unmount and mount a mass storage from shell > Importance: High > > Hi Jaben, > > Thanks a lot for your input. > > As I have mentioned in previous mail, I'm facing an issue now, that, If I > reconnect my client device, the mass storage is not able to mount again > automatically. > Here is few more details. Expecting some help on this : > > I connect the the client device to UEFI host. I get the mass storage > successfully. (device is listed as Mass storage in devices command) > The client device also has serial CDC functionality (It is Linux CDC > gadget, which will enumerate as both Mass storage (FAT32) and CDC serial > com port). > To use serial port, I have developed a custom serial driver. I use VID PID > of the device in this custom driver to bind the driver to the device. I > load this driver, and I get serial port (It is listed in sermode command) > Now I refresh the mapping using map -r. Still I get the mass storage of > device, and I'm able to access it correctly. > Now I disconnect the client from host (UEFI) by unplugging the device. > When I connect the device again, I'm not able to get Mass storage if i run > map -r. But serial port will start to work fine again. > > If I run devices command, it is not shown as mass storage. but as linux > gadget. > Now if I use disconnect command, and followed by connect command to this > device with mass storage driver, I'm able to mount the mass storage and use > it. > The issue is present if I load my serial driver, which uses device's VID > PID. If I unload this driver and do the unplug-plug, I'm able to get mass > storage automatically.. > > What could be the issue? Is there any way to solve this? > > (sorry for long post, it's difficult to explain otherwise) > > Thanks again. > Regards, > Keshava > > On Tue, 30 May 2017 at 20:56 Carsey, Jaben > wrote: > > > I think that you will always need to inform the UEFI Shell of the change. > > It is not designed to automatically do detection of > added/removed/changed > > devices. > > > > > > > > I think that your solution to use the code from mount makes the most > sense. > > > > > > > > -Jaben > > > > > > > > *From:* GN Keshava [mailto:keshava...@gmail.com] > > *Sent:* Thursday, May 25, 2017 11:02 PM > > *To:* Carsey, Jaben ; edk2-devel@lists.01.org > > *Subject:* Re: [edk2] Unmount and mount a mass storage from shell > > *Importance:* High > > > > > > > > Hi Jaben, Thanks a lot for input. My necessity for unmount-mount is that, > > the USB client is a Linux storage gadget, which needs to be remounted to > > get the updated/new files created by Linux. Anyhow, now I'm doing this > > programmatically by copying mount command code from older shell. :) > > > > > > > > One more issue is that, after Linux updates some file (on client side, > > Linux will mount the same partition, save some file, and then umount the > > partition. Then if i remount the partition on Host side, when host is > > windows, i will get updated files) I will manually remove and connect the > > cable (MS device), UEFI is not able to detect the MS itself. (This issue > > observed, regardless of remount. This issue is not there on windows 10 > > host). > > > > Can you give some pointers on this? > > > > > > > > Thanks a lot, Jaben. > > > > > > > > Regards, > > > > Keshava > > > > > > > > On Thu, 25 May 2017 at 21:26 Carsey, Jaben > wrote: > > > > You can "disconnect" the driver > > You can do "map -d" to delete a mapping > > > > I am unsure what your goals are for mount/unmount > > > > -Jaben > > > > > -Original Message- > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > > GN Keshava > > > Sent: Wednesday, May 24, 2017 10:59 PM > > > To: edk2-devel@lists.01.org > > > Subject: [edk2] Unmount and mount a mass storage from shell > > > Importance: High > > > > > > How can I unmount and mount a mass storage fs from UEFI shell? > > > > > > In older EFI shells, I can do with "mount" command. But it just does > > > "mapping" in newer shell. It doesn't actually remounting the device. > > > > > > Please help. > > > > > > thanks > > > ___ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk
Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform
-Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Bill Paul Sent: Tuesday, May 30, 2017 12:34 PM To: edk2-de...@ml01.01.org Cc: edk2-de...@ml01.01.org; Vladimir Olovyannikov ; Ard Biesheuvel Subject: Re: [edk2] Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform Of all the gin joints in all the towns in all the world, Vladimir Olovyannikov had to walk into mine at 09:49:16 on Tuesday 30 May 2017 and say: > > -Original Message- > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > Sent: May-30-17 9:35 AM > > To: Vladimir Olovyannikov > > Cc: edk2-devel@lists.01.org > > Subject: Re: Using a generic PciHostBridgeDxe driver for a > > multi-PCIe-domain platform > > > > On 30 May 2017 at 16:23, Vladimir Olovyannikov > > > > wrote: > > > Hi, > > > > > > I've started PCIe stack implementation design for an armv8 aarch64 > > > platform. > > > The platform's PCIe represents several host bridges, and each > > > hostbridge has one rootbridge. > > > They do not share any resources between each other. > > > Looking into the PciHostBridgeDxe implementation I can see that it > > > supports only one hostbridge, and there is a comment: > > > // Most systems in the world including complex servers have only > > > one Host Bridge. > > > > > > So in my case should I create my own PciHostBridgeDxe driver > > > supporting multiple hostbridges and do not use the Industry > > > standard > > > > driver? > > > > > I am very new to it, and will appreciate any help or idea. > > > > As far as I can tell, PciHostBridgeLib allows you to return an > > arbitrary number of PCI host bridges, each with their own segment > > number. I haven't tried it myself, but it is worth a try whether > > returning an array of all host bridges on your platform works as > > expected. > > Thank you Ard, > Right, but PciHostBridgeDxe seems to work with one hostbridge. > I am confused that > > // Make sure all root bridges share the same ResourceAssigned value > > The rootbridges are independent on the platform, and should not share > anything. Or am I missing anything? > Anyway, I will try to return multiple hostbridges in the PciHostBridgeLib. This may be an Intel-ism. Note that for PCIe, I typically refer to "host bridges" as root complexes. On PowerPC SoCs that I've worked with (e.g. Freescale/NXP MPC8548, P2020, P4080, T4240) there are often several root complexes. A typical board design may have several PCIe slots where each slot is connected to one root complex in the SoC. Each root complex is therefore the parent of a separate "segment" which has its own unique bus/dev/func space. Each root complex has its own bank of registers to control it, including a separate set of configuration space access registers. This means you can have multiple PCIe trees each with its own bus0/dev0/func0 root. There can therefore be several devices with the same bus/dev/func tuple, but which reside on separate segments. The ARMv8 board you're working with is probably set up the same way. I've only worked with ARM Cortex-A boards and those have all had just one PCIe root complex, but it stands to reason those that have multiple root complexes would follow the same pattern as the PPC devices. Intel systems can (and often do) also have multiple PCIe root complexes, however for the sake of backwards compatibility, they all end up sharing the same configuration space access registers (0xCF8/0xCFC or memory mapped extended config space) and share a single unified bus/dev/func tree. Note that the tree is not always contiguous. For example, I've seen one Intel board where there was a special PCIe device on bus 128. In the ACPI tables, there were two PCI "segments" described, the second of which corresponded to bus 128. There was no switch or bridge to connect bus 128 to the tree rooted at bus0/dev0/func0, so it would not be possible to automatically discover it by just walking the bus0/dev0/func0 tree and all its branches: you needed to use the ACPI hint to know it was there. I have also seen cases like this with pre-PCIe systems. For example, I've seen a Dell server that had both 32-bit and 64-bit PCI buses, where the 64-bit bus was at bus 1, but was not directly bridged to bus 0 (the 32-bit bus). There was a reason for this: 64-bit PCIe buses are usually clocked at 66MHz, but will fall back to 33MHz if you connect a 32-bit PCI device to them (this is supported for backward compatibility). Reducing the bus clock reduces performance, so to avoid that it's necessary to keep the 32-bit and 64-bit buses separate and thus give each one its own host bridge. As with the previous example, all the devices shared the same bus/dev/func space, but the only way to learn about the other segment was to probe the ACPI tables. It sounds as if the UEFI PCI host bridge code may be biased towards the Intel PCI behavior, though I'm not sure to what
[edk2] [PATCH 2/2] MdeModulePkg/UsbBus: Correct debug message
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Star Zeng Cc: Hao A Wu --- MdeModulePkg/Bus/Usb/UsbBusDxe/UsbUtility.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbUtility.c b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbUtility.c index abce63d734..d168d19214 100644 --- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbUtility.c +++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbUtility.c @@ -1363,9 +1363,9 @@ UsbBusRecursivelyConnectWantedUsbIo ( // // Recursively connect the wanted Usb Io handle // - DEBUG ((EFI_D_INFO, "UsbConnectDriver: TPL before connect is %d\n", (UINT32)UsbGetCurrentTpl ())); + DEBUG ((EFI_D_INFO, "UsbBusRecursivelyConnectWantedUsbIo: TPL before connect is %d\n", (UINT32)UsbGetCurrentTpl ())); gBS->ConnectController (UsbIf->Handle, NULL, NULL, TRUE); - DEBUG ((EFI_D_INFO, "UsbConnectDriver: TPL after connect is %d\n", (UINT32)UsbGetCurrentTpl())); + DEBUG ((EFI_D_INFO, "UsbBusRecursivelyConnectWantedUsbIo: TPL after connect is %d\n", (UINT32)UsbGetCurrentTpl())); } } -- 2.12.2.windows.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/2] MdeModulePkg/UsbBus: Fix system hang when failed to uninstall UsbIo
When "reconnect -r" is typed in shell, UsbFreeInterface() is called
to uninstall the UsbIo and DevicePath. But When a UsbIo is opened
by a driver and that driver rejects to close the UsbIo in Stop(),
the uninstall doesn't succeed.
But UsbFreeInterface () frees the DevicePath memory without check
whether the uninstall succeeds.
It leads to the DXE core database contain a DevicePath instance but
that instance's memory is freed.
Assertion happens when someone calls InstallProtocol(DevicePath)
because the InstallProtocol() checks all DevicePath instance to
find whether the same one exits in database.
We haven't seen any USB device driver which rejects to close UsbIo
in Stop(), but it's very likely.
The patch removes IsManaged flag from USB_INTERFACE structure because
this flag cannot reflect the managing status of the USB interface.
When the USB BUS driver is started first time, it creates all UsbIo
instances but only call ConnectController() for those specified by
RemainingDevicePath. Later platform BDS may call ConnectController
for certain UsbIo instances, though some upper layer drivers are
started to mange the UsbIo instances, the IsManaged flag is still
FALSE because these drivers are not started by UsbBus driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Feng Tian
Cc: Star Zeng
Cc: Hao A Wu
---
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.h | 3 +-
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 87 +++--
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbUtility.c | 17 +++---
3 files changed, 27 insertions(+), 80 deletions(-)
diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.h
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.h
index 9ede83ab7e..e8a55c584c 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.h
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.h
@@ -2,7 +2,7 @@
Usb Bus Driver Binding and Bus IO Protocol.
-Copyright (c) 2004 - 2012, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 2017, Intel Corporation. All rights reserved.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -216,7 +216,6 @@ struct _USB_INTERFACE {
EFI_HANDLEHandle;
EFI_USB_IO_PROTOCOL UsbIo;
EFI_DEVICE_PATH_PROTOCOL *DevicePath;
- BOOLEAN IsManaged;
//
// Hub device special data
diff --git a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
index ea54d37c93..1514b63eb9 100644
--- a/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
+++ b/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c
@@ -2,7 +2,7 @@
Usb bus enumeration support.
-Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.
+Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -59,21 +59,9 @@ UsbFreeInterface (
IN USB_INTERFACE*UsbIf
)
{
- UsbCloseHostProtoByChild (UsbIf->Device->Bus, UsbIf->Handle);
-
- gBS->UninstallMultipleProtocolInterfaces (
- UsbIf->Handle,
- &gEfiDevicePathProtocolGuid,
- UsbIf->DevicePath,
- &gEfiUsbIoProtocolGuid,
- &UsbIf->UsbIo,
- NULL
- );
-
if (UsbIf->DevicePath != NULL) {
FreePool (UsbIf->DevicePath);
}
-
FreePool (UsbIf);
}
@@ -279,13 +267,12 @@ UsbConnectDriver (
// Only recursively wanted usb child device
//
if (UsbBusIsWantedUsbIO (UsbIf->Device->Bus, UsbIf)) {
- OldTpl= UsbGetCurrentTpl ();
+ OldTpl = UsbGetCurrentTpl ();
DEBUG ((EFI_D_INFO, "UsbConnectDriver: TPL before connect is %d, %p\n",
(UINT32)OldTpl, UsbIf->Handle));
gBS->RestoreTPL (TPL_CALLBACK);
- Status= gBS->ConnectController (UsbIf->Handle, NULL, NULL,
TRUE);
- UsbIf->IsManaged = (BOOLEAN)!EFI_ERROR (Status);
+ gBS->ConnectController (UsbIf->Handle, NULL, NULL, TRUE);
DEBUG ((EFI_D_INFO, "UsbConnectDriver: TPL after connect is %d\n",
(UINT32)UsbGetCurrentTpl()));
ASSERT (UsbGetCurrentTpl () == TPL_CALLBACK);
@@ -444,57 +431,6 @@ UsbSelectConfig (
return EFI_SUCCESS;
}
-
-/**
- Disconnect the USB interface with its driver.
-
- @param UsbIf The interface to disconnect driver from.
-
-**/
-EFI_STATUS
-UsbDisconnectDriver (
- IN USB_INTERFACE*UsbIf
- )
-{
- EFI_TPL OldTpl;
- EFI_STATUS Status;
-
- //
- // Release the hub if it's a hub controller, otherwise
- // disconnect the driver if it is managed by other drivers.
- //
- Status = EFI_SUCCESS;
- if (UsbIf->IsHub) {
-Status = UsbIf->HubApi->Release (UsbIf);
-
- } else if (UsbIf->IsManaged) {
-
[edk2] [PATCH 0/2] MdeModulePkg/UsbBus: Fix system hang when failed to uninstall UsbIo
Please refer to first patch for details. Patch 2/2 is to correct debug message to ease future debugging. Ruiyu Ni (2): MdeModulePkg/UsbBus: Fix system hang when failed to uninstall UsbIo MdeModulePkg/UsbBus: Correct debug message MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.h | 3 +- MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c | 87 +++-- MdeModulePkg/Bus/Usb/UsbBusDxe/UsbUtility.c | 17 +++--- 3 files changed, 27 insertions(+), 80 deletions(-) -- 2.12.2.windows.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-staging/BaseToolsOpt]: Add new branch BaseToolsOpt
On 05/31/17 06:57, Gao, Liming wrote: > Hi All, > I would like to add new branch BaseToolsOpt in edk2-staging for BaseTools > build performance optimization. Here is its Readme.MD. Please help review. > > Readme.MD: > This branch is used to optimize BaseTools build performance. It bases on edk2 > repo UDK2017 branch. > > The branch owner: > Gao, Liming > Zhu, Yonghong > > ## Feature Introduction > BaseTools supports more and more features. They will take more build time. To > reduce build overhead, some points have been > identified to be optimized. POC code will be added in this branch for > evaluation. > 1) Enable the multiple thread in GenFds phase. > 2) Support to merge multiple drivers into one. It should save the link time. > But, it doesn't save much in the multiple build. >Besides, this feature can save the image size when the image is not > compressed, such as PEI images. > 3) Reduce the extra copy actions in build process. > 4) Analyze cProfile data and enhance the parser logic. > https://bugzilla.tianocore.org/show_bug.cgi?id=42 > > ## Timeline > Target for 2017 Q3 > > ### NOTES > Most changes in this branch are BaseTools. To apply them, user needs to run > BaseTools > from sources. In Linux, BaseTools run from source. In Windows, BaseTools can > run from source. And, Reconfig option is also > required to apply new config settings in BaseTools\Conf. The step is like > below: > 1. enter into edk2 > 2. set PYTHON_HOME=C:\Python27 > 3. type edksetup.bat --nt32 Reconfig > 4. nmake -f BaseTools\Makefile > 5. type build command to build platform. This looks very valuable to me. Another spot where "build" spends quite a bit of time is the initial metadata parsing. Perhaps there are some gains to be made there. I guess the profile data referenced under point (4) above, and in BZ#42, will help analyze that step. Thanks! Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Copy bus scanning workaround from ARM Juno PCIe driver.
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: 30 May 2017 11:14 > To: Scott Telford > Cc: Leif Lindholm ; edk2-devel@lists.01.org de...@ml01.01.org>; Tian, Feng ; Zeng, Star > > Subject: Re: [edk2] [PATCH] Copy bus scanning workaround from ARM Juno > PCIe driver. > >> I'd still like to understand why this issue does not occur under > >> Linux, or if it does occur, if we need an ECAM quirk for Juno to work > >> around it. Reading up on the subject, in the PCI Express Base Specification 3.0, section 7.3.1 (Configuration Transaction Rules: Device Number) states "Non-ARI [Alternative Routing-ID Interpretation] Devices must respond to all Type 0 Configuration Read Requests, regardless of the Device Number specified in the Request", which I guess would explain what I'm seeing with the same device appearing at all possible device numbers when reading the VIDs, without the workaround present. In Linux's drivers/pci/probe.c, the functions pci_scan_slot() and only_one_child() will scan only device 0 function 0 if the parent bus is a PCIe root port or downstream port. See the comment for commit f07852d6442c46c50b59c7e2acc8a1b291f9ab6d: "We can then speed up the pci_scan_slot by skipping the scan of subsequent devfns for PCIe devices which are the direct children of Root Ports or Downstream Ports. These devices are only permitted to implement device 0, unless they are ARI devices, in which case they'll be scanned by the ARI code above." So it doesn't matter if they respond to all device numbers, because we know they're only allowed to have a device 0. However, PciLib.c:PciScanBus() in TianoCore will always scan for all possible devices. Looks like it should be behaving more like the Linux driver in the case of PCIe? Regards, Scott. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/Xhci: Remove TRB when canceling Async Int Transfer
Could you correct the indention in the code block below?
With that corrected, Reviewed-by: Star Zeng
+
+ //
+ // Device doesn't finish the IntTransfer until real data comes
+ // So the TRB should be removed as well.
+ //
+Status = XhcDequeueTrbFromEndpoint (Xhc, Urb);
+if (EFI_ERROR (Status)) {
+ DEBUG ((EFI_D_ERROR, "XhciDelAllAsyncIntTransfers:
XhcDequeueTrbFromEndpoint failed\n"));
+}
+
Thanks,
Star
-Original Message-
From: Ni, Ruiyu
Sent: Wednesday, May 31, 2017 11:04 AM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Zeng, Star
Subject: [PATCH] MdeModulePkg/Xhci: Remove TRB when canceling Async Int Transfer
Some USB devices don't report data periodically through Int Transfer. They
report data only when be asked. If the TRB is not removed from the XHCI HW,
when next time HOST asks data again, the data is reported but consumed by the
previous TRB, which results the HOST thinks data never comes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao A Wu
Cc: Star Zeng
---
MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
index 4bec76a85f..058e8f36ba 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
@@ -2,7 +2,7 @@
XHCI transfer scheduling routines.
-Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2011 - 2017, Intel Corporation. All rights reserved.
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
distribution. The full text of the license may be found at @@ -1319,6 +1319,7
@@ XhciDelAsyncIntTransfer (
LIST_ENTRY *Next;
URB *Urb;
EFI_USB_DATA_DIRECTION Direction;
+ EFI_STATUS Status;
Direction = ((EpNum & 0x80) != 0) ? EfiUsbDataIn : EfiUsbDataOut;
EpNum&= 0x0F;
@@ -1330,6 +1331,15 @@ XhciDelAsyncIntTransfer (
if ((Urb->Ep.BusAddr == BusAddr) &&
(Urb->Ep.EpAddr == EpNum) &&
(Urb->Ep.Direction == Direction)) {
+ //
+ // Device doesn't finish the IntTransfer until real data comes
+ // So the TRB should be removed as well.
+ //
+ Status = XhcDequeueTrbFromEndpoint (Xhc, Urb);
+ if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, "XhciDelAsyncIntTransfer:
XhcDequeueTrbFromEndpoint failed\n"));
+ }
+
RemoveEntryList (&Urb->UrbList);
FreePool (Urb->Data);
XhcFreeUrb (Xhc, Urb);
@@ -1354,9 +1364,20 @@ XhciDelAllAsyncIntTransfers (
LIST_ENTRY *Entry;
LIST_ENTRY *Next;
URB *Urb;
+ EFI_STATUS Status;
EFI_LIST_FOR_EACH_SAFE (Entry, Next, &Xhc->AsyncIntTransfers) {
Urb = EFI_LIST_CONTAINER (Entry, URB, UrbList);
+
+ //
+ // Device doesn't finish the IntTransfer until real data comes
+ // So the TRB should be removed as well.
+ //
+Status = XhcDequeueTrbFromEndpoint (Xhc, Urb);
+if (EFI_ERROR (Status)) {
+ DEBUG ((EFI_D_ERROR, "XhciDelAllAsyncIntTransfers:
XhcDequeueTrbFromEndpoint failed\n"));
+}
+
RemoveEntryList (&Urb->UrbList);
FreePool (Urb->Data);
XhcFreeUrb (Xhc, Urb);
--
2.12.2.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/2] Avoid reading undefined contents in PrintLib
Reviewed-by: Liming Gao > -Original Message- > From: Wu, Hao A > Sent: Wednesday, May 31, 2017 2:13 PM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A ; Yao, Jiewen ; Gao, > Liming ; Kinney, Michael D > > Subject: [PATCH v2 0/2] Avoid reading undefined contents in PrintLib > > V2 changes: > Refines the code logic to replace the 'if else' statments with the '? :' > operator. > > V1 history: > This series add logic to avoid reading content beyond a ASCII format > string. > > Cc: Jiewen Yao > Cc: Liming Gao > Cc: Michael Kinney > > Hao Wu (2): > MdePkg/BasePrintLib: Avoid reading content beyond the format string > MdeModulePkg/PrintLib: Avoid reading content beyond the format string > > MdeModulePkg/Library/DxePrintLibPrint2Protocol/PrintLib.c | 22 > ++-- > MdePkg/Library/BasePrintLib/PrintLibInternal.c| 16 +++--- > 2 files changed, 19 insertions(+), 19 deletions(-) > > -- > 2.12.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
