Re: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap
Yes that makes sense. I missed it since I have not tried to build the new Tcg2 drivers yet. Thanks, --Samer -Original Message- From: Yao, Jiewen [mailto:jiewen@intel.com] Sent: Tuesday, August 18, 2015 12:15 AM To: El-Haj-Mahmoud, Samer ; edk2-devel@lists.01.org Cc: Zhang, Chao B Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap Reviewed-by: Yao, Jiewen At same time, I suggest we move PcdTpm2HashMask to Dynamic section too, because now Tcg2Pei will set this PCD according to TPM2 device capability. If you agree, I will check in both. Thank you Yao Jiewen -Original Message- From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] Sent: Tuesday, August 18, 2015 12:29 PM To: Yao, Jiewen; edk2-devel@lists.01.org Cc: Zhang, Chao B; El-Haj-Mahmoud, Samer Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap Please see attached patch file. Can you help review it and check it in please? Thanks, --Samer -Original Message- From: Yao, Jiewen [mailto:jiewen@intel.com] Sent: Saturday, August 15, 2015 1:10 AM To: El-Haj-Mahmoud, Samer ; edk2-devel@lists.01.org Cc: Zhang, Chao B ; Yao, Jiewen Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap Sounds good to me. Thank you Yao Jiewen -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of El-Haj-Mahmoud, Samer Sent: Saturday, August 15, 2015 8:55 AM To: edk2-devel@lists.01.org Cc: El-Haj-Mahmoud, Samer; Zhang, Chao B Subject: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap PcdTcg2HashAlgorithmBitmap is declared in a section that allows it to be Fixed or PatchableAtBuild, but there is code that sets it. This breaks the build on some platforms. Changed it to be PcdsDynamic and PcdsDynamicEx only. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud System Firmware Architect HP Servers el...@hp.com T +1.281.514.5973 C +1.512.659.1523 Hewlett-Packard Company hp.com/go/proliant/uefi ___ 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
Re: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap
Reviewed-by: Yao, Jiewen At same time, I suggest we move PcdTpm2HashMask to Dynamic section too, because now Tcg2Pei will set this PCD according to TPM2 device capability. If you agree, I will check in both. Thank you Yao Jiewen -Original Message- From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] Sent: Tuesday, August 18, 2015 12:29 PM To: Yao, Jiewen; edk2-devel@lists.01.org Cc: Zhang, Chao B; El-Haj-Mahmoud, Samer Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap Please see attached patch file. Can you help review it and check it in please? Thanks, --Samer -Original Message- From: Yao, Jiewen [mailto:jiewen@intel.com] Sent: Saturday, August 15, 2015 1:10 AM To: El-Haj-Mahmoud, Samer ; edk2-devel@lists.01.org Cc: Zhang, Chao B ; Yao, Jiewen Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap Sounds good to me. Thank you Yao Jiewen -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of El-Haj-Mahmoud, Samer Sent: Saturday, August 15, 2015 8:55 AM To: edk2-devel@lists.01.org Cc: El-Haj-Mahmoud, Samer; Zhang, Chao B Subject: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap PcdTcg2HashAlgorithmBitmap is declared in a section that allows it to be Fixed or PatchableAtBuild, but there is code that sets it. This breaks the build on some platforms. Changed it to be PcdsDynamic and PcdsDynamicEx only. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud System Firmware Architect HP Servers el...@hp.com T +1.281.514.5973 C +1.512.659.1523 Hewlett-Packard Company hp.com/go/proliant/uefi ___ 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
Re: [edk2] [PATCH v2 16/16] OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules
On 18 August 2015 at 04:35, Gao, Liming wrote: > Ard: > I think this patch needs to update VS tool chain link flag to enable 4K for > DXE_RUNTIME modules, because Ovmf platform also supports VS tool chain. > Good point, thanks. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard > Biesheuvel > Sent: Monday, August 17, 2015 10:25 PM > To: edk2-devel@lists.01.org; Liu, Yingke D > Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel; Justen, Jordan L; > Gao, Liming; dw...@infradead.org > Subject: [edk2] [PATCH v2 16/16] OvmfPkg/X64: enable 4 KB alignment for > DXE_RUNTIME modules > > This enables 4 KB section alignment for DXE_RUNTIME modules, for ELF based > toolchains and for the UNIXGCC PE/COFF toolchain. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel > --- > OvmfPkg/OvmfPkgX64.dsc | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index > b72eaa92f82e..817c381f4913 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -48,6 +48,13 @@ [BuildOptions] >INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable !endif > > +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] > +!if $(TOOLCHAIN) == UNIXGCC > + GCC:*_*_X64_DLINK_FLAGS = --section-alignment 0x1000 --file-alignment > +0x1000 !else > + GCC:*_*_X64_DLINK_FLAGS = -z common-page-size=0x1000 !endif > + > > > # > # SKU Identification section - list of all SKU IDs supported by this > Platform. > -- > 1.9.1 > > ___ > 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
Re: [edk2] Help debugging PEIM on Minnowboard Max
Hi Feng, Now I understand the concept. I was expecting that PEIM would already be available for the Minnowboard Max. Is Usb in the PEI phase not supported in Minnowboard? >From my digging in the code today, it seems to enable the xhci controller, it's PCI BAR needs to be set and enabled for memory access. I found memory base addresses for some devices in Vlv2DeviceRefCodePkg\ValleyView2Soc\NorthCluster\Include\PlatformBaseAddress es.h but not for XHCI. From looking at the Atom E3800 datasheet, the xhci memory base doesn't have a fixed location so I believe I need to pick an unused range in the Low MMIO space to set as the xhci BAR. If you or someone else on the list can recommend a different platform that already supports xhci in the PEI phase to use as a development platform that might be a better option for me. Thank you again for your patience and prompt responses. Eric > -Original Message- > From: Tian, Feng [mailto:feng.t...@intel.com] > Sent: Sunday, August 16, 2015 10:20 PM > To: Eric Wittmayer; edk2-devel@lists.01.org > Cc: Tian, Feng > Subject: RE: [edk2] Help debugging PEIM on Minnowboard Max > > Do you look into the UsbController.h in MdeModulePkg/Include/Ppi > directory? > > typedef > EFI_STATUS > (EFIAPI *PEI_GET_USB_CONTROLLER)( > IN EFI_PEI_SERVICES**PeiServices, > IN PEI_USB_CONTROLLER_PPI *This, > IN UINT8 UsbControllerId, > OUT UINTN *ControllerType, > OUT UINTN *BaseAddress > ); > > You need write a PEIM to produce this PPI and implement the above > interface according to your platform setting. > > For how to write a PEIM module, you can refer to EDKII Module Writer's > Guide in edk2.sourceforge.net > > Thanks > Feng > > -Original Message- > From: Eric Wittmayer [mailto:e...@frescologic.com] > Sent: Monday, August 17, 2015 11:50 > To: Tian, Feng; edk2-devel@lists.01.org > Subject: RE: [edk2] Help debugging PEIM on Minnowboard Max > > Hi Feng, >I see now that XhciPei needs gPeiUsbControllerPpiGuid and creates > gPeiUsbHostControllerPpiGuid which UsbBusPei needs. > > I can't seem to figure out what creates gPeiUsbControllerPpiGuid? I see it > listed in the .dec file I'm using but that apparently isn't enough to > install the Ppi. What should be installing the gPeiUsbControllerPpiGuid? > > Thanks, > Eric > > > -Original Message- > > From: Tian, Feng [mailto:feng.t...@intel.com] > > Sent: Sunday, August 16, 2015 6:09 PM > > To: Eric Wittmayer; edk2-devel@lists.01.org > > Cc: Tian, Feng > > Subject: RE: [edk2] Help debugging PEIM on Minnowboard Max > > > > Eric, > > > > I must agree the naming of these usb pei related ppi guids are not > > good, which misleads you. > > > > There is no the chicken and egg problem. gPeiUsbHostControllerPpiGuid > > and gPeiUsbControllerPpiGuid are two different ppis. The former is > > consumed by UsbPei and the latter is consumed by XhciPei. You need > > write a pei module to produce PeiUsbControllerPpi (see > > MdeModulePkg/Include/Ppi for > > definitions) at first. > > > > Thanks > > Feng > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Eric Wittmayer > > Sent: Saturday, August 15, 2015 08:12 > > To: edk2-devel@lists.01.org > > Subject: [edk2] Help debugging PEIM on Minnowboard Max > > > > I'm writing a PEIM for a USB3 device but having trouble even getting > > the UsbBusPie and XhciPei modules to load during boot. > > > > I thought getting the existing Usb Peims to load would be a good first > step. > > I looked at the DEPEX for both of the above modules and tried removing > > "gEfiPeiBootInRecoveryModePpiGuid" but I didn't see them load. If I > > set both of their DEPEX == TRUE then I see some print statements that > > show they are at least trying to load but then I have a chicken and > > egg problem > in > > that UsbBusPie needs either gPeiUsbHostControllerPpiGuid or > > gPeiUsb2HostControllerPpiGuid which come from XhciPei. However, > > XhciPei needs gPeiUsbControllerPpiGuid which comes from UsbBusPei > > before it will install the gPeiUsb2HostControllerPpiGuid. The same > > cross dependency is shown in the DEPEX for these two modules. > > > > I feel like I'm missing something simple and fundamental and I'm > > hoping someone will point me in the right direction. > > > > Thanks, > > Eric W > > > > ___ > > 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
Re: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap
Please see attached patch file. Can you help review it and check it in please? Thanks, --Samer -Original Message- From: Yao, Jiewen [mailto:jiewen@intel.com] Sent: Saturday, August 15, 2015 1:10 AM To: El-Haj-Mahmoud, Samer ; edk2-devel@lists.01.org Cc: Zhang, Chao B ; Yao, Jiewen Subject: RE: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap Sounds good to me. Thank you Yao Jiewen -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of El-Haj-Mahmoud, Samer Sent: Saturday, August 15, 2015 8:55 AM To: edk2-devel@lists.01.org Cc: El-Haj-Mahmoud, Samer; Zhang, Chao B Subject: [edk2] [patch] SecurityPkg: Fixed build error due to FixedAtBuild PcdTcg2HashAlgorithmBitmap PcdTcg2HashAlgorithmBitmap is declared in a section that allows it to be Fixed or PatchableAtBuild, but there is code that sets it. This breaks the build on some platforms. Changed it to be PcdsDynamic and PcdsDynamicEx only. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud System Firmware Architect HP Servers el...@hp.com TÂ +1.281.514.5973 C +1.512.659.1523 Hewlett-Packard Company hp.com/go/proliant/uefi ___ 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
Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
OK
-Original Message-
From: Gao, Liming
Sent: Tuesday, August 18, 2015 10:48 AM
To: Yao, Jiewen; Michael Zimmermann; edk2-devel@lists.01.org
Subject: RE: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
Jiewen:
The updated message is useful. I suggest to change error level from
EFI_D_ERROR to EFI_D_INFO.
Thanks
Liming
-Original Message-
From: Yao, Jiewen
Sent: Tuesday, August 18, 2015 10:46 AM
To: Gao, Liming; Michael Zimmermann; edk2-devel@lists.01.org
Subject: RE: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
Hi
How about we update debug message like below:
Index: PropertiesTable.c
===
--- PropertiesTable.c (revision 18191)
+++ PropertiesTable.c (working copy)
@@ -1120,7 +1120,7 @@
SetPropertiesTableSectionAlignment (SectionAlignment);
if ((SectionAlignment & (EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT - 1)) !=
0) {
-DEBUG ((EFI_D_ERROR, " InsertImageRecord - Section
Alignment(0x%x) is not %dK \n",
+DEBUG ((EFI_D_ERROR, " UEFI2.5 PropertiesTable - Runtime Driver
Section Alignment(0x%x) is not %dK \n",
SectionAlignment, EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT >> 10));
PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN) ImageAddress);
if (PdbPointer != NULL) {
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
Liming
Sent: Tuesday, August 18, 2015 10:39 AM
To: Michael Zimmermann; edk2-devel@lists.01.org
Subject: Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
Hi,
This is a warning message that describes the runtime driver alignment is not
4K.
UEFI PropertiesTable table feature expects all runtime driver alignment is
4K. When DxeCore loads Runtime driver, it will check its alignment and report
such warning message if it doesn't meet with the alignment. If you want to
enable this feature, you need to make sure all runtime driver at 4K. If you
don't enable it, you can just ignore this message.
To configure runtime driver with 4K alignment, you can modify DSC file to add
the following section.
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
GCC: *_*_*_DLINK_FLAGS = -z common-page-size=0x1000
MSFT: *_*_*_DLINK_FLAGS = /ALIGN:4096
Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael
Zimmermann
Sent: Sunday, August 16, 2015 12:32 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
When booting(a new device I'm currently working on) I get these warnings:
InsertImageRecord - Section Alignment(0x20) is not 4K
the warning is raised by "MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c" and
when compiling using GCC from Linux, the SectionAlignment is set by
"BaseTools/Source/C/GenFw/Elf32Convert.c".
I checked the resulting binaries using "readpe" and indeed they have a
SectionAlignment of 0x20, while the precompiled binaries like Shell.efi have a
Alignment of 0x1000(4K).
So, is this a bug of my GCC compiler or of EDK2?
___
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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
Jiewen:
The updated message is useful. I suggest to change error level from
EFI_D_ERROR to EFI_D_INFO.
Thanks
Liming
-Original Message-
From: Yao, Jiewen
Sent: Tuesday, August 18, 2015 10:46 AM
To: Gao, Liming; Michael Zimmermann; edk2-devel@lists.01.org
Subject: RE: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
Hi
How about we update debug message like below:
Index: PropertiesTable.c
===
--- PropertiesTable.c (revision 18191)
+++ PropertiesTable.c (working copy)
@@ -1120,7 +1120,7 @@
SetPropertiesTableSectionAlignment (SectionAlignment);
if ((SectionAlignment & (EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT - 1)) !=
0) {
-DEBUG ((EFI_D_ERROR, " InsertImageRecord - Section
Alignment(0x%x) is not %dK \n",
+DEBUG ((EFI_D_ERROR, " UEFI2.5 PropertiesTable - Runtime Driver
Section Alignment(0x%x) is not %dK \n",
SectionAlignment, EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT >> 10));
PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN) ImageAddress);
if (PdbPointer != NULL) {
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
Liming
Sent: Tuesday, August 18, 2015 10:39 AM
To: Michael Zimmermann; edk2-devel@lists.01.org
Subject: Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
Hi,
This is a warning message that describes the runtime driver alignment is not
4K.
UEFI PropertiesTable table feature expects all runtime driver alignment is
4K. When DxeCore loads Runtime driver, it will check its alignment and report
such warning message if it doesn't meet with the alignment. If you want to
enable this feature, you need to make sure all runtime driver at 4K. If you
don't enable it, you can just ignore this message.
To configure runtime driver with 4K alignment, you can modify DSC file to add
the following section.
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
GCC: *_*_*_DLINK_FLAGS = -z common-page-size=0x1000
MSFT: *_*_*_DLINK_FLAGS = /ALIGN:4096
Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael
Zimmermann
Sent: Sunday, August 16, 2015 12:32 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
When booting(a new device I'm currently working on) I get these warnings:
InsertImageRecord - Section Alignment(0x20) is not 4K
the warning is raised by "MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c" and
when compiling using GCC from Linux, the SectionAlignment is set by
"BaseTools/Source/C/GenFw/Elf32Convert.c".
I checked the resulting binaries using "readpe" and indeed they have a
SectionAlignment of 0x20, while the precompiled binaries like Shell.efi have a
Alignment of 0x1000(4K).
So, is this a bug of my GCC compiler or of EDK2?
___
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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
Hi
How about we update debug message like below:
Index: PropertiesTable.c
===
--- PropertiesTable.c (revision 18191)
+++ PropertiesTable.c (working copy)
@@ -1120,7 +1120,7 @@
SetPropertiesTableSectionAlignment (SectionAlignment);
if ((SectionAlignment & (EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT - 1)) !=
0) {
-DEBUG ((EFI_D_ERROR, " InsertImageRecord - Section
Alignment(0x%x) is not %dK \n",
+DEBUG ((EFI_D_ERROR, " UEFI2.5 PropertiesTable - Runtime Driver
Section Alignment(0x%x) is not %dK \n",
SectionAlignment, EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT >> 10));
PdbPointer = PeCoffLoaderGetPdbPointer ((VOID*) (UINTN) ImageAddress);
if (PdbPointer != NULL) {
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
Liming
Sent: Tuesday, August 18, 2015 10:39 AM
To: Michael Zimmermann; edk2-devel@lists.01.org
Subject: Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
Hi,
This is a warning message that describes the runtime driver alignment is not
4K.
UEFI PropertiesTable table feature expects all runtime driver alignment is
4K. When DxeCore loads Runtime driver, it will check its alignment and report
such warning message if it doesn't meet with the alignment. If you want to
enable this feature, you need to make sure all runtime driver at 4K. If you
don't enable it, you can just ignore this message.
To configure runtime driver with 4K alignment, you can modify DSC file to add
the following section.
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
GCC: *_*_*_DLINK_FLAGS = -z common-page-size=0x1000
MSFT: *_*_*_DLINK_FLAGS = /ALIGN:4096
Thanks
Liming
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael
Zimmermann
Sent: Sunday, August 16, 2015 12:32 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
When booting(a new device I'm currently working on) I get these warnings:
InsertImageRecord - Section Alignment(0x20) is not 4K
the warning is raised by "MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c" and
when compiling using GCC from Linux, the SectionAlignment is set by
"BaseTools/Source/C/GenFw/Elf32Convert.c".
I checked the resulting binaries using "readpe" and indeed they have a
SectionAlignment of 0x20, while the precompiled binaries like Shell.efi have a
Alignment of 0x1000(4K).
So, is this a bug of my GCC compiler or of EDK2?
___
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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 6/8] OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API
Jordan,
Sorry I missed your previous questions. Let me try to answer all your questions
in this email.
Q1: Why merging Ex and non-Ex APIs? Providing Non-Ex APIs was to make simpler
functions available for blt operations.
Merging the Ex and non-EX APIs is to avoid the library APIs provide overlapped
functionalities. And it aligns to the interfaces defined in GOP protocol.
Q2: If removing BltConfigure, does that mean the library will have to check to
see if the mode is different? what's the benefit?
After removing BltConfigure(), the library will calculate the shift/mask every
time when doing the BLT operations. The benefit is to make the library
stateless so it doesn't contain any state information so it can be called from
different threads/CPUs.
For example strtok_r() is the stateless and reentrant version of strtok().
char *strtok(char *str, const char *delim);
char *strtok_r(char *str, const char *delim, char **saveptr);
Q3: What if we design a VideoModeSetLib?
GraphicsOutputDxe + null_VideoModeSetLib + BltLib -> current GraphicsOutputDxe
GraphicsOutputDxe + qemu_VideoModeSetLib + BltLib -> current QemuVideoDxe
Null_VideoModeSetLib only allows the video in the fixed mode supplied from PEI
HOB
Qemu_VideoModeSetLib allows the video in several modes for QEMU.
Is my understanding correct?
Do you have more usage scenarios about the VideoModeSetLib? For now I only see
two and only two, considering the design complexity introduced by
VideoModeSetLib, leave the QemuVideoDxe driver as is make people easier to
understand.
Thanks,
Ray
-Original Message-
From: Justen, Jordan L
Sent: Tuesday, August 18, 2015 1:18 AM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Laszlo Ersek
Subject: Re: [Patch 6/8] OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API
On 2015-08-17 06:45:27, Ruiyu Ni wrote:
> The BltConfigure() API caches the video frame buffer meta data which
> forbids the library to be implemented to support re-entry.
How does this help? GraphicsOutputDxe will set a mode, and then use
BltLib with that mode.
I already asked this, and I had some other questions:
http://article.gmane.org/gmane.comp.bios.edk2.devel/1209
-Jordan
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni
> Cc: Laszlo Ersek
> Cc: Jordan Justen
> ---
> .../Application/BltLibSample/BltLibSample.c| 129 +++---
> OptionRomPkg/Include/Library/BltLib.h | 151 +++---
> .../Library/FrameBufferBltLib/FrameBufferBltLib.c | 514
> +++--
> OptionRomPkg/Library/GopBltLib/GopBltLib.c | 289 ++--
> OvmfPkg/QemuVideoDxe/Gop.c | 13 +-
> 5 files changed, 576 insertions(+), 520 deletions(-)
>
> diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
> b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
> index 333b054..3c7e392 100644
> --- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
> +++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
>
> UINT64
> @@ -68,8 +69,8 @@ Rand32 (
>
> VOID
> TestFills (
> - UINT32 HorizontalResolution,
> - UINT32 VerticalResolution
> + IN VOID *FrameBuffer,
> + IN EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
>)
> {
>EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color;
> @@ -79,44 +80,45 @@ TestFills (
>UINTN W;
>UINTN H;
>
> - for (Loop = 0; Loop < 1; Loop++) {
> -W = HorizontalResolution - (Rand32 () % HorizontalResolution);
> -H = VerticalResolution - (Rand32 () % VerticalResolution);
> -if (W != HorizontalResolution) {
> - X = Rand32 () % (HorizontalResolution - W);
> + for (Loop = 0; Loop < 1000; Loop++) {
> +W = FrameBufferInfo->HorizontalResolution - (Rand32 () %
> FrameBufferInfo->HorizontalResolution);
> +H = FrameBufferInfo->VerticalResolution - (Rand32 () %
> FrameBufferInfo->VerticalResolution);
> +if (W != FrameBufferInfo->HorizontalResolution) {
> + X = Rand32 () % (FrameBufferInfo->HorizontalResolution - W);
> } else {
>X = 0;
> }
> -if (H != VerticalResolution) {
> - Y = Rand32 () % (VerticalResolution - H);
> +if (H != FrameBufferInfo->VerticalResolution) {
> + Y = Rand32 () % (FrameBufferInfo->VerticalResolution - H);
> } else {
>Y = 0;
> }
> *(UINT32*) (&Color) = Rand32 () & 0xff;
> -BltVideoFill (&Color, X, Y, W, H);
> +BltVideoFill (FrameBuffer, FrameBufferInfo, &Color, X, Y, W, H);
>}
> }
>
>
> VOID
> TestColor1 (
> - UINT32 HorizontalResolution,
> - UINT32 VerticalResolution
> + IN VOID *FrameBuffer,
> + IN EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
>)
> {
> - EFI_GRAPHICS_OU
Re: [edk2] Section Alignment of elf binaries compiled with GCC(Linux)
Hi, This is a warning message that describes the runtime driver alignment is not 4K. UEFI PropertiesTable table feature expects all runtime driver alignment is 4K. When DxeCore loads Runtime driver, it will check its alignment and report such warning message if it doesn't meet with the alignment. If you want to enable this feature, you need to make sure all runtime driver at 4K. If you don't enable it, you can just ignore this message. To configure runtime driver with 4K alignment, you can modify DSC file to add the following section. [BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] GCC: *_*_*_DLINK_FLAGS = -z common-page-size=0x1000 MSFT: *_*_*_DLINK_FLAGS = /ALIGN:4096 Thanks Liming -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael Zimmermann Sent: Sunday, August 16, 2015 12:32 PM To: edk2-devel@lists.01.org Subject: [edk2] Section Alignment of elf binaries compiled with GCC(Linux) When booting(a new device I'm currently working on) I get these warnings: InsertImageRecord - Section Alignment(0x20) is not 4K the warning is raised by "MdeModulePkg/Core/Dxe/Misc/PropertiesTable.c" and when compiling using GCC from Linux, the SectionAlignment is set by "BaseTools/Source/C/GenFw/Elf32Convert.c". I checked the resulting binaries using "readpe" and indeed they have a SectionAlignment of 0x20, while the precompiled binaries like Shell.efi have a Alignment of 0x1000(4K). So, is this a bug of my GCC compiler or of EDK2? ___ 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
Re: [edk2] [PATCH v2 16/16] OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules
Ard: I think this patch needs to update VS tool chain link flag to enable 4K for DXE_RUNTIME modules, because Ovmf platform also supports VS tool chain. Thanks Liming -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Monday, August 17, 2015 10:25 PM To: edk2-devel@lists.01.org; Liu, Yingke D Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel; Justen, Jordan L; Gao, Liming; dw...@infradead.org Subject: [edk2] [PATCH v2 16/16] OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules This enables 4 KB section alignment for DXE_RUNTIME modules, for ELF based toolchains and for the UNIXGCC PE/COFF toolchain. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- OvmfPkg/OvmfPkgX64.dsc | 7 +++ 1 file changed, 7 insertions(+) diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index b72eaa92f82e..817c381f4913 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -48,6 +48,13 @@ [BuildOptions] INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable !endif +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] +!if $(TOOLCHAIN) == UNIXGCC + GCC:*_*_X64_DLINK_FLAGS = --section-alignment 0x1000 --file-alignment +0x1000 !else + GCC:*_*_X64_DLINK_FLAGS = -z common-page-size=0x1000 !endif + # # SKU Identification section - list of all SKU IDs supported by this Platform. -- 1.9.1 ___ 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
Re: [edk2] [patch] Add restriction that HashFinal() must be after at least one HashUpdate().
It is good to me.
Reviewed-by: Chao Zhang
Thanks & Best regards
Chao Zhang
-Original Message-
From: Yao, Jiewen
Sent: Monday, August 17, 2015 3:51 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Zhang, Chao B
Subject: [patch] Add restriction that HashFinal() must be after at least one
HashUpdate().
Just follow UEFI spec.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen"
Cc: "Zhang, Chao B"
---
SecurityPkg/Hash2DxeCrypto/Driver.h | 1 +
SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/SecurityPkg/Hash2DxeCrypto/Driver.h
b/SecurityPkg/Hash2DxeCrypto/Driver.h
index 771aedc..a145858 100644
--- a/SecurityPkg/Hash2DxeCrypto/Driver.h
+++ b/SecurityPkg/Hash2DxeCrypto/Driver.h
@@ -57,6 +57,7 @@ typedef struct {
EFI_HASH2_PROTOCOL Hash2Protocol;
VOID *HashContext;
VOID *HashInfoContext;
+ BOOLEAN Updated;
} HASH2_INSTANCE_DATA;
#define HASH2_INSTANCE_DATA_FROM_THIS(a) \ diff --git
a/SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c
b/SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c
index 94057ab..ab34de7 100644
--- a/SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c
+++ b/SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c
@@ -500,6 +500,7 @@ BaseCrypto2HashInit (
//
Instance->HashContext = HashCtx;
Instance->HashInfoContext = HashInfo;
+ Instance->Updated = FALSE;
return EFI_SUCCESS;
}
@@ -551,6 +552,8 @@ BaseCrypto2HashUpdate (
return EFI_OUT_OF_RESOURCES;
}
+ Instance->Updated = TRUE;
+
return EFI_SUCCESS;
}
@@ -590,7 +593,8 @@ BaseCrypto2HashFinal (
// Consistency Check
//
Instance = HASH2_INSTANCE_DATA_FROM_THIS(This);
- if ((Instance->HashContext == NULL) || (Instance->HashInfoContext == NULL)) {
+ if ((Instance->HashContext == NULL) || (Instance->HashInfoContext == NULL) ||
+ (!Instance->Updated)) {
return EFI_NOT_READY;
}
HashInfo = Instance->HashInfoContext; @@ -604,6 +608,7 @@
BaseCrypto2HashFinal (
FreePool (HashCtx);
Instance->HashInfoContext = NULL;
Instance->HashContext = NULL;
+ Instance->Updated = FALSE;
if (!Ret) {
return EFI_OUT_OF_RESOURCES;
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [MinnowBoard] i2cdetect inconsistency/problem
Hi All, I have some problems and inconsistencies on i2c bus on my minnowBoard MAX. Two problems: 1. When I run "i2cdetect -l" on the same board with my yocto project build and then again with running Ubuntu 14.04.3 LTS I get different listing for i2c buses. 2. Even though I have no lures attached (so basic MinnowBoad MAX, "A2" with 0.81 or 0.82 firmware - same result), "i2cdetect -y N" (where N is different for yocto & Ubuntu) shows a number of i2c devices detected which I assume should not be there!? I have two questions: 1. Where does i2cdetect get the "i2c adapter" bus names? How can they be different with same firmware & hardware & linux kernel (between yocto & Ubuntu)? Is this from some firmware or OS config? 2. Why are all those i2c devices detected by BOTH yocto linux and Ubuntu!? Where do they come from? Is this due to some firmware or OS config? Below are the i2cdetect outputs from both my yocto and Ubuntu OS's (NOTE: both are using the linux 3.19 kernel): YOCTO: # uname -a Linux intel-corei7-64 3.19.5-yocto-standard #1 SMP PREEMPT Fri Aug 14 00:21:30 UTC 2015 x86_64 GNU/Linux #modprobe i2c-dev #i2cdetect -l i2c-0 i2c i915 gmbus ssc I2C adapter i2c-1 i2c i915 gmbus vga I2C adapter i2c-2 i2c i915 gmbus panelI2C adapter i2c-3 i2c i915 gmbus dpc I2C adapter i2c-4 i2c i915 gmbus dpb I2C adapter i2c-5 i2c i915 gmbus dpd I2C adapter i2c-6 i2c DPDDC-B I2C adapter #i2cdetect -y 4 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 -- -- -- -- -- -- 37 -- -- 3a -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- 4a 4b -- -- -- -- 50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- UBUNTU: # uname -a Linux tekmagic 3.19.0-26-generic #28~14.04.1-Ubuntu SMP Wed Aug 12 14:09:17 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux # modprobe i2c-dev # i2cdetect -l i2c-0 i2c Synopsys DesignWare I2C adapter I2C adapter i2c-1 i2c Synopsys DesignWare I2C adapter I2C adapter i2c-2 i2c i915 gmbus ssc I2C adapter i2c-3 i2c i915 gmbus vga I2C adapter i2c-4 i2c i915 gmbus panelI2C adapter i2c-5 i2c i915 gmbus dpc I2C adapter i2c-6 i2c i915 gmbus dpb I2C adapter i2c-7 i2c i915 gmbus dpd I2C adapter i2c-8 i2c DPDDC-B I2C adapter # i2cdetect -y 6 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 -- -- -- -- -- -- 37 -- -- 3a -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- 4a 4b -- -- -- -- 50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Thanks!! Gerard ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Emulator not spawning window, triggering breakpoint instead
Hi all, About a week or two ago I was able to start the emulator + shell (Fedora 22 64-bit host) using: $ sh EmulatorPkg/build.sh run However, after re-cloning the git repository today and trying the same process, a breakpoint is instead triggered somewhere in PeiCore (I believe). If I run "continue" from gdb twice, the application segfaults and exits. I tried looking through the commit history to see if anything changed, but I've been unable to find anything. Does anyone have suggestions on how I can get this going again? Full output below. Thanks, David >> sh EmulatorPkg/build.sh run Building from: /edk2 using prebuilt tools Reading symbols from /edk2/Build/Emulator/DEBUG_GCC49/X64/Host...done. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". EDK II UNIX Host Emulation Environment from http://www.tianocore.org/edk2/ BootMode 0x00 OS Emulator passing in 128 KB of temp RAM at 0x4000 to SEC FD loaded from ../FV/FV_RECOVERY.fd at 0x10200 contains SEC Core 0x1020003e0 Loading /edk2/Build/Emulator/DEBUG_GCC49/X64/EmulatorPkg/Sec/Sec/DEBUG/EmuSec.dll with entry point 0x1020003e0 SEC Has Started 0x1020052e0 Loading /edk2/Build/Emulator/DEBUG_GCC49/X64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll with entry point 0x1020052e0 Program received signal SIGTRAP, Trace/breakpoint trap. add symbol table from file "/edk2/Build/Emulator/DEBUG_GCC49/X64/EmulatorPkg/Sec/Sec/DEBUG/EmuSec.dll" at .text_addr = 0x1020003e0 add symbol table from file "/edk2/Build/Emulator/DEBUG_GCC49/X64/MdeModulePkg/Core/Pei/PeiMain/DEBUG/PeiCore.dll" at .text_addr = 0x1020052e0 CpuBreakpoint () at /edk2/MdePkg/Library/BaseLib/X64/GccInline.c:107 107 } (gdb) continue Continuing. 0x10202af00 Loading /edk2/Build/Emulator/DEBUG_GCC49/X64/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei/DEBUG/StatusCodeHandlerPei.dll with entry point 0x10202af00 Program received signal SIGTRAP, Trace/breakpoint trap. add symbol table from file "/edk2/Build/Emulator/DEBUG_GCC49/X64/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei/DEBUG/StatusCodeHandlerPei.dll" at .text_addr = 0x10202af00 CpuBreakpoint () at /edk2/MdePkg/Library/BaseLib/X64/GccInline.c:107 107 } (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x00010202b196 in StatusCodeHandlerPeiEntry (FileHandle=0x10202ac68, PeiServices=0x4000f878) at /edk2/MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.c:57 57 Status = RscHandlerPpi->Register (SerialStatusCodeReportWorker); (gdb) ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
See http://www.infradead.org/rpr.html X-SRS-Rewrite: SMTP reverse-path rewritten from by twosheds.infradead.org See http://www.infradead.org/rpr.html > On 2015-08-17 11:25:41, David Woodhouse wrote: >> On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote: >> > Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead? >> >> Not for testing LLP64, no. > > How/who is this helping? It was massively useful for testing the OpenSSL stuff I've been working on recently. It showed up a number of issues which would otherwise only occur a Windows build. >> > I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be >> > based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part >> > of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if >> > you count the comment in tools_def :) This is why I'd rather deprecate >> > it as a toolchain, and use the GCC4X toolchains instead. >> >> Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage >> is lost. > > Maybe MINGW49. But, please not before we figure out how to actually > deprecate toolchains. :) > > By 'figure out', I mean get to the point where we are okay with > actually deprecating toolchains. Deprecating toolchains is pointless until we can ditch the badly maintained 20th century crap that holds us back from using C99 code. Once we have the political will to say "here's a nickel, kid. Buy yourself a real compiler" and provide Windows-hosted GCC or LLVM based toolchains, there really is no point. -- dwmw2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] System is restarting instead of shut down when ResetSystem is called
Hi, I have an application that runs in DXE phase. It executes some code and then call ResetSystem() from RunTimeServices to shut down the system (consider that the OS has put the system in S4 state previously, and this app is being called right after system resumes from S4). The system goes down, however, after ~4 seconds, it restarts automatically. Trying to investigate this issue, I observed that it only happens when there is(are) some USB device(s) connected to the system (e.g., mouse, keyboard, pen-drive), and the system was returned from S4. In the case where there is(are) no USB device(s) connected, even if the system was returned from S4, the system shuts down and does not restart. Scenario 1: USB device(s) + resume from S4 = shut down and restart. Scenario 2: no USB device(s) + resume from S4 = shut down. Scenario 3: USB device(s) + resume from S5 = shut down. Scenario 4: no USB device(s) + resume from S5 = shut down. On Scenario 1, for instance, I think a USB device is waking up the system after it is turned off. Do you know why this issue happens and how to circumvent it? ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On 2015-08-17 11:25:41, David Woodhouse wrote: > On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote: > > Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead? > > Not for testing LLP64, no. How/who is this helping? > > I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be > > based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part > > of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if > > you count the comment in tools_def :) This is why I'd rather deprecate > > it as a toolchain, and use the GCC4X toolchains instead. > > Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage > is lost. Maybe MINGW49. But, please not before we figure out how to actually deprecate toolchains. :) By 'figure out', I mean get to the point where we are okay with actually deprecating toolchains. -Jordan ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On 17 August 2015 at 20:37, Scott Duplichan wrote: > Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] wrote: > > ]Sent: Monday, August 17, 2015 09:25 AM > ]To: edk2-de...@ml01.01.org; yingke.d@intel.com > ]Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel > ; jordan.l.jus...@intel.com; > ]liming@intel.com; dw...@infradead.org > ]Subject: [edk2] [PATCH v2 00/16] unify GCC command line options > ] > ]This got a bit out of hand after I noticed the ELFGCC and UNIXGCC > ]toolchains that needed some tlc as well. > ] > ]Anyway, this series aims to refactor the toolchains definitions for > ]UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC, > ]CYGGCC and CYGGCCxASL so that they share as much of the settings as > ]possible. Currently, there is very little coordination between these, > ]which means for instance that the 4 KB alignment feature is only supported > ]on GCC4x at the moment. > ] > ]The primary difference between these toolchains is that GCC4x and ELFGCC > ]are entirely ELF based, whereas the other are PE/COFF based (but only when > ]building for IA32 or X64) > ] > ]Note that this series does not remove any toolchains, nor should it result > ]in major changes in the command lines that are passed to the various tools. > ]However, things may be reordered, and (in case of ELFGCC), missing > functionality > ]such as increased section alignment has been added so there are some changes > ]there. > ] > ]Patch #1 is a patch from Scott that I am reposting, but updated to cover > ]AARCH64 as well. > ] > ]Patch #2 fixes a problem in the GenFv tool where it may access unallocated > ]memory while rebasing the FFS when using large section and file alignment. > ] > ]Patch #3 removes an unused DEFINE from tools_def > ] > ]Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to > ]all GCC versions. > ] > ]Patch #5 is the first big refactor patch that introduces PE and ELF variants > ]for some CC flags. > ] > ]Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above. > ] > ]Patch #7 fixes the issue mentioned by Bill where the underscore decoration > ]is erroneously applied on X64 as well. > ] > ]Patch #8 is the second refactor the introduces PE and ELF variants for the > ]various DLINK flags. > ] > ]Patch #9 changes the way the start of the .data section is set in > GccBase.lds. > ]This is needed since the linker will reorganize the internal layout of the > .data > ]section rather than update its start address to ensure all objects that it > ]contains meet their respective alignments, even if the start address is not > ]aligned to the max value of all inputs. > ] > ]Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The > latest > ]GenFw and linker script propagate the alignment automatically, i.e., if > objects > ]with such alignment requirement are present, GCC will set the ELF header > ]accordingly, and this value will be used for the PE/COFF section alignment > ]as well. > ] > ]Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed > above. > ] > ]Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the > ]redundant definitions. > ] > ]Patch #13 as #11 but for the linker. > ] > ]Patch #14 unifies the ASM flags for all archs. > ] > ]Patch #15 brings the remaining configuration options of ELFGCC in line with > ]the GCC4x series. > ] > ]Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section > alignment > ]for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support > ]the properties table memprotection feature. > ] > ]Changes since v1: > ]- added patch #9 to address the IA32 and X86 failures on 4.9 reported by > Scott > ]- don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott) > ]- improved wording of commit messages of various patches > ]- rebased onto latest upstream, which includes a fix related to the ARM 4.6 > ] issue mentioned above > ] > ]Branch can be found here > ]https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2 > ] > ]Ard Biesheuvel (15): > ] BaseTools/GenFv: use PE/COFF virtual section size if raw size is > ]larger > ] BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS > ] BaseTools GCC: merge warning flags for all GCC versions > ] BaseTools GCC: refactor tools_def internal GCC defines for CC flags > ] BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC > ] BaseTools GCC: use leading underscore for symbol names where > ]appropriate > ] BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK > ] BaseTools GCC: don't set .data address explicitly > ] BaseTools GCC: remove GCC 4.9 specific linker alignment override > ] BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based > ]GCC > ] BaseTools GCC: unify ARM and AARCH64 GCC compiler flags > ] BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions > ] BaseTools GC
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On 2015-08-17 11:25:56, Ard Biesheuvel wrote: > On 17 August 2015 at 20:22, Jordan Justen wrote: > > Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead? > > > > I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be > > based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part > > of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if > > you count the comment in tools_def :) This is why I'd rather deprecate > > it as a toolchain, and use the GCC4X toolchains instead. > > > > No, you can't really. > > MinGW generates PE/COFF not ELF, so much of the linker command line is > different, and it really deserves a toolchain of its own Why does it deserve a toolchain of its own if the other toolchain produces better code? Why should EDK II care about using the different linker path if it isn't the best recommended way to build images? > Making version 4.3.0 part of the definition of UNIXGCC sounds awkward > to me. In fact, the idea of supporting all toolchains into eternity > sounds awkward, and it is obviously not working, since many are > deprecated and don't work at all or only partially. It would be much > better imo to allow a definition like UNIXGCC to evolve with the state > of the art I mostly agree, but I would rather see us add new toolchains and deprecate the old ones rather than evolving the requirements for a particular toolchain. I think the name UNIXGCC is too generic and too short sighted. It made sense at the time, but I don't think we should keep moving it forward and turn it into a moving target. The MYTOOLS toolchain was what you are describing, but for MSVC. It looks like it is stuck at VS2008 though. Anyway, I guess we should also deprecate MYTOOLS. :) -Jordan ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
Of all the gin joints in all the towns in all the world, Jordan Justen had to walk into mine at 11:22:15 on Monday 17 August 2015 and say: > On 2015-08-17 11:10:57, Bill Paul wrote: > > Of all the gin joints in all the towns in all the world, David Woodhouse > > had > > > > to walk into mine at 11:00:23 on Monday 17 August 2015 and say: > > > On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote: > > > > UNIXGCC and CYGGCC are GCC 4.3 & mingw based. Did this get tested? > > > > > > > > I think ELFGCC is unused at this point. (And has been since UnixPkg > > > > was deprecated.) > > > > > > > > I think we should deprecate all three of these toolchains. I would > > > > like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll > > > > add Larry to this email, because I think he disagrees with > > > > deprecating > > > > toolchains... > > > > > > > > If you make these changes and it breaks those toolchains, I don't > > > > think we would be able to notice, because I don't think we test them > > > > in our build pool anymore. To me this is all the more reason to move > > > > them out of tools_def.template. > > > > > > I was building with UNIXGCC last week, to test LLP64 builds without the > > > pain of actually having to deal with Windows. > > > > > > I'd rather see it updated to work with modern MinGW rather than > > > deprecated. > > > > I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc- > > build.py. Yes, I know the existing version of the script uses GCC 4.3.0. > > That's why I made an updated version that uses 4.9.3: > > > > http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py > > > > I know you don't want to support this script, that's why I did the work > > for you. :) Yes I've tested both IA32 and X64 builds. Yes they work > > fine. > > > > There is value in being able to bootstrap your own cross-build toolchain > > on whatever platform. I don't think you should be so quick to remove it. > > Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead? I could, but there's not really much point. UEFI uses PE/COFF as its object format, right? Using an ELF-based GCC means that you have to add a extra conversion step during the build process in order to go from ELF to PE/COFF. The rationale for doing it that way is: "A lot of *NIX systems already have ELF-based system compilers installed, we might as well use them." I understand the usefulness of this approach. However, if I'm going to be bootstrapping my own cross-build tools from scratch, that rationale no longer applies: if I have the option of selecting a target that gets me PE/COFF objects directly, I might as well do that. > I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be > based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part > of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if > you count the comment in tools_def :) This is why I'd rather deprecate > it as a toolchain, and use the GCC4X toolchains instead. I don't think this reasoning is valid. It doesn't seem fair to say that just because the UNIXGCC target was originally set up to use GCC 4.3.0, you can never upgrade it to a newer version. Technically, GCC 4.3.0 is buggy if you consider that it gets the underscore decoration convention wrong for X64. I would argue that it makes sense to fix this, since if the intent was to produce a cross-build toolchain that emulates the Microsoft toolchain behavior, it's not actually doing that now. It hasn't been left like that because people wanted it that way: it was left like that because until now nobody cared enough to fix it. -Bill > -Jordan > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel -- = -Bill Paul(510) 749-2329 | Senior Member of Technical Staff, wp...@windriver.com | Master of Unix-Fu - Wind River Systems = "I put a dollar in a change machine. Nothing changed." - George Carlin = ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] wrote: ]Sent: Monday, August 17, 2015 09:25 AM ]To: edk2-de...@ml01.01.org; yingke.d@intel.com ]Cc: wp...@windriver.com; sc...@notabs.org; Ard Biesheuvel ; jordan.l.jus...@intel.com; ]liming@intel.com; dw...@infradead.org ]Subject: [edk2] [PATCH v2 00/16] unify GCC command line options ] ]This got a bit out of hand after I noticed the ELFGCC and UNIXGCC ]toolchains that needed some tlc as well. ] ]Anyway, this series aims to refactor the toolchains definitions for ]UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC, ]CYGGCC and CYGGCCxASL so that they share as much of the settings as ]possible. Currently, there is very little coordination between these, ]which means for instance that the 4 KB alignment feature is only supported ]on GCC4x at the moment. ] ]The primary difference between these toolchains is that GCC4x and ELFGCC ]are entirely ELF based, whereas the other are PE/COFF based (but only when ]building for IA32 or X64) ] ]Note that this series does not remove any toolchains, nor should it result ]in major changes in the command lines that are passed to the various tools. ]However, things may be reordered, and (in case of ELFGCC), missing functionality ]such as increased section alignment has been added so there are some changes ]there. ] ]Patch #1 is a patch from Scott that I am reposting, but updated to cover ]AARCH64 as well. ] ]Patch #2 fixes a problem in the GenFv tool where it may access unallocated ]memory while rebasing the FFS when using large section and file alignment. ] ]Patch #3 removes an unused DEFINE from tools_def ] ]Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to ]all GCC versions. ] ]Patch #5 is the first big refactor patch that introduces PE and ELF variants ]for some CC flags. ] ]Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above. ] ]Patch #7 fixes the issue mentioned by Bill where the underscore decoration ]is erroneously applied on X64 as well. ] ]Patch #8 is the second refactor the introduces PE and ELF variants for the ]various DLINK flags. ] ]Patch #9 changes the way the start of the .data section is set in GccBase.lds. ]This is needed since the linker will reorganize the internal layout of the .data ]section rather than update its start address to ensure all objects that it ]contains meet their respective alignments, even if the start address is not ]aligned to the max value of all inputs. ] ]Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The latest ]GenFw and linker script propagate the alignment automatically, i.e., if objects ]with such alignment requirement are present, GCC will set the ELF header ]accordingly, and this value will be used for the PE/COFF section alignment ]as well. ] ]Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed above. ] ]Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the ]redundant definitions. ] ]Patch #13 as #11 but for the linker. ] ]Patch #14 unifies the ASM flags for all archs. ] ]Patch #15 brings the remaining configuration options of ELFGCC in line with ]the GCC4x series. ] ]Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section alignment ]for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support ]the properties table memprotection feature. ] ]Changes since v1: ]- added patch #9 to address the IA32 and X86 failures on 4.9 reported by Scott ]- don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott) ]- improved wording of commit messages of various patches ]- rebased onto latest upstream, which includes a fix related to the ARM 4.6 ] issue mentioned above ] ]Branch can be found here ]https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2 ] ]Ard Biesheuvel (15): ] BaseTools/GenFv: use PE/COFF virtual section size if raw size is ]larger ] BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS ] BaseTools GCC: merge warning flags for all GCC versions ] BaseTools GCC: refactor tools_def internal GCC defines for CC flags ] BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC ] BaseTools GCC: use leading underscore for symbol names where ]appropriate ] BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK ] BaseTools GCC: don't set .data address explicitly ] BaseTools GCC: remove GCC 4.9 specific linker alignment override ] BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based ]GCC ] BaseTools GCC: unify ARM and AARCH64 GCC compiler flags ] BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions ] BaseTools GCC: unify ASM flags for all GCC versions ] BaseTools GCC: align ELFGCC with GCC4x toolchains ] OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules ] ]Scott Duplichan (1): ] BaseTools GCC: Fix GCC49 build failure ] ] BaseTools/Conf/tools_def.template | 412 -
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On 17 August 2015 at 20:22, Jordan Justen wrote: > On 2015-08-17 11:10:57, Bill Paul wrote: >> Of all the gin joints in all the towns in all the world, David Woodhouse had >> to walk into mine at 11:00:23 on Monday 17 August 2015 and say: >> >> > On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote: >> > > UNIXGCC and CYGGCC are GCC 4.3 & mingw based. Did this get tested? >> > > >> > > I think ELFGCC is unused at this point. (And has been since UnixPkg >> > > was deprecated.) >> > > >> > > I think we should deprecate all three of these toolchains. I would >> > > like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll >> > > add Larry to this email, because I think he disagrees with >> > > deprecating >> > > toolchains... >> > > >> > > If you make these changes and it breaks those toolchains, I don't >> > > think we would be able to notice, because I don't think we test them >> > > in our build pool anymore. To me this is all the more reason to move >> > > them out of tools_def.template. >> > >> > I was building with UNIXGCC last week, to test LLP64 builds without the >> > pain of actually having to deal with Windows. >> > >> > I'd rather see it updated to work with modern MinGW rather than >> > deprecated. >> >> I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc- >> build.py. Yes, I know the existing version of the script uses GCC 4.3.0. >> That's why I made an updated version that uses 4.9.3: >> >> http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py >> >> I know you don't want to support this script, that's why I did the work for >> you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine. >> >> There is value in being able to bootstrap your own cross-build toolchain on >> whatever platform. I don't think you should be so quick to remove it. > > Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead? > > I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be > based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part > of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if > you count the comment in tools_def :) This is why I'd rather deprecate > it as a toolchain, and use the GCC4X toolchains instead. > No, you can't really. MinGW generates PE/COFF not ELF, so much of the linker command line is different, and it really deserves a toolchain of its own Making version 4.3.0 part of the definition of UNIXGCC sounds awkward to me. In fact, the idea of supporting all toolchains into eternity sounds awkward, and it is obviously not working, since many are deprecated and don't work at all or only partially. It would be much better imo to allow a definition like UNIXGCC to evolve with the state of the art ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On Mon, 2015-08-17 at 11:22 -0700, Jordan Justen wrote: > Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead? Not for testing LLP64, no. > I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be > based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part > of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if > you count the comment in tools_def :) This is why I'd rather deprecate > it as a toolchain, and use the GCC4X toolchains instead. Or kill UNIXGCC and replace it with MINGWGCC so the historical baggage is lost. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On 2015-08-17 11:10:57, Bill Paul wrote: > Of all the gin joints in all the towns in all the world, David Woodhouse had > to walk into mine at 11:00:23 on Monday 17 August 2015 and say: > > > On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote: > > > UNIXGCC and CYGGCC are GCC 4.3 & mingw based. Did this get tested? > > > > > > I think ELFGCC is unused at this point. (And has been since UnixPkg > > > was deprecated.) > > > > > > I think we should deprecate all three of these toolchains. I would > > > like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll > > > add Larry to this email, because I think he disagrees with > > > deprecating > > > toolchains... > > > > > > If you make these changes and it breaks those toolchains, I don't > > > think we would be able to notice, because I don't think we test them > > > in our build pool anymore. To me this is all the more reason to move > > > them out of tools_def.template. > > > > I was building with UNIXGCC last week, to test LLP64 builds without the > > pain of actually having to deal with Windows. > > > > I'd rather see it updated to work with modern MinGW rather than > > deprecated. > > I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc- > build.py. Yes, I know the existing version of the script uses GCC 4.3.0. > That's why I made an updated version that uses 4.9.3: > > http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py > > I know you don't want to support this script, that's why I did the work for > you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine. > > There is value in being able to bootstrap your own cross-build toolchain on > whatever platform. I don't think you should be so quick to remove it. Can't you use an elf-based GCC4.9 with the GCC49 toolchain instead? I'm not sure it makes sense to 'upgrade' the UNIXGCC toolchain to be based on GCC 4.9 rather than 4.3. I think GCC 4.3 was implicitly part of the definition of the UNIXGCC toolchain. (Well, maybe explicitly if you count the comment in tools_def :) This is why I'd rather deprecate it as a toolchain, and use the GCC4X toolchains instead. -Jordan ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On 17 August 2015 at 19:53, Jordan Justen wrote: > On 2015-08-17 07:24:57, Ard Biesheuvel wrote: >> This got a bit out of hand after I noticed the ELFGCC and UNIXGCC >> toolchains that needed some tlc as well. >> >> Anyway, this series aims to refactor the toolchains definitions for >> UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC, >> CYGGCC and CYGGCCxASL so that they share as much of the settings as > > UNIXGCC and CYGGCC are GCC 4.3 & mingw based. Did this get tested? > I sent some patches around to bring them up to date: http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297 and with that version, it works fine. GCC 4.3 probably does not work anymore for X64, since it incorrectly decorates symbol names with underscores, which the MS ABI only specifies for 32-bit code. > I think ELFGCC is unused at this point. (And has been since UnixPkg > was deprecated.) > > I think we should deprecate all three of these toolchains. I would > like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll > add Larry to this email, because I think he disagrees with deprecating > toolchains... > I agree. It makes no sense to have dozens of toolchains when only a couple are widely used by developers, especially with new features like the 4 KB alignment for memory permissions that rely on options that are only passed to some of them. I already removed ARMGCC and ARMLINUXGCC last week, by the way, but I don't suppose Larry would care about those? > If you make these changes and it breaks those toolchains, I don't > think we would be able to notice, because I don't think we test them > in our build pool anymore. To me this is all the more reason to move > them out of tools_def.template. > The only ones I did not test are the CYGGCC ones, which I cannot test since it obviously only runs under Windows. Everything else seems to work just fine, including mingw and IPF/ELF, although more coverage is required of course. -- Ard. >> possible. Currently, there is very little coordination between these, >> which means for instance that the 4 KB alignment feature is only supported >> on GCC4x at the moment. >> >> The primary difference between these toolchains is that GCC4x and ELFGCC >> are entirely ELF based, whereas the other are PE/COFF based (but only when >> building for IA32 or X64) >> >> Note that this series does not remove any toolchains, nor should it result >> in major changes in the command lines that are passed to the various tools. >> However, things may be reordered, and (in case of ELFGCC), missing >> functionality >> such as increased section alignment has been added so there are some changes >> there. >> >> Patch #1 is a patch from Scott that I am reposting, but updated to cover >> AARCH64 as well. >> >> Patch #2 fixes a problem in the GenFv tool where it may access unallocated >> memory while rebasing the FFS when using large section and file alignment. >> >> Patch #3 removes an unused DEFINE from tools_def >> >> Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to >> all GCC versions. >> >> Patch #5 is the first big refactor patch that introduces PE and ELF variants >> for some CC flags. >> >> Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above. >> >> Patch #7 fixes the issue mentioned by Bill where the underscore decoration >> is erroneously applied on X64 as well. >> >> Patch #8 is the second refactor the introduces PE and ELF variants for the >> various DLINK flags. >> >> Patch #9 changes the way the start of the .data section is set in >> GccBase.lds. >> This is needed since the linker will reorganize the internal layout of the >> .data >> section rather than update its start address to ensure all objects that it >> contains meet their respective alignments, even if the start address is not >> aligned to the max value of all inputs. >> >> Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The >> latest >> GenFw and linker script propagate the alignment automatically, i.e., if >> objects >> with such alignment requirement are present, GCC will set the ELF header >> accordingly, and this value will be used for the PE/COFF section alignment >> as well. >> >> Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed >> above. >> >> Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the >> redundant definitions. >> >> Patch #13 as #11 but for the linker. >> >> Patch #14 unifies the ASM flags for all archs. >> >> Patch #15 brings the remaining configuration options of ELFGCC in line with >> the GCC4x series. >> >> Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section >> alignment >> for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support >> the properties table memprotection feature. >> >> Changes since v1: >> - added patch #9 to address the IA32 and X86 failures on 4.9 reported by >> Scott >> - don't pass -mno-unaligned-access to ARM 4
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
Of all the gin joints in all the towns in all the world, David Woodhouse had to walk into mine at 11:00:23 on Monday 17 August 2015 and say: > On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote: > > UNIXGCC and CYGGCC are GCC 4.3 & mingw based. Did this get tested? > > > > I think ELFGCC is unused at this point. (And has been since UnixPkg > > was deprecated.) > > > > I think we should deprecate all three of these toolchains. I would > > like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll > > add Larry to this email, because I think he disagrees with > > deprecating > > toolchains... > > > > If you make these changes and it breaks those toolchains, I don't > > think we would be able to notice, because I don't think we test them > > in our build pool anymore. To me this is all the more reason to move > > them out of tools_def.template. > > I was building with UNIXGCC last week, to test LLP64 builds without the > pain of actually having to deal with Windows. > > I'd rather see it updated to work with modern MinGW rather than > deprecated. I use UNIXGCC with the cross-compiler toolchain generated by mingw-gcc- build.py. Yes, I know the existing version of the script uses GCC 4.3.0. That's why I made an updated version that uses 4.9.3: http://people.freebsd.org/~wpaul/edk2/mingw-gcc-build.py I know you don't want to support this script, that's why I did the work for you. :) Yes I've tested both IA32 and X64 builds. Yes they work fine. There is value in being able to bootstrap your own cross-build toolchain on whatever platform. I don't think you should be so quick to remove it. -Bill -- = -Bill Paul(510) 749-2329 | Senior Member of Technical Staff, wp...@windriver.com | Master of Unix-Fu - Wind River Systems = "I put a dollar in a change machine. Nothing changed." - George Carlin = ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On Mon, 2015-08-17 at 10:53 -0700, Jordan Justen wrote: > > UNIXGCC and CYGGCC are GCC 4.3 & mingw based. Did this get tested? > > I think ELFGCC is unused at this point. (And has been since UnixPkg > was deprecated.) > > I think we should deprecate all three of these toolchains. I would > like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll > add Larry to this email, because I think he disagrees with > deprecating > toolchains... > > If you make these changes and it breaks those toolchains, I don't > think we would be able to notice, because I don't think we test them > in our build pool anymore. To me this is all the more reason to move > them out of tools_def.template. I was building with UNIXGCC last week, to test LLP64 builds without the pain of actually having to deal with Windows. I'd rather see it updated to work with modern MinGW rather than deprecated. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 00/16] unify GCC command line options
On 2015-08-17 07:24:57, Ard Biesheuvel wrote: > This got a bit out of hand after I noticed the ELFGCC and UNIXGCC > toolchains that needed some tlc as well. > > Anyway, this series aims to refactor the toolchains definitions for > UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC, > CYGGCC and CYGGCCxASL so that they share as much of the settings as UNIXGCC and CYGGCC are GCC 4.3 & mingw based. Did this get tested? I think ELFGCC is unused at this point. (And has been since UnixPkg was deprecated.) I think we should deprecate all three of these toolchains. I would like to see us move them to BaseTools/Conf/tools_def.deprecated. I'll add Larry to this email, because I think he disagrees with deprecating toolchains... If you make these changes and it breaks those toolchains, I don't think we would be able to notice, because I don't think we test them in our build pool anymore. To me this is all the more reason to move them out of tools_def.template. -Jordan > possible. Currently, there is very little coordination between these, > which means for instance that the 4 KB alignment feature is only supported > on GCC4x at the moment. > > The primary difference between these toolchains is that GCC4x and ELFGCC > are entirely ELF based, whereas the other are PE/COFF based (but only when > building for IA32 or X64) > > Note that this series does not remove any toolchains, nor should it result > in major changes in the command lines that are passed to the various tools. > However, things may be reordered, and (in case of ELFGCC), missing > functionality > such as increased section alignment has been added so there are some changes > there. > > Patch #1 is a patch from Scott that I am reposting, but updated to cover > AARCH64 as well. > > Patch #2 fixes a problem in the GenFv tool where it may access unallocated > memory while rebasing the FFS when using large section and file alignment. > > Patch #3 removes an unused DEFINE from tools_def > > Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to > all GCC versions. > > Patch #5 is the first big refactor patch that introduces PE and ELF variants > for some CC flags. > > Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above. > > Patch #7 fixes the issue mentioned by Bill where the underscore decoration > is erroneously applied on X64 as well. > > Patch #8 is the second refactor the introduces PE and ELF variants for the > various DLINK flags. > > Patch #9 changes the way the start of the .data section is set in GccBase.lds. > This is needed since the linker will reorganize the internal layout of the > .data > section rather than update its start address to ensure all objects that it > contains meet their respective alignments, even if the start address is not > aligned to the max value of all inputs. > > Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The > latest > GenFw and linker script propagate the alignment automatically, i.e., if > objects > with such alignment requirement are present, GCC will set the ELF header > accordingly, and this value will be used for the PE/COFF section alignment > as well. > > Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed > above. > > Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the > redundant definitions. > > Patch #13 as #11 but for the linker. > > Patch #14 unifies the ASM flags for all archs. > > Patch #15 brings the remaining configuration options of ELFGCC in line with > the GCC4x series. > > Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section > alignment > for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support > the properties table memprotection feature. > > Changes since v1: > - added patch #9 to address the IA32 and X86 failures on 4.9 reported by Scott > - don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott) > - improved wording of commit messages of various patches > - rebased onto latest upstream, which includes a fix related to the ARM 4.6 > issue mentioned above > > Branch can be found here > https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2 > > Ard Biesheuvel (15): > BaseTools/GenFv: use PE/COFF virtual section size if raw size is > larger > BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS > BaseTools GCC: merge warning flags for all GCC versions > BaseTools GCC: refactor tools_def internal GCC defines for CC flags > BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC > BaseTools GCC: use leading underscore for symbol names where > appropriate > BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK > BaseTools GCC: don't set .data address explicitly > BaseTools GCC: remove GCC 4.9 specific linker alignment override > BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based > GCC >
Re: [edk2] [Patch 8/8] MdeModulePkg: Add GraphicsOutputDxe driver
Nice. :) One of my motivations for BltLib was the hope that we could
make a common GOP driver. Similar to what you are doing here it was
for a platform that only supported a single video mode.
Another idea: What if we design a VideoModeSetLib? We could have a
'Null' driver that uses the GraphicsInfo HOB and supports a single
mode. Or, a platform could provide a non-null library to allow setting
other modes. For example, this might allow OVMF to use
GraphicsOutputDxe.
-Jordan
On 2015-08-17 06:45:29, Ruiyu Ni wrote:
> The driver consumes the GraphicsInfo HOB and produces GOP protocol.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni
> Cc: Feng Tian
> ---
> MdeModulePkg/MdeModulePkg.dsc | 4 +
> .../Console/GraphicsOutputDxe/ComponentName.c | 190 ++
> .../Console/GraphicsOutputDxe/GraphicsOutput.c | 659
> +
> .../Console/GraphicsOutputDxe/GraphicsOutput.h | 53 ++
> .../GraphicsOutputDxe/GraphicsOutputDxe.inf| 57 ++
> 5 files changed, 963 insertions(+)
> create mode 100644
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
> create mode 100644
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
> create mode 100644
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
> create mode 100644
> MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf
>
> diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
> index e475dc1..cd3e21e 100644
> --- a/MdeModulePkg/MdeModulePkg.dsc
> +++ b/MdeModulePkg/MdeModulePkg.dsc
> @@ -290,6 +290,10 @@
>MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
>MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
>MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
> + MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf {
> +
> + BltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
> + }
>MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
>MdeModulePkg/Universal/DebugPortDxe/DebugPortDxe.inf
>MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> diff --git a/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
> b/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
> new file mode 100644
> index 000..9f1c79d
> --- /dev/null
> +++ b/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
> @@ -0,0 +1,190 @@
> +/** @file
> + UEFI Component Name(2) protocol implementation for the generic GOP driver.
> +
> +Copyright (c) 2015, 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
> +http://opensource.org/licenses/bsd-license.php
> +
> +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> +
> +
> +**/
> +
> +#include
> +#include
> +
> +extern EFI_COMPONENT_NAME_PROTOCOL mGraphicsOutputComponentName;
> +extern EFI_COMPONENT_NAME2_PROTOCOL mGraphicsOutputComponentName2;
> +
> +//
> +// Driver name table for GraphicsOutput module.
> +// It is shared by the implementation of ComponentName & ComponentName2
> Protocol.
> +//
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE
> mGraphicsOutputDriverNameTable[] = {
> + {
> +"eng;en",
> +L"Generic Graphics Output Driver"
> + },
> + {
> +NULL,
> +NULL
> + }
> +};
> +
> +/**
> + Retrieves a Unicode string that is the user readable name of the driver.
> +
> + This function retrieves the user readable name of a driver in the form of a
> + Unicode string. If the driver specified by This has a user readable name in
> + the language specified by Language, then a pointer to the driver name is
> + returned in DriverName, and EFI_SUCCESS is returned. If the driver
> specified
> + by This does not support the language specified by Language,
> + then EFI_UNSUPPORTED is returned.
> +
> + @param This[in] A pointer to the
> EFI_COMPONENT_NAME2_PROTOCOL or
> +EFI_COMPONENT_NAME_PROTOCOL instance.
> +
> + @param Language[in] A pointer to a Null-terminated ASCII string
> +array indicating the language. This is the
> +language of the driver name that the caller
> is
> +requesting, and it must match one of the
> +languages specified in SupportedLanguages.
> The
> +number of languages supported by a driver is
> up
> +to the driver writer. Language is specified
> +in RFC 4646 or
Re: [edk2] [uswg] Shell 2.0 and 2.1
The UEFI Shell 2.1 has been available for a long time. Any UDK release after Aug last year should have it. I am not an expert on the UDK releases... -Jaben > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Daniel Samuelraj > Sent: Monday, August 17, 2015 10:09 AM > To: Carsey, Jaben ; uswg > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [uswg] Shell 2.0 and 2.1 > Importance: High > > Thank you, Jaben. > > > > I have added my comments inline > > > > *From:* Carsey, Jaben [mailto:jaben.car...@intel.com] > *Sent:* Monday, August 17, 2015 11:12 AM > *To:* Daniel Samuelraj; uswg > *Cc:* edk2-devel@lists.01.org; Carsey, Jaben > *Subject:* RE: [uswg] Shell 2.0 and 2.1 > > > > (note: I changed the edk2 mailing list) > > > > Daniel, > > > > A UEFI Shell 2.0 application will work fine in UEFI Shell 2.1 with no > changes. > > > > To create/build a UEFI Shell 2.1 application would need to have a version > of the UDK that has the updated protocol to get easy access to the new > API’s that were added to the protocol. > > *[Samuelraj, Daniel] I assume that this UDK is not available yet?* > > > > If you create a UEFI Shell 2.1 application AND you use a API in the > protocol that is not in the 2.0 version of the protocol, you should check > the version information in the protocol itself to make sure that the > application will function on a UEFI Shell 2.0 system (even if that just > generates an error). If you call the API that does not exist, you will > certainly have undefined behavior. > > > > -Jaben > > > > > > > > > > *From:* u...@uefi.org [mailto:u...@uefi.org ] *On > Behalf Of *Daniel > Samuelraj > *Sent:* Friday, August 14, 2015 9:40 AM > *To:* uswg ; edk2-de...@lists.sourceforge.net > *Subject:* [uswg] Shell 2.0 and 2.1 > *Importance:* High > > > > Hi, > > I assume that Shell 2.0 apps are expected to run fine in Shell 2.1. Can you > please confirm? > > > > Should shell 2.1 app be using new toolkit (e.g., UDK2014 or newer?) when > app want to make use of the content added in Shell 2.1? > > > > Will there be any backward or forward compatibility issue? That is end user > running Shell 2.0 app in shell 2.1; similarly running Shell 2.1 app in > Shell 2.0? > > > > Appreciate the response! > > > > Thanks, > > Daniel > ___ > 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
Re: [edk2] [Patch 6/8] OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API
On 2015-08-17 06:45:27, Ruiyu Ni wrote:
> The BltConfigure() API caches the video frame buffer meta data which
> forbids the library to be implemented to support re-entry.
How does this help? GraphicsOutputDxe will set a mode, and then use
BltLib with that mode.
I already asked this, and I had some other questions:
http://article.gmane.org/gmane.comp.bios.edk2.devel/1209
-Jordan
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ruiyu Ni
> Cc: Laszlo Ersek
> Cc: Jordan Justen
> ---
> .../Application/BltLibSample/BltLibSample.c| 129 +++---
> OptionRomPkg/Include/Library/BltLib.h | 151 +++---
> .../Library/FrameBufferBltLib/FrameBufferBltLib.c | 514
> +++--
> OptionRomPkg/Library/GopBltLib/GopBltLib.c | 289 ++--
> OvmfPkg/QemuVideoDxe/Gop.c | 13 +-
> 5 files changed, 576 insertions(+), 520 deletions(-)
>
> diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
> b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
> index 333b054..3c7e392 100644
> --- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
> +++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
>
> UINT64
> @@ -68,8 +69,8 @@ Rand32 (
>
> VOID
> TestFills (
> - UINT32 HorizontalResolution,
> - UINT32 VerticalResolution
> + IN VOID *FrameBuffer,
> + IN EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
>)
> {
>EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color;
> @@ -79,44 +80,45 @@ TestFills (
>UINTN W;
>UINTN H;
>
> - for (Loop = 0; Loop < 1; Loop++) {
> -W = HorizontalResolution - (Rand32 () % HorizontalResolution);
> -H = VerticalResolution - (Rand32 () % VerticalResolution);
> -if (W != HorizontalResolution) {
> - X = Rand32 () % (HorizontalResolution - W);
> + for (Loop = 0; Loop < 1000; Loop++) {
> +W = FrameBufferInfo->HorizontalResolution - (Rand32 () %
> FrameBufferInfo->HorizontalResolution);
> +H = FrameBufferInfo->VerticalResolution - (Rand32 () %
> FrameBufferInfo->VerticalResolution);
> +if (W != FrameBufferInfo->HorizontalResolution) {
> + X = Rand32 () % (FrameBufferInfo->HorizontalResolution - W);
> } else {
>X = 0;
> }
> -if (H != VerticalResolution) {
> - Y = Rand32 () % (VerticalResolution - H);
> +if (H != FrameBufferInfo->VerticalResolution) {
> + Y = Rand32 () % (FrameBufferInfo->VerticalResolution - H);
> } else {
>Y = 0;
> }
> *(UINT32*) (&Color) = Rand32 () & 0xff;
> -BltVideoFill (&Color, X, Y, W, H);
> +BltVideoFill (FrameBuffer, FrameBufferInfo, &Color, X, Y, W, H);
>}
> }
>
>
> VOID
> TestColor1 (
> - UINT32 HorizontalResolution,
> - UINT32 VerticalResolution
> + IN VOID *FrameBuffer,
> + IN EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
>)
> {
> - EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color;
> + EFI_GRAPHICS_OUTPUT_BLT_PIXEL *BltBuffer;
>UINTN X;
>UINTN Y;
>
> - *(UINT32*) (&Color) = 0;
> + BltBuffer = AllocatePool (sizeof (*BltBuffer) *
> FrameBufferInfo->HorizontalResolution);
> + ASSERT (BltBuffer != NULL);
>
> - for (Y = 0; Y < VerticalResolution; Y++) {
> -for (X = 0; X < HorizontalResolution; X++) {
> - Color.Red = (UINT8) ((X * 0x100) / HorizontalResolution);
> - Color.Green = (UINT8) ((Y * 0x100) / VerticalResolution);
> - Color.Blue = (UINT8) ((Y * 0x100) / VerticalResolution);
> - BltVideoFill (&Color, X, Y, 1, 1);
> + for (Y = 0; Y < FrameBufferInfo->VerticalResolution; Y++) {
> +for (X = 0; X < FrameBufferInfo->HorizontalResolution; X++) {
> + BltBuffer[X].Red = (UINT8) ((X * 0x100) /
> FrameBufferInfo->HorizontalResolution);
> + BltBuffer[X].Green = (UINT8) ((Y * 0x100) /
> FrameBufferInfo->VerticalResolution);
> + BltBuffer[X].Blue = (UINT8) ((Y * 0x100) /
> FrameBufferInfo->VerticalResolution);
> }
> +BltBufferToVideo (FrameBuffer, FrameBufferInfo, BltBuffer, 0, 0, 0, Y,
> FrameBufferInfo->HorizontalResolution, 1, 0);
>}
> }
>
> @@ -176,8 +178,8 @@ GetTriColor (
>
> VOID
> TestColor (
> - UINT32 HorizontalResolution,
> - UINT32 VerticalResolution
> + IN VOID *FrameBuffer,
> + IN EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
>)
> {
>EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color;
> @@ -187,34 +189,38 @@ TestColor (
>UINTN LineWidth, TriWidth;
>UINTN TriHeight;
>UINT32 ColorDist;
> + EFI_GRAPHICS_OUTPUT_BLT_PIXEL
Re: [edk2] [uswg] Shell 2.0 and 2.1
Thank you, Jaben. I have added my comments inline *From:* Carsey, Jaben [mailto:jaben.car...@intel.com] *Sent:* Monday, August 17, 2015 11:12 AM *To:* Daniel Samuelraj; uswg *Cc:* edk2-devel@lists.01.org; Carsey, Jaben *Subject:* RE: [uswg] Shell 2.0 and 2.1 (note: I changed the edk2 mailing list) Daniel, A UEFI Shell 2.0 application will work fine in UEFI Shell 2.1 with no changes. To create/build a UEFI Shell 2.1 application would need to have a version of the UDK that has the updated protocol to get easy access to the new API’s that were added to the protocol. *[Samuelraj, Daniel] I assume that this UDK is not available yet?* If you create a UEFI Shell 2.1 application AND you use a API in the protocol that is not in the 2.0 version of the protocol, you should check the version information in the protocol itself to make sure that the application will function on a UEFI Shell 2.0 system (even if that just generates an error). If you call the API that does not exist, you will certainly have undefined behavior. -Jaben *From:* u...@uefi.org [mailto:u...@uefi.org ] *On Behalf Of *Daniel Samuelraj *Sent:* Friday, August 14, 2015 9:40 AM *To:* uswg ; edk2-de...@lists.sourceforge.net *Subject:* [uswg] Shell 2.0 and 2.1 *Importance:* High Hi, I assume that Shell 2.0 apps are expected to run fine in Shell 2.1. Can you please confirm? Should shell 2.1 app be using new toolkit (e.g., UDK2014 or newer?) when app want to make use of the content added in Shell 2.1? Will there be any backward or forward compatibility issue? That is end user running Shell 2.0 app in shell 2.1; similarly running Shell 2.1 app in Shell 2.0? Appreciate the response! Thanks, Daniel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [uswg] Shell 2.0 and 2.1
(note: I changed the edk2 mailing list) Daniel, A UEFI Shell 2.0 application will work fine in UEFI Shell 2.1 with no changes. To create/build a UEFI Shell 2.1 application would need to have a version of the UDK that has the updated protocol to get easy access to the new API’s that were added to the protocol. If you create a UEFI Shell 2.1 application AND you use a API in the protocol that is not in the 2.0 version of the protocol, you should check the version information in the protocol itself to make sure that the application will function on a UEFI Shell 2.0 system (even if that just generates an error). If you call the API that does not exist, you will certainly have undefined behavior. -Jaben From: u...@uefi.org [mailto:u...@uefi.org] On Behalf Of Daniel Samuelraj Sent: Friday, August 14, 2015 9:40 AM To: uswg ; edk2-de...@lists.sourceforge.net Subject: [uswg] Shell 2.0 and 2.1 Importance: High Hi, I assume that Shell 2.0 apps are expected to run fine in Shell 2.1. Can you please confirm? Should shell 2.1 app be using new toolkit (e.g., UDK2014 or newer?) when app want to make use of the content added in Shell 2.1? Will there be any backward or forward compatibility issue? That is end user running Shell 2.0 app in shell 2.1; similarly running Shell 2.1 app in Shell 2.0? Appreciate the response! Thanks, Daniel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 01/16] BaseTools GCC: Fix GCC49 build failure
From: Scott Duplichan 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 option to satisfy this requirement and avoid a GCC44 build failure. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan Additional change by Ard Biesheuvel: move the --defsym= command line option also for AARCH64. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index dd44de033519..c35fd6ce0dd2 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3844,9 +3844,9 @@ DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 -fno-stack-p DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections -z common-page-size=0x20 DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) --entry ReferenceAcpiTable -u ReferenceAcpiTable DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map -DEFINE GCC44_IA32_DLINK2_FLAGS = DEF(GCC_DLINK2_FLAGS_COMMON) --defsym=PECOFF_HEADER_SIZE=0x220 +DEFINE GCC44_IA32_DLINK2_FLAGS = --defsym=PECOFF_HEADER_SIZE=0x220 DEF(GCC_DLINK2_FLAGS_COMMON) DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) -melf_x86_64 --oformat=elf64-x86-64 -DEFINE GCC44_X64_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) --defsym=PECOFF_HEADER_SIZE=0x228 +DEFINE GCC44_X64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_DLINK2_FLAGS_COMMON) DEFINE GCC44_ASM_FLAGS = DEF(GCC_ASM_FLAGS) DEFINE GCC45_IA32_CC_FLAGS = DEF(GCC44_IA32_CC_FLAGS) @@ -3888,7 +3888,7 @@ DEFINE GCC47_ARM_CC_FLAGS= DEF(GCC46_ARM_CC_FLAGS) -mno-unaligned-ac DEFINE GCC47_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC44_ALL_CC_FLAGS) DEF(GCC_AARCH64_CC_FLAGS) DEFINE GCC47_ARM_DLINK_FLAGS = DEF(GCC46_ARM_DLINK_FLAGS) DEFINE GCC47_AARCH64_DLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS) -DEFINE GCC47_AARCH64_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) --defsym=PECOFF_HEADER_SIZE=0x228 +DEFINE GCC47_AARCH64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_DLINK2_FLAGS_COMMON) DEFINE GCC47_ARM_ASLDLINK_FLAGS = DEF(GCC46_ARM_ASLDLINK_FLAGS) DEFINE GCC47_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_ASLDLINK_FLAGS) -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 03/16] BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS
The definition of GCC_WINDRES_FLAGS is never referenced again so remove it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 1 - 1 file changed, 1 deletion(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index c35fd6ce0dd2..506e734b6895 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3831,7 +3831,6 @@ DEFINE GCC_PP_FLAGS= -E -x assembler-with-cpp -include $(DEST_DI DEFINE GCC_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE --include $(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h DEFINE GCC_ASLPP_FLAGS = -x c -E -P DEFINE GCC_ASLCC_FLAGS = -x c -DEFINE GCC_WINDRES_FLAGS = -J rc -O coff DEFINE GCC_IA32_RC_FLAGS = -I binary -O elf32-i386 -B i386 --rename-section .data=.hii DEFINE GCC_X64_RC_FLAGS= -I binary -O elf64-x86-64-B i386 --rename-section .data=.hii DEFINE GCC_IPF_RC_FLAGS= -I binary -O elf64-ia64-little -B ia64 --rename-section .data=.hii -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 16/16] OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules
This enables 4 KB section alignment for DXE_RUNTIME modules, for ELF based toolchains and for the UNIXGCC PE/COFF toolchain. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- OvmfPkg/OvmfPkgX64.dsc | 7 +++ 1 file changed, 7 insertions(+) diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index b72eaa92f82e..817c381f4913 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -48,6 +48,13 @@ [BuildOptions] INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable !endif +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER] +!if $(TOOLCHAIN) == UNIXGCC + GCC:*_*_X64_DLINK_FLAGS = --section-alignment 0x1000 --file-alignment 0x1000 +!else + GCC:*_*_X64_DLINK_FLAGS = -z common-page-size=0x1000 +!endif + # # SKU Identification section - list of all SKU IDs supported by this Platform. -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 15/16] BaseTools GCC: align ELFGCC with GCC4x toolchains
This aligns the remaining configuration options for ELFGCC with the other ELF based toolchains. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index a21b44ffd413..a29591793e07 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -4873,8 +4873,8 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) *_ELFGCC_IA32_DLINK2_FLAGS = DEF(GCC_IA32_DLINK2_FLAGS) *_ELFGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_ASLDLINK_ELF_FLAGS) *_ELFGCC_IA32_ASM_FLAGS = DEF(GCC_IA32_ASM_FLAGS) -*_ELFGCC_IA32_PP_FLAGS = -m32 -E -x assembler-with-cpp -include $(DEST_DIR_DEBUG)/AutoGen.h -*_ELFGCC_IA32_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE --include $(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h +*_ELFGCC_IA32_PP_FLAGS = DEF(GCC_PP_FLAGS) +*_ELFGCC_IA32_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) *_ELFGCC_IA32_RC_FLAGS = DEF(GCC_IA32_RC_FLAGS) *_ELFGCC_IA32_OBJCOPY_FLAGS = *_ELFGCC_IA32_NASM_FLAGS= -f elf32 @@ -4899,8 +4899,8 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) *_ELFGCC_X64_DLINK2_FLAGS = DEF(GCC_X64_DLINK2_FLAGS) *_ELFGCC_X64_ASLDLINK_FLAGS= DEF(GCC_X64_ASLDLINK_ELF_FLAGS) *_ELFGCC_X64_ASM_FLAGS = DEF(GCC_X64_ASM_FLAGS) -*_ELFGCC_X64_PP_FLAGS = -E -x assembler-with-cpp -include $(DEST_DIR_DEBUG)/AutoGen.h -*_ELFGCC_X64_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE --include $(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h +*_ELFGCC_X64_PP_FLAGS = DEF(GCC_PP_FLAGS) +*_ELFGCC_X64_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) *_ELFGCC_X64_RC_FLAGS = DEF(GCC_X64_RC_FLAGS) *_ELFGCC_X64_NASM_FLAGS= -f elf64 @@ -4918,12 +4918,12 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) *_ELFGCC_IPF_VFRPP_PATH = DEF(ELFGCC_BIN)/gcc *_ELFGCC_IPF_RC_PATH = DEF(ELFGCC_BIN)/objcopy -*_ELFGCC_IPF_CC_FLAGS = -Os -fshort-wchar -Wall -Werror -c -include AutoGen.h -D_EFI_P64 -*_ELFGCC_IPF_DLINK_FLAGS = -nostdlib --shared --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +*_ELFGCC_IPF_CC_FLAGS = DEF(GCC_IPF_CC_FLAGS) *_ELFGCC_IPF_SLINK_FLAGS = -*_ELFGCC_IPF_ASM_FLAGS= -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h -*_ELFGCC_IPF_PP_FLAGS = -E -x assembler-with-cpp -include $(DEST_DIR_DEBUG)/AutoGen.h -*_ELFGCC_IPF_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE --include $(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h +*_ELFGCC_IPF_DLINK_FLAGS = DEF(GCC_IPF_DLINK_FLAGS) +*_ELFGCC_IPF_ASM_FLAGS= DEF(GCC_ASM_FLAGS) +*_ELFGCC_IPF_PP_FLAGS = DEF(GCC_PP_FLAGS) +*_ELFGCC_IPF_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) *_ELFGCC_IPF_RC_FLAGS = DEF(GCC_IPF_RC_FLAGS) -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 04/16] BaseTools GCC: merge warning flags for all GCC versions
The warning flags -Wno-address -Wno-unused-but-set-variable are added for version 4.6 and up, but since they are happily accepted by version 4.4 and 4.5, add them there as well. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Reviewed-by: Liming Gao --- BaseTools/Conf/tools_def.template | 22 ++-- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 506e734b6895..af9e99f5647c 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3837,7 +3837,7 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O elf64-ia64-little -B ia64 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm --rename-section .data=.hii DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B aarch64 --rename-section .data=.hii -DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -ffunction-sections -fdata-sections -c -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings +DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -Wno-address -Wno-unused-but-set-variable -ffunction-sections -fdata-sections -c -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings DEFINE GCC44_IA32_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -m32 -malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS -mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections -z common-page-size=0x20 @@ -3858,8 +3858,8 @@ DEFINE GCC45_X64_DLINK_FLAGS = DEF(GCC44_X64_DLINK_FLAGS) DEFINE GCC45_X64_DLINK2_FLAGS= DEF(GCC44_X64_DLINK2_FLAGS) DEFINE GCC45_ASM_FLAGS = DEF(GCC44_ASM_FLAGS) -DEFINE GCC46_IA32_CC_FLAGS = DEF(GCC45_IA32_CC_FLAGS) -Wno-address -Wno-unused-but-set-variable -DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS) -Wno-address -Wno-unused-but-set-variable +DEFINE GCC46_IA32_CC_FLAGS = DEF(GCC45_IA32_CC_FLAGS) +DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS) DEFINE GCC46_IA32_X64_DLINK_COMMON = DEF(GCC45_IA32_X64_DLINK_COMMON) DEFINE GCC46_IA32_X64_ASLDLINK_FLAGS = DEF(GCC45_IA32_X64_ASLDLINK_FLAGS) DEFINE GCC46_IA32_X64_DLINK_FLAGS= DEF(GCC45_IA32_X64_DLINK_FLAGS) @@ -4255,7 +4255,7 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS = DEF(GCC48_AARCH64_ASLDLINK_FLAGS) *_GCC46_ARM_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) DEBUG_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -D__ARM_FEATURE_UNALIGNED=0 -O0 -RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -D__ARM_FEATURE_UNALIGNED=0 -Wno-unused-but-set-variable +RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -D__ARM_FEATURE_UNALIGNED=0 # @@ -4354,7 +4354,7 @@ RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -D__ARM_FEATURE_UNALI *_GCC47_ARM_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) DEBUG_GCC47_ARM_CC_FLAGS = DEF(GCC47_ARM_CC_FLAGS) -O0 -RELEASE_GCC47_ARM_CC_FLAGS = DEF(GCC47_ARM_CC_FLAGS) -Wno-unused-but-set-variable +RELEASE_GCC47_ARM_CC_FLAGS = DEF(GCC47_ARM_CC_FLAGS) ## # GCC47 AARCH64 definitions @@ -4381,7 +4381,7 @@ RELEASE_GCC47_ARM_CC_FLAGS = DEF(GCC47_ARM_CC_FLAGS) -Wno-unused-but-set-v *_GCC47_AARCH64_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) DEBUG_GCC47_AARCH64_CC_FLAGS = DEF(GCC47_AARCH64_CC_FLAGS) -O0 -RELEASE_GCC47_AARCH64_CC_FLAGS = DEF(GCC47_AARCH64_CC_FLAGS) -Wno-unused-but-set-variable +RELEASE_GCC47_AARCH64_CC_FLAGS = DEF(GCC47_AARCH64_CC_FLAGS) # @@ -4480,7 +4480,7 @@ RELEASE_GCC47_AARCH64_CC_FLAGS = DEF(GCC47_AARCH64_CC_FLAGS) -Wno-unused-but-s *_GCC48_ARM_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) DEBUG_GCC48_ARM_CC_FLAGS = DEF(GCC48_ARM_CC_FLAGS) -O0 -RELEASE_GCC48_ARM_CC_FLAGS = DEF(GCC48_ARM_CC_FLAGS) -Wno-unused-but-set-variable +RELEASE_GCC48_ARM_CC_FLAGS = DEF(GCC48_ARM_CC_FLAGS) ## # GCC48 AARCH64 definitions @@ -4507,7 +4507,7 @@ RELEASE_GCC48_ARM_CC_FLAGS = DEF(GCC48_ARM_CC_FLAGS) -Wno-unused-but-set-v *_GCC48_AARCH64_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) DEBUG_GCC48_AARCH64_CC_FLAGS = DEF(GCC48_AARCH64_CC_FLAGS) -O0 -RELEASE_GCC48_AARCH64_CC_FLAGS = DEF(GCC48_AARCH64_CC_FL
[edk2] [PATCH v2 14/16] BaseTools GCC: unify ASM flags for all GCC versions
Use the same GCC options for assembling regardless of the exact GCC version. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 67 1 file changed, 27 insertions(+), 40 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 18ae92623e1c..a21b44ffd413 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3845,7 +3845,13 @@ DEFINE GCC_AARCH64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_A DEFINE GCC_IPF_OBJCOPY_FLAGS = -I elf64-ia64-little -O efi-bsdrv-ia64 DEFINE GCC_IPF_SYMRENAME_FLAGS = --redefine-sym memcpy=CopyMem + DEFINE GCC_ASM_FLAGS = -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h +DEFINE GCC_IA32_ASM_FLAGS = DEF(GCC_ASM_FLAGS) -m32 -Wa,--32 -march=i386 +DEFINE GCC_X64_ASM_FLAGS = DEF(GCC_ASM_FLAGS) -m64 -Wa,--64 +DEFINE GCC_ARM_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ASM_FLAGS) -mlittle-endian +DEFINE GCC_AARCH64_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ASM_FLAGS) -mlittle-endian + DEFINE GCC_PP_FLAGS= -E -x assembler-with-cpp -include $(DEST_DIR_DEBUG)/AutoGen.h DEFINE GCC_VFRPP_FLAGS = -x c -E -P -DVFRCOMPILE --include $(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h DEFINE GCC_ASLPP_FLAGS = -x c -E -P @@ -3856,25 +3862,6 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O elf64-ia64-little -B ia64 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm --rename-section .data=.hii DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B aarch64 --rename-section .data=.hii -DEFINE GCC44_ASM_FLAGS = DEF(GCC_ASM_FLAGS) - -DEFINE GCC45_ASM_FLAGS = DEF(GCC44_ASM_FLAGS) - -DEFINE GCC46_ASM_FLAGS = DEF(GCC45_ASM_FLAGS) -DEFINE GCC46_ARM_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ASM_FLAGS) -mlittle-endian - -DEFINE GCC47_ASM_FLAGS = DEF(GCC46_ASM_FLAGS) -DEFINE GCC47_ARM_ASM_FLAGS = DEF(GCC46_ARM_ASM_FLAGS) -DEFINE GCC47_AARCH64_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ASM_FLAGS) -mlittle-endian - -DEFINE GCC48_ASM_FLAGS = DEF(GCC47_ASM_FLAGS) -DEFINE GCC48_ARM_ASM_FLAGS = DEF(GCC47_ARM_ASM_FLAGS) -DEFINE GCC48_AARCH64_ASM_FLAGS = DEF(GCC47_AARCH64_ASM_FLAGS) - -DEFINE GCC49_ASM_FLAGS = DEF(GCC48_ASM_FLAGS) -DEFINE GCC49_ARM_ASM_FLAGS = DEF(GCC48_ARM_ASM_FLAGS) -DEFINE GCC49_AARCH64_ASM_FLAGS = DEF(GCC48_AARCH64_ASM_FLAGS) - # # Unix GCC And Intel Linux ACPI Compiler @@ -4000,7 +3987,7 @@ DEFINE GCC49_AARCH64_ASM_FLAGS = DEF(GCC48_AARCH64_ASM_FLAGS) *_GCC44_IA32_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m32 *_GCC44_IA32_ASLDLINK_FLAGS = DEF(GCC_IA32_ASLDLINK_ELF_FLAGS) -*_GCC44_IA32_ASM_FLAGS= DEF(GCC44_ASM_FLAGS) -m32 --32 -march=i386 +*_GCC44_IA32_ASM_FLAGS= DEF(GCC_IA32_ASM_FLAGS) *_GCC44_IA32_CC_FLAGS = DEF(GCC_IA32_CC_ELF_FLAGS) -Os *_GCC44_IA32_DLINK_FLAGS = DEF(GCC_IA32_DLINK_ELF_FLAGS) *_GCC44_IA32_DLINK2_FLAGS = DEF(GCC_IA32_DLINK2_FLAGS) @@ -4025,7 +4012,7 @@ DEFINE GCC49_AARCH64_ASM_FLAGS = DEF(GCC48_AARCH64_ASM_FLAGS) *_GCC44_X64_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m64 *_GCC44_X64_ASLDLINK_FLAGS = DEF(GCC_X64_ASLDLINK_ELF_FLAGS) -*_GCC44_X64_ASM_FLAGS= DEF(GCC44_ASM_FLAGS) -m64 --64 -melf_x86_64 +*_GCC44_X64_ASM_FLAGS= DEF(GCC_X64_ASM_FLAGS) -melf_x86_64 *_GCC44_X64_CC_FLAGS = DEF(GCC_X64_CC_ELF_FLAGS) *_GCC44_X64_DLINK_FLAGS = DEF(GCC_X64_DLINK_ELF_FLAGS) *_GCC44_X64_DLINK2_FLAGS = DEF(GCC_X64_DLINK2_FLAGS) @@ -4070,7 +4057,7 @@ DEFINE GCC49_AARCH64_ASM_FLAGS = DEF(GCC48_AARCH64_ASM_FLAGS) *_GCC45_IA32_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m32 *_GCC45_IA32_ASLDLINK_FLAGS = DEF(GCC_IA32_ASLDLINK_ELF_FLAGS) -*_GCC45_IA32_ASM_FLAGS= DEF(GCC45_ASM_FLAGS) -m32 --32 -march=i386 +*_GCC45_IA32_ASM_FLAGS= DEF(GCC_IA32_ASM_FLAGS) *_GCC45_IA32_CC_FLAGS = DEF(GCC_IA32_CC_ELF_FLAGS) -Os *_GCC45_IA32_DLINK_FLAGS = DEF(GCC_IA32_DLINK_ELF_FLAGS) *_GCC45_IA32_DLINK2_FLAGS = DEF(GCC_IA32_DLINK2_FLAGS) @@ -4095,7 +4082,7 @@ DEFINE GCC49_AARCH64_ASM_FLAGS = DEF(GCC48_AARCH64_ASM_FLAGS) *_GCC45_X64_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m64 *_GCC45_X64_ASLDLINK_FLAGS = DEF(GCC_X64_ASLDLINK_ELF_FLAGS) -*_GCC45_X64_ASM_FLAGS= DEF(GCC45_ASM_FLAGS) -m64 --64 -melf_x86_64 +*_GCC45_X64_ASM_FLAGS= DEF(GCC_X64_ASM_FLAGS) -melf_x86_64 *_GCC45_X64_CC_FLAGS = DEF(GCC_X64_CC_ELF_FLAGS) *_GC
[edk2] [PATCH v2 06/16] BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC
GCC4x and ELFGCC are both ELF based GCC toolchains, so there is no justification for allowing the command line option to deviate. So align them. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 43 1 file changed, 17 insertions(+), 26 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 8b03f3081669..ee3275c7f668 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3811,10 +3811,13 @@ DEFINE GCC_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing -Wall DEFINE GCC_ALL_PE_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) DEFINE GCC_ALL_ELF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -ffunction-sections -fdata-sections -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings DEFINE GCC_IA32_CC_PE_FLAGS= DEF(GCC_ALL_PE_CC_FLAGS) -m32 -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 -mno-stack-arg-probe +DEFINE GCC_IA32_CC_ELF_FLAGS = DEF(GCC_ALL_ELF_CC_FLAGS) -m32 -malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables DEFINE GCC_X64_CC_PE_FLAGS = DEF(GCC_ALL_PE_CC_FLAGS) -Os -mno-red-zone -mno-stack-arg-probe +DEFINE GCC_X64_CC_ELF_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS -mno-red-zone -mcmodel=large -fno-asynchronous-unwind-tables DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -minline-int-divide-min-latency DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables + DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie DEFINE GCC_DLINK2_FLAGS_COMMON = --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections @@ -3839,8 +3842,6 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O elf64-ia64-little -B ia64 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm --rename-section .data=.hii DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B aarch64 --rename-section .data=.hii -DEFINE GCC44_IA32_CC_FLAGS = DEF(GCC_ALL_ELF_CC_FLAGS) -m32 -malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables -DEFINE GCC44_X64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS -mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections -z common-page-size=0x20 DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) --entry ReferenceAcpiTable -u ReferenceAcpiTable DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map @@ -3849,8 +3850,6 @@ DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) -melf_x8 DEFINE GCC44_X64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_DLINK2_FLAGS_COMMON) DEFINE GCC44_ASM_FLAGS = DEF(GCC_ASM_FLAGS) -DEFINE GCC45_IA32_CC_FLAGS = DEF(GCC44_IA32_CC_FLAGS) -DEFINE GCC45_X64_CC_FLAGS= DEF(GCC44_X64_CC_FLAGS) DEFINE GCC45_IA32_X64_DLINK_COMMON = DEF(GCC44_IA32_X64_DLINK_COMMON) DEFINE GCC45_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_ASLDLINK_FLAGS) DEFINE GCC45_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_FLAGS) @@ -3859,8 +3858,6 @@ DEFINE GCC45_X64_DLINK_FLAGS = DEF(GCC44_X64_DLINK_FLAGS) DEFINE GCC45_X64_DLINK2_FLAGS= DEF(GCC44_X64_DLINK2_FLAGS) DEFINE GCC45_ASM_FLAGS = DEF(GCC44_ASM_FLAGS) -DEFINE GCC46_IA32_CC_FLAGS = DEF(GCC45_IA32_CC_FLAGS) -DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS) DEFINE GCC46_IA32_X64_DLINK_COMMON = DEF(GCC45_IA32_X64_DLINK_COMMON) DEFINE GCC46_IA32_X64_ASLDLINK_FLAGS = DEF(GCC45_IA32_X64_ASLDLINK_FLAGS) DEFINE GCC46_IA32_X64_DLINK_FLAGS= DEF(GCC45_IA32_X64_DLINK_FLAGS) @@ -3873,8 +3870,6 @@ DEFINE GCC46_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --oformat=elf32-littlearm DEFINE GCC46_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_ASLDLINK_FLAGS) --oformat=elf32-littlearm -DEFINE GCC47_IA32_CC_FLAGS = DEF(GCC46_IA32_CC_FLAGS) -DEFINE GCC47_X64_CC_FLAGS
[edk2] [PATCH v2 08/16] BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK
Disentangle the arguments passed to the various flavors of GCC we support, by refactoring the [AS]DLINK flags so that we distinguish more clearly between toolchains that generate PE/COFF directly (for IA32 and X86 only) and toolchains that generate ELF only. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 30 +++- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 1304f514cd37..c7e4e0ac5867 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3818,19 +3818,21 @@ DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -minline-int- DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables -DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie DEFINE GCC_DLINK2_FLAGS_COMMON = --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds -DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections +DEFINE GCC_ALL_DLINK_FLAGS = -nostdlib +DEFINE GCC_ALL_DLINK_PE_FLAGS = DEF(GCC_ALL_DLINK_FLAGS) --pie +DEFINE GCC_IA32_X64_DLINK_PE_FLAGS = DEF(GCC_ALL_DLINK_PE_FLAGS) --gc-sections +DEFINE GCC_IA32_DLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_X64_DLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry $(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -Ttext=0x0 DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z common-page-size=0x20 -DEFINE GCC_IA32_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry _ReferenceAcpiTable -u _$(IMAGE_ENTRY_POINT) -DEFINE GCC_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) +DEFINE GCC_IA32_ASLDLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry _ReferenceAcpiTable -u _$(IMAGE_ENTRY_POINT) +DEFINE GCC_X64_ASLDLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) -DEFINE GCC_IA32_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_COMMON) --entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map -DEFINE GCC_X64_DLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry $(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_IPF_DLINK_FLAGS = -nostdlib -O2 --gc-sections --dll -static --entry $(IMAGE_ENTRY_POINT) --undefined $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map + DEFINE GCC_IPF_OBJCOPY_FLAGS = -I elf64-ia64-little -O efi-bsdrv-ia64 DEFINE GCC_IPF_SYMRENAME_FLAGS = --redefine-sym memcpy=CopyMem DEFINE GCC_ASM_FLAGS = -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h @@ -3935,10 +3937,10 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS = DEF(GCC48_AARCH64_ASLDLINK_FLAGS) *_UNIXGCC_*_MAKE_PATH= make *_UNIXGCC_*_ASL_PATH = DEF(UNIX_IASL_BIN) -*_UNIXGCC_IA32_DLINK_FLAGS = DEF(GCC_IA32_DLINK_FLAGS) --image-base=0 -*_UNIXGCC_X64_DLINK_FLAGS= DEF(GCC_X64_DLINK_FLAGS) --image-base=0 -*_UNIXGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_ASLDLINK_FLAGS) -*_UNIXGCC_X64_ASLDLINK_FLAGS = DEF(GCC_X64_ASLDLINK_FLAGS) +*_UNIXGCC_IA32_DLINK_FLAGS = DEF(GCC_IA32_DLINK_PE_FLAGS) --image-base=0 +*_UNIXGCC_X64_DLINK_FLAGS= DEF(GCC_X64_DLINK_PE_FLAGS) --image-base=0 +*_UNIXGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_ASLDLINK_PE_FLAGS) +*_UNIXGCC_X64_ASLDLINK_FLAGS = DEF(GCC_X64_ASLDLINK_PE_FLAGS) *_UNIXGCC_*_ASM_FLAGS= DEF(GCC_ASM_FLAGS) *_UNIXGCC_*_PP_FLAGS = DEF(GCC_PP_FLAGS) *_UNIXGCC_*_ASLPP_FLAGS
[edk2] [PATCH v2 07/16] BaseTools GCC: use leading underscore for symbol names where appropriate
The MS ABI uses leading underscores to decorate symbol names only when generating 32-bit code. Due to a bug in GCC prior to version 4.3, it used the same decoration for 64-bit code but this has been fixed since. So uses the leading underscore for IA32 only, and remove it for X64. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 22 +++- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index ee3275c7f668..1304f514cd37 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3824,10 +3824,12 @@ DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -Ttext=0x0 DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z common-page-size=0x20 -DEFINE GCC_IA32_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry _ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) +DEFINE GCC_IA32_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry _ReferenceAcpiTable -u _$(IMAGE_ENTRY_POINT) +DEFINE GCC_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) -DEFINE GCC_IA32_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_COMMON) --entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_IA32_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_COMMON) --entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_X64_DLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry $(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_IPF_DLINK_FLAGS = -nostdlib -O2 --gc-sections --dll -static --entry $(IMAGE_ENTRY_POINT) --undefined $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_IPF_OBJCOPY_FLAGS = -I elf64-ia64-little -O efi-bsdrv-ia64 DEFINE GCC_IPF_SYMRENAME_FLAGS = --redefine-sym memcpy=CopyMem @@ -3933,10 +3935,10 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS = DEF(GCC48_AARCH64_ASLDLINK_FLAGS) *_UNIXGCC_*_MAKE_PATH= make *_UNIXGCC_*_ASL_PATH = DEF(UNIX_IASL_BIN) -*_UNIXGCC_IA32_DLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_FLAGS) --image-base=0 -*_UNIXGCC_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_FLAGS) --image-base=0 -*_UNIXGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_X64_ASLDLINK_FLAGS) -*_UNIXGCC_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_ASLDLINK_FLAGS) +*_UNIXGCC_IA32_DLINK_FLAGS = DEF(GCC_IA32_DLINK_FLAGS) --image-base=0 +*_UNIXGCC_X64_DLINK_FLAGS= DEF(GCC_X64_DLINK_FLAGS) --image-base=0 +*_UNIXGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_ASLDLINK_FLAGS) +*_UNIXGCC_X64_ASLDLINK_FLAGS = DEF(GCC_X64_ASLDLINK_FLAGS) *_UNIXGCC_*_ASM_FLAGS= DEF(GCC_ASM_FLAGS) *_UNIXGCC_*_PP_FLAGS = DEF(GCC_PP_FLAGS) *_UNIXGCC_*_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS) @@ -4692,10 +4694,10 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) *_CYGGCC_*_MAKE_PATH = DEF(MS_VS_BIN)\nmake.exe *_CYGGCC_*_ASL_PATH = DEF(DEFAULT_WIN_ASL_BIN) -*_CYGGCC_IA32_DLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_FLAGS) --image-base=0 -*_CYGGCC_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_FLAGS) --image-base=0 -*_CYGGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_X64_ASLDLINK_FLAGS) -*_CYGGCC_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_ASLDLINK_FLAGS) +*_CYGGCC_IA32_DLINK_FLAGS = DEF(GCC_IA32_DLINK_FLAGS) --image-base=0 +*_CYGGCC_X64_DLINK_FLAGS= DEF(GCC_X64_DLINK_FLAGS) --image-base=0 +*_CYGGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_ASLDLINK_FLAGS) +*_CYGGCC_X64_ASLDLINK_FLAGS = DEF(GCC_X64_ASLDLINK_FLAGS) *_CYGGCC_*_MAKE_FLAGS = /nologo *_CYGGCC_*_ASM_FLAGS= DEF(GCC_ASM_FLAGS) *_CYGGCC_*_PP_FLAGS = DEF(GCC_PP_FLAGS) -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 13/16] BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions
Use the same GCC options for linking regardless of the exact GCC version. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 63 +++- 1 file changed, 23 insertions(+), 40 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 8161660ca839..18ae92623e1c 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3818,7 +3818,6 @@ DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -minline-int- DEFINE GCC_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft -fstack-protector DEFINE GCC_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables -DEFINE GCC_DLINK2_FLAGS_COMMON = --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds DEFINE GCC_ALL_DLINK_FLAGS = -nostdlib DEFINE GCC_ALL_DLINK_PE_FLAGS = DEF(GCC_ALL_DLINK_FLAGS) --pie DEFINE GCC_ALL_DLINK_ELF_FLAGS = DEF(GCC_ALL_DLINK_FLAGS) -n -q --gc-sections -z common-page-size=0x20 @@ -3828,20 +3827,21 @@ DEFINE GCC_IA32_DLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry _$ DEFINE GCC_IA32_DLINK_ELF_FLAGS= DEF(GCC_IA32_X64_DLINK_ELF_FLAGS) -m elf_i386 --oformat=elf32-i386 DEFINE GCC_X64_DLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry $(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_X64_DLINK_ELF_FLAGS = DEF(GCC_IA32_X64_DLINK_ELF_FLAGS) -melf_x86_64 --oformat=elf64-x86-64 -DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map -DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -Ttext=0x0 -DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z common-page-size=0x20 +DEFINE GCC_ARM_AARCH64_DLINK_FLAGS = --emit-relocs -nostdlib --gc-sections -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_FLAGS) -Ttext=0x0 --oformat=elf32-littlearm +DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_FLAGS) -z common-page-size=0x20 DEFINE GCC_IA32_ASLDLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry _ReferenceAcpiTable -u _$(IMAGE_ENTRY_POINT) DEFINE GCC_X64_ASLDLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_IA32_ASLDLINK_ELF_FLAGS = DEF(GCC_ALL_DLINK_ELF_FLAGS) --entry ReferenceAcpiTable -u ReferenceAcpiTable -melf_i386 DEFINE GCC_X64_ASLDLINK_ELF_FLAGS = DEF(GCC_ALL_DLINK_ELF_FLAGS) --entry ReferenceAcpiTable -u ReferenceAcpiTable -melf_x86_64 -DEFINE GCC_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) +DEFINE GCC_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) --oformat=elf32-littlearm DEFINE GCC_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_IPF_DLINK_FLAGS = -nostdlib -O2 --gc-sections --dll -static --entry $(IMAGE_ENTRY_POINT) --undefined $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_ALL_DLINK2_FLAGS= --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds DEFINE GCC_IA32_DLINK2_FLAGS = --defsym=PECOFF_HEADER_SIZE=0x220 DEF(GCC_ALL_DLINK2_FLAGS) DEFINE GCC_X64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_ALL_DLINK2_FLAGS) +DEFINE GCC_AARCH64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_ALL_DLINK2_FLAGS) DEFINE GCC_IPF_OBJCOPY_FLAGS = -I elf64-ia64-little -O efi-bsdrv-ia64 DEFINE GCC_IPF_SYMRENAME_FLAGS = --redefine-sym memcpy=CopyMem @@ -3862,35 +3862,18 @@ DEFINE GCC45_ASM_FLAGS = DEF(GCC44_ASM_FLAGS) DEFINE GCC46_ASM_FLAGS = DEF(GCC45_ASM_FLAGS) DEFINE GCC46_ARM_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ASM_FLAGS) -mlittle-endian -DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --oformat=elf32-littlearm -DEFINE GCC46_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_ASLDLINK_FLAGS) --oformat=elf32-littlearm DEFINE GCC47_ASM_FLAGS = DEF(GCC46_ASM_FLAGS) DEFINE GCC47_ARM_ASM_FLAGS = DEF(GCC46_ARM_ASM_FLAGS) DEFINE GCC47_AARCH64_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAG
[edk2] [PATCH v2 09/16] BaseTools GCC: don't set .data address explicitly
When a section's start address is set explicitly and is not aligned to
the alignment of its contents, the linker will rearrange them so that
everything lines up provided that the misalignment is preserved.
Since we cannot do the same in PE/COFF, don't set the .data start
address directly, but advance the location pointer by the same amount.
This way, the linker will be free to choose the start address, but will
ultimately end up using the exact same value.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
BaseTools/Scripts/GccBase.lds | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 4ee6d998532c..eef8325c96a5 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -44,7 +44,8 @@ SECTIONS {
* between these sections is the same in the ELF and the PE/COFF versions of
* this binary.
*/
- .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) {
+ . = ALIGN(ALIGNOF(.text));
+ .data : ALIGN(CONSTANT(COMMONPAGESIZE)) {
*(.data .data.* .gnu.linkonce.d.*)
*(.bss .bss.* *COM*)
}
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 05/16] BaseTools GCC: refactor tools_def internal GCC defines for CC flags
As a first step towards disentangling the arguments passed to the various flavors of GCC we support, refactor the CC flags so that we distinguish more clearly between toolchains that generate PE/COFF directly (for IA32 and X86 only) and toolchains that generate ELF only. Note that this does not modify the options that are ultimately passed to GCC, although it does deduplicate ARM and AARCH64 since those toolchains were passing both GCC_ALL_CC_FLAGS and GCC44_ALL_CC_FLAGS, which overlap to a great extent. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 35 ++-- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index af9e99f5647c..8b03f3081669 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3807,12 +3807,14 @@ NOOPT_DDK3790xASL_IPF_DLINK_FLAGS= /NOLOGO /NODEFAULTLIB /LTCG /DLL /OPT:REF DEBUG_*_*_OBJCOPY_ADDDEBUGFLAG = --add-gnu-debuglink=$(DEBUG_DIR)/$(MODULE_NAME).debug RELEASE_*_*_OBJCOPY_ADDDEBUGFLAG = -DEFINE GCC_ALL_CC_FLAGS= -g -Os -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -c -include AutoGen.h -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) -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables +DEFINE GCC_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -Wno-address -Wno-unused-but-set-variable -c -include AutoGen.h +DEFINE GCC_ALL_PE_CC_FLAGS = DEF(GCC_ALL_CC_FLAGS) +DEFINE GCC_ALL_ELF_CC_FLAGS= DEF(GCC_ALL_CC_FLAGS) -ffunction-sections -fdata-sections -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings +DEFINE GCC_IA32_CC_PE_FLAGS= DEF(GCC_ALL_PE_CC_FLAGS) -m32 -malign-double -freorder-blocks -freorder-blocks-and-partition -O2 -mno-stack-arg-probe +DEFINE GCC_X64_CC_PE_FLAGS = DEF(GCC_ALL_PE_CC_FLAGS) -Os -mno-red-zone -mno-stack-arg-probe +DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -minline-int-divide-min-latency +DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft +DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie DEFINE GCC_DLINK2_FLAGS_COMMON = --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) --gc-sections @@ -3837,9 +3839,8 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O elf64-ia64-little -B ia64 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm --rename-section .data=.hii DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B aarch64 --rename-section .data=.hii -DEFINE GCC44_ALL_CC_FLAGS= -g -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -Wno-address -Wno-unused-but-set-variable -ffunction-sections -fdata-sections -c -include AutoGen.h -DSTRING_ARRAY_NAME=$(BASE_NAME)Strings -DEFINE GCC44_IA32_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -m32 -malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables -DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS -mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables +DEFINE GCC44_IA32_CC_FLAGS = DEF(GCC_ALL_ELF_CC_FLAGS) -m32 -malign-double -fno-stack-protector -D EFI32 -fno-asynchronous-unwind-tables +DEFINE GCC44_X64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS -mno-red-zone -Wno-address -mcmodel=large -fno-asynchronous-unwind-tables DEFINE GCC44_
[edk2] [PATCH v2 12/16] BaseTools GCC: unify ARM and AARCH64 GCC compiler flags
Use the same GCC options for compiling regardless of the exact GCC version. The only option that needs special treatment is -mno-unaligned-access on ARM, which is not supported by upstream GCC v4.6. Everything else can be shared by all versions. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 39 1 file changed, 16 insertions(+), 23 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index b92bd4c16a0e..8161660ca839 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3815,8 +3815,8 @@ DEFINE GCC_IA32_CC_ELF_FLAGS = DEF(GCC_ALL_ELF_CC_FLAGS) -m32 -malign-doub DEFINE GCC_X64_CC_PE_FLAGS = DEF(GCC_ALL_PE_CC_FLAGS) -Os -mno-red-zone -mno-stack-arg-probe DEFINE GCC_X64_CC_ELF_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -m64 -fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" -DNO_BUILTIN_VA_FUNCS -mno-red-zone -mcmodel=large -fno-asynchronous-unwind-tables DEFINE GCC_IPF_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -minline-int-divide-min-latency -DEFINE GCC_ARM_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft -DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables +DEFINE GCC_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mword-relocations -mlittle-endian -mabi=aapcs -mapcs -fno-short-enums -save-temps -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -Wno-address -mthumb -mfloat-abi=soft -fstack-protector +DEFINE GCC_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mcmodel=large -mlittle-endian -fno-short-enums -save-temps -fverbose-asm -fsigned-char -ffunction-sections -fdata-sections -fomit-frame-pointer -fno-builtin -Wno-address -fno-asynchronous-unwind-tables DEFINE GCC_DLINK2_FLAGS_COMMON = --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds DEFINE GCC_ALL_DLINK_FLAGS = -nostdlib @@ -3862,15 +3862,12 @@ DEFINE GCC45_ASM_FLAGS = DEF(GCC44_ASM_FLAGS) DEFINE GCC46_ASM_FLAGS = DEF(GCC45_ASM_FLAGS) DEFINE GCC46_ARM_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ASM_FLAGS) -mlittle-endian -DEFINE GCC46_ARM_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector DEFINE GCC46_ARM_DLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --oformat=elf32-littlearm DEFINE GCC46_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_ASLDLINK_FLAGS) --oformat=elf32-littlearm DEFINE GCC47_ASM_FLAGS = DEF(GCC46_ASM_FLAGS) DEFINE GCC47_ARM_ASM_FLAGS = DEF(GCC46_ARM_ASM_FLAGS) DEFINE GCC47_AARCH64_ASM_FLAGS = $(ARCHASM_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_ASM_FLAGS) -mlittle-endian -DEFINE GCC47_ARM_CC_FLAGS= DEF(GCC46_ARM_CC_FLAGS) -mno-unaligned-access -DEFINE GCC47_AARCH64_CC_FLAGS= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_AARCH64_CC_FLAGS) DEFINE GCC47_ARM_DLINK_FLAGS = DEF(GCC46_ARM_DLINK_FLAGS) DEFINE GCC47_AARCH64_DLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS) DEFINE GCC47_AARCH64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_DLINK2_FLAGS_COMMON) @@ -3880,8 +3877,6 @@ DEFINE GCC47_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_ASLDLINK_FLAGS) DEFINE GCC48_ASM_FLAGS = DEF(GCC47_ASM_FLAGS) DEFINE GCC48_ARM_ASM_FLAGS = DEF(GCC47_ARM_ASM_FLAGS) DEFINE GCC48_AARCH64_ASM_FLAGS = DEF(GCC47_AARCH64_ASM_FLAGS) -DEFINE GCC48_ARM_CC_FLAGS= DEF(GCC47_ARM_CC_FLAGS) -DEFINE GCC48_AARCH64_CC_FLAGS= DEF(GCC47_AARCH64_CC_FLAGS) DEFINE GCC48_ARM_DLINK_FLAGS = DEF(GCC47_ARM_DLINK_FLAGS) DEFINE GCC48_AARCH64_DLINK_FLAGS = DEF(GCC47_AARCH64_DLINK_FLAGS) DEFINE GCC48_AARCH64_DLINK2_FLAGS= DEF(GCC47_AARCH64_DLINK2_FLAGS) @@ -3891,8 +3886,6 @@ DEFINE GCC48_AARCH64_ASLDLINK_FLAGS = DEF(GCC47_AARCH64_ASLDLINK_FLAGS) DEFINE GCC49_ASM_FLAGS = DEF(GCC48_ASM_FLAGS) DEFINE GCC49_ARM_ASM_FLAGS = DEF(GCC48_ARM_ASM_FLAGS) DEFINE GCC49_AARCH64_ASM_FLAGS = DEF(GCC48_AARCH64_ASM_FLAGS) -DEFINE GCC49_ARM_CC_FLAGS= DEF(GCC48_ARM_CC_FLAGS) -DEFINE GCC49_AARCH64_CC_FLAGS= DEF(GCC48_AARCH64_CC_FLAGS) DEFINE GCC49_ARM_DLINK_FLAGS = DEF(GCC48_ARM_DLINK_FLAGS) DEFINE GCC49_AARCH64_DLINK_FLAGS = DEF(GCC48_AARCH64_DLINK_FLAGS) DEFINE GCC49_AARCH64_DLINK2_FLAGS= DEF(GCC48_AARCH64_DLINK2_FLAGS) @@ -4224,8 +4217,8 @@ DEFINE GCC49_
[edk2] [PATCH v2 10/16] BaseTools GCC: remove GCC 4.9 specific linker alignment override
If any version of GCC emits any object whose actual alignment requirement exceeds 32 bytes, this actual alignment value will automatically become the PE/COFF section alignment value after PE/COFF conversion, now that GenFw propagates the alignment of the ELF input sections. So there is no longer a need for special treatment of GCC 4.9, and the linker command line override can be removed. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index c7e4e0ac5867..620770cae9c7 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3908,11 +3908,11 @@ DEFINE GCC48_AARCH64_DLINK2_FLAGS= DEF(GCC47_AARCH64_DLINK2_FLAGS) DEFINE GCC48_ARM_ASLDLINK_FLAGS = DEF(GCC47_ARM_ASLDLINK_FLAGS) DEFINE GCC48_AARCH64_ASLDLINK_FLAGS = DEF(GCC47_AARCH64_ASLDLINK_FLAGS) -DEFINE GCC49_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections -z common-page-size=0x40 -DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) --entry ReferenceAcpiTable -u ReferenceAcpiTable -DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC49_IA32_X64_DLINK_COMMON) --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC49_IA32_X64_DLINK_COMMON = DEF(GCC48_IA32_X64_DLINK_COMMON) +DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC48_IA32_X64_ASLDLINK_FLAGS) +DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC48_IA32_X64_DLINK_FLAGS) DEFINE GCC49_IA32_DLINK2_FLAGS = DEF(GCC48_IA32_DLINK2_FLAGS) -DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) -melf_x86_64 --oformat=elf64-x86-64 +DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC48_X64_DLINK_FLAGS) DEFINE GCC49_X64_DLINK2_FLAGS= DEF(GCC48_X64_DLINK2_FLAGS) DEFINE GCC49_ASM_FLAGS = DEF(GCC48_ASM_FLAGS) DEFINE GCC49_ARM_ASM_FLAGS = DEF(GCC48_ARM_ASM_FLAGS) -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 11/16] BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based GCC
GCC4x and ELFGCC are both ELF based GCC toolchains, so there is no justification for allowing the command line options to deviate. So align them. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 128 1 file changed, 52 insertions(+), 76 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 620770cae9c7..b92bd4c16a0e 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3821,18 +3821,28 @@ DEFINE GCC_AARCH64_CC_FLAGS= DEF(GCC_ALL_ELF_CC_FLAGS) -Os -mcmodel=larg DEFINE GCC_DLINK2_FLAGS_COMMON = --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds DEFINE GCC_ALL_DLINK_FLAGS = -nostdlib DEFINE GCC_ALL_DLINK_PE_FLAGS = DEF(GCC_ALL_DLINK_FLAGS) --pie +DEFINE GCC_ALL_DLINK_ELF_FLAGS = DEF(GCC_ALL_DLINK_FLAGS) -n -q --gc-sections -z common-page-size=0x20 DEFINE GCC_IA32_X64_DLINK_PE_FLAGS = DEF(GCC_ALL_DLINK_PE_FLAGS) --gc-sections +DEFINE GCC_IA32_X64_DLINK_ELF_FLAGS= DEF(GCC_ALL_DLINK_ELF_FLAGS) --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_IA32_DLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry _$(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_IA32_DLINK_ELF_FLAGS= DEF(GCC_IA32_X64_DLINK_ELF_FLAGS) -m elf_i386 --oformat=elf32-i386 DEFINE GCC_X64_DLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry $(IMAGE_ENTRY_POINT) --file-alignment 0x20 --section-alignment 0x20 -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_X64_DLINK_ELF_FLAGS = DEF(GCC_IA32_X64_DLINK_ELF_FLAGS) -melf_x86_64 --oformat=elf64-x86-64 DEFINE GCC_ARM_AARCH64_DLINK_COMMON= --emit-relocs -nostdlib --gc-sections -u $(IMAGE_ENTRY_POINT) -e $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -Ttext=0x0 DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z common-page-size=0x20 DEFINE GCC_IA32_ASLDLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry _ReferenceAcpiTable -u _$(IMAGE_ENTRY_POINT) DEFINE GCC_X64_ASLDLINK_PE_FLAGS = DEF(GCC_IA32_X64_DLINK_PE_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) +DEFINE GCC_IA32_ASLDLINK_ELF_FLAGS = DEF(GCC_ALL_DLINK_ELF_FLAGS) --entry ReferenceAcpiTable -u ReferenceAcpiTable -melf_i386 +DEFINE GCC_X64_ASLDLINK_ELF_FLAGS = DEF(GCC_ALL_DLINK_ELF_FLAGS) --entry ReferenceAcpiTable -u ReferenceAcpiTable -melf_x86_64 DEFINE GCC_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_DLINK_FLAGS) --entry ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) DEFINE GCC_IPF_DLINK_FLAGS = -nostdlib -O2 --gc-sections --dll -static --entry $(IMAGE_ENTRY_POINT) --undefined $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map +DEFINE GCC_ALL_DLINK2_FLAGS= --script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds +DEFINE GCC_IA32_DLINK2_FLAGS = --defsym=PECOFF_HEADER_SIZE=0x220 DEF(GCC_ALL_DLINK2_FLAGS) +DEFINE GCC_X64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_ALL_DLINK2_FLAGS) + DEFINE GCC_IPF_OBJCOPY_FLAGS = -I elf64-ia64-little -O efi-bsdrv-ia64 DEFINE GCC_IPF_SYMRENAME_FLAGS = --redefine-sym memcpy=CopyMem DEFINE GCC_ASM_FLAGS = -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h @@ -3846,40 +3856,16 @@ DEFINE GCC_IPF_RC_FLAGS= -I binary -O elf64-ia64-little -B ia64 DEFINE GCC_ARM_RC_FLAGS= -I binary -O elf32-littlearm -B arm --rename-section .data=.hii DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B aarch64 --rename-section .data=.hii -DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections -z common-page-size=0x20 -DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) --entry ReferenceAcpiTable -u ReferenceAcpiTable -DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) --entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map $(DEST_DIR_DEBUG)/$(BASE_NAME).map -DEFINE GCC44_IA32_DLINK2_FLAGS = --defsym=PECOFF_HEADER_SIZE=0x220 DEF(GCC_DLINK2_FLAGS_COMMON) -DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) -melf_x86_64 --oformat=elf64-x86-64 -DEFINE GCC44_X64_DLINK2_FLAGS= --defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_DLINK2_FLAGS_COMMON) DEFINE GCC44_ASM_FLAGS = DEF(GCC_ASM_FLAGS) -DEFINE GCC45_IA32_X64_DLINK_COMMON = DEF(GCC44_IA32_X64_DLINK_COMMON) -DEFINE GCC45_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_ASLDLINK_FLAGS) -DEFINE GCC45_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_FLAGS) -DEFINE GCC45_IA32_DLINK2_FLAGS = DEF(GCC44_IA32_DLINK2_FLAGS) -DEFINE GC
[edk2] [PATCH v2 02/16] BaseTools/GenFv: use PE/COFF virtual section size if raw size is larger
When copying the relocated sections into the FFS file, we need to take care that we don't overrun the end of the file. Since, unlike the virtual size, the PE/COFF raw section size must be a multiple of the file alignment, which means its size may exceed the virtual size. So use the minimum of the two. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Source/C/GenFv/GenFvInternalLib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/BaseTools/Source/C/GenFv/GenFvInternalLib.c b/BaseTools/Source/C/GenFv/GenFvInternalLib.c index 6d2d5d1f8c67..b0135bf0155a 100644 --- a/BaseTools/Source/C/GenFv/GenFvInternalLib.c +++ b/BaseTools/Source/C/GenFv/GenFvInternalLib.c @@ -3329,7 +3329,7 @@ Returns: CopyMem ( (UINT8 *) CurrentPe32Section.Pe32Section + CurSecHdrSize + SectionHeader->PointerToRawData, (VOID*) (UINTN) (ImageContext.ImageAddress + SectionHeader->VirtualAddress), -SectionHeader->SizeOfRawData +MIN(SectionHeader->SizeOfRawData, SectionHeader->Misc.VirtualSize) ); } -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 00/16] unify GCC command line options
This got a bit out of hand after I noticed the ELFGCC and UNIXGCC toolchains that needed some tlc as well. Anyway, this series aims to refactor the toolchains definitions for UNIXGCC, GCC44, GCC45, GCC46, GCC47, GCC48, GCC49, CLANG35, ELFGCC, CYGGCC and CYGGCCxASL so that they share as much of the settings as possible. Currently, there is very little coordination between these, which means for instance that the 4 KB alignment feature is only supported on GCC4x at the moment. The primary difference between these toolchains is that GCC4x and ELFGCC are entirely ELF based, whereas the other are PE/COFF based (but only when building for IA32 or X64) Note that this series does not remove any toolchains, nor should it result in major changes in the command lines that are passed to the various tools. However, things may be reordered, and (in case of ELFGCC), missing functionality such as increased section alignment has been added so there are some changes there. Patch #1 is a patch from Scott that I am reposting, but updated to cover AARCH64 as well. Patch #2 fixes a problem in the GenFv tool where it may access unallocated memory while rebasing the FFS when using large section and file alignment. Patch #3 removes an unused DEFINE from tools_def Patch #4 moved some warning flags that were applied to GCC4x 4.6 and up to all GCC versions. Patch #5 is the first big refactor patch that introduces PE and ELF variants for some CC flags. Patch #6 unifies the IA32 and X64 CC flags for all toolchains listed above. Patch #7 fixes the issue mentioned by Bill where the underscore decoration is erroneously applied on X64 as well. Patch #8 is the second refactor the introduces PE and ELF variants for the various DLINK flags. Patch #9 changes the way the start of the .data section is set in GccBase.lds. This is needed since the linker will reorganize the internal layout of the .data section rather than update its start address to ensure all objects that it contains meet their respective alignments, even if the start address is not aligned to the max value of all inputs. Patch #10 removes the explicit 64 byte alignment applied to GCC 4.9. The latest GenFw and linker script propagate the alignment automatically, i.e., if objects with such alignment requirement are present, GCC will set the ELF header accordingly, and this value will be used for the PE/COFF section alignment as well. Patch #11 unifies the IA32 and X64 linker flags for all toolchains listed above. Patch #12 unifies the ARM and AARCH64 CC flags, i.e., it removes all the redundant definitions. Patch #13 as #11 but for the linker. Patch #14 unifies the ASM flags for all archs. Patch #15 brings the remaining configuration options of ELFGCC in line with the GCC4x series. Patch #16 is a PoC that allows Ovmf/X64 to be built with 4 KB section alignment for DXE_RUNTIME modules using UNIXGCC and ELFGCC, as is required to support the properties table memprotection feature. Changes since v1: - added patch #9 to address the IA32 and X86 failures on 4.9 reported by Scott - don't pass -mno-unaligned-access to ARM 4.6 compiler (Scott) - improved wording of commit messages of various patches - rebased onto latest upstream, which includes a fix related to the ARM 4.6 issue mentioned above Branch can be found here https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/unify-gcc-v2 Ard Biesheuvel (15): BaseTools/GenFv: use PE/COFF virtual section size if raw size is larger BaseTools GCC: remove unused definition of GCC_WINDRES_FLAGS BaseTools GCC: merge warning flags for all GCC versions BaseTools GCC: refactor tools_def internal GCC defines for CC flags BaseTools GCC: unify all IA32 and X64 CC flags for ELF based GCC BaseTools GCC: use leading underscore for symbol names where appropriate BaseTools GCC: refactor tools_def internal GCC defines for [AS]DLINK BaseTools GCC: don't set .data address explicitly BaseTools GCC: remove GCC 4.9 specific linker alignment override BaseTools GCC: unify all IA32 and X64 [AS]DLINK[2] flags for ELF based GCC BaseTools GCC: unify ARM and AARCH64 GCC compiler flags BaseTools GCC: unify ARM and AARCH64 DLINK flags for all GCC versions BaseTools GCC: unify ASM flags for all GCC versions BaseTools GCC: align ELFGCC with GCC4x toolchains OvmfPkg/X64: enable 4 KB alignment for DXE_RUNTIME modules Scott Duplichan (1): BaseTools GCC: Fix GCC49 build failure BaseTools/Conf/tools_def.template | 412 BaseTools/Scripts/GccBase.lds | 3 +- BaseTools/Source/C/GenFv/GenFvInternalLib.c | 2 +- OvmfPkg/OvmfPkgX64.dsc | 7 + 4 files changed, 183 insertions(+), 241 deletions(-) -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/8] Move BltLib to MdeModulePkg and create GraphicsOutputDxe driver
The code was also checked in to below URL: https://github.com/niruiyu/edk2/tree/GOP -Original Message- From: Ni, Ruiyu Sent: Monday, August 17, 2015 9:45 PM To: edk2-devel@lists.01.org Cc: Ni, Ruiyu Subject: [Patch 0/8] Move BltLib to MdeModulePkg and create GraphicsOutputDxe driver The patch serials refined the BltLib and moved it to MdeModulePkg. Based on the BltLib, the patch created the GraphicsOutputDxe driver which consumes the GraphicsInfo HOB. Ruiyu Ni (8): OptionRomPkg: Refine FrameBufferBltLib to use UINT8* instead of VOID* OptionRomPkg: Add video move test case to BltLibSample application OptionRomPkg: Fix a bug in BltVideoToVideo operation OptionRomPkg: Remove BltLibGetSizes() interface from BltLib OptionRomPkg/OvmfPkg: BltLib API refinement OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API MdeModulePkg: Move BltLib from OptionRomPkg to MdeModulePkg MdeModulePkg: Add GraphicsOutputDxe driver MdeModulePkg/Include/Library/BltLib.h | 147 .../Library/FrameBufferBltLib/FrameBufferBltLib.c | 573 .../FrameBufferBltLib/FrameBufferBltLib.inf| 33 + MdeModulePkg/Library/GopBltLib/GopBltLib.c | 324 + MdeModulePkg/Library/GopBltLib/GopBltLib.inf | 35 + MdeModulePkg/MdeModulePkg.dec | 4 + MdeModulePkg/MdeModulePkg.dsc | 6 + .../Console/GraphicsOutputDxe/ComponentName.c | 190 ++ .../Console/GraphicsOutputDxe/GraphicsOutput.c | 659 ++ .../Console/GraphicsOutputDxe/GraphicsOutput.h | 53 ++ .../GraphicsOutputDxe/GraphicsOutputDxe.inf| 57 ++ .../Application/BltLibSample/BltLibSample.c| 148 ++-- .../Application/BltLibSample/BltLibSample.inf | 4 +- OptionRomPkg/Include/Library/BltLib.h | 259 --- .../Library/FrameBufferBltLib/FrameBufferBltLib.c | 750 - .../FrameBufferBltLib/FrameBufferBltLib.inf| 35 - OptionRomPkg/Library/GopBltLib/GopBltLib.c | 455 - OptionRomPkg/Library/GopBltLib/GopBltLib.inf | 37 - OptionRomPkg/OptionRomPkg.dsc | 7 +- OvmfPkg/OvmfPkgIa32.dsc| 2 +- OvmfPkg/OvmfPkgIa32X64.dsc | 2 +- OvmfPkg/OvmfPkgX64.dsc | 2 +- OvmfPkg/QemuVideoDxe/Gop.c | 84 ++- OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf | 3 +- 24 files changed, 2242 insertions(+), 1627 deletions(-) create mode 100644 MdeModulePkg/Include/Library/BltLib.h create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf create mode 100644 MdeModulePkg/Library/GopBltLib/GopBltLib.c create mode 100644 MdeModulePkg/Library/GopBltLib/GopBltLib.inf create mode 100644 MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c create mode 100644 MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c create mode 100644 MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h create mode 100644 MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf delete mode 100644 OptionRomPkg/Include/Library/BltLib.h delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.c delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.inf -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 6/8] OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API
The BltConfigure() API caches the video frame buffer meta data which
forbids the library to be implemented to support re-entry.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Laszlo Ersek
Cc: Jordan Justen
---
.../Application/BltLibSample/BltLibSample.c| 129 +++---
OptionRomPkg/Include/Library/BltLib.h | 151 +++---
.../Library/FrameBufferBltLib/FrameBufferBltLib.c | 514 +++--
OptionRomPkg/Library/GopBltLib/GopBltLib.c | 289 ++--
OvmfPkg/QemuVideoDxe/Gop.c | 13 +-
5 files changed, 576 insertions(+), 520 deletions(-)
diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
index 333b054..3c7e392 100644
--- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
+++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
UINT64
@@ -68,8 +69,8 @@ Rand32 (
VOID
TestFills (
- UINT32 HorizontalResolution,
- UINT32 VerticalResolution
+ IN VOID *FrameBuffer,
+ IN EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
)
{
EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color;
@@ -79,44 +80,45 @@ TestFills (
UINTN W;
UINTN H;
- for (Loop = 0; Loop < 1; Loop++) {
-W = HorizontalResolution - (Rand32 () % HorizontalResolution);
-H = VerticalResolution - (Rand32 () % VerticalResolution);
-if (W != HorizontalResolution) {
- X = Rand32 () % (HorizontalResolution - W);
+ for (Loop = 0; Loop < 1000; Loop++) {
+W = FrameBufferInfo->HorizontalResolution - (Rand32 () %
FrameBufferInfo->HorizontalResolution);
+H = FrameBufferInfo->VerticalResolution - (Rand32 () %
FrameBufferInfo->VerticalResolution);
+if (W != FrameBufferInfo->HorizontalResolution) {
+ X = Rand32 () % (FrameBufferInfo->HorizontalResolution - W);
} else {
X = 0;
}
-if (H != VerticalResolution) {
- Y = Rand32 () % (VerticalResolution - H);
+if (H != FrameBufferInfo->VerticalResolution) {
+ Y = Rand32 () % (FrameBufferInfo->VerticalResolution - H);
} else {
Y = 0;
}
*(UINT32*) (&Color) = Rand32 () & 0xff;
-BltVideoFill (&Color, X, Y, W, H);
+BltVideoFill (FrameBuffer, FrameBufferInfo, &Color, X, Y, W, H);
}
}
VOID
TestColor1 (
- UINT32 HorizontalResolution,
- UINT32 VerticalResolution
+ IN VOID *FrameBuffer,
+ IN EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
)
{
- EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color;
+ EFI_GRAPHICS_OUTPUT_BLT_PIXEL *BltBuffer;
UINTN X;
UINTN Y;
- *(UINT32*) (&Color) = 0;
+ BltBuffer = AllocatePool (sizeof (*BltBuffer) *
FrameBufferInfo->HorizontalResolution);
+ ASSERT (BltBuffer != NULL);
- for (Y = 0; Y < VerticalResolution; Y++) {
-for (X = 0; X < HorizontalResolution; X++) {
- Color.Red = (UINT8) ((X * 0x100) / HorizontalResolution);
- Color.Green = (UINT8) ((Y * 0x100) / VerticalResolution);
- Color.Blue = (UINT8) ((Y * 0x100) / VerticalResolution);
- BltVideoFill (&Color, X, Y, 1, 1);
+ for (Y = 0; Y < FrameBufferInfo->VerticalResolution; Y++) {
+for (X = 0; X < FrameBufferInfo->HorizontalResolution; X++) {
+ BltBuffer[X].Red = (UINT8) ((X * 0x100) /
FrameBufferInfo->HorizontalResolution);
+ BltBuffer[X].Green = (UINT8) ((Y * 0x100) /
FrameBufferInfo->VerticalResolution);
+ BltBuffer[X].Blue = (UINT8) ((Y * 0x100) /
FrameBufferInfo->VerticalResolution);
}
+BltBufferToVideo (FrameBuffer, FrameBufferInfo, BltBuffer, 0, 0, 0, Y,
FrameBufferInfo->HorizontalResolution, 1, 0);
}
}
@@ -176,8 +178,8 @@ GetTriColor (
VOID
TestColor (
- UINT32 HorizontalResolution,
- UINT32 VerticalResolution
+ IN VOID *FrameBuffer,
+ IN EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
)
{
EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color;
@@ -187,34 +189,38 @@ TestColor (
UINTN LineWidth, TriWidth;
UINTN TriHeight;
UINT32 ColorDist;
+ EFI_GRAPHICS_OUTPUT_BLT_PIXEL *BltBuffer;
*(UINT32*) (&Color) = 0;
- BltVideoFill (&Color, 0, 0, HorizontalResolution, VerticalResolution);
+ BltVideoFill (FrameBuffer, FrameBufferInfo, &Color, 0, 0,
FrameBufferInfo->HorizontalResolution, FrameBufferInfo->VerticalResolution);
TriWidth = (UINTN) DivU64x32 (
- MultU64x32 (11547005, (UINT32) VerticalResolution),
+ MultU64x32 (11547005,
FrameBufferInfo->HorizontalResolution),
1000
[edk2] [Patch 3/8] OptionRomPkg: Fix a bug in BltVideoToVideo operation
The bug can be reproduced by the BltLibSample application TestMove1() test case.
The old code cannot handle the case when the source and destination video is
overlapped.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Laszlo Ersek
Cc: Jordan Justen
---
OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
b/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
index 7fd8196..49ef568 100644
--- a/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
+++ b/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
@@ -694,6 +694,11 @@ BltLibVideoToVideo (
LineStride = mBltLibWidthInBytes;
if (Destination > Source) {
+//
+// Copy from last line to avoid source is corrupted by copying
+//
+Source += Height * LineStride;
+Destination += Height * LineStride;
LineStride = -LineStride;
}
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 7/8] MdeModulePkg: Move BltLib from OptionRomPkg to MdeModulePkg
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Laszlo Ersek Cc: Jordan Justen Cc: Kinney Michael Cc: Feng Tian --- MdeModulePkg/Include/Library/BltLib.h | 147 ++ .../Library/FrameBufferBltLib/FrameBufferBltLib.c | 573 + .../FrameBufferBltLib/FrameBufferBltLib.inf| 33 ++ MdeModulePkg/Library/GopBltLib/GopBltLib.c | 324 MdeModulePkg/Library/GopBltLib/GopBltLib.inf | 35 ++ MdeModulePkg/MdeModulePkg.dec | 4 + MdeModulePkg/MdeModulePkg.dsc | 2 + .../Application/BltLibSample/BltLibSample.inf | 4 +- OptionRomPkg/Include/Library/BltLib.h | 147 -- .../Library/FrameBufferBltLib/FrameBufferBltLib.c | 573 - .../FrameBufferBltLib/FrameBufferBltLib.inf| 35 -- OptionRomPkg/Library/GopBltLib/GopBltLib.c | 324 OptionRomPkg/Library/GopBltLib/GopBltLib.inf | 37 -- OptionRomPkg/OptionRomPkg.dsc | 7 +- OvmfPkg/OvmfPkgIa32.dsc| 2 +- OvmfPkg/OvmfPkgIa32X64.dsc | 2 +- OvmfPkg/OvmfPkgX64.dsc | 2 +- OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf | 3 +- 18 files changed, 1127 insertions(+), 1127 deletions(-) create mode 100644 MdeModulePkg/Include/Library/BltLib.h create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf create mode 100644 MdeModulePkg/Library/GopBltLib/GopBltLib.c create mode 100644 MdeModulePkg/Library/GopBltLib/GopBltLib.inf delete mode 100644 OptionRomPkg/Include/Library/BltLib.h delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.c delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.inf diff --git a/MdeModulePkg/Include/Library/BltLib.h b/MdeModulePkg/Include/Library/BltLib.h new file mode 100644 index 000..65ea9d4 --- /dev/null +++ b/MdeModulePkg/Include/Library/BltLib.h @@ -0,0 +1,147 @@ +/** @file + Library for performing video blt operations + + Copyright (c) 2009 - 2015, 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 + http://opensource.org/licenses/bsd-license.php + + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. + +**/ + +#ifndef __BLT_LIB__ +#define __BLT_LIB__ + +#include + +/** + Performs a UEFI Graphics Output Protocol Blt Video Fill. + + @param[in] FrameBuffer Pointer to the start of the frame buffer + @param[in] FrameBufferInfo Describes the frame buffer characteristics + @param[in] Color Color to fill the region with + @param[in] DestinationXX location to start fill operation + @param[in] DestinationYY location to start fill operation + @param[in] Width Width (in pixels) to fill + @param[in] Height Height to fill + + @retval EFI_DEVICE_ERROR A hardware error occured + @retval EFI_INVALID_PARAMETER Invalid parameter passed in + @retval EFI_SUCCESS Blt operation success + +**/ +EFI_STATUS +EFIAPI +BltVideoFill ( + IN VOID *FrameBuffer, + IN EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo, + IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL *Color, + IN UINTN DestinationX, + IN UINTN DestinationY, + IN UINTN Width, + IN UINTN Height + ); + +/** + Performs a UEFI Graphics Output Protocol Blt Video to Buffer operation. + + @param[in] FrameBuffer Pointer to the start of the frame buffer + @param[in] FrameBufferInfo Describes the frame buffer characteristics + @param[out] BltBuffer Output buffer for pixel color data + @param[in] SourceX X location within video + @param[in] SourceY Y location within video + @param[in] DestinationXX location within BltBuffer + @param[in] DestinationYY location within BltBuffer + @param[in] Width Width (in pixels) + @param[in] Height Height + @param[in] Delta Number of bytes in a row of BltBuffer + + @retval EFI_DEVICE_ERROR A hardware error occured + @retval EFI_INVALID_PARAMETER Invalid parameter passed in + @retval EFI_SUCCESS Blt operation success + +**/ +EFI_STATUS +EFIAPI +BltVideoToBuffer ( + IN VOID *FrameBuffer,
[edk2] [Patch 4/8] OptionRomPkg: Remove BltLibGetSizes() interface from BltLib
Since the library consumes the GOP mode structure which is provided by
library caller, library caller doesn't need to ask the library about
the screen resolution, instead, it can directly get from the GOP mode
structure.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Laszlo Ersek
Cc: Jordan Justen
---
.../Application/BltLibSample/BltLibSample.c| 64 ++
OptionRomPkg/Include/Library/BltLib.h | 20 +--
.../Library/FrameBufferBltLib/FrameBufferBltLib.c | 27 -
OptionRomPkg/Library/GopBltLib/GopBltLib.c | 32 +--
4 files changed, 32 insertions(+), 111 deletions(-)
diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
index 09fea62..3409b2c 100644
--- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
+++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
@@ -68,7 +68,8 @@ Rand32 (
VOID
TestFills (
- VOID
+ UINT32 HorizontalResolution,
+ UINT32 VerticalResolution
)
{
EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color;
@@ -77,20 +78,17 @@ TestFills (
UINTN Y;
UINTN W;
UINTN H;
- UINTN Width;
- UINTN Height;
- BltLibGetSizes (&Width, &Height);
for (Loop = 0; Loop < 1; Loop++) {
-W = Width - (Rand32 () % Width);
-H = Height - (Rand32 () % Height);
-if (W != Width) {
- X = Rand32 () % (Width - W);
+W = HorizontalResolution - (Rand32 () % HorizontalResolution);
+H = VerticalResolution - (Rand32 () % VerticalResolution);
+if (W != HorizontalResolution) {
+ X = Rand32 () % (HorizontalResolution - W);
} else {
X = 0;
}
-if (H != Height) {
- Y = Rand32 () % (Height - H);
+if (H != VerticalResolution) {
+ Y = Rand32 () % (VerticalResolution - H);
} else {
Y = 0;
}
@@ -102,23 +100,21 @@ TestFills (
VOID
TestColor1 (
- VOID
+ UINT32 HorizontalResolution,
+ UINT32 VerticalResolution
)
{
EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color;
UINTN X;
UINTN Y;
- UINTN Width;
- UINTN Height;
- BltLibGetSizes (&Width, &Height);
*(UINT32*) (&Color) = 0;
- for (Y = 0; Y < Height; Y++) {
-for (X = 0; X < Width; X++) {
- Color.Red = (UINT8) ((X * 0x100) / Width);
- Color.Green = (UINT8) ((Y * 0x100) / Height);
- Color.Blue = (UINT8) ((Y * 0x100) / Height);
+ for (Y = 0; Y < VerticalResolution; Y++) {
+for (X = 0; X < HorizontalResolution; X++) {
+ Color.Red = (UINT8) ((X * 0x100) / HorizontalResolution);
+ Color.Green = (UINT8) ((Y * 0x100) / VerticalResolution);
+ Color.Blue = (UINT8) ((Y * 0x100) / VerticalResolution);
BltLibVideoFill (&Color, X, Y, 1, 1);
}
}
@@ -180,43 +176,43 @@ GetTriColor (
VOID
TestColor (
- VOID
+ UINT32 HorizontalResolution,
+ UINT32 VerticalResolution
)
{
EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color;
UINTN X, Y;
UINTN X1, X2, X3;
UINTN Y1, Y2;
- UINTN LineWidth, TriWidth, ScreenWidth;
- UINTN TriHeight, ScreenHeight;
+ UINTN LineWidth, TriWidth;
+ UINTN TriHeight;
UINT32 ColorDist;
- BltLibGetSizes (&ScreenWidth, &ScreenHeight);
*(UINT32*) (&Color) = 0;
- BltLibVideoFill (&Color, 0, 0, ScreenWidth, ScreenHeight);
+ BltLibVideoFill (&Color, 0, 0, HorizontalResolution, VerticalResolution);
TriWidth = (UINTN) DivU64x32 (
- MultU64x32 (11547005, (UINT32) ScreenHeight),
+ MultU64x32 (11547005, (UINT32) VerticalResolution),
1000
);
TriHeight = (UINTN) DivU64x32 (
-MultU64x32 (8660254, (UINT32) ScreenWidth),
+MultU64x32 (8660254, (UINT32) HorizontalResolution),
1000
);
- if (TriWidth > ScreenWidth) {
+ if (TriWidth > HorizontalResolution) {
DEBUG ((EFI_D_INFO, "TriWidth at %d was too big\n", TriWidth));
-TriWidth = ScreenWidth;
- } else if (TriHeight > ScreenHeight) {
+TriWidth = HorizontalResolution;
+ } else if (TriHeight > VerticalResolution) {
DEBUG ((EFI_D_INFO, "TriHeight at %d was too big\n", TriHeight));
-TriHeight = ScreenHeight;
+TriHeight = VerticalResolution;
}
DEBUG ((EFI_D_INFO, "Triangle Width: %d; Height: %d\n", TriWidth,
TriHeight));
- X1 = (ScreenWidth - TriWidth) / 2;
+ X1 = (HorizontalResolution - T
[edk2] [Patch 5/8] OptionRomPkg/OvmfPkg: BltLib API refinement
API removal:
BltLibVideoToBltBuffer
BltLibBufferToVideo
BltLibGopBlt
API rename:
BltLibVideoToBltBufferEx -> BltVideoToBuffer
BltLibBufferToVideoEx -> BltBufferToVideo
BltLibVideoToVideo -> BltVideoToVideo
BltLibVideoFill -> BltVideoFill
BltLibConfigure -> BltConfigure
The 3 APIs in above are removed because their functionality overlaps with
the other APIs.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Laszlo Ersek
Cc: Jordan Justen
---
.../Application/BltLibSample/BltLibSample.c| 16 +-
OptionRomPkg/Include/Library/BltLib.h | 101 +
.../Library/FrameBufferBltLib/FrameBufferBltLib.c | 168 +
OptionRomPkg/Library/GopBltLib/GopBltLib.c | 138 +
OvmfPkg/QemuVideoDxe/Gop.c | 73 ++---
5 files changed, 74 insertions(+), 422 deletions(-)
diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
index 3409b2c..333b054 100644
--- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
+++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
@@ -93,7 +93,7 @@ TestFills (
Y = 0;
}
*(UINT32*) (&Color) = Rand32 () & 0xff;
-BltLibVideoFill (&Color, X, Y, W, H);
+BltVideoFill (&Color, X, Y, W, H);
}
}
@@ -115,7 +115,7 @@ TestColor1 (
Color.Red = (UINT8) ((X * 0x100) / HorizontalResolution);
Color.Green = (UINT8) ((Y * 0x100) / VerticalResolution);
Color.Blue = (UINT8) ((Y * 0x100) / VerticalResolution);
- BltLibVideoFill (&Color, X, Y, 1, 1);
+ BltVideoFill (&Color, X, Y, 1, 1);
}
}
}
@@ -189,7 +189,7 @@ TestColor (
UINT32 ColorDist;
*(UINT32*) (&Color) = 0;
- BltLibVideoFill (&Color, 0, 0, HorizontalResolution, VerticalResolution);
+ BltVideoFill (&Color, 0, 0, HorizontalResolution, VerticalResolution);
TriWidth = (UINTN) DivU64x32 (
MultU64x32 (11547005, (UINT32) VerticalResolution),
@@ -231,7 +231,7 @@ TestColor (
ColorDist = Uint32Dist(X3 - X, Y1 - Y);
Color.Blue = GetTriColor (ColorDist, TriWidth);
- BltLibVideoFill (&Color, X, Y, 1, 1);
+ BltVideoFill (&Color, X, Y, 1, 1);
}
}
@@ -255,14 +255,14 @@ TestMove1 (
Width = 100;
Height = 20;
- BltLibVideoFill (&Black, 0, 0, HorizontalResolution, VerticalResolution);
+ BltVideoFill (&Black, 0, 0, HorizontalResolution, VerticalResolution);
*(UINT32 *) &Blue = 0;
Blue.Blue = 0xff;
- BltLibVideoFill (&Blue, 0, 0, Width, Height);
+ BltVideoFill (&Blue, 0, 0, Width, Height);
for (X = 1, Y = 1; X < HorizontalResolution && Y < VerticalResolution; X++,
Y++) {
-BltLibVideoToVideo (X - 1, Y - 1, X, Y, Width, Height);
+BltVideoToVideo (X - 1, Y - 1, X, Y, Width, Height);
gBS->Stall (100);
}
gBS->Stall (1000 * 1000 * 2);
@@ -298,7 +298,7 @@ UefiMain (
return Status;
}
- Status = BltLibConfigure (
+ Status = BltConfigure (
(VOID*)(UINTN) Gop->Mode->FrameBufferBase,
Gop->Mode->Info
);
diff --git a/OptionRomPkg/Include/Library/BltLib.h
b/OptionRomPkg/Include/Library/BltLib.h
index 8bc5d91..230dac2 100644
--- a/OptionRomPkg/Include/Library/BltLib.h
+++ b/OptionRomPkg/Include/Library/BltLib.h
@@ -30,48 +30,11 @@
**/
EFI_STATUS
EFIAPI
-BltLibConfigure (
+BltConfigure (
IN VOID *FrameBuffer,
IN EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *FrameBufferInfo
);
-
-/**
- Performs a UEFI Graphics Output Protocol Blt operation.
-
- @param[in,out] BltBuffer - The data to transfer to screen
- @param[in] BltOperation - The operation to perform
- @param[in] SourceX - The X coordinate of the source for
BltOperation
- @param[in] SourceY - The Y coordinate of the source for
BltOperation
- @param[in] DestinationX - The X coordinate of the destination for
BltOperation
- @param[in] DestinationY - The Y coordinate of the destination for
BltOperation
- @param[in] Width - The width of a rectangle in the blt rectangle
in pixels
- @param[in] Height- The height of a rectangle in the blt
rectangle in pixels
- @param[in] Delta - Not used for EfiBltVideoFill and
EfiBltVideoToVideo operation.
- If a Delta of 0 is used, the entire BltBuffer
will be operated on.
- If a subrectangle of the BltBuffer is used,
then Delta represents
- the number of bytes in a row of the BltBuffer.
-
- @retval EFI_DEVICE_ERROR - A hardware error occured
- @retval EFI_INVALID_PARAMETER - Invalid parameter passed in
- @retval EFI_SUCCESS - Blt operation success
-
-**/
-EFI_STATUS
-EFIAPI
-BltLibGopBlt (
- IN OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL *BltBuffer, OPTIONAL
- IN EFI_GRAPHICS_OUTPUT_BLT_OPERA
[edk2] [Patch 8/8] MdeModulePkg: Add GraphicsOutputDxe driver
The driver consumes the GraphicsInfo HOB and produces GOP protocol.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Feng Tian
---
MdeModulePkg/MdeModulePkg.dsc | 4 +
.../Console/GraphicsOutputDxe/ComponentName.c | 190 ++
.../Console/GraphicsOutputDxe/GraphicsOutput.c | 659 +
.../Console/GraphicsOutputDxe/GraphicsOutput.h | 53 ++
.../GraphicsOutputDxe/GraphicsOutputDxe.inf| 57 ++
5 files changed, 963 insertions(+)
create mode 100644
MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
create mode 100644
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c
create mode 100644
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h
create mode 100644
MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index e475dc1..cd3e21e 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -290,6 +290,10 @@
MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
+ MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf {
+
+ BltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
+ }
MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
MdeModulePkg/Universal/DebugPortDxe/DebugPortDxe.inf
MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
diff --git a/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
b/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
new file mode 100644
index 000..9f1c79d
--- /dev/null
+++ b/MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c
@@ -0,0 +1,190 @@
+/** @file
+ UEFI Component Name(2) protocol implementation for the generic GOP driver.
+
+Copyright (c) 2015, 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
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+
+**/
+
+#include
+#include
+
+extern EFI_COMPONENT_NAME_PROTOCOL mGraphicsOutputComponentName;
+extern EFI_COMPONENT_NAME2_PROTOCOL mGraphicsOutputComponentName2;
+
+//
+// Driver name table for GraphicsOutput module.
+// It is shared by the implementation of ComponentName & ComponentName2
Protocol.
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE
mGraphicsOutputDriverNameTable[] = {
+ {
+"eng;en",
+L"Generic Graphics Output Driver"
+ },
+ {
+NULL,
+NULL
+ }
+};
+
+/**
+ Retrieves a Unicode string that is the user readable name of the driver.
+
+ This function retrieves the user readable name of a driver in the form of a
+ Unicode string. If the driver specified by This has a user readable name in
+ the language specified by Language, then a pointer to the driver name is
+ returned in DriverName, and EFI_SUCCESS is returned. If the driver specified
+ by This does not support the language specified by Language,
+ then EFI_UNSUPPORTED is returned.
+
+ @param This[in] A pointer to the EFI_COMPONENT_NAME2_PROTOCOL
or
+EFI_COMPONENT_NAME_PROTOCOL instance.
+
+ @param Language[in] A pointer to a Null-terminated ASCII string
+array indicating the language. This is the
+language of the driver name that the caller is
+requesting, and it must match one of the
+languages specified in SupportedLanguages. The
+number of languages supported by a driver is up
+to the driver writer. Language is specified
+in RFC 4646 or ISO 639-2 language code format.
+
+ @param DriverName[out] A pointer to the Unicode string to return.
+This Unicode string is the name of the
+driver specified by This in the language
+specified by Language.
+
+ @retval EFI_SUCCESS The Unicode string for the Driver specified by
+This and the language specified by Language was
+returned in DriverName.
+
+ @retval EFI_INVALID_PARAMETER Language is NULL.
+
+ @retval EFI_INVALID_PARAMETER DriverName is NULL.
+
+ @retval EFI_UNSUPPORTED The driver specified by This does not support
+
[edk2] [Patch 0/8] Move BltLib to MdeModulePkg and create GraphicsOutputDxe driver
The patch serials refined the BltLib and moved it to MdeModulePkg. Based on the BltLib, the patch created the GraphicsOutputDxe driver which consumes the GraphicsInfo HOB. Ruiyu Ni (8): OptionRomPkg: Refine FrameBufferBltLib to use UINT8* instead of VOID* OptionRomPkg: Add video move test case to BltLibSample application OptionRomPkg: Fix a bug in BltVideoToVideo operation OptionRomPkg: Remove BltLibGetSizes() interface from BltLib OptionRomPkg/OvmfPkg: BltLib API refinement OptionRomPkg/OvmfPkg: Remove BltLib::BltConfigure API MdeModulePkg: Move BltLib from OptionRomPkg to MdeModulePkg MdeModulePkg: Add GraphicsOutputDxe driver MdeModulePkg/Include/Library/BltLib.h | 147 .../Library/FrameBufferBltLib/FrameBufferBltLib.c | 573 .../FrameBufferBltLib/FrameBufferBltLib.inf| 33 + MdeModulePkg/Library/GopBltLib/GopBltLib.c | 324 + MdeModulePkg/Library/GopBltLib/GopBltLib.inf | 35 + MdeModulePkg/MdeModulePkg.dec | 4 + MdeModulePkg/MdeModulePkg.dsc | 6 + .../Console/GraphicsOutputDxe/ComponentName.c | 190 ++ .../Console/GraphicsOutputDxe/GraphicsOutput.c | 659 ++ .../Console/GraphicsOutputDxe/GraphicsOutput.h | 53 ++ .../GraphicsOutputDxe/GraphicsOutputDxe.inf| 57 ++ .../Application/BltLibSample/BltLibSample.c| 148 ++-- .../Application/BltLibSample/BltLibSample.inf | 4 +- OptionRomPkg/Include/Library/BltLib.h | 259 --- .../Library/FrameBufferBltLib/FrameBufferBltLib.c | 750 - .../FrameBufferBltLib/FrameBufferBltLib.inf| 35 - OptionRomPkg/Library/GopBltLib/GopBltLib.c | 455 - OptionRomPkg/Library/GopBltLib/GopBltLib.inf | 37 - OptionRomPkg/OptionRomPkg.dsc | 7 +- OvmfPkg/OvmfPkgIa32.dsc| 2 +- OvmfPkg/OvmfPkgIa32X64.dsc | 2 +- OvmfPkg/OvmfPkgX64.dsc | 2 +- OvmfPkg/QemuVideoDxe/Gop.c | 84 ++- OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf | 3 +- 24 files changed, 2242 insertions(+), 1627 deletions(-) create mode 100644 MdeModulePkg/Include/Library/BltLib.h create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.c create mode 100644 MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf create mode 100644 MdeModulePkg/Library/GopBltLib/GopBltLib.c create mode 100644 MdeModulePkg/Library/GopBltLib/GopBltLib.inf create mode 100644 MdeModulePkg/Universal/Console/GraphicsOutputDxe/ComponentName.c create mode 100644 MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.c create mode 100644 MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutput.h create mode 100644 MdeModulePkg/Universal/Console/GraphicsOutputDxe/GraphicsOutputDxe.inf delete mode 100644 OptionRomPkg/Include/Library/BltLib.h delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c delete mode 100644 OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.c delete mode 100644 OptionRomPkg/Library/GopBltLib/GopBltLib.inf -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 2/8] OptionRomPkg: Add video move test case to BltLibSample application
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Laszlo Ersek
Cc: Jordan Justen
---
.../Application/BltLibSample/BltLibSample.c| 33 ++
1 file changed, 33 insertions(+)
diff --git a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
index c21eb7a..09fea62 100644
--- a/OptionRomPkg/Application/BltLibSample/BltLibSample.c
+++ b/OptionRomPkg/Application/BltLibSample/BltLibSample.c
@@ -238,9 +238,40 @@ TestColor (
BltLibVideoFill (&Color, X, Y, 1, 1);
}
}
+
+ gBS->Stall (1000 * 1000);
}
+VOID
+TestMove1 (
+ UINT32 HorizontalResolution,
+ UINT32 VerticalResolution
+ )
+{
+ EFI_GRAPHICS_OUTPUT_BLT_PIXEL Blue;
+ EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
+ UINTN X, Y;
+ UINTN Width;
+ UINTN Height;
+
+ *(UINT32 *) &Black = 0;
+ Width = 100;
+ Height = 20;
+
+ BltLibVideoFill (&Black, 0, 0, HorizontalResolution, VerticalResolution);
+
+ *(UINT32 *) &Blue = 0;
+ Blue.Blue = 0xff;
+ BltLibVideoFill (&Blue, 0, 0, Width, Height);
+
+ for (X = 1, Y = 1; X < HorizontalResolution && Y < VerticalResolution; X++,
Y++) {
+BltLibVideoToVideo (X - 1, Y - 1, X, Y, Width, Height);
+gBS->Stall (100);
+ }
+ gBS->Stall (1000 * 1000 * 2);
+}
+
/**
The user Entry Point for Application. The user code starts with this function
as the real entry point for the application.
@@ -283,5 +314,7 @@ UefiMain (
TestColor ();
+ TestMove1 (Gop->Mode->Info->HorizontalResolution,
Gop->Mode->Info->VerticalResolution);
+
return EFI_SUCCESS;
}
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 1/8] OptionRomPkg: Refine FrameBufferBltLib to use UINT8* instead of VOID*
Using UINT8* can remove the unnecessary VOID* type cast.
The patch also rename the BltMemSrc/BltMemDest to Source/Destination.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni
Cc: Laszlo Ersek
Cc: Jordan Justen
---
.../Library/FrameBufferBltLib/FrameBufferBltLib.c | 131 +
1 file changed, 58 insertions(+), 73 deletions(-)
diff --git a/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
b/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
index 955ae3d..7fd8196 100644
--- a/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
+++ b/OptionRomPkg/Library/FrameBufferBltLib/FrameBufferBltLib.c
@@ -1,7 +1,7 @@
/** @file
FrameBufferBltLib - Library to perform blt operations on a frame buffer.
- Copyright (c) 2007 - 2011, Intel Corporation. All rights reserved.
+ Copyright (c) 2007 - 2015, 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
@@ -12,11 +12,12 @@
**/
-#include "PiDxe.h"
+#include
#include
#include
-#include
#include
+#include
+#include
#if 0
#define VDEBUG DEBUG
@@ -38,7 +39,6 @@ EFI_PIXEL_BITMASK mPixelBitMasks;
INTNmPixelShl[4]; // R-G-B-Rsvd
INTNmPixelShr[4]; // R-G-B-Rsvd
-
VOID
ConfigurePixelBitMaskFormat (
IN EFI_PIXEL_BITMASK *BitMask
@@ -73,7 +73,6 @@ ConfigurePixelBitMaskFormat (
CopyMem (&mPixelBitMasks, BitMask, sizeof (*BitMask));
}
-
/**
Configure the FrameBufferLib instance
@@ -126,7 +125,6 @@ BltLibConfigure (
return EFI_SUCCESS;
}
-
/**
Performs a UEFI Graphics Output Protocol Blt operation.
@@ -210,7 +208,6 @@ BltLibGopBlt (
}
}
-
/**
Performs a UEFI Graphics Output Protocol Blt Video Fill.
@@ -235,8 +232,8 @@ BltLibVideoFill (
IN UINTN Height
)
{
- UINTN DstY;
- VOID*BltMemDst;
+ UINTN Y;
+ UINT8 *Destination;
UINTN X;
UINT8 Uint8;
UINT32 Uint32;
@@ -300,7 +297,7 @@ BltLibVideoFill (
}
}
if (UseWideFill) {
- SetMem ((VOID*) &WideFill, sizeof (WideFill), Uint8);
+ SetMem (&WideFill, sizeof (WideFill), Uint8);
}
}
@@ -308,31 +305,31 @@ BltLibVideoFill (
VDEBUG ((EFI_D_INFO, "VideoFill (wide, one-shot)\n"));
Offset = DestinationY * mBltLibWidthInPixels;
Offset = mBltLibBytesPerPixel * Offset;
-BltMemDst = (VOID*) (mBltLibFrameBuffer + Offset);
+Destination = mBltLibFrameBuffer + Offset;
SizeInBytes = WidthInBytes * Height;
if (SizeInBytes >= 8) {
- SetMem32 (BltMemDst, SizeInBytes & ~3, (UINT32) WideFill);
- SizeInBytes = SizeInBytes & 3;
+ SetMem32 (Destination, SizeInBytes & ~3, (UINT32) WideFill);
+ SizeInBytes &= 3;
}
if (SizeInBytes > 0) {
- SetMem (BltMemDst, SizeInBytes, (UINT8)(UINTN) WideFill);
+ SetMem (Destination, SizeInBytes, (UINT8)(UINTN) WideFill);
}
} else {
LineBufferReady = FALSE;
-for (DstY = DestinationY; DstY < (Height + DestinationY); DstY++) {
- Offset = (DstY * mBltLibWidthInPixels) + DestinationX;
+for (Y = DestinationY; Y < (Height + DestinationY); Y++) {
+ Offset = (Y * mBltLibWidthInPixels) + DestinationX;
Offset = mBltLibBytesPerPixel * Offset;
- BltMemDst = (VOID*) (mBltLibFrameBuffer + Offset);
+ Destination = mBltLibFrameBuffer + Offset;
- if (UseWideFill && (((UINTN) BltMemDst & 7) == 0)) {
+ if (UseWideFill && (((UINTN) Destination & 7) == 0)) {
VDEBUG ((EFI_D_INFO, "VideoFill (wide)\n"));
SizeInBytes = WidthInBytes;
if (SizeInBytes >= 8) {
- SetMem64 (BltMemDst, SizeInBytes & ~7, WideFill);
- SizeInBytes = SizeInBytes & 7;
+ SetMem64 (Destination, SizeInBytes & ~7, WideFill);
+ SizeInBytes &= 7;
}
if (SizeInBytes > 0) {
- CopyMem (BltMemDst, (VOID*) &WideFill, SizeInBytes);
+ CopyMem (Destination, &WideFill, SizeInBytes);
}
} else {
VDEBUG ((EFI_D_INFO, "VideoFill (not wide)\n"));
@@ -344,11 +341,11 @@ BltLibVideoFill (
mBltLibLineBuffer,
MIN (X, Width - X) * mBltLibBytesPerPixel
);
-X = X + MIN (X, Width - X);
+X += MIN (X, Width - X);
}
LineBufferReady = TRUE;
}
-CopyMem (BltMemDst, mBltLibLineBuffer, WidthInBytes);
+CopyMem (Destination, mBltLibLineBuffer, WidthInBytes);
}
}
}
@@ -356,7 +353,6 @@ BltLibVideoFill (
return EFI_SUCCESS;
}
-
/**
Performs a UEFI G
Re: [edk2] [PATCH] BaseTools GCC: prevent unaligned memory accesses on ARM GCC 4.6
On 17 August 2015 at 13:43, Leif Lindholm wrote: > On Mon, Aug 17, 2015 at 01:09:20PM +0200, Ard Biesheuvel wrote: >> In GCC 4.7, a feature was added to the ARM backend that allows >> unaligned loads and stores to be emitted. Since it is enabled by >> default on ARMv6 and later CPUs, and since such code is not suitable >> in our case (i.e., bare metal code), we must disable it by passing the >> -mno-unaligned-access option if we are using GCC 4.7 or later. >> >> However, this particular feature and its enabling by default have been >> backported to version 4.6 by Linaro. Since the Linaro toolchains are >> widely used for ARM development, and also shipped by distros such as >> Ubuntu, we should disable the feature on version 4.6 as well. >> Unfortunately, since the upstream version does not support the feature, >> it also does not understand the -mno-unaligned-access option. >> >> Since GCC sets the builtin #define __ARM_FEATURE_UNALIGNED to 1 when >> -munaligned-access is in effect, we can force the build to fail in this >> case by passing -D__ARM_FEATURE_UNALIGNED=0 on the GCC command line. >> >> This will produce the following error message: >> >> :0:0: error: "__ARM_FEATURE_UNALIGNED" redefined [-Werror] >> :0:0: note: this is the location of the previous definition >> >> and terminate the build. > > Thanks Ard. > > This patch may cause some existing builds to fail, but they will be > builds that were previously at risk of unexpected runtime exceptions. > Those builds can also easily be switched to the GCC47 profile instead, > generating safe binaries. (May be worth adding that to the message > when committing?) > > Reviewed-by: Leif Lindholm > Thanks Committed as SVN r18228 (with your addition incorporated into the commit log) -- Ard. >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Ard Biesheuvel >> --- >> 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 859fbe14ad59..dd44de033519 100644 >> --- a/BaseTools/Conf/tools_def.template >> +++ b/BaseTools/Conf/tools_def.template >> @@ -4255,8 +4255,8 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS = >> DEF(GCC48_AARCH64_ASLDLINK_FLAGS) >> *_GCC46_ARM_RC_FLAGS = DEF(GCC_ARM_RC_FLAGS) >> *_GCC46_ARM_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) >> DEF(GCC_VFRPP_FLAGS) >> >> - DEBUG_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -O0 >> -RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) >> -Wno-unused-but-set-variable >> + DEBUG_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) >> -D__ARM_FEATURE_UNALIGNED=0 -O0 >> +RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) >> -D__ARM_FEATURE_UNALIGNED=0 -Wno-unused-but-set-variable >> >> >> >> # >> -- >> 1.9.1 >> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools GCC: prevent unaligned memory accesses on ARM GCC 4.6
On Mon, Aug 17, 2015 at 01:09:20PM +0200, Ard Biesheuvel wrote: > In GCC 4.7, a feature was added to the ARM backend that allows > unaligned loads and stores to be emitted. Since it is enabled by > default on ARMv6 and later CPUs, and since such code is not suitable > in our case (i.e., bare metal code), we must disable it by passing the > -mno-unaligned-access option if we are using GCC 4.7 or later. > > However, this particular feature and its enabling by default have been > backported to version 4.6 by Linaro. Since the Linaro toolchains are > widely used for ARM development, and also shipped by distros such as > Ubuntu, we should disable the feature on version 4.6 as well. > Unfortunately, since the upstream version does not support the feature, > it also does not understand the -mno-unaligned-access option. > > Since GCC sets the builtin #define __ARM_FEATURE_UNALIGNED to 1 when > -munaligned-access is in effect, we can force the build to fail in this > case by passing -D__ARM_FEATURE_UNALIGNED=0 on the GCC command line. > > This will produce the following error message: > > :0:0: error: "__ARM_FEATURE_UNALIGNED" redefined [-Werror] > :0:0: note: this is the location of the previous definition > > and terminate the build. Thanks Ard. This patch may cause some existing builds to fail, but they will be builds that were previously at risk of unexpected runtime exceptions. Those builds can also easily be switched to the GCC47 profile instead, generating safe binaries. (May be worth adding that to the message when committing?) Reviewed-by: Leif Lindholm > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel > --- > 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 859fbe14ad59..dd44de033519 100644 > --- a/BaseTools/Conf/tools_def.template > +++ b/BaseTools/Conf/tools_def.template > @@ -4255,8 +4255,8 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS = > DEF(GCC48_AARCH64_ASLDLINK_FLAGS) > *_GCC46_ARM_RC_FLAGS = DEF(GCC_ARM_RC_FLAGS) > *_GCC46_ARM_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) > DEF(GCC_VFRPP_FLAGS) > > - DEBUG_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -O0 > -RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) > -Wno-unused-but-set-variable > + DEBUG_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) > -D__ARM_FEATURE_UNALIGNED=0 -O0 > +RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) > -D__ARM_FEATURE_UNALIGNED=0 -Wno-unused-but-set-variable > > > > # > -- > 1.9.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] BaseTools GCC: prevent unaligned memory accesses on ARM GCC 4.6
In GCC 4.7, a feature was added to the ARM backend that allows unaligned loads and stores to be emitted. Since it is enabled by default on ARMv6 and later CPUs, and since such code is not suitable in our case (i.e., bare metal code), we must disable it by passing the -mno-unaligned-access option if we are using GCC 4.7 or later. However, this particular feature and its enabling by default have been backported to version 4.6 by Linaro. Since the Linaro toolchains are widely used for ARM development, and also shipped by distros such as Ubuntu, we should disable the feature on version 4.6 as well. Unfortunately, since the upstream version does not support the feature, it also does not understand the -mno-unaligned-access option. Since GCC sets the builtin #define __ARM_FEATURE_UNALIGNED to 1 when -munaligned-access is in effect, we can force the build to fail in this case by passing -D__ARM_FEATURE_UNALIGNED=0 on the GCC command line. This will produce the following error message: :0:0: error: "__ARM_FEATURE_UNALIGNED" redefined [-Werror] :0:0: note: this is the location of the previous definition and terminate the build. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- 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 859fbe14ad59..dd44de033519 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -4255,8 +4255,8 @@ DEFINE GCC49_AARCH64_ASLDLINK_FLAGS = DEF(GCC48_AARCH64_ASLDLINK_FLAGS) *_GCC46_ARM_RC_FLAGS = DEF(GCC_ARM_RC_FLAGS) *_GCC46_ARM_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) - DEBUG_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -O0 -RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -Wno-unused-but-set-variable + DEBUG_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -D__ARM_FEATURE_UNALIGNED=0 -O0 +RELEASE_GCC46_ARM_CC_FLAGS = DEF(GCC46_ARM_CC_FLAGS) -D__ARM_FEATURE_UNALIGNED=0 -Wno-unused-but-set-variable # -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPkg: remove ARMv6 support code
On 17 August 2015 at 12:32, Leif Lindholm wrote:
> Hi Ard,
>
> Thanks for this.
>
> On Mon, Aug 17, 2015 at 09:59:51AM +0200, Ard Biesheuvel wrote:
>> No platforms use the ARMv6 (ARM11) support code anymore. In fact, the
>> only reference to it in ArmPkg.dsc was commented out by Andrew in SVN
>> r11298 (2011-02-03) so it may well be broken. So remove it.
>
> I'm basically happy with this (a few comments inline), but let's give
> people oh say 48h to shout if they disagree?
>
Sounds fine. I will respin with the below changed, and post it on Wednesday.
Thanks,
Ard.
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel
>> ---
>> ArmPkg/ArmPkg.dsc | 4 -
>> ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c | 37 ---
>> .../ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf| 32 ---
>> ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c | 49
>> ArmPkg/Library/ArmLib/Arm11/Arm11Lib.inf | 50
>> ArmPkg/Library/ArmLib/Arm11/Arm11LibMem.c | 135 ---
>> ArmPkg/Library/ArmLib/Arm11/Arm11LibPrePi.inf | 50
>> ArmPkg/Library/ArmLib/Arm11/Arm11LibSec.inf| 46
>> ArmPkg/Library/ArmLib/Arm11/Arm11Support.S | 257
>> -
>> ArmPkg/Library/ArmLib/Arm11/Arm11Support.asm | 157 -
>> 10 files changed, 817 deletions(-)
>> delete mode 100644 ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
>> delete mode 100644
>> ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
>> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
>> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Lib.inf
>> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibMem.c
>> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibPrePi.inf
>> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibSec.inf
>> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Support.S
>> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Support.asm
>>
>> diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
>> index 10e8a1a83d46..1237eed65953 100644
>> --- a/ArmPkg/ArmPkg.dsc
>> +++ b/ArmPkg/ArmPkg.dsc
>> @@ -152,10 +152,6 @@ [Components.ARM]
>>ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Lib.inf
>>ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
>>
>> -# ArmPkg/Library/ArmLib/Arm11/Arm11ArmLib.inf
>> -# ArmPkg/Library/ArmLib/Arm11/Arm11ArmLibPrePi.inf
>> -# ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf
>> -# ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf
>>ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
>>ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf
>>
>> diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
>> b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
>> deleted file mode 100644
>> index a08b7b1aee3f..
>> --- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
>> +++ /dev/null
>> @@ -1,37 +0,0 @@
>> -/** @file
>> -
>> - Copyright (c) 2011-2012, ARM Limited. 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
>> - http://opensource.org/licenses/bsd-license.php
>> -
>> - THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> - WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
>> IMPLIED.
>> -
>> -**/
>> -
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -
>> -VOID
>> -ArmCpuSetup (
>> - IN UINTN MpId
>> - )
>> -{
>> - ASSERT(0); //TODO: Implement me
>> -}
>> -
>> -
>> -VOID
>> -ArmCpuSetupSmpNonSecure (
>> - IN UINTN MpId
>> - )
>> -{
>> - ASSERT(0); //TODO: Implement me
>> -}
>> -
>> diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
>> b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
>> deleted file mode 100644
>> index 3a796c19d0cc..
>> --- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
>> +++ /dev/null
>> @@ -1,32 +0,0 @@
>> -#/* @file
>> -# Copyright (c) 2011-2012, ARM Limited. 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
>> -# http://opensource.org/licenses/bsd-license.php
>> -#
>> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
>> IMPLIED.
>> -#
>> -#*/
>> -
>> -[Defines]
>> - INF_VERSION= 0x00010005
>> - BASE_NAME = Arm11MpCoreLib
>> - FILE_GUID = dc8a69e0-6be0-469c-94d3-5e6d71aa9808
>> - MODULE_TYPE= BASE
>> - VERSION_STRING
Re: [edk2] [PATCH] ArmPkg: remove ARMv6 support code
Hi Ard,
Thanks for this.
On Mon, Aug 17, 2015 at 09:59:51AM +0200, Ard Biesheuvel wrote:
> No platforms use the ARMv6 (ARM11) support code anymore. In fact, the
> only reference to it in ArmPkg.dsc was commented out by Andrew in SVN
> r11298 (2011-02-03) so it may well be broken. So remove it.
I'm basically happy with this (a few comments inline), but let's give
people oh say 48h to shout if they disagree?
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
> ---
> ArmPkg/ArmPkg.dsc | 4 -
> ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c | 37 ---
> .../ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf| 32 ---
> ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c | 49
> ArmPkg/Library/ArmLib/Arm11/Arm11Lib.inf | 50
> ArmPkg/Library/ArmLib/Arm11/Arm11LibMem.c | 135 ---
> ArmPkg/Library/ArmLib/Arm11/Arm11LibPrePi.inf | 50
> ArmPkg/Library/ArmLib/Arm11/Arm11LibSec.inf| 46
> ArmPkg/Library/ArmLib/Arm11/Arm11Support.S | 257
> -
> ArmPkg/Library/ArmLib/Arm11/Arm11Support.asm | 157 -
> 10 files changed, 817 deletions(-)
> delete mode 100644 ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
> delete mode 100644 ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Lib.inf
> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibMem.c
> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibPrePi.inf
> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibSec.inf
> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Support.S
> delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Support.asm
>
> diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
> index 10e8a1a83d46..1237eed65953 100644
> --- a/ArmPkg/ArmPkg.dsc
> +++ b/ArmPkg/ArmPkg.dsc
> @@ -152,10 +152,6 @@ [Components.ARM]
>ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Lib.inf
>ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
>
> -# ArmPkg/Library/ArmLib/Arm11/Arm11ArmLib.inf
> -# ArmPkg/Library/ArmLib/Arm11/Arm11ArmLibPrePi.inf
> -# ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf
> -# ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf
>ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
>ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf
>
> diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
> b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
> deleted file mode 100644
> index a08b7b1aee3f..
> --- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
> +++ /dev/null
> @@ -1,37 +0,0 @@
> -/** @file
> -
> - Copyright (c) 2011-2012, ARM Limited. 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
> - http://opensource.org/licenses/bsd-license.php
> -
> - THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> - WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> -
> -**/
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -VOID
> -ArmCpuSetup (
> - IN UINTN MpId
> - )
> -{
> - ASSERT(0); //TODO: Implement me
> -}
> -
> -
> -VOID
> -ArmCpuSetupSmpNonSecure (
> - IN UINTN MpId
> - )
> -{
> - ASSERT(0); //TODO: Implement me
> -}
> -
> diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
> b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
> deleted file mode 100644
> index 3a796c19d0cc..
> --- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -#/* @file
> -# Copyright (c) 2011-2012, ARM Limited. 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
> -# http://opensource.org/licenses/bsd-license.php
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> -#
> -#*/
> -
> -[Defines]
> - INF_VERSION= 0x00010005
> - BASE_NAME = Arm11MpCoreLib
> - FILE_GUID = dc8a69e0-6be0-469c-94d3-5e6d71aa9808
> - MODULE_TYPE= BASE
> - VERSION_STRING = 1.0
> - LIBRARY_CLASS = ArmCpuLib
> -
> -[Packages]
> - MdePkg/MdePkg.dec
> - ArmPkg/ArmPkg.dec
> -
> -[LibraryClasses]
> - ArmLib
> - IoLib
> - PcdLib
> -
> -[Sources.common]
> - Arm11Lib.c
> diff --git a/ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
Re: [edk2] [PATCH] ArmPkg: Bug fix for UncachedMemoryAllocationLib
On 13 August 2015 at 16:37, Heyi Guo wrote:
> NewNode is the node we found, while Node is the last node in the
> list. Also update mFreedBufferSize.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Heyi Guo
> Cc: Leif Lindholm
> Cc: Ard Biesheuvel
> ---
> .../UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c | 7
> ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
Reviewed-by: Ard Biesheuvel
> diff --git
> a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
> b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
> index e70d877..b859f63 100644
> --- a/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
> +++ b/ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c
> @@ -125,9 +125,10 @@ AllocatePagesFromList (
>}
>// Check if we have found a node that could contain our new allocation
>if (NewNode != NULL) {
> -NewNode->Allocated = TRUE;
> -Node->Allocation = (VOID*)(UINTN)Node->Base;
> -*Allocation= Node->Allocation;
> +NewNode->Allocated = TRUE;
> +NewNode->Allocation = (VOID*)(UINTN)NewNode->Base;
> +*Allocation = NewNode->Allocation;
> +mFreedBufferSize-= NewNode->Pages * EFI_PAGE_SIZE;
> return EFI_SUCCESS;
>}
>
> --
> 2.1.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [patch] MdeModulePkg:Full support F10 hot key in UiApp.
In current UiApp/Boot Maintenance manager,some pages don't support F10,
they use Commit Changes and Exit menu to save changes.Now support F10
in these pages.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi
---
.../Application/UiApp/BootMaint/Bmstring.uni | Bin 41522 -> 42370 bytes
.../Application/UiApp/BootMaint/BootMaint.c| 415 +
.../Application/UiApp/BootMaint/BootMaint.h| 123 +-
.../Application/UiApp/BootMaint/ConsoleOption.c| 147
MdeModulePkg/Application/UiApp/BootMaint/Data.c| 13 +
MdeModulePkg/Application/UiApp/BootMaint/FE.vfr| 24 +-
.../Application/UiApp/BootMaint/FileExplorer.c | 187 --
.../Application/UiApp/BootMaint/FormGuid.h | 32 +-
.../Application/UiApp/BootMaint/UpdatePage.c | 188 ++
.../Application/UiApp/BootMaint/Variable.c | 26 +-
10 files changed, 768 insertions(+), 387 deletions(-)
diff --git a/MdeModulePkg/Application/UiApp/BootMaint/Bmstring.uni
b/MdeModulePkg/Application/UiApp/BootMaint/Bmstring.uni
index
8d9544db450322835972597234a07d76207e1102..f64837b7735f247eb0704c7d21d6639e4eac181b
100644
GIT binary patch
delta 272
zcmdmVgsJH?(}o2p;%*E+4E_w^4Dk%kK-!NXgdqq>`%F$`6Q4YRO=WU|0>|XKBo3gu
z9EN;`as~yUx_pK_h7yJ%Ae}S$p;;qd`M_Mu$y3~@k1X`E^bO4Z^ESQ=-c>}8eKZ+g2*`Wm!MGW(CG+
WPCmdTFuAOu0AvD?=9|1^VIKf3g+yrp
delta 18
acmZoV&9vzV(}o2pn;)dI*iQbkqz?dBZV7Gx
diff --git a/MdeModulePkg/Application/UiApp/BootMaint/BootMaint.c
b/MdeModulePkg/Application/UiApp/BootMaint/BootMaint.c
index 0a6eb6c..fdcdf2d 100644
--- a/MdeModulePkg/Application/UiApp/BootMaint/BootMaint.c
+++ b/MdeModulePkg/Application/UiApp/BootMaint/BootMaint.c
@@ -294,13 +294,16 @@ BootMaintRouteConfig (
EFI_STATUS Status;
UINTN BufferSize;
EFI_HII_CONFIG_ROUTING_PROTOCOL *ConfigRouting;
BMM_FAKE_NV_DATA*NewBmmData;
BMM_FAKE_NV_DATA*OldBmmData;
+ BM_CONSOLE_CONTEXT *NewConsoleContext;
+ BM_TERMINAL_CONTEXT *NewTerminalContext;
BM_MENU_ENTRY *NewMenuEntry;
BM_LOAD_CONTEXT *NewLoadContext;
- UINT16 Index;
+ UINT16 Index;
+ BOOLEAN TerminalAttChange;
BMM_CALLBACK_DATA *Private;
if (Progress == NULL) {
return EFI_INVALID_PARAMETER;
}
@@ -366,18 +369,32 @@ BootMaintRouteConfig (
Index ++) {
NewMenuEntry= BOpt_GetMenuEntry (&BootOptionMenu, Index);
NewLoadContext = (BM_LOAD_CONTEXT *)
NewMenuEntry->VariableContext;
NewLoadContext->Deleted = NewBmmData->BootOptionDel[Index];
NewBmmData->BootOptionDel[Index] = FALSE;
+ NewBmmData->BootOptionDelMark[Index] = FALSE;
}
Var_DelBootOption ();
}
if (CompareMem (NewBmmData->BootOptionOrder, OldBmmData->BootOptionOrder,
sizeof (NewBmmData->BootOptionOrder)) != 0) {
Status = Var_UpdateBootOrder (Private);
- }
+ }
+
+ if (CompareMem (&NewBmmData->BootTimeOut, &OldBmmData->BootTimeOut, sizeof
(NewBmmData->BootTimeOut)) != 0){
+Status = gRT->SetVariable(
+L"Timeout",
+&gEfiGlobalVariableGuid,
+EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+sizeof(UINT16),
+&(NewBmmData->BootTimeOut)
+);
+ASSERT_EFI_ERROR(Status);
+
+Private->BmmOldFakeNVData.BootTimeOut = NewBmmData->BootTimeOut;
+ }
//
// Check data which located in Driver Options Menu and save the settings if
need
//
if (CompareMem (NewBmmData->DriverOptionDel, OldBmmData->DriverOptionDel,
sizeof (NewBmmData->DriverOptionDel)) != 0) {
@@ -386,17 +403,98 @@ BootMaintRouteConfig (
Index++) {
NewMenuEntry= BOpt_GetMenuEntry (&DriverOptionMenu, Index);
NewLoadContext = (BM_LOAD_CONTEXT *)
NewMenuEntry->VariableContext;
NewLoadContext->Deleted = NewBmmData->DriverOptionDel[Index];
NewBmmData->DriverOptionDel[Index] = FALSE;
+ NewBmmData->DriverOptionDelMark[Index] = FALSE;
}
Var_DelDriverOption ();
}
if (CompareMem (NewBmmData->DriverOptionOrder,
OldBmmData->DriverOptionOrder, sizeof (NewBmmData->DriverOptionOrder)) != 0) {
Status = Var_UpdateDriverOrder (Private);
- }
+ }
+
+ if (CompareMem (&NewBmmData->ConsoleOutMode, &OldBmmData->ConsoleOutMode,
sizeof (NewBmmData->ConsoleOutMode)) != 0){
+Var_UpdateConMode(Private);
+ }
+
+ TerminalAttChange = FALSE;
+ for (Index = 0; Index < TerminalMenu.MenuNumber; Index++) {
+
+//
+// only need update modified items
+//
+if (CompareMem (&NewBmmData->COMBaudRate[Index],
&OldBmmData->COMBaudRate[Index], sizeof (NewBmmData->COMBaudRate[Index])) == 0
&&
+
Re: [edk2] [PATCH] ArmPkg/CpuDxe: Disable interrupt before restoring context
On 13 August 2015 at 05:10, Heyi Guo wrote:
> Interrupt must be disabled before we storing ELR and other system
> registers, or else ELR will be overridden by interrupt reentrance.
>
> This bug is critical as we may get occasional exception or dead loop
> when interrupt reentrance occurs:
>
> After increasing SP ... Before popping out registers
> Or
> After restoring ELR
>
> The 1st circumstance could also be resolved by optimizing SP operation
> (Pop out registers before adding SP back), but the 2nd could not be
> resolved by disabling interrupt.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Heyi Guo
> Cc: Leif Lindholm
> Cc: Ard Biesheuvel
> ---
> ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
> b/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
> index 2682f4f..ca6c9a1 100644
> --- a/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
> +++ b/ArmPkg/Drivers/CpuDxe/AArch64/ExceptionSupport.S
> @@ -358,6 +358,14 @@ ASM_PFX(AsmCommonExceptionEntry):
> #define REG_PAIR(REG1, REG2, OFFSET, CONTEXT_SIZE)ldp REG1, REG2, [sp,
> #(OFFSET-CONTEXT_SIZE)]
> #define REG_ONE(REG1, OFFSET, CONTEXT_SIZE) ldur REG1, [sp,
> #(OFFSET-CONTEXT_SIZE)]
>
> + //
> + // Disable interrupt(IRQ and FIQ) before restoring context,
> + // or else the context will be corrupted by interrupt reentrance.
> + // Interrupt mask will be restored from spsr by hardware when we call eret
> + //
> + msr daifset, #3
> + isb
> +
Are you sure this is necessary? According to the ARM ARM
"""
On taking any exception to an Exception level using AArch64, all of
PSTATE.{A, I, F} are set to 1, masking all
interrupts that target that Exception level.
"""
Since you are disabling interrupts after your exception handler
returns, could it be the case that that function is reenabling
interrupts too early?
>// Adjust SP to pop system registers
>add sp, sp, #(GP_CONTEXT_SIZE + FP_CONTEXT_SIZE + SYS_CONTEXT_SIZE)
>ALL_SYS_REGS
> --
> 2.1.4
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 00/15] unify GCC command line options
On 16 August 2015 at 23:48, Scott Duplichan wrote:
> ]Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] wrote:
>
> . . .
>
> ]> Thanks for this much needed tool chain definition consolidation. I ran
> ]> a build test with and without the patch. The build test uses GCC44-49
> ]> and Microsoft tool chains. Log files are here: http://notabs.org/uefi/tmp/.
> ]
> ]Thanks a lot for giving it a spin.
> ]
> ]> Here is what is see in the log files with respect to the patch:
> ]> 1) GCC49 X64 and IA32
> ]>GenFw: ERROR 3000: Invalid Unsupported section alignment.
> ]
> ]I cannot reproduce this, unfortunately. Can you please check whether
> ]your BaseTools are up to date? There have been some changes recently
> ]to GenFw regarding section alignment which may cause this. My gcc is
> ]4.9.1 btw (Ubuntu)
> ]
> ]My Jenkins job has a 'git clean -dxf BaseTools/; make -C BaseTools' at
> ]the beginning so they are up to date, although I think that for GenFw,
> ]the git clean is not necessary. (Some other tools don't rebuild
> ]correctly if any of the common C code is modified)
>
> I used rebuilt BaseTools\Bin\Win32 with up to date source code. The SVN
> GenFw binary gives the same message. Adding some debug prints gives:
>
> Unsupported section alignment: sh_addr=84a0 addralign=64 mCoffOffset=84c0
>
> Objdump -h gives:
> d:\edk2build\edk2\Build\OvmfX64\RELEASE_GCC49\X64\MdeModulePkg\Core\
> Pei\PeiMain\DEBUG\PeiCore.dll: file format elf64-x86-64
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .text 8250 0240 0240 00c0 2**5
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
> 1 .data 03b8 84a0 84a0 8320 2**6
> CONTENTS, ALLOC, LOAD, RELOC, DATA
>
Thanks for the analysis. As it turns out, this only happens in the debug build.
Anyway, as it turns out, GNU ld uses the same optimization that the
comments in ElfConvert[32|64].c allude to, i.e., if a section's
address is not aligned to its alignment, the misalignment should be
preserved. In this example, it means that mPcdInstance [which needs
64-byte alignment] is placed such that it will end up aligned
correctly only if .data is loaded 0x20 bytes into a 0x40 byte aligned
region.
The cause turns out to be the explicit base address for .data. The
following fixes it for me:
diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 4ee6d998532c..eef8325c96a5 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -44,7 +44,8 @@ SECTIONS {
* between these sections is the same in the ELF and the PE/COFF versions of
* this binary.
*/
- .data ALIGN(ALIGNOF(.text)) : ALIGN(CONSTANT(COMMONPAGESIZE)) {
+ . = ALIGN(ALIGNOF(.text));
+ .data : ALIGN(CONSTANT(COMMONPAGESIZE)) {
*(.data .data.* .gnu.linkonce.d.*)
*(.bss .bss.* *COM*)
}
so I will add this change to v2
> ]> 2) GCC46 ARM
> ]>unrecognized command line option '-mno-unaligned-access'
> ]>
> ]
> ]Could you send me the output of gcc -v for this compiler? Mine is
> ]Linaro 4.6.3 which supports it fine, but the feature may be a Linaro
> ]contribution that only made it into 4.7 upstream. In any case, we
> ]cannot tolerate unaligned accesses so we may need to deprecate 4.6 or
> ]mandate that the Linaro version be used if older versions emit
> ]unaligned accesses.
>
> The GCC46 is the Windows hosted build from:
> http://sourceforge.net/projects/edk2developertoolsforwindows/
>
> It is built from the latest gcc 4.6 source code:
> http://ftpmirror.gnu.org/gcc/gcc-4.6.4/gcc-4.6.4.tar.bz2
>
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=d:/edk2build/uefitools/gcc464-arm/bin/../lib/gcc/arm-linux-gnueabi/4.6.4/lto-wrapper.exe
> Target: arm-linux-gnueabi
> Configured with: ../gcc-4.6.4/configure --prefix=/gcc/xgcc
> --libexecdir=/gcc/xgcc/lib --target=arm-linux-gnueabi --disable-werror
> --disable-shared --disable-libssp --disable-bootstrap --disable-nls
> --disable-libquadmath --without-headers --enable-languages=c
> --with-gmp=/gcc/xgcc --with-mpfr=/gcc/xgcc --with-mpc=/gcc/xgcc
> --with-libelf=/gcc/xgcc --with-pkgversion='EDK2 version 1.0' MAKEINFO=missing
> --enable-twoprocess --disable-threads --disable-decimal-float
> --disable-win32-registry --disable-libc --with-windres
> Thread model: single
> gcc version 4.6.4 (EDK2 version 1.0)
>
> Source code for gcc-linaro-4.6-2012.04 shows what you suspected:
> ChangeLog.linaro contains: (insv, extzv): Add unaligned-access support.
>
OK, this sucks.
Linaro dropped the ball on this one IMO. By backporting this issue to
4.6 and enabling it by default, we can no longer have a single 4.6
definition for both compilers, since for the Linaro on we must pass
-mno-unaligned-access and for the stock one we must not pass it.
The best way to fix this is remove 4.6, I think. We could disable the
optimization indirectly by generating code for ARMv5, but I don't
think
Re: [edk2] [PATCH 00/15] Separate variable check service to library
The patch for Vlv2TbltDevicePkg is good. Thanks. Thanks, David | SSG BIOS -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng Sent: Monday, August 17, 2015 4:24 PM To: edk2-devel@lists.01.org Subject: [edk2] [PATCH 00/15] Separate variable check service to library NOTICE: To keep git bisect, the update to platform package Nt32Pkg, OvmfPkg, EmulatorPkg, ArmVirtPkg, ArmPlatformPkg and Vlv2TbltDevicePkg has been split to two patches. For your easy review, the forked code is at g...@github.com:lzeng14/edk2.git branch VariableCheckService. What to do: 1. Add VarCheckLib library and VarCheckUefiLib NULL class library. 2. Update Variable driver to consume the separated VarCheckLib. 3. Update platform package to add VarCheckLib library mapping and link separated VarCheckUefiLib NULL class library Why to do: Share code. Separate variable check service from Variable driver in MdeModulePkg. We are going to separate generic software logic code from Variable Driver to benefit other variable driver implementation. Auth services has been done to be AuthVariableLib, now to cover variable check service. What test done: Nt32 and OVMF: Boot fine same with no code separation. Internal real platform: Boot fine to OS. What is the impact to platform: Only platform dsc need to be updated. Star Zeng (15): MdeModulePkg: Add VarCheckLib library MdeModulePkg: Add VarCheckUefiLib NULL class library Nt32Pkg: Add VarCheckLib library mapping OvmfPkg: Add VarCheckLib library mapping EmulatorPkg: Add VarCheckLib library mapping ArmVirtPkg: Add VarCheckLib library mapping ArmPlatformPkg: Add VarCheckLib library mapping Vlv2TbltDevicePkg: Add VarCheckLib library mapping MdeModulePkg Variable: Consume the separated VarCheckLib Nt32Pkg: Link separated VarCheckUefiLib NULL class library instance OvmfPkg: Link separated VarCheckUefiLib NULL class library instance EmulatorPkg: Link separated VarCheckUefiLib NULL class library instance ArmVirtPkg: Link separated VarCheckUefiLib NULL class library instance ArmPlatformPkg: Link separated VarCheckUefiLib NULL class library instance Vlv2TbltDevicePkg: Link separated VarCheckUefiLib NULL class library instance ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc |5 +- .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc|5 +- .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc |5 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |5 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc |1 + ArmVirtPkg/ArmVirt.dsc.inc |1 + ArmVirtPkg/ArmVirtQemu.dsc |5 +- EmulatorPkg/EmulatorPkg.dsc|6 +- MdeModulePkg/Include/Library/VarCheckLib.h | 180 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c | 632 +++ MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf | 51 + MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni | Bin 0 -> 1798 bytes .../Library/VarCheckUefiLib/VarCheckUefiLib.inf| 88 ++ .../Library/VarCheckUefiLib/VarCheckUefiLib.uni| Bin 0 -> 2158 bytes .../VarCheckUefiLib/VarCheckUefiLibNullClass.c | 930 MdeModulePkg/MdeModulePkg.dec |4 + MdeModulePkg/MdeModulePkg.dsc | 13 +- .../Universal/Variable/RuntimeDxe/VarCheck.c | 1117 +--- .../Universal/Variable/RuntimeDxe/Variable.c | 193 +--- .../Universal/Variable/RuntimeDxe/Variable.h | 97 +- .../Universal/Variable/RuntimeDxe/VariableDxe.c| 48 +- .../Variable/RuntimeDxe/VariableRuntimeDxe.inf | 15 +- .../Universal/Variable/RuntimeDxe/VariableSmm.c| 23 +- .../Universal/Variable/RuntimeDxe/VariableSmm.inf | 15 +- Nt32Pkg/Nt32Pkg.dsc|6 +- OvmfPkg/OvmfPkgIa32.dsc|6 +- OvmfPkg/OvmfPkgIa32X64.dsc |6 +- OvmfPkg/OvmfPkgX64.dsc |6 +- Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc|2 + Vlv2TbltDevicePkg/PlatformPkgIA32.dsc |2 + Vlv2TbltDevicePkg/PlatformPkgX64.dsc |2 + 31 files changed, 2045 insertions(+), 1424 deletions(-) create mode 100644 MdeModulePkg/Include/Library/VarCheckLib.h create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.uni create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel __
Re: [edk2] [PATCH 00/15] Separate variable check service to library
Star, The NT32Pkg changes are good. Reviewed-by: Ruiyu Ni -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng Sent: Monday, August 17, 2015 4:24 PM To: edk2-devel@lists.01.org Subject: [edk2] [PATCH 00/15] Separate variable check service to library NOTICE: To keep git bisect, the update to platform package Nt32Pkg, OvmfPkg, EmulatorPkg, ArmVirtPkg, ArmPlatformPkg and Vlv2TbltDevicePkg has been split to two patches. For your easy review, the forked code is at g...@github.com:lzeng14/edk2.git branch VariableCheckService. What to do: 1. Add VarCheckLib library and VarCheckUefiLib NULL class library. 2. Update Variable driver to consume the separated VarCheckLib. 3. Update platform package to add VarCheckLib library mapping and link separated VarCheckUefiLib NULL class library Why to do: Share code. Separate variable check service from Variable driver in MdeModulePkg. We are going to separate generic software logic code from Variable Driver to benefit other variable driver implementation. Auth services has been done to be AuthVariableLib, now to cover variable check service. What test done: Nt32 and OVMF: Boot fine same with no code separation. Internal real platform: Boot fine to OS. What is the impact to platform: Only platform dsc need to be updated. Star Zeng (15): MdeModulePkg: Add VarCheckLib library MdeModulePkg: Add VarCheckUefiLib NULL class library Nt32Pkg: Add VarCheckLib library mapping OvmfPkg: Add VarCheckLib library mapping EmulatorPkg: Add VarCheckLib library mapping ArmVirtPkg: Add VarCheckLib library mapping ArmPlatformPkg: Add VarCheckLib library mapping Vlv2TbltDevicePkg: Add VarCheckLib library mapping MdeModulePkg Variable: Consume the separated VarCheckLib Nt32Pkg: Link separated VarCheckUefiLib NULL class library instance OvmfPkg: Link separated VarCheckUefiLib NULL class library instance EmulatorPkg: Link separated VarCheckUefiLib NULL class library instance ArmVirtPkg: Link separated VarCheckUefiLib NULL class library instance ArmPlatformPkg: Link separated VarCheckUefiLib NULL class library instance Vlv2TbltDevicePkg: Link separated VarCheckUefiLib NULL class library instance ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc |5 +- .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc|5 +- .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc |5 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |5 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc |1 + ArmVirtPkg/ArmVirt.dsc.inc |1 + ArmVirtPkg/ArmVirtQemu.dsc |5 +- EmulatorPkg/EmulatorPkg.dsc|6 +- MdeModulePkg/Include/Library/VarCheckLib.h | 180 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c | 632 +++ MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf | 51 + MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni | Bin 0 -> 1798 bytes .../Library/VarCheckUefiLib/VarCheckUefiLib.inf| 88 ++ .../Library/VarCheckUefiLib/VarCheckUefiLib.uni| Bin 0 -> 2158 bytes .../VarCheckUefiLib/VarCheckUefiLibNullClass.c | 930 MdeModulePkg/MdeModulePkg.dec |4 + MdeModulePkg/MdeModulePkg.dsc | 13 +- .../Universal/Variable/RuntimeDxe/VarCheck.c | 1117 +--- .../Universal/Variable/RuntimeDxe/Variable.c | 193 +--- .../Universal/Variable/RuntimeDxe/Variable.h | 97 +- .../Universal/Variable/RuntimeDxe/VariableDxe.c| 48 +- .../Variable/RuntimeDxe/VariableRuntimeDxe.inf | 15 +- .../Universal/Variable/RuntimeDxe/VariableSmm.c| 23 +- .../Universal/Variable/RuntimeDxe/VariableSmm.inf | 15 +- Nt32Pkg/Nt32Pkg.dsc|6 +- OvmfPkg/OvmfPkgIa32.dsc|6 +- OvmfPkg/OvmfPkgIa32X64.dsc |6 +- OvmfPkg/OvmfPkgX64.dsc |6 +- Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc|2 + Vlv2TbltDevicePkg/PlatformPkgIA32.dsc |2 + Vlv2TbltDevicePkg/PlatformPkgX64.dsc |2 + 31 files changed, 2045 insertions(+), 1424 deletions(-) create mode 100644 MdeModulePkg/Include/Library/VarCheckLib.h create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.uni create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___
Re: [edk2] [PATCH 7/10] ShellPkg: Support format string argument checking
Reviewed-by: Qiu Shumin
This patch for ShellPkg depends on the ' EFIFORMAT ' change in MdePkg. So block
the check in after the MdePkg has been updated.
-Shumin
-Original Message-
From: Scott Duplichan [mailto:sc...@notabs.org]
Sent: Saturday, August 08, 2015 2:04 PM
To: edk2-devel@lists.01.org
Cc: Carsey, Jaben; Qiu, Shumin
Subject: [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 assumes the variable argument list immediately follows the
format string. Format string argument checking requires a compiler that
understands EDK2 format strings, such as GCC with the gcc_format from
BaseTools/gcc applied.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan
---
ShellPkg/Include/Library/ShellLib.h | 1 +
ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/ShellPkg/Include/Library/ShellLib.h
b/ShellPkg/Include/Library/ShellLib.h
index 23da4ee..0be5613 100644
--- a/ShellPkg/Include/Library/ShellLib.h
+++ b/ShellPkg/Include/Library/ShellLib.h
@@ -885,6 +885,7 @@ ShellInitialize (
**/
EFI_STATUS
EFIAPI
+EFIFORMAT_SHELL (3)
ShellPrintEx(
IN INT32Col OPTIONAL,
IN INT32Row OPTIONAL,
diff --git a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
index 9bd7b2c..6dd81d4 100644
--- a/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
+++ b/ShellPkg/Library/UefiShellCommandLib/ConsistMapping.c
@@ -81,6 +81,7 @@ typedef struct {
**/
CHAR16 *
EFIAPI
+EFIFORMAT (2)
CatPrint (
IN OUT POOL_PRINT *Str,
IN CHAR16 *Fmt,
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 14/15] ArmPlatformPkg: Link separated VarCheckUefiLib NULL class library instance
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc | 5 -
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc| 5 -
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc | 5 -
ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 5 -
4 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
index 09ec5b3..f5af426 100644
--- a/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
+++ b/ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc
@@ -220,7 +220,10 @@ [Components.common]
MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
EmbeddedPkg/SerialDxe/SerialDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
#
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
index c1e3513..c76d729 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc
@@ -233,7 +233,10 @@ [Components.common]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
index 119ba3a..71c794b 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -262,7 +262,10 @@ [Components.common]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
index 37f3648..72103e2 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
+++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc
@@ -245,7 +245,10 @@ [Components.common]
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 05/15] EmulatorPkg: Add VarCheckLib library mapping
Since Variable driver has been updated to consume the separated VarCheckLib. Cc: Jordan Justen Cc: Andrew Fish Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- EmulatorPkg/EmulatorPkg.dsc | 1 + 1 file changed, 1 insertion(+) diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc index dfcd476..71943e4 100644 --- a/EmulatorPkg/EmulatorPkg.dsc +++ b/EmulatorPkg/EmulatorPkg.dsc @@ -107,6 +107,7 @@ [LibraryClasses] CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf [LibraryClasses.common.SEC] PeiServicesLib|EmulatorPkg/Library/SecPeiServicesLib/SecPeiServicesLib.inf -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 13/15] ArmVirtPkg: Link separated VarCheckUefiLib NULL class library instance
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
ArmVirtPkg/ArmVirtQemu.dsc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 216f130..f1af968 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -256,7 +256,10 @@ [Components.common]
#
ArmPkg/Drivers/CpuDxe/CpuDxe.inf
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
!if $(SECURE_BOOT_ENABLE) == TRUE
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 12/15] EmulatorPkg: Link separated VarCheckUefiLib NULL class library instance
Cc: Jordan Justen
Cc: Andrew Fish
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
EmulatorPkg/EmulatorPkg.dsc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index 71943e4..8eff20e 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -315,7 +315,10 @@ [Components]
EmulatorPkg/TimerDxe/Timer.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 15/15] Vlv2TbltDevicePkg: Link separated VarCheckUefiLib NULL class library instance
Cc: David Wei
Cc: Tim He
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 1 +
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 1 +
Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 1 +
3 files changed, 3 insertions(+)
diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
index 39884af..5c0b68a 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc
@@ -1157,6 +1157,7 @@ [Components.X64]
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
}
$(PLATFORM_PACKAGE)/FvbRuntimeDxe/FvbSmm.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index e89b5f9..dad2eb0 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -1144,6 +1144,7 @@ [Components.IA32]
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
}
$(PLATFORM_PACKAGE)/FvbRuntimeDxe/FvbSmm.inf
diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index fc8334f..e32092e 100644
--- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -1150,6 +1150,7 @@ [Components.X64]
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
SerialPortLib|$(PLATFORM_PACKAGE)/Library/SerialPortLib/SerialPortLib.inf
}
$(PLATFORM_PACKAGE)/FvbRuntimeDxe/FvbSmm.inf
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 08/15] Vlv2TbltDevicePkg: Add VarCheckLib library mapping
Since Variable driver has been updated to consume the separated VarCheckLib. Cc: David Wei Cc: Tim He Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 1 + Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 1 + Vlv2TbltDevicePkg/PlatformPkgX64.dsc| 1 + 3 files changed, 3 insertions(+) diff --git a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc index 45008a0..39884af 100644 --- a/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc +++ b/Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc @@ -267,6 +267,7 @@ [LibraryClasses.common] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf !if $(RC_BINARY_RELEASE) == TRUE I2cLib|Vlv2TbltDevicePkg/Library/I2CLib/I2CLibNull.inf !endif diff --git a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc index 2fa7a36..e89b5f9 100644 --- a/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc +++ b/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc @@ -267,6 +267,7 @@ [LibraryClasses.common] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf !if $(RC_BINARY_RELEASE) == TRUE I2cLib|Vlv2TbltDevicePkg/Library/I2CLib/I2CLibNull.inf !endif diff --git a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc index 4e0a9f8..fc8334f 100644 --- a/Vlv2TbltDevicePkg/PlatformPkgX64.dsc +++ b/Vlv2TbltDevicePkg/PlatformPkgX64.dsc @@ -267,6 +267,7 @@ [LibraryClasses.common] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf !if $(RC_BINARY_RELEASE) == TRUE I2cLib|Vlv2TbltDevicePkg/Library/I2CLib/I2CLibNull.inf !endif -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 01/15] MdeModulePkg: Add VarCheckLib library
What to do:
1. Add VarCheckLib LibraryClass definitions.
2. Implement VarCheckLib library instance.
The code logic are separated from Variable driver.
Why to do: Share code.
Separate variable check service from Variable driver in MdeModulePkg.
We are going to separate generic software logic code from Variable Driver
to benefit other variable driver implementation. Auth services has been done
to be AuthVariableLib, now to cover variable check service.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
Reviewed-by: Jiewen Yao
---
MdeModulePkg/Include/Library/VarCheckLib.h | 180 +++
MdeModulePkg/Library/VarCheckLib/VarCheckLib.c | 632 +++
MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf | 51 ++
MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni | Bin 0 -> 1798 bytes
MdeModulePkg/MdeModulePkg.dec| 4 +
5 files changed, 867 insertions(+)
create mode 100644 MdeModulePkg/Include/Library/VarCheckLib.h
create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c
create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni
diff --git a/MdeModulePkg/Include/Library/VarCheckLib.h
b/MdeModulePkg/Include/Library/VarCheckLib.h
new file mode 100644
index 000..a423bc0
--- /dev/null
+++ b/MdeModulePkg/Include/Library/VarCheckLib.h
@@ -0,0 +1,180 @@
+/** @file
+ Provides variable check services and database management.
+
+Copyright (c) 2015, 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 that accompanies this distribution.
+The full text of the license may be found at
+http://opensource.org/licenses/bsd-license.php.
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _VARIABLE_CHECK_LIB_H_
+#define _VARIABLE_CHECK_LIB_H_
+
+#include
+
+typedef enum {
+ VarCheckRequestReserved0 = 0,
+ VarCheckRequestReserved1 = 1,
+ VarCheckFromTrusted = 2,
+ VarCheckFromUntrusted = 3,
+} VAR_CHECK_REQUEST_SOURCE;
+
+typedef
+VOID
+(EFIAPI *VAR_CHECK_END_OF_DXE_CALLBACK) (
+ VOID
+ );
+
+/**
+ Register END_OF_DXE callback.
+ The callback will be invoked by VarCheckLibInitializeAtEndOfDxe().
+
+ @param[in] Callback END_OF_DXE callback.
+
+ @retval EFI_SUCCESS The callback was registered successfully.
+ @retval EFI_INVALID_PARAMETER Callback is NULL.
+ @retval EFI_ACCESS_DENIED EFI_END_OF_DXE_EVENT_GROUP_GUID or
EFI_EVENT_GROUP_READY_TO_BOOT has
+already been signaled.
+ @retval EFI_OUT_OF_RESOURCES There is not enough resource for the callback
register request.
+
+**/
+EFI_STATUS
+EFIAPI
+VarCheckLibRegisterEndOfDxeCallback (
+ IN VAR_CHECK_END_OF_DXE_CALLBACK Callback
+ );
+
+/**
+ Var check initialize at END_OF_DXE.
+
+ This function needs to be called at END_OF_DXE.
+ Address pointers may be returned,
+ and caller needs to ConvertPointer() for the pointers.
+
+ @param[in, out] AddressPointerCount Output pointer to address pointer
count.
+
+ @return Address pointer buffer, NULL if input AddressPointerCount is NULL.
+
+**/
+VOID ***
+EFIAPI
+VarCheckLibInitializeAtEndOfDxe (
+ IN OUT UINTN *AddressPointerCount OPTIONAL
+ );
+
+/**
+ Register address pointer.
+ The AddressPointer may be returned by VarCheckLibInitializeAtEndOfDxe().
+
+ @param[in] AddressPointer Address pointer.
+
+ @retval EFI_SUCCESS The address pointer was registered
successfully.
+ @retval EFI_INVALID_PARAMETER AddressPointer is NULL.
+ @retval EFI_ACCESS_DENIED EFI_END_OF_DXE_EVENT_GROUP_GUID or
EFI_EVENT_GROUP_READY_TO_BOOT has
+already been signaled.
+ @retval EFI_OUT_OF_RESOURCES There is not enough resource for the address
pointer register request.
+
+**/
+EFI_STATUS
+EFIAPI
+VarCheckLibRegisterAddressPointer (
+ IN VOID **AddressPointer
+ );
+
+/**
+ Register SetVariable check handler.
+
+ @param[in] HandlerPointer to check handler.
+
+ @retval EFI_SUCCESS The SetVariable check handler was registered
successfully.
+ @retval EFI_INVALID_PARAMETER Handler is NULL.
+ @retval EFI_ACCESS_DENIED EFI_END_OF_DXE_EVENT_GROUP_GUID or
EFI_EVENT_GROUP_READY_TO_BOOT has
+already been signaled.
+ @retval EFI_OUT_OF_RESOURCES There is not enough resource for the
SetVariable check handler register request.
+ @retval EFI_UNSUPPORTED This interface is not implemented.
+For example, it is unsupported in VarCheck
protocol if both VarCheck and SmmVarCheck protocols are present.
+
+**/
+EFI_STATUS
+EFIAPI
+VarCheckLibRegisterSetVariableCheckHandler (
+ IN VAR_CHECK_SET_VARIABLE_CHE
[edk2] [PATCH 06/15] ArmVirtPkg: Add VarCheckLib library mapping
Since Variable driver has been updated to consume the separated VarCheckLib. Cc: Laszlo Ersek Cc: Ard Biesheuvel Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- ArmVirtPkg/ArmVirt.dsc.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index 7bba6eb..8372c58 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -134,6 +134,7 @@ [LibraryClasses.common] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf [LibraryClasses.common.SEC] PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 10/15] Nt32Pkg: Link separated VarCheckUefiLib NULL class library instance
Cc: Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
Nt32Pkg/Nt32Pkg.dsc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc
index a95f4e9..90a7b75 100644
--- a/Nt32Pkg/Nt32Pkg.dsc
+++ b/Nt32Pkg/Nt32Pkg.dsc
@@ -373,7 +373,10 @@ [Components]
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
Nt32Pkg/WinNtOemHookStatusCodeHandlerDxe/WinNtOemHookStatusCodeHandlerDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
!if $(SECURE_BOOT_ENABLE) == TRUE
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
!endif
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 04/15] OvmfPkg: Add VarCheckLib library mapping
Since Variable driver has been updated to consume the separated VarCheckLib. Cc: Jordan Justen Cc: Laszlo Ersek Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- OvmfPkg/OvmfPkgIa32.dsc| 1 + OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + 3 files changed, 3 insertions(+) diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 4ab618d..df00011 100644 --- a/OvmfPkg/OvmfPkgIa32.dsc +++ b/OvmfPkg/OvmfPkgIa32.dsc @@ -128,6 +128,7 @@ [LibraryClasses] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 90ca42a..355ed6a 100644 --- a/OvmfPkg/OvmfPkgIa32X64.dsc +++ b/OvmfPkg/OvmfPkgIa32X64.dsc @@ -133,6 +133,7 @@ [LibraryClasses] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index b72eaa9..4469bd1 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -133,6 +133,7 @@ [LibraryClasses] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 07/15] ArmPlatformPkg: Add VarCheckLib library mapping
Since Variable driver has been updated to consume the separated VarCheckLib. Cc: Leif Lindholm Cc: Ard Biesheuvel Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 1 + 1 file changed, 1 insertion(+) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc index d2f8f5a..dc69bbb 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc @@ -130,6 +130,7 @@ [LibraryClasses.common] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf [LibraryClasses.common.SEC] ArmPlatformSecExtraActionLib|ArmPlatformPkg/Library/DebugSecExtraActionLib/DebugSecExtraActionLib.inf -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 03/15] Nt32Pkg: Add VarCheckLib library mapping
Since Variable driver has been updated to consume the separated VarCheckLib. Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- Nt32Pkg/Nt32Pkg.dsc | 1 + 1 file changed, 1 insertion(+) diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc index 2b1d8c0..a95f4e9 100644 --- a/Nt32Pkg/Nt32Pkg.dsc +++ b/Nt32Pkg/Nt32Pkg.dsc @@ -141,6 +141,7 @@ [LibraryClasses] TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif + VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf [LibraryClasses.common.USER_DEFINED] DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 00/15] Separate variable check service to library
NOTICE: To keep git bisect, the update to platform package Nt32Pkg, OvmfPkg, EmulatorPkg, ArmVirtPkg, ArmPlatformPkg and Vlv2TbltDevicePkg has been split to two patches. For your easy review, the forked code is at g...@github.com:lzeng14/edk2.git branch VariableCheckService. What to do: 1. Add VarCheckLib library and VarCheckUefiLib NULL class library. 2. Update Variable driver to consume the separated VarCheckLib. 3. Update platform package to add VarCheckLib library mapping and link separated VarCheckUefiLib NULL class library Why to do: Share code. Separate variable check service from Variable driver in MdeModulePkg. We are going to separate generic software logic code from Variable Driver to benefit other variable driver implementation. Auth services has been done to be AuthVariableLib, now to cover variable check service. What test done: Nt32 and OVMF: Boot fine same with no code separation. Internal real platform: Boot fine to OS. What is the impact to platform: Only platform dsc need to be updated. Star Zeng (15): MdeModulePkg: Add VarCheckLib library MdeModulePkg: Add VarCheckUefiLib NULL class library Nt32Pkg: Add VarCheckLib library mapping OvmfPkg: Add VarCheckLib library mapping EmulatorPkg: Add VarCheckLib library mapping ArmVirtPkg: Add VarCheckLib library mapping ArmPlatformPkg: Add VarCheckLib library mapping Vlv2TbltDevicePkg: Add VarCheckLib library mapping MdeModulePkg Variable: Consume the separated VarCheckLib Nt32Pkg: Link separated VarCheckUefiLib NULL class library instance OvmfPkg: Link separated VarCheckUefiLib NULL class library instance EmulatorPkg: Link separated VarCheckUefiLib NULL class library instance ArmVirtPkg: Link separated VarCheckUefiLib NULL class library instance ArmPlatformPkg: Link separated VarCheckUefiLib NULL class library instance Vlv2TbltDevicePkg: Link separated VarCheckUefiLib NULL class library instance ArmPlatformPkg/ArmJunoPkg/ArmJuno.dsc |5 +- .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc|5 +- .../ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc |5 +- .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc |5 +- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc |1 + ArmVirtPkg/ArmVirt.dsc.inc |1 + ArmVirtPkg/ArmVirtQemu.dsc |5 +- EmulatorPkg/EmulatorPkg.dsc|6 +- MdeModulePkg/Include/Library/VarCheckLib.h | 180 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c | 632 +++ MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf | 51 + MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni | Bin 0 -> 1798 bytes .../Library/VarCheckUefiLib/VarCheckUefiLib.inf| 88 ++ .../Library/VarCheckUefiLib/VarCheckUefiLib.uni| Bin 0 -> 2158 bytes .../VarCheckUefiLib/VarCheckUefiLibNullClass.c | 930 MdeModulePkg/MdeModulePkg.dec |4 + MdeModulePkg/MdeModulePkg.dsc | 13 +- .../Universal/Variable/RuntimeDxe/VarCheck.c | 1117 +--- .../Universal/Variable/RuntimeDxe/Variable.c | 193 +--- .../Universal/Variable/RuntimeDxe/Variable.h | 97 +- .../Universal/Variable/RuntimeDxe/VariableDxe.c| 48 +- .../Variable/RuntimeDxe/VariableRuntimeDxe.inf | 15 +- .../Universal/Variable/RuntimeDxe/VariableSmm.c| 23 +- .../Universal/Variable/RuntimeDxe/VariableSmm.inf | 15 +- Nt32Pkg/Nt32Pkg.dsc|6 +- OvmfPkg/OvmfPkgIa32.dsc|6 +- OvmfPkg/OvmfPkgIa32X64.dsc |6 +- OvmfPkg/OvmfPkgX64.dsc |6 +- Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc|2 + Vlv2TbltDevicePkg/PlatformPkgIA32.dsc |2 + Vlv2TbltDevicePkg/PlatformPkgX64.dsc |2 + 31 files changed, 2045 insertions(+), 1424 deletions(-) create mode 100644 MdeModulePkg/Include/Library/VarCheckLib.h create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.c create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf create mode 100644 MdeModulePkg/Library/VarCheckLib/VarCheckLib.uni create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.uni create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c -- 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 02/15] MdeModulePkg: Add VarCheckUefiLib NULL class library
What to do: Implement VarCheckUefiLib NULL class library instance. The code logic are separated from Variable driver, and it will consume VarCheckLib to register var check handler and variable property set for UEFI defined variables. Why to do: Share code. Separate variable check UEFI code from Variable driver in MdeModulePkg. We are going to separate generic software logic code from Variable Driver to benefit other variable driver implementation. Auth services has been done to be AuthVariableLib, now to cover variable check service. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng Reviewed-by: Jiewen Yao --- .../Library/VarCheckUefiLib/VarCheckUefiLib.inf| 88 ++ .../Library/VarCheckUefiLib/VarCheckUefiLib.uni| Bin 0 -> 2158 bytes .../VarCheckUefiLib/VarCheckUefiLibNullClass.c | 930 + 3 files changed, 1018 insertions(+) create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.uni create mode 100644 MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c diff --git a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf new file mode 100644 index 000..ecfe6b3 --- /dev/null +++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf @@ -0,0 +1,88 @@ +## @file +# NULL class library to register var check handler and variable property set for UEFI defined variables. +# +# Copyright (c) 2015, 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 +# http://opensource.org/licenses/bsd-license.php +# +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +# +## + +[Defines] + INF_VERSION= 0x00010005 + BASE_NAME = VarCheckUefiLib + MODULE_UNI_FILE= VarCheckUefiLib.uni + FILE_GUID = AC24A4C7-F845-4665-90E5-6431D6E28DC0 + MODULE_TYPE= DXE_RUNTIME_DRIVER + VERSION_STRING = 1.0 + LIBRARY_CLASS = NULL|DXE_RUNTIME_DRIVER DXE_SMM_DRIVER + CONSTRUCTOR= VarCheckUefiLibNullClassConstructor + +# +# The following information is for reference only and not required by the build tools. +# +# VALID_ARCHITECTURES = IA32 X64 +# + +[Sources] + VarCheckUefiLibNullClass.c + +[Packages] + MdePkg/MdePkg.dec + MdeModulePkg/MdeModulePkg.dec + +[LibraryClasses] + BaseLib + BaseMemoryLib + DebugLib + DevicePathLib + VarCheckLib + +[Guids] + ## SOMETIMES_CONSUMES ## Variable:L"LangCodes" + ## SOMETIMES_CONSUMES ## Variable:L"Lang" + ## SOMETIMES_CONSUMES ## Variable:L"Timeout" + ## SOMETIMES_CONSUMES ## Variable:L"PlatformLangCodes" + ## SOMETIMES_CONSUMES ## Variable:L"PlatformLang" + ## SOMETIMES_CONSUMES ## Variable:L"ConIn" + ## SOMETIMES_CONSUMES ## Variable:L"ConOut" + ## SOMETIMES_CONSUMES ## Variable:L"ErrOut" + ## SOMETIMES_CONSUMES ## Variable:L"ConInDev" + ## SOMETIMES_CONSUMES ## Variable:L"ConOutDev" + ## SOMETIMES_CONSUMES ## Variable:L"ErrOutDev" + ## SOMETIMES_CONSUMES ## Variable:L"BootOrder" + ## SOMETIMES_CONSUMES ## Variable:L"BootNext" + ## SOMETIMES_CONSUMES ## Variable:L"BootCurrent" + ## SOMETIMES_CONSUMES ## Variable:L"BootOptionSupport" + ## SOMETIMES_CONSUMES ## Variable:L"DriverOrder" + ## SOMETIMES_CONSUMES ## Variable:L"SysPrepOrder" + ## SOMETIMES_CONSUMES ## Variable:L"HwErrRecSupport" + ## SOMETIMES_CONSUMES ## Variable:L"SetupMode" + ## SOMETIMES_CONSUMES ## Variable:L"PK" + ## SOMETIMES_CONSUMES ## Variable:L"KEK" + ## SOMETIMES_CONSUMES ## Variable:L"SignatureSupport" + ## SOMETIMES_CONSUMES ## Variable:L"SecureBoot" + ## SOMETIMES_CONSUMES ## Variable:L"KEKDefault" + ## SOMETIMES_CONSUMES ## Variable:L"PKDefault" + ## SOMETIMES_CONSUMES ## Variable:L"dbDefault" + ## SOMETIMES_CONSUMES ## Variable:L"dbxDefault" + ## SOMETIMES_CONSUMES ## Variable:L"dbtDefault" + ## SOMETIMES_CONSUMES ## Variable:L"OsIndicationsSupported" + ## SOMETIMES_CONSUMES ## Variable:L"OsIndications" + ## SOMETIMES_CONSUMES ## Variable:L"VendorKeys" + ## SOMETIMES_CONSUMES ## Variable:L"Boot" + ## SOMETIMES_CONSUMES ## Variable:L"Driver" + ## SOMETIMES_CONSUMES ## Variable:L"SysPrep" + ## SOMETIMES_CONSUMES ## Variable:L"Key" + gEfiGlobalVariableGuid + ## SOMETIMES_CONSUMES ## Variable:L"DB" + ## SOMETIMES_CONSUMES ## Variable:L"DBX" + ## SOMETIMES_CONSUMES ## Variable:L"DBT" + gEfiImageSecurityDatabaseGuid + gEfiHardwareErrorVariableGuid ## SOMETIMES_CONSUMES ## Variable:L"HwErrRec" diff --git a/MdeM
[edk2] [PATCH 09/15] MdeModulePkg Variable: Consume the separated VarCheckLib
Since the variable check service has be separated to VarCheckLib
from Variable driver, so update Variable driver to consume the
separated VarCheckLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
Reviewed-by: Jiewen Yao
---
MdeModulePkg/MdeModulePkg.dsc | 13 +-
.../Universal/Variable/RuntimeDxe/VarCheck.c | 1117 +---
.../Universal/Variable/RuntimeDxe/Variable.c | 193 +---
.../Universal/Variable/RuntimeDxe/Variable.h | 97 +-
.../Universal/Variable/RuntimeDxe/VariableDxe.c| 48 +-
.../Variable/RuntimeDxe/VariableRuntimeDxe.inf | 15 +-
.../Universal/Variable/RuntimeDxe/VariableSmm.c| 23 +-
.../Universal/Variable/RuntimeDxe/VariableSmm.inf | 15 +-
8 files changed, 107 insertions(+), 1414 deletions(-)
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 20edc08..7b14e61 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -97,6 +97,7 @@ [LibraryClasses]
PlatformBootManagerLib|MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManagerLibNull.inf
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+ VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
[LibraryClasses.EBC.PEIM]
IoLib|MdePkg/Library/PeiIoLibCpuIo/PeiIoLibCpuIo.inf
@@ -277,6 +278,8 @@ [Components]
MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManagerLibNull.inf
MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
+ MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
+ MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf
@@ -369,13 +372,19 @@ [Components.IA32, Components.X64, Components.IPF]
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
[Components.IA32, Components.X64, Components.Ebc]
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf
[Components.IA32, Components.X64]
MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
MdeModulePkg/Library/SmmReportStatusCodeLib/SmmReportStatusCodeLib.inf
MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c
index 27b4801..ad56a9f 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VarCheck.c
@@ -1,5 +1,6 @@
/** @file
- Implementation functions and structures for var check protocol.
+ Implementation functions and structures for var check protocol
+ and variable lock protocol based on VarCheckLib.
Copyright (c) 2015, Intel Corporation. All rights reserved.
This program and the accompanying materials
@@ -13,900 +14,53 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED.
**/
#include "Variable.h"
-#include
-
-extern LIST_ENTRY mLockedVariableList;
-extern BOOLEAN mEndOfDxe;
-extern BOOLEAN mEnableLocking;
-
-#define VAR_CHECK_HANDLER_TABLE_SIZE0x8
-
-UINT32 mNumberOfHandler = 0;
-UINT32 mMaxNumberOfHandler = 0;
-VAR_CHECK_SET_VARIABLE_CHECK_HANDLER*mHandlerTable = NULL;
-
-typedef struct {
- LIST_ENTRYLink;
- EFI_GUID Guid;
- VAR_CHECK_VARIABLE_PROPERTY VariableProperty;
- //CHAR16*Name;
-} VAR_CHECK_VARIABLE_ENTRY;
-
-LIST_ENTRY mVarCheckVariableList = INITIALIZE_LIST_HEAD_VARIABLE
(mVarCheckVariableList);
-
-typedef
-EFI_STATUS
-(EFIAPI *INTERNAL_VAR_CHECK_FUNCTION) (
- IN VAR_CHECK_VARIABLE_PROPERTY*Propery,
- IN UINTN DataSize,
- IN VOID *Data
- );
-
-typedef struct {
- CHAR16*Name;
- VAR_CHECK_VARIABLE_PROPERTY VariableProperty;
- INTERNAL_VAR_CHECK_FUNCTION CheckFunction;
-} UEFI_DEFINED_VARIABLE_ENTRY;
-
-/**
- Internal check for load option.
-
- @param[in] VariableProperyPointer to variable property.
- @param[in] DataSize Data size.
- @param[in] Data Pointer to data buffer.
-
- @retval EFI_SUCCE
[edk2] [PATCH 11/15] OvmfPkg: Link separated VarCheckUefiLib NULL class library instance
Cc: Jordan Justen
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng
---
OvmfPkg/OvmfPkgIa32.dsc| 5 -
OvmfPkg/OvmfPkgIa32X64.dsc | 5 -
OvmfPkg/OvmfPkgX64.dsc | 5 -
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index df00011..e55f0db 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -461,7 +461,10 @@ [Components]
PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
}
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 355ed6a..a8fcd88 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -468,7 +468,10 @@ [Components.X64]
PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
}
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 4469bd1..63e8c12 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -466,7 +466,10 @@ [Components]
PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
}
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
- MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
+ MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
+
+ NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+ }
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 1/2] NetworkPkg: Remove the hostname from the http request url
The hostname is already set in the header of the http request.
The url shouldn't contain the hostname since the hostname will
be prepended to the url when the server interprets the request.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin
Reviewed-by: Ye Ting
---
NetworkPkg/HttpDxe/HttpImpl.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 545fe42..030dcfe 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -227,6 +227,7 @@ EfiHttpRequest (
CHAR16*HostNameStr;
HTTP_TOKEN_WRAP *Wrap;
HTTP_TCP_TOKEN_WRAP *TcpWrap;
+ CHAR8 *FileUrl;
if ((This == NULL) || (Token == NULL)) {
return EFI_INVALID_PARAMETER;
@@ -450,7 +451,18 @@ EfiHttpRequest (
//
// Create request message.
//
- RequestStr = HttpGenRequestString (HttpInstance, HttpMsg, Url);
+ FileUrl = Url;
+ while (*FileUrl != ':')
+FileUrl++;
+ if ((*(FileUrl+1) == '/') && (*(FileUrl+2) == '/')) {
+FileUrl += 3;
+while (*FileUrl != '/')
+ FileUrl++;
+ } else {
+Status = EFI_INVALID_PARAMETER;
+goto Error3;
+ }
+ RequestStr = HttpGenRequestString (HttpInstance, HttpMsg, FileUrl);
if (RequestStr == NULL) {
Status = EFI_OUT_OF_RESOURCES;
goto Error3;
--
2.1.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 0/2] Add HttpBoot support to OvmfPkg
V2: Updated my git config to generate the reviewer-friendly diff. This patch series fixes a http request bug in HttpDxe and adds the HttpBoot support to OvmfPkg. I've tested the HttpBoot implementation with a simple environment: [QEMU] <---(tap0)---> [HOST] Ovmf DHCP server HTTP server With a proper config for the dhcp and http server in the host, the firmware successfully fetched the remote EFI file and executed it. It's recommended to update gnu-efi to the latest version to detect the IPv4 device path correctly. Known issues: * DHCPv6 support is not implemented in HttpBootDxe at this moment. * The unexpected TCP disconnection isn't handled properly in HttpDxe and the GET request may fail while fetching the EFI image from some featureless http daemon such as thttpd. Gary Ching-Pang Lin (2): NetworkPkg: Remove the hostname from the http request url OvmfPkg: Add HttpBoot support NetworkPkg/HttpDxe/HttpImpl.c | 14 +- OvmfPkg/OvmfPkgIa32.dsc | 10 ++ OvmfPkg/OvmfPkgIa32.fdf | 5 + OvmfPkg/OvmfPkgIa32X64.dsc| 10 ++ OvmfPkg/OvmfPkgIa32X64.fdf| 5 + OvmfPkg/OvmfPkgX64.dsc| 10 ++ OvmfPkg/OvmfPkgX64.fdf| 5 + 7 files changed, 58 insertions(+), 1 deletion(-) -- 2.1.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 2/2] OvmfPkg: Add HttpBoot support
This commit introdues a new build option to OvmfPkg: HTTP_BOOT_ENABLE. When HttpBoot is enabled, a new Network boot option will show in the boot manager menu with the device path like this: PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0)/Uri() It works like the PXE one but fetches the NBP from the given http url instead of the tftp service. A simple testing environment can be set up with the QEMU tap network and dnsmasq + lighttpd. Here is the example of the dnsmasq config: interface= dhcp-range=192.168.111.100,192.168.111.120,12h dhcp-option=60,"HTTPClient" dhcp-boot="http:///" It's similar to the PXE server settings except the tftp function is disabled, the option 60 must be "HTTPClient", and the boot uri is a http url. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Ching-Pang Lin --- OvmfPkg/OvmfPkgIa32.dsc| 10 ++ OvmfPkg/OvmfPkgIa32.fdf| 5 + OvmfPkg/OvmfPkgIa32X64.dsc | 10 ++ OvmfPkg/OvmfPkgIa32X64.fdf | 5 + OvmfPkg/OvmfPkgX64.dsc | 10 ++ OvmfPkg/OvmfPkgX64.fdf | 5 + 6 files changed, 45 insertions(+) diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 4ab618d..9a6de15 100644 --- a/OvmfPkg/OvmfPkgIa32.dsc +++ b/OvmfPkg/OvmfPkgIa32.dsc @@ -35,6 +35,7 @@ [Defines] # DEFINE SECURE_BOOT_ENABLE = FALSE DEFINE NETWORK_IP6_ENABLE = FALSE + DEFINE HTTP_BOOT_ENABLE= FALSE [BuildOptions] GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG @@ -129,6 +130,10 @@ [LibraryClasses] AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf +!endif + S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf @@ -551,6 +556,11 @@ [Components] MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + NetworkPkg/DnsDxe/DnsDxe.inf + NetworkPkg/HttpDxe/HttpDxe.inf + NetworkPkg/HttpBootDxe/HttpBootDxe.inf +!endif OvmfPkg/VirtioNetDxe/VirtioNet.inf # diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index 16675f8..0e4ee49 100644 --- a/OvmfPkg/OvmfPkgIa32.fdf +++ b/OvmfPkg/OvmfPkgIa32.fdf @@ -324,6 +324,11 @@ [FV.DXEFV] INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + INF NetworkPkg/DnsDxe/DnsDxe.inf + INF NetworkPkg/HttpDxe/HttpDxe.inf + INF NetworkPkg/HttpBootDxe/HttpBootDxe.inf +!endif INF OvmfPkg/VirtioNetDxe/VirtioNet.inf # diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 90ca42a..2f8006d 100644 --- a/OvmfPkg/OvmfPkgIa32X64.dsc +++ b/OvmfPkg/OvmfPkgIa32X64.dsc @@ -35,6 +35,7 @@ [Defines] # DEFINE SECURE_BOOT_ENABLE = FALSE DEFINE NETWORK_IP6_ENABLE = FALSE + DEFINE HTTP_BOOT_ENABLE= FALSE [BuildOptions] GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG @@ -134,6 +135,10 @@ [LibraryClasses] AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + HttpLib|MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.inf +!endif + S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf @@ -558,6 +563,11 @@ [Components.X64] MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + NetworkPkg/DnsDxe/DnsDxe.inf + NetworkPkg/HttpDxe/HttpDxe.inf + NetworkPkg/HttpBootDxe/HttpBootDxe.inf +!endif OvmfPkg/VirtioNetDxe/VirtioNet.inf # diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf index e6c525a..74412d4 100644 --- a/OvmfPkg/OvmfPkgIa32X64.fdf +++ b/OvmfPkg/OvmfPkgIa32X64.fdf @@ -324,6 +324,11 @@ [FV.DXEFV] INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf INF MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf !endif +!if $(HTTP_BOOT_ENABLE) == TRUE + INF NetworkPkg/DnsDxe/DnsDxe.inf + INF NetworkPkg/HttpDxe/HttpDxe.inf + INF NetworkPkg/HttpBootDxe/HttpBootDxe.inf +!endif INF OvmfPkg/VirtioNetDxe/VirtioNet.inf # diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index b72eaa9..5407d9d 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -35,6 +35,7 @@ [Defines] # DEFINE SECURE_BOOT_ENABLE = FALSE DEFINE NETWORK_IP6_ENABLE = FALSE +
[edk2] [PATCH 2/2] BaseTools GCC: update mingw-gcc-build.py to GCC 4.9.3
This updates mingw-gcc-build.py to the newest version of GCC currently
supported by the EDK2 build system, which is 4.9.3. At the same time,
binutils is updated to version 2.24.51.0.2.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
BaseTools/gcc/mingw-gcc-build.py | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/BaseTools/gcc/mingw-gcc-build.py b/BaseTools/gcc/mingw-gcc-build.py
index 4b697c4382af..908589b52ba6 100755
--- a/BaseTools/gcc/mingw-gcc-build.py
+++ b/BaseTools/gcc/mingw-gcc-build.py
@@ -210,8 +210,8 @@ class SourceFiles:
'binutils': {
'url': 'http://www.kernel.org/pub/linux/devel/binutils/' + \
'binutils-$version.tar.bz2',
-'version': '2.20.51.0.5',
-'md5': '6d2de7cdf7a8389e70b124e3d73b4d37',
+'version': '2.24.51.0.2',
+'md5': 'c116833f7807d766bf68511ca271c821',
},
}
@@ -219,8 +219,8 @@ class SourceFiles:
'gcc': {
'url': 'http://ftpmirror.gnu.org/gcc/' + \
'gcc-$version/gcc-$version.tar.bz2',
-'version': '4.3.0',
-'md5': '197ed8468b38db1d3481c3111691d85b',
+'version': '4.9.3',
+'md5': '6f831b4d251872736e8e9cc09746f327',
},
}
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/2] BaseTools GCC: drop sysroot from mingw-gcc-build.py
We pass --with-sysroot= when configuring binutils and
GCC, which results in a failure since the installation expects a
include/mingw directory to already be present there.
However, a sysroot is not needed for the GCC-only toolchain build,
since we are not building anything for the target, e.g., libgcc or
libc. So drop it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
BaseTools/gcc/mingw-gcc-build.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/BaseTools/gcc/mingw-gcc-build.py b/BaseTools/gcc/mingw-gcc-build.py
index 420b3dea80f7..4b697c4382af 100755
--- a/BaseTools/gcc/mingw-gcc-build.py
+++ b/BaseTools/gcc/mingw-gcc-build.py
@@ -457,7 +457,6 @@ class Builder:
configure,
'--target=%s' % self.config.target_combo,
'--prefix=' + prefix,
-'--with-sysroot=' + prefix,
'--disable-werror',
)
if os.path.exists('/opt/local/include/gmp.h'):
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] ArmPkg: remove ARMv6 support code
No platforms use the ARMv6 (ARM11) support code anymore. In fact, the
only reference to it in ArmPkg.dsc was commented out by Andrew in SVN
r11298 (2011-02-03) so it may well be broken. So remove it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
ArmPkg/ArmPkg.dsc | 4 -
ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c | 37 ---
.../ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf| 32 ---
ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c | 49
ArmPkg/Library/ArmLib/Arm11/Arm11Lib.inf | 50
ArmPkg/Library/ArmLib/Arm11/Arm11LibMem.c | 135 ---
ArmPkg/Library/ArmLib/Arm11/Arm11LibPrePi.inf | 50
ArmPkg/Library/ArmLib/Arm11/Arm11LibSec.inf| 46
ArmPkg/Library/ArmLib/Arm11/Arm11Support.S | 257 -
ArmPkg/Library/ArmLib/Arm11/Arm11Support.asm | 157 -
10 files changed, 817 deletions(-)
delete mode 100644 ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
delete mode 100644 ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Lib.inf
delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibMem.c
delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibPrePi.inf
delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11LibSec.inf
delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Support.S
delete mode 100644 ArmPkg/Library/ArmLib/Arm11/Arm11Support.asm
diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
index 10e8a1a83d46..1237eed65953 100644
--- a/ArmPkg/ArmPkg.dsc
+++ b/ArmPkg/ArmPkg.dsc
@@ -152,10 +152,6 @@ [Components.ARM]
ArmPkg/Drivers/ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Lib.inf
ArmPkg/Drivers/ArmCpuLib/ArmCortexA15Lib/ArmCortexA15Lib.inf
-# ArmPkg/Library/ArmLib/Arm11/Arm11ArmLib.inf
-# ArmPkg/Library/ArmLib/Arm11/Arm11ArmLibPrePi.inf
-# ArmPkg/Library/ArmLib/Arm9/Arm9ArmLib.inf
-# ArmPkg/Library/ArmLib/Arm9/Arm9ArmLibPrePi.inf
ArmPkg/Library/ArmLib/ArmV7/ArmV7LibSec.inf
ArmPkg/Library/ArmLib/ArmV7/ArmV7LibPrePi.inf
diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
deleted file mode 100644
index a08b7b1aee3f..
--- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11Lib.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/** @file
-
- Copyright (c) 2011-2012, ARM Limited. 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
- http://opensource.org/licenses/bsd-license.php
-
- THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
- WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-
-#include
-#include
-#include
-#include
-#include
-
-VOID
-ArmCpuSetup (
- IN UINTN MpId
- )
-{
- ASSERT(0); //TODO: Implement me
-}
-
-
-VOID
-ArmCpuSetupSmpNonSecure (
- IN UINTN MpId
- )
-{
- ASSERT(0); //TODO: Implement me
-}
-
diff --git a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
b/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
deleted file mode 100644
index 3a796c19d0cc..
--- a/ArmPkg/Drivers/ArmCpuLib/Arm11MpCoreLib/Arm11MpCoreLib.inf
+++ /dev/null
@@ -1,32 +0,0 @@
-#/* @file
-# Copyright (c) 2011-2012, ARM Limited. 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
-# http://opensource.org/licenses/bsd-license.php
-#
-# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
-#
-#*/
-
-[Defines]
- INF_VERSION= 0x00010005
- BASE_NAME = Arm11MpCoreLib
- FILE_GUID = dc8a69e0-6be0-469c-94d3-5e6d71aa9808
- MODULE_TYPE= BASE
- VERSION_STRING = 1.0
- LIBRARY_CLASS = ArmCpuLib
-
-[Packages]
- MdePkg/MdePkg.dec
- ArmPkg/ArmPkg.dec
-
-[LibraryClasses]
- ArmLib
- IoLib
- PcdLib
-
-[Sources.common]
- Arm11Lib.c
diff --git a/ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
b/ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
deleted file mode 100644
index 8c54b6cc8fd5..
--- a/ArmPkg/Library/ArmLib/Arm11/Arm11Lib.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/** @file
-
- Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
- Copyright (c) 2011 - 2014, ARM Limited. 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
[edk2] [patch] Add restriction that HashFinal() must be after at least one HashUpdate().
Just follow UEFI spec.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen"
Cc: "Zhang, Chao B"
---
SecurityPkg/Hash2DxeCrypto/Driver.h | 1 +
SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/SecurityPkg/Hash2DxeCrypto/Driver.h
b/SecurityPkg/Hash2DxeCrypto/Driver.h
index 771aedc..a145858 100644
--- a/SecurityPkg/Hash2DxeCrypto/Driver.h
+++ b/SecurityPkg/Hash2DxeCrypto/Driver.h
@@ -57,6 +57,7 @@ typedef struct {
EFI_HASH2_PROTOCOL Hash2Protocol;
VOID *HashContext;
VOID *HashInfoContext;
+ BOOLEAN Updated;
} HASH2_INSTANCE_DATA;
#define HASH2_INSTANCE_DATA_FROM_THIS(a) \
diff --git a/SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c
b/SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c
index 94057ab..ab34de7 100644
--- a/SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c
+++ b/SecurityPkg/Hash2DxeCrypto/Hash2DxeCrypto.c
@@ -500,6 +500,7 @@ BaseCrypto2HashInit (
//
Instance->HashContext = HashCtx;
Instance->HashInfoContext = HashInfo;
+ Instance->Updated = FALSE;
return EFI_SUCCESS;
}
@@ -551,6 +552,8 @@ BaseCrypto2HashUpdate (
return EFI_OUT_OF_RESOURCES;
}
+ Instance->Updated = TRUE;
+
return EFI_SUCCESS;
}
@@ -590,7 +593,8 @@ BaseCrypto2HashFinal (
// Consistency Check
//
Instance = HASH2_INSTANCE_DATA_FROM_THIS(This);
- if ((Instance->HashContext == NULL) || (Instance->HashInfoContext == NULL)) {
+ if ((Instance->HashContext == NULL) || (Instance->HashInfoContext == NULL) ||
+ (!Instance->Updated)) {
return EFI_NOT_READY;
}
HashInfo = Instance->HashInfoContext;
@@ -604,6 +608,7 @@ BaseCrypto2HashFinal (
FreePool (HashCtx);
Instance->HashInfoContext = NULL;
Instance->HashContext = NULL;
+ Instance->Updated = FALSE;
if (!Ret) {
return EFI_OUT_OF_RESOURCES;
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] MdeModulePkg: IP4 should re-initiate a DHCP while network reconnection
Reviewed-by: Ye Ting
-Original Message-
From: Wu, Jiaxin
Sent: Monday, August 17, 2015 11:25 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Zhang, Lubo
Subject: [PATCH v2] MdeModulePkg: IP4 should re-initiate a DHCP while network
reconnection
v2:
* Update the MediaPresent detect declaring.
IP4 driver should re-initiate a DHCP if it detects that there is a network
reconnection.
To fix this issue, we can implement the DHCP re-initiate policy while the media
change detected. The Ip4 driver should set a timer to signal the Ip4 to run the
DHCP configuration again(D.O.R.A). IP4 driver should free old IP address
related resource, then initiate a DHCP process to acquire new IP.
Cc: Ye Ting
Cc: Zhang Lubo
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu
---
.../Universal/Network/Ip4Dxe/Ip4Config2Impl.c | 1 +
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c | 10 ++
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c| 121 -
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.h| 7 ++
4 files changed, 133 insertions(+), 6 deletions(-)
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
index fcb2bdd..caf84fb 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c
@@ -490,10 +490,11 @@ Ip4Config2SetDefaultAddr (
IpSb = IP4_SERVICE_FROM_IP4_CONFIG2_INSTANCE (Instance);
IpIf = IpSb->DefaultInterface;
ASSERT (IpIf != NULL);
if ((IpIf->Ip == StationAddress) && (IpIf->SubnetMask == SubnetMask)) {
+IpSb->State = IP4_SERVICE_CONFIGED;
return EFI_SUCCESS;
}
//
// The default address is changed, free the previous interface first.
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
index 101390c..4d3ccec 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
@@ -208,10 +208,14 @@ Ip4CreateService (
ZeroMem (&IpSb->SnpMode, sizeof (EFI_SIMPLE_NETWORK_MODE));
IpSb->Timer = NULL;
+ IpSb->ReconfigEvent = NULL;
+
+ IpSb->MediaPresent = TRUE;
+
//
// Create various resources. First create the route table, timer
// event and MNP child. IGMP, interface's initialization depend
// on the MNP child.
//
@@ -384,10 +388,16 @@ Ip4CleanService (
gBS->CloseEvent (IpSb->Timer);
IpSb->Timer = NULL;
}
+ if (IpSb->ReconfigEvent != NULL) {
+gBS->CloseEvent (IpSb->ReconfigEvent);
+
+IpSb->ReconfigEvent = NULL;
+ }
+
if (IpSb->MacString != NULL) {
FreePool (IpSb->MacString);
}
Ip4Config2CleanInstance (&IpSb->Ip4Config2Instance); diff --git
a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
index 2fb4f4c..ac8fb1a 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
@@ -561,10 +561,58 @@ Ip4InitProtocol (
EfiInitializeLock (&IpInstance->RecycleLock, TPL_NOTIFY); }
+/**
+ The event handle for IP4 auto reconfiguration. The original default
+ interface and route table will be removed as the default.
+
+ @param[in] ContextThe IP4 service binding instance.
+
+**/
+VOID
+EFIAPI
+Ip4AutoReconfigCallBackDpc (
+ IN VOID *Context
+ )
+{
+ IP4_SERVICE *IpSb;
+
+ IpSb = (IP4_SERVICE *) Context;
+ NET_CHECK_SIGNATURE (IpSb, IP4_SERVICE_SIGNATURE);
+
+ if (IpSb->State > IP4_SERVICE_UNSTARTED) {
+IpSb->State = IP4_SERVICE_UNSTARTED; }
+
+ Ip4StartAutoConfig (&IpSb->Ip4Config2Instance);
+
+ return ;
+}
+
+
+/**
+ Request Ip4AutoReconfigCallBackDpc as a DPC at TPL_CALLBACK.
+
+ @param Event The event that is signalled.
+ @param Context The IP4 service binding instance.
+
+**/
+VOID
+EFIAPI
+Ip4AutoReconfigCallBack (
+ IN EFI_EVENT Event,
+ IN VOID *Context
+ )
+{
+ //
+ // Request Ip4AutoReconfigCallBackDpc as a DPC at TPL_CALLBACK
+ //
+ QueueDpc (TPL_CALLBACK, Ip4AutoReconfigCallBackDpc, Context); }
+
/**
Configure the IP4 child. If the child is already configured,
change the configuration parameter. Otherwise configure it
for the first time. The caller should validate the configuration @@ -676,14
+724,31 @@ Ip4ConfigProtocol (
//
// Use the default address. If the default configuration hasn't
// been started, start it.
//
if (IpSb->State == IP4_SERVICE_UNSTARTED) {
+ //
+ // Create the ReconfigEvent to start the new configuration.
+ //
+ if (IpSb->ReconfigEvent == NULL) {
+Status = gBS->CreateEvent (
+EVT_NOTIFY_SIGNAL,
+TPL_NOTIFY,
+Ip4AutoReconfigCallBack,
+IpSb,
+&IpSb->ReconfigEvent
