[edk2] [PATCH 5/10] OvmfPkg: Support format string argument checking

Support compile time argument consistency checking for functions that accept a PrintLib format string followed by a variable argument list. Macro 'EFIFORMAT' added to the function prototype accepts a single argument indicating which function argument holds the format string. The EFIFORMAT macro

[edk2] [PATCH 6/10] SecurityPkg: Support format string argument checking

Support compile time argument consistency checking for functions that accept a PrintLib format string followed by a variable argument list. Macro 'EFIFORMAT' added to the function prototype accepts a single argument indicating which function argument holds the format string. The EFIFORMAT macro

[edk2] [PATCH 7/10] ShellPkg: Support format string argument checking

Support compile time argument consistency checking for functions that accept a PrintLib format string followed by a variable argument list. Macro 'EFIFORMAT' added to the function prototype accepts a single argument indicating which function argument holds the format string. The EFIFORMAT macro

[edk2] [PATCH 8/10] SourceLevelDebugPkg: Support format string argument checking

Support compile time argument consistency checking for functions that accept a PrintLib format string followed by a variable argument list. Macro 'EFIFORMAT' added to the function prototype accepts a single argument indicating which function argument holds the format string. The EFIFORMAT macro

[edk2] [PATCH 9/10] UefiCpuPkg: Support format string argument checking

Support compile time argument consistency checking for functions that accept a PrintLib format string followed by a variable argument list. Macro 'EFIFORMAT' added to the function prototype accepts a single argument indicating which function argument holds the format string. The EFIFORMAT macro

[edk2] [PATCH 1/10] BaseTools: Add GCC patch for EDK2 format string argument checking

Add patch to extend GCC format string argument consistency checks to include the UEFI EDK2 PrintLib and ShellLib format strings. The patch adds GCC predefined compiler macro __GCC_EDK2_FORMATS__ for identification of the feature. EDK2 format string of type CHAR8[] and CHAR16[] can be checked.

[edk2] [PATCH 10/10] Vlv2TbltDevicePkg: Support format string argument checking

Support compile time argument consistency checking for functions that accept a PrintLib format string followed by a variable argument list. Macro 'EFIFORMAT' added to the function prototype accepts a single argument indicating which function argument holds the format string. The EFIFORMAT macro

Re: [edk2] [PATCH] BaseTools: Fix GCC49 build failure

On 7 August 2015 at 22:15, Scott Duplichan sc...@notabs.org wrote: Some gnu linkers used with GCC44, such as GNU ld 2.19.1, require a --defsym= command line option to precede the --script= option in order for the definition to be available for use by the script. Move the --defsym= command line

[edk2] [PATCH 2/5] ArmPlatformPkg/PlatformIntelBdsLib: fix error handling

In InitializeConsolePipe (), we clobber the Status variable in the error handling path that reports Status in its output. Instead, use a NULL check on the LocateProtocol () output argument. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel

[edk2] [PATCH 0/5] secure boot support for ARM FVP

This series adds support for using the Intel BDS with ArmVExpress-FVP, and for building it with UEFI Secure Boot enabled. Note that the former is a prerequisite of the latter, since the ARM BDS has no GUI for enrolling certificates and enabling secure boot. Patch #1 removes the

[edk2] [PATCH 5/5] ArmPlatformPkg/ArmVExpressPkg: enable UEFI Secure Boot

This allows the FVP target to be built with UEFI Secure Boot enabled, by passing -D SECURE_BOOT_ENABLE to the build command line. Note that you will need to disable the ARM BDS (-D USE_ARM_BDS=FALSE) or you will not be able to enroll certificates, since the ARM BDS does not provide a GUI to do so.

[edk2] [PATCH 1/5] ArmPlatformPkg/PlatformIntelBdsLib: remove ARM BDS dependency

The Intel BDS platform library still depends on the ARM BDS specific BdsLib. So replace its invocations with GenericBdsLib counterparts, and fix up where needed, so that we can drop the dependency. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel

[edk2] [PATCH 4/5] ArmPlatformPkg/ArmVExpressPkg: add support for the Intel BDS

This adds support for the Intel BDS, by introducing a define 'USE_ARM_BDS' which defaults to TRUE, and can be overridden on the build command line. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org ---

Re: [edk2] Question about memory reservation from PrePi to DXE

On Aug 8, 2015, at 8:12 AM, Laszlo Ersek ler...@redhat.com wrote: On 08/08/15 08:13, Benjamin Herrenschmidt wrote: Hi ! I'm still trying to get my head around the internals of EDK here so bear with me if there's an obvious answer that I missed ... :-) I'm trying to understand how I

Re: [edk2] Error on executing shell command ifconfig

Does anyone tested network(ping/tftp) using E1000/NIC PCI card on Juno board? Which LAN E1000 driver(source or any link) is used and tested for Intel NIC card? Thanks and Regards, Shaveta -Original Message- From: Leekha Shaveta-B20052 Sent: Friday, August 07, 2015 10:59 AM To: 'Ye,

Re: [edk2] Question about memory reservation from PrePi to DXE

On Sat, 2015-08-08 at 17:12 +0200, Laszlo Ersek wrote: What am I missing ? :-) I think you were missing the conceptual hierarchy between the GCD memory space map and the UEFI memory map, and which HOBs produced in PEI (resource vs. allocation), and which services called in DXE and later

Re: [edk2] Question about memory reservation from PrePi to DXE

On Sat, 2015-08-08 at 08:56 -0700, Andrew Fish wrote: If you really need to punch holes in the memory map, then you can use resource descriptors. Yes, I do need to punch holes in there, Laszlo explanation (which I haven't fully digested yet) implies that using allocation hobs should work which

Re: [edk2] Question about memory reservation from PrePi to DXE

On Sat, 2015-08-08 at 17:12 +0200, Laszlo Ersek wrote: If that's indeed your point, then maybe it will help to look at the call tree context in the DXE core, where this function -- CoreInitializeMemoryServices() -- is called from: DxeMain()