[edk2] [PATCH v3 06/12] BaseTools/GCC: align start of .data to .text alignment
Now that GenFw honors the ELF section alignment when placing the
PE/COFF sections in the output, the start of the PE/COFF version of
.data will be aligned to the alignment of .text if its alignment is
higher than the default. So duplicate this behavior in the ELF output,
this will make the memory layout of the PE/COFF binary match the
layout of the ELF version more closely.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Scripts/GccBase.lds | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 0f0210e40703..3d99f01db21f 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -37,7 +37,7 @@ SECTIONS {
* between these sections is the same in the ELF and the PE/COFF versions of
* this binary.
*/
- .data : ALIGN(CONSTANT(COMMONPAGESIZE)) {
+ .data ALIGN(ALIGNOF(.text)) : 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 v3 10/12] ArmVirtPkg: move to unified GCC linker script
Move to the parametrised generic GCC linker script and set 64 KB alignment, instead of using the AARCH64 specific incremental linker script for 64 KB alignment which is about to be removed. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Acked-by: Laszlo Ersek ler...@redhat.com --- ArmVirtPkg/ArmVirt.dsc.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index b2003a58be04..8c54242b597b 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -18,7 +18,7 @@ [Defines] DEFINE TTY_TERMINAL= FALSE [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER] - GCC:*_*_AARCH64_DLINK_FLAGS = --script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script + GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1 [LibraryClasses.common] !if $(TARGET) == RELEASE -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 09/12] ArmPlatformPkg/ArmVExpressPkg: move to unified GCC linker script
Move to the parametrised generic GCC linker script and set 64 KB alignment, instead of using the AARCH64 specific incremental linker script for 64 KB alignment which is about to be removed. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc index 7e0d8ff4b6e6..d2f8f5aa6d41 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc @@ -13,7 +13,7 @@ # [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER] - GCC:*_*_AARCH64_DLINK_FLAGS = --script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script + GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1 [LibraryClasses.common] !if $(TARGET) == RELEASE -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 02/12] BaseTools/GCC: move .rodata to PE/COFF .text section
The .rodata ELF section contains constant non-executable data that
should never be modified by the program itself. Since the risk of
inadvertent modification is typically higher than the risk of
inadvertent execution, it makes sense to put this data in the
R-X .text section rather than in the RW- .data section.
So move it there.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Scripts/gcc-4K-align-ld-script | 2 +-
BaseTools/Scripts/gcc4.4-ld-script | 2 +-
BaseTools/Scripts/gcc4.9-ld-script | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script
b/BaseTools/Scripts/gcc-4K-align-ld-script
index 16cf623a3362..1f0f1afb27f4 100644
--- a/BaseTools/Scripts/gcc-4K-align-ld-script
+++ b/BaseTools/Scripts/gcc-4K-align-ld-script
@@ -6,12 +6,12 @@ SECTIONS
.text : ALIGN(0x1000)
{
*(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
. = ALIGN(0x20);
}
.data : ALIGN(0x1000)
{
*(
- .rodata .rodata.* .gnu.linkonce.r.*
.data .data.* .gnu.linkonce.d.*
.bss .bss.*
*COM*
diff --git a/BaseTools/Scripts/gcc4.4-ld-script
b/BaseTools/Scripts/gcc4.4-ld-script
index c0aa62180440..22b3220816c9 100644
--- a/BaseTools/Scripts/gcc4.4-ld-script
+++ b/BaseTools/Scripts/gcc4.4-ld-script
@@ -6,12 +6,12 @@ SECTIONS
.text ALIGN(0x20) :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
. = ALIGN(0x20);
}
.data ALIGN(0x20) :
{
*(
- .rodata .rodata.* .gnu.linkonce.r.*
.data .data.* .gnu.linkonce.d.*
.bss .bss.*
*COM*
diff --git a/BaseTools/Scripts/gcc4.9-ld-script
b/BaseTools/Scripts/gcc4.9-ld-script
index 37a93cd85e94..2ac86e38fac7 100644
--- a/BaseTools/Scripts/gcc4.9-ld-script
+++ b/BaseTools/Scripts/gcc4.9-ld-script
@@ -6,12 +6,12 @@ SECTIONS
.text ALIGN(0x20) :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
+*(.rodata .rodata.* .gnu.linkonce.r.*)
. = ALIGN(0x20);
}
.data ALIGN(0x40) :
{
*(
- .rodata .rodata.* .gnu.linkonce.r.*
.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 v3 04/12] BaseTools/GCC: move .got contents to the PE/COFF .text section
Move the .got contents to the PE/COFF .text section. This should be
a no-op, since we typically don't generate position independent code
(i.e., using -fPIC). But since the GOT contains variable addresses that
are updated at relocation time only, its contents are best kept in .text
to prevent them from being overwritten inadvertently.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
BaseTools/Scripts/gcc-4K-align-ld-script | 5 +
BaseTools/Scripts/gcc4.4-ld-script | 5 +
BaseTools/Scripts/gcc4.9-ld-script | 5 +
3 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/BaseTools/Scripts/gcc-4K-align-ld-script
b/BaseTools/Scripts/gcc-4K-align-ld-script
index 3ed1c12fb8aa..34957a53147c 100644
--- a/BaseTools/Scripts/gcc-4K-align-ld-script
+++ b/BaseTools/Scripts/gcc-4K-align-ld-script
@@ -7,6 +7,7 @@ SECTIONS
{
*(.text .stub .text.* .gnu.linkonce.t.*)
*(.rodata .rodata.* .gnu.linkonce.r.*)
+*(.got .got.*)
}
.data : ALIGN(0x1000)
{
@@ -20,10 +21,6 @@ SECTIONS
{
KEEP (*(.eh_frame))
}
- .got : ALIGN(0x1000)
- {
-*(.got .got.*)
- }
.rela : ALIGN(0x1000)
{
*(.rela .rela.*)
diff --git a/BaseTools/Scripts/gcc4.4-ld-script
b/BaseTools/Scripts/gcc4.4-ld-script
index 0d86908d0b30..48320c6611e4 100644
--- a/BaseTools/Scripts/gcc4.4-ld-script
+++ b/BaseTools/Scripts/gcc4.4-ld-script
@@ -7,6 +7,7 @@ SECTIONS
{
*(.text .stub .text.* .gnu.linkonce.t.*)
*(.rodata .rodata.* .gnu.linkonce.r.*)
+*(.got .got.*)
}
.data ALIGN(0x20) :
{
@@ -20,10 +21,6 @@ SECTIONS
{
KEEP (*(.eh_frame))
}
- .got ALIGN(0x20) :
- {
-*(.got .got.*)
- }
.rela ALIGN(0x20) :
{
*(.rela .rela.*)
diff --git a/BaseTools/Scripts/gcc4.9-ld-script
b/BaseTools/Scripts/gcc4.9-ld-script
index 207b9e1dc7f0..3dff0b2907e6 100644
--- a/BaseTools/Scripts/gcc4.9-ld-script
+++ b/BaseTools/Scripts/gcc4.9-ld-script
@@ -7,6 +7,7 @@ SECTIONS
{
*(.text .stub .text.* .gnu.linkonce.t.*)
*(.rodata .rodata.* .gnu.linkonce.r.*)
+*(.got .got.*)
}
.data ALIGN(0x40) :
{
@@ -20,10 +21,6 @@ SECTIONS
{
KEEP (*(.eh_frame))
}
- .got ALIGN(0x20) :
- {
-*(.got .got.*)
- }
.rela ALIGN(0x20) :
{
*(.rela .rela.*)
--
1.9.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2] ArmPlatformPkg: remove obsolete ARM and AARCH64 platforms
Remove obsolete ARM and AARCH64 platforms so the maintainers can focus on the ones that are still supported, which are: - TC2 (ArmVExpress-CTA15-A7.dsc) - Foundation model and Fast model emulators (ArmVExpress-FVP-AArch64.dsc) - Juno (ArmJunoPkg/ArmJuno.dsc) - Cortex-A15 MPcore RTSM (ArmVExpress-RTSM-A15_MPCore) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- Branch is here: https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/shortlog/refs/heads/remove-obsolete-platforms ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-A8.dsc | 235 -- ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-A9x2.dsc | 235 -- ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-MPCore.fdf | 322 - ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-UniCore.fdf | 324 - ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb.dsc.inc | 342 -- ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEbPkg.dec | 39 -- ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/EBLoadSecSyms.inc | 16 - ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/EfiFuncs.inc | 463 --- ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_boot_from_ram.inc | 21 - ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_convert_symbols.sh | 23 - ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_hw_setup.inc | 67 --- ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_load_symbols.inc | 23 - ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_symbols_macros.inc | 194 ArmPlatformPkg/ArmRealViewEbPkg/Debugger_scripts/rvi_unload_symbols.inc | 118 - ArmPlatformPkg/ArmRealViewEbPkg/FvbDxe/FvbDxe.c | 417 - ArmPlatformPkg/ArmRealViewEbPkg/FvbDxe/FvbDxe.inf | 53 --- ArmPlatformPkg/ArmRealViewEbPkg/Include/Platform/ArmPlatform.h | 122 - ArmPlatformPkg/ArmRealViewEbPkg/InterruptDxe/InterruptDxe.c | 484 ArmPlatformPkg/ArmRealViewEbPkg/InterruptDxe/InterruptDxe.inf | 53 --- ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEb.c | 146 -- ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEbHelper.S | 53 --- ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEbHelper.asm | 59 --- ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEbLib.inf | 50 -- ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEbLibSec.inf | 46 -- ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbLibRTSM/ArmRealViewEbMem.c | 116 - ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbSecLibRTSM/ArmRealViewEbBoot.S | 54 --- ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbSecLibRTSM/ArmRealViewEbBoot.asm | 58 --- ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbSecLibRTSM/ArmRealViewEbSec.c | 78 ArmPlatformPkg/ArmRealViewEbPkg/Library/ArmRealViewEbSecLibRTSM/ArmRealViewEbSecLib.inf | 41 -- ArmPlatformPkg/ArmRealViewEbPkg/Library/DebugAgentTimerLib/DebugAgentTimerLib.c | 77 ArmPlatformPkg/ArmRealViewEbPkg/Library/DebugAgentTimerLib/DebugAgentTimerLib.inf | 38 -- ArmPlatformPkg/ArmRealViewEbPkg/Library/GdbSerialLib/GdbSerialLib.c | 118 - ArmPlatformPkg/ArmRealViewEbPkg/Library/GdbSerialLib/GdbSerialLib.inf | 39 -- ArmPlatformPkg/ArmRealViewEbPkg/Library/NorFlashArmRealViewEbLib/NorFlashArmRealViewEb.c | 54 --- ArmPlatformPkg/ArmRealViewEbPkg/Library/NorFlashArmRealViewEbLib/NorFlashArmRealViewEbLib.inf | 35 -- ArmPlatformPkg/ArmRealViewEbPkg/Library/PL111LcdArmRealViewEbLib/PL111LcdArmRealViewEb.c | 232 -- ArmPlatformPkg/ArmRealViewEbPkg/Library/PL111LcdArmRealViewEbLib/PL111LcdArmRealViewEbLib.inf | 65 --- ArmPlatformPkg/ArmRealViewEbPkg/Library/ResetSystemLib/ResetSystemLib.c | 87 ArmPlatformPkg/ArmRealViewEbPkg/Library/ResetSystemLib/ResetSystemLib.inf | 35 -- ArmPlatformPkg/ArmRealViewEbPkg/b.bat | 43 -- ArmPlatformPkg/ArmRealViewEbPkg/ba.bat
Re: [edk2] [PATCH] EmbeddedPkg: Added Marvell Yukon Ethernet support
On 2015-07-28 10:51:38, Leif Lindholm wrote: Hi Jordan, Sorry, (metaphorically) snowed under for a few days. On Fri, Jul 17, 2015 at 02:44:10PM -0700, Jordan Justen wrote: Does this depend on ArmPkg / EmbeddedPkg, or is this just a generic PCI based driver? It could be nice to have a generic place for such drivers, but I think OptionRomPkg is the closest we have today. Well, I'm planning to add it to my OpenPlatformPkg tree. If that was to be merged into edk2, that would contain such a generic place. But, the name 'open platform' also sounds strange, assuming this a plain PCI bus driver. Couldn't it live in a 'pci drivers' package? Personally, I think we should rename OptionRomPkg to DriversPkg, or split it into UsbDriversPkg and PciDriversPkg. Mike, This seems like another thing we've been talking about for years. :) What do you think about adding: DriversPkg DriversPkg/Pci DriversPkg/Usb or PciDriversPkg UsbDriversPkg One possible concern is who will own/maintain such a package. In this case, it might make sense to have a separate Maintainers.txt file under the package. Or, what I would suggest is that we just start out by saying that edk2-devel collectively owns it, and that any other package maintainer can commit contributions to the package. -Jordan So, OpenPlatformPkg is my current way of dealing with the lack of a unified handling of platform/driver code in edk2. It is not something I mind giving up if this situation resolves itself another way. Or renaming to something more palatable :) I gave a presentation (more like lightning talk) at the spring plugfest in Seattle on this: http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_Platforms_Tree_May_2015.pdf If we simply rename OptionRomPkg to DriversPkg (and restructure a bit in there), then that solves the drivers part of my problem. But I still need something for opensource platform support. / Leif ___ 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 v3 09/12] ArmPlatformPkg/ArmVExpressPkg: move to unified GCC linker script
On 2015-07-29 08:11:59, Ard Biesheuvel wrote: Move to the parametrised generic GCC linker script and set 64 KB alignment, instead of using the AARCH64 specific incremental linker script for 64 KB alignment which is about to be removed. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc index 7e0d8ff4b6e6..d2f8f5aa6d41 100644 --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc @@ -13,7 +13,7 @@ # [BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER] - GCC:*_*_AARCH64_DLINK_FLAGS = --script=$(EDK_TOOLS_PATH)/Scripts/gcc-aarch64-64K-align-ld-script + GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1 Nice. This seems like a big improvement. common-page-size doesn't map exactly to 'image section alignment', so there is a little bit of a disconnect here in terminology. I think you said that something like --defsym=IMAGE_SECTION_ALIGN=0x1 can't be used because it doesn't work in the linker script. Is that right? I guess if we added -z common-page-size=$(SECTIONALIGN_FLAGS) directly in build_rule, then we might be able to use: GCC:*_*_*_SECTIONALIGN_FLAGS = 0x1 That's not great either. -Jordan [LibraryClasses.common] !if $(TARGET) == RELEASE -- 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] efi acpidump port
Password: edk2efiacpidump -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew Fish Sent: Wednesday, July 29, 2015 1:50 PM To: Smith, Jonathan D Cc: edk2-devel@lists.01.org Subject: Re: [edk2] efi acpidump port On Jul 29, 2015, at 1:43 PM, Smith, Jonathan D jonathan.d.sm...@intel.com wrote: Attaching a zip of the files Looks like you need to rename the inf, or add a password to the Zip. cat 0_Warning.txt BLOCKED FILE ALERTA file has been blocked due to the 'Intel Email File Filtering Policy' rule.Context: 'acpidump.inf'Disallowed due to Ticket Number: '0ab4-55b9-3aff-0008' See your system administrator for further information. Copyright 1999-2011 McAfee, Inc.All Rights Reserved.http://www.mcafee.com Thanks for working on this. Thanks, Andrew Fish -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan D Sent: Wednesday, July 29, 2015 1:37 PM To: 'Andrew Fish'; 'edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org' Subject: Re: [edk2] efi acpidump port Hi all, Let me know if the attachments to this message do not show up. I’ve elaborated the build metadata, reduced the ACPICA changes (moving alterations into additional files as needed), and verified that the compiled AcpicaPkg provides a correct implementation of acpidump that works for Minnow. To set up the EDK2 AcpicaPkg from the ACPICA sources: 1.)Go to https://acpica.org/downloads https://acpica.org/downloads and download aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar https://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar 2.)Extract the tar and put it in the root of edk2 as AcpicaPkg 3.)Apply acenv.patch to edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two lines manually. 4.)Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and acpi_main.c to the dir edk2\AcpicaPkg 5.)Add the file acedk2efi.h to the dir edk2\AcpicaPkg\source\include\platform I had to make several changes to link to the edk2 implementation of LibC. Now the only code in ACPICA that changes is the #ifdef that includes our acedk2efi.h file; this is a slightly modified version of the #else block in acefi.h we had earlier. Cheers, Jonathan Smith From: Andrew Fish [mailto:af...@apple.com mailto:af...@apple.com] Sent: Saturday, July 18, 2015 12:44 PM To: Smith, Jonathan D Cc: edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org Subject: Re: [edk2] efi acpidump port On Jul 18, 2015, at 11:23 AM, Smith, Jonathan D jonathan.d.sm...@intel.com mailto:jonathan.d.sm...@intel.commailto:jonathan.d.sm...@intel.com mailto:jonathan.d.sm...@intel.com wrote: The issues I ran into were after solving issues with the /D options. I’ve been working with /D _EDK2_EFI /D _ACPI_DUMP_APP so far. A lot of warnings escalated to errors were simple fixes, such as unsigned-to-signed comparisons. I was asking whether the parameter I mentioned called “Address” which was declared as type ACPI_SIZE should have been declared ACPI_PHYSICAL_ADDRESS, since every use of that function (OslMapTable) passes in type ACPI_PHYSICAL_ADDRESS. Changing to the address type fixes some compile warnings, but I was wondering if there was some implicit reason why we used the size type instead. Jonathan, 1st off this code comes from acpica, so the experts about this code don’t subscribe to this mailing list. You would need to ask questions about why on some acpica list. I only looked at the acpiaca code for the 1st time to try and port it. ACPI_PHYSICAL_ADDRESS is defined in actypes.h. This file supports different modes of acpica, but it is tool agnostic. So I did not change it.This file is modified by #define’s so you probably have the wrong combination? You probably have some more fundamental bug that you are hiding by changing the common code. The acpica code supports being compiled for VC++ and gcc, so it “should work”? The edk2 defines EFI_PHYSICAL_ADDERSS as: typedef UINT64EFI_PHYSICAL_ADDRESS; ~/work/src/edk2/acpica(acpica)git grep --untracked ACPI_PHYSICAL_ADDRESS -- *.h | grep typedef source/include/actypes.h:238:typedef UINT64 ACPI_PHYSICAL_ADDRESS; source/include/actypes.h:285:typedef UINT32 ACPI_PHYSICAL_ADDRESS; source/include/actypes.h:295:typedef UINT64 ACPI_PHYSICAL_ADDRESS; Thus you don’t really need to set things to EFI_PHYSICAL_ADDRESS, you just need to make sure acpica has the right settings. It looks like ACPI_32BIT_PHYSICAL_ADDRESS getting set will cause a 32-bit address. If EFI_PHYSICAL_ADDERSS and EFI_PHYSICAL_ADDERSS are both defined to be UINT64 I would not thing you would have an issue?
Re: [edk2] efi acpidump port
On Jul 29, 2015, at 1:43 PM, Smith, Jonathan D jonathan.d.sm...@intel.com wrote: Attaching a zip of the files Looks like you need to rename the inf, or add a password to the Zip. cat 0_Warning.txt BLOCKED FILE ALERTA file has been blocked due to the 'Intel Email File Filtering Policy' rule.Context: 'acpidump.inf'Disallowed due to Ticket Number: '0ab4-55b9-3aff-0008' See your system administrator for further information. Copyright 1999-2011 McAfee, Inc.All Rights Reserved.http://www.mcafee.com Thanks for working on this. Thanks, Andrew Fish -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan D Sent: Wednesday, July 29, 2015 1:37 PM To: 'Andrew Fish'; 'edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org' Subject: Re: [edk2] efi acpidump port Hi all, Let me know if the attachments to this message do not show up. I’ve elaborated the build metadata, reduced the ACPICA changes (moving alterations into additional files as needed), and verified that the compiled AcpicaPkg provides a correct implementation of acpidump that works for Minnow. To set up the EDK2 AcpicaPkg from the ACPICA sources: 1.)Go to https://acpica.org/downloads https://acpica.org/downloads and download aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar https://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar 2.)Extract the tar and put it in the root of edk2 as AcpicaPkg 3.)Apply acenv.patch to edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two lines manually. 4.)Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and acpi_main.c to the dir edk2\AcpicaPkg 5.)Add the file acedk2efi.h to the dir edk2\AcpicaPkg\source\include\platform I had to make several changes to link to the edk2 implementation of LibC. Now the only code in ACPICA that changes is the #ifdef that includes our acedk2efi.h file; this is a slightly modified version of the #else block in acefi.h we had earlier. Cheers, Jonathan Smith From: Andrew Fish [mailto:af...@apple.com mailto:af...@apple.com] Sent: Saturday, July 18, 2015 12:44 PM To: Smith, Jonathan D Cc: edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org Subject: Re: [edk2] efi acpidump port On Jul 18, 2015, at 11:23 AM, Smith, Jonathan D jonathan.d.sm...@intel.com mailto:jonathan.d.sm...@intel.commailto:jonathan.d.sm...@intel.com mailto:jonathan.d.sm...@intel.com wrote: The issues I ran into were after solving issues with the /D options. I’ve been working with /D _EDK2_EFI /D _ACPI_DUMP_APP so far. A lot of warnings escalated to errors were simple fixes, such as unsigned-to-signed comparisons. I was asking whether the parameter I mentioned called “Address” which was declared as type ACPI_SIZE should have been declared ACPI_PHYSICAL_ADDRESS, since every use of that function (OslMapTable) passes in type ACPI_PHYSICAL_ADDRESS. Changing to the address type fixes some compile warnings, but I was wondering if there was some implicit reason why we used the size type instead. Jonathan, 1st off this code comes from acpica, so the experts about this code don’t subscribe to this mailing list. You would need to ask questions about why on some acpica list. I only looked at the acpiaca code for the 1st time to try and port it. ACPI_PHYSICAL_ADDRESS is defined in actypes.h. This file supports different modes of acpica, but it is tool agnostic. So I did not change it.This file is modified by #define’s so you probably have the wrong combination? You probably have some more fundamental bug that you are hiding by changing the common code. The acpica code supports being compiled for VC++ and gcc, so it “should work”? The edk2 defines EFI_PHYSICAL_ADDERSS as: typedef UINT64EFI_PHYSICAL_ADDRESS; ~/work/src/edk2/acpica(acpica)git grep --untracked ACPI_PHYSICAL_ADDRESS -- *.h | grep typedef source/include/actypes.h:238:typedef UINT64 ACPI_PHYSICAL_ADDRESS; source/include/actypes.h:285:typedef UINT32 ACPI_PHYSICAL_ADDRESS; source/include/actypes.h:295:typedef UINT64 ACPI_PHYSICAL_ADDRESS; Thus you don’t really need to set things to EFI_PHYSICAL_ADDRESS, you just need to make sure acpica has the right settings. It looks like ACPI_32BIT_PHYSICAL_ADDRESS getting set will cause a 32-bit address. If EFI_PHYSICAL_ADDERSS and EFI_PHYSICAL_ADDERSS are both defined to be UINT64 I would not thing you would have an issue? I’m running into further issues now with the ACPICA package trying to define functions like memcpy which are intrinsic and cause a fatal error on compile What error are you getting? You should fix the thing that is throwing the error, and not modify
Re: [edk2] [PATCH v3 12/12] BaseTools/X86|IA32: move to unified GCC linker script
Subject prefix: BaseTools/X86|IA32 = BaseTools IA32/X64 What about 1 more step? :) This change starts to make use of the -z common-page-size and --defsym=PECOFF_HEADER_SIZE params, but the description says 'move to unified script'. So, how about first modifying the gcc*-ld-script files to use -z common-page-size and --defsym=PECOFF_HEADER_SIZE and then the last patch is trivial: BaseTools IA32/X64: Use GccBase.lds instead of gcc*-ld-script These scripts all now have the same contents, so we only need to use GccBase.lds. Therefore we can delete gcc-4K-align-ld-script, gcc4.4-ld-script and gcc4.9-ld-script. With that change, the series is Reviewed-by: Jordan Justen jordan.l.jus...@intel.com although, I would like someone to test the changes on a '4k' aligned image build. Liming, do you know who might be able to do that? -Jordan On 2015-07-29 08:12:02, Ard Biesheuvel wrote: Drop the GCC 4.4/X86 and 4.9/X86 specific linker scripts and use the new unified one instead. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- BaseTools/Conf/tools_def.template| 28 +-- BaseTools/Scripts/gcc-4K-align-ld-script | 38 BaseTools/Scripts/gcc4.4-ld-script | 38 BaseTools/Scripts/gcc4.9-ld-script | 38 4 files changed, 26 insertions(+), 116 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index d3dfdc41ada1..eeb488fb3597 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3847,10 +3847,12 @@ DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B aarch64 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_IA32_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -m32 -malign-double -fno-stack-protector -D EFI32 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 -DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.4-ld-script +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_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_ASM_FLAGS = DEF(GCC_ASM_FLAGS) DEFINE GCC45_IA32_CC_FLAGS = DEF(GCC44_IA32_CC_FLAGS) @@ -3858,7 +3860,9 @@ 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) +DEFINE GCC45_IA32_DLINK2_FLAGS = DEF(GCC44_IA32_DLINK2_FLAGS) 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 @@ -3866,7 +3870,9 @@ DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS) -Wno-address -Wno 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) +DEFINE GCC46_IA32_DLINK2_FLAGS = DEF(GCC45_IA32_DLINK2_FLAGS) DEFINE GCC46_X64_DLINK_FLAGS = DEF(GCC45_X64_DLINK_FLAGS) +DEFINE GCC46_X64_DLINK2_FLAGS= DEF(GCC45_X64_DLINK2_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(GCC44_ALL_CC_FLAGS) DEF(GCC_ARM_CC_FLAGS) -fstack-protector @@ -3878,7 +3884,9 @@ DEFINE GCC47_X64_CC_FLAGS= DEF(GCC46_X64_CC_FLAGS) DEFINE GCC47_IA32_X64_DLINK_COMMON = DEF(GCC46_IA32_X64_DLINK_COMMON) DEFINE
Re: [edk2] efi acpidump port
On 2015-07-29 16:27:38, Andrew Fish wrote: On Jul 29, 2015, at 4:11 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-07-29 13:43:43, Smith, Jonathan D wrote: Attaching a zip of the files -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan D Sent: Wednesday, July 29, 2015 1:37 PM To: 'Andrew Fish'; 'edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org' Subject: Re: [edk2] efi acpidump port Hi all, Let me know if the attachments to this message do not show up. I’ve elaborated the build metadata, reduced the ACPICA changes (moving alterations into additional files as needed), and verified that the compiled AcpicaPkg provides a correct implementation of acpidump that works for Minnow. To set up the EDK2 AcpicaPkg from the ACPICA sources: 1.) Go to https://acpica.org/downloads https://acpica.org/downloads and download aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar https://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar 2.) Extract the tar and put it in the root of edk2 as AcpicaPkg 3.) Apply acenv.patch to edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two lines manually. 4.) Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and acpi_main.c to the dir edk2\AcpicaPkg 5.) Add the file acedk2efi.h to the dir edk2\AcpicaPkg\source\include\platform This seems a little silly. Like the Intel email server removing the INF from the zip file? It is usually pretty entertaining to watch people trying to outsmart this filtering. Wow. After all these years, I think I finally convinced myself that this filtering is good for something. :) Seems silly to make a branch to add a single package. This is a perfect example of how much better it is to work with git than svn. There is no fuss to work on a new feature such as this on a new branch and make it available to everyone... How do you add a subproject? Like the FatPkg? He can just run mkdir and add the files in his branch. Hopefully they'll make it into EDK II proper at some point. -Jordan ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] efi acpidump port
On 2015-07-29 13:43:43, Smith, Jonathan D wrote: Attaching a zip of the files -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan D Sent: Wednesday, July 29, 2015 1:37 PM To: 'Andrew Fish'; 'edk2-devel@lists.01.org' Subject: Re: [edk2] efi acpidump port Hi all, Let me know if the attachments to this message do not show up. I’ve elaborated the build metadata, reduced the ACPICA changes (moving alterations into additional files as needed), and verified that the compiled AcpicaPkg provides a correct implementation of acpidump that works for Minnow. To set up the EDK2 AcpicaPkg from the ACPICA sources: 1.) Go to https://acpica.org/downloads and download aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar 2.) Extract the tar and put it in the root of edk2 as AcpicaPkg 3.) Apply acenv.patch to edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two lines manually. 4.) Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and acpi_main.c to the dir edk2\AcpicaPkg 5.) Add the file acedk2efi.h to the dir edk2\AcpicaPkg\source\include\platform This seems a little silly. Maybe you can just fork edk2, make the required changes and provide a link to your branch? https://github.com/tianocore/edk2 Also, what about 'Contributed-under'? (MdePkg/Contributions.txt) By the way, I think Prince (Cc'd) did a port of acpidump in the past, but never tried to release it externally. -Jordan I had to make several changes to link to the edk2 implementation of LibC. Now the only code in ACPICA that changes is the #ifdef that includes our acedk2efi.h file; this is a slightly modified version of the #else block in acefi.h we had earlier. Cheers, Jonathan Smith From: Andrew Fish [mailto:af...@apple.com] Sent: Saturday, July 18, 2015 12:44 PM To: Smith, Jonathan D Cc: edk2-devel@lists.01.org Subject: Re: [edk2] efi acpidump port On Jul 18, 2015, at 11:23 AM, Smith, Jonathan D jonathan.d.sm...@intel.commailto:jonathan.d.sm...@intel.com wrote: The issues I ran into were after solving issues with the /D options. I’ve been working with /D _EDK2_EFI /D _ACPI_DUMP_APP so far. A lot of warnings escalated to errors were simple fixes, such as unsigned-to-signed comparisons. I was asking whether the parameter I mentioned called “Address” which was declared as type ACPI_SIZE should have been declared ACPI_PHYSICAL_ADDRESS, since every use of that function (OslMapTable) passes in type ACPI_PHYSICAL_ADDRESS. Changing to the address type fixes some compile warnings, but I was wondering if there was some implicit reason why we used the size type instead. Jonathan, 1st off this code comes from acpica, so the experts about this code don’t subscribe to this mailing list. You would need to ask questions about why on some acpica list. I only looked at the acpiaca code for the 1st time to try and port it. ACPI_PHYSICAL_ADDRESS is defined in actypes.h. This file supports different modes of acpica, but it is tool agnostic. So I did not change it.This file is modified by #define’s so you probably have the wrong combination? You probably have some more fundamental bug that you are hiding by changing the common code. The acpica code supports being compiled for VC++ and gcc, so it “should work”? The edk2 defines EFI_PHYSICAL_ADDERSS as: typedef UINT64EFI_PHYSICAL_ADDRESS; ~/work/src/edk2/acpica(acpica)git grep --untracked ACPI_PHYSICAL_ADDRESS -- *.h | grep typedef source/include/actypes.h:238:typedef UINT64 ACPI_PHYSICAL_ADDRESS; source/include/actypes.h:285:typedef UINT32 ACPI_PHYSICAL_ADDRESS; source/include/actypes.h:295:typedef UINT64 ACPI_PHYSICAL_ADDRESS; Thus you don’t really need to set things to EFI_PHYSICAL_ADDRESS, you just need to make sure acpica has the right settings. It looks like ACPI_32BIT_PHYSICAL_ADDRESS getting set will cause a 32-bit address. If EFI_PHYSICAL_ADDERSS and EFI_PHYSICAL_ADDERSS are both defined to be UINT64 I would not thing you would have an issue? I’m running into further issues now with the ACPICA package trying to define functions like memcpy which are intrinsic and cause a fatal error on compile What error are you getting? You should fix the thing that is throwing the error, and not modify the code. I thin the gcc side might depend on that code? The edk2 StdLib includes a memcpy, so this issue must have been solved? . My workaround is to do #if !defined(_EDK2_EFI) guards since I searched the package and didn’t find any uses of those functions. I added the _EDK2_EFI, I don’t think it is a good idea to work around some compiler specific issue you are hitting by adding it in new locations. Currently I’m just combing the code for any
Re: [edk2] efi acpidump port
On Jul 29, 2015, at 4:11 PM, Jordan Justen jordan.l.jus...@intel.com wrote: On 2015-07-29 13:43:43, Smith, Jonathan D wrote: Attaching a zip of the files -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Smith, Jonathan D Sent: Wednesday, July 29, 2015 1:37 PM To: 'Andrew Fish'; 'edk2-devel@lists.01.org mailto:edk2-devel@lists.01.org' Subject: Re: [edk2] efi acpidump port Hi all, Let me know if the attachments to this message do not show up. I’ve elaborated the build metadata, reduced the ACPICA changes (moving alterations into additional files as needed), and verified that the compiled AcpicaPkg provides a correct implementation of acpidump that works for Minnow. To set up the EDK2 AcpicaPkg from the ACPICA sources: 1.) Go to https://acpica.org/downloads https://acpica.org/downloads and download aspia-unix-20150619.tarhttps://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar https://acpica.org/downloads%20and%20download%20aspia-unix-20150619.tar 2.) Extract the tar and put it in the root of edk2 as AcpicaPkg 3.) Apply acenv.patch to edk2\AcpicaPkg\source\include\platform\acenv.h or just add the two lines manually. 4.) Add the files AcpicaPkg.dec, AcpicaPkg.dsc, acpidump.inf, and acpi_main.c to the dir edk2\AcpicaPkg 5.) Add the file acedk2efi.h to the dir edk2\AcpicaPkg\source\include\platform This seems a little silly. Like the Intel email server removing the INF from the zip file? Seems silly to make a branch to add a single package. How do you add a subproject? Like the FatPkg? Thanks, Andrew Fish Maybe you can just fork edk2, make the required changes and provide a link to your branch? https://github.com/tianocore/edk2 https://github.com/tianocore/edk2 Also, what about 'Contributed-under'? (MdePkg/Contributions.txt) By the way, I think Prince (Cc'd) did a port of acpidump in the past, but never tried to release it externally. -Jordan ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] MdeModulePkg: Enhance PciBusDxe to handle high 32bit of MEM64 BAR returns 0
According to the PCI spec, when software writes all-one to BAR for size probing,
the value read back should be 0b1...10...0 after masking the BAR type bits.
But in real world, it's possible that certain device returns 0b0...01...10...0
for MEM64 BAR size probing: some bits in the high 32bit may be 0.
PciBus driver has the code to handle such case. However, it doesn't handle the
case that the high 32bit is totally 0. The patch is to handle the special case.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Eric Dong eric.d...@intel.com
---
MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
index 9e7ac74..f46025e 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
@@ -1,7 +1,7 @@
/** @file
PCI emumeration support functions implementation for PCI Bus module.
-Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.BR
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
@@ -1770,14 +1770,19 @@ PciParseBar (
// some device implement MMIO bar with 0 length, need to treat it as
no-bar
//
PciIoDevice-PciBar[BarIndex].BarType = PciBarTypeUnknown;
+ return Offset + 4;
}
-return Offset + 4;
}
//
// Fix the length to support some spefic 64 bit BAR
//
- Value |= ((UINT32)(-1) HighBitSet32 (Value));
+ if (Value == 0) {
+DEBUG ((EFI_D_INFO, [PciBus]BAR probing for upper 32bit of MEM64 BAR
returns 0, change to 0x.\n));
+Value = (UINT32) -1;
+ } else {
+Value |= ((UINT32)(-1) HighBitSet32 (Value));
+ }
//
// Calculate the size of 64bit bar
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/2] Update License Header to use BSD License
Reviewed-by: Ruiyu Ni ruiyu...@intel.com -Original Message- From: Dong, Eric Sent: Wednesday, July 29, 2015 4:59 PM To: Ni, Ruiyu ruiyu...@intel.com; Gao, Liming liming@intel.com; edk2-devel@lists.01.org Subject: [Patch 0/2] Update License Header to use BSD License Some code error used intel license, this patch update it to use BSD license. Eric Dong (2): Update copyright info, use BDS license. Update copyright info, use BDS license. .../LegacyBootMaintUiLib/LegacyBootMaintUi.c | 19 +++--- .../LegacyBootMaintUiLib/LegacyBootMaintUi.h | 19 +++--- .../LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf | 16 ++-- .../LegacyBootMaintUiStrings.uni | Bin 6318 - 6376 bytes .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr | 19 +++--- .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h| 19 +++--- .../Include/Guid/HiiBootMaintenanceFormset.h | 28 + 7 files changed, 59 insertions(+), 61 deletions(-) -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/3] Add UiApp/LegacyBootMaintUiLib used for New BdsDxe code.
Reviewed-by: Ruiyu Ni ruiyu...@intel.com Thanks a lot for filling the gap after new BDS driver is added. -Original Message- From: Dong, Eric Sent: Wednesday, July 29, 2015 4:26 PM To: Ni, Ruiyu ruiyu...@intel.com; Gao, Liming liming@intel.com; edk2-devel@lists.01.org Subject: [Patch 0/3] Add UiApp/LegacyBootMaintUiLib used for New BdsDxe code. After new BdsDxe driver checked in at MdeModulePkg/Universal/BdsDxe, it does not have an UI part code to cowork with this new bds code. Now this UiApp and LegacyBootMaintUiLib is develop to meet this requirement. We split the legacyBootMaintUiLib from UiApp is to make the UiApp are legacy free. It's used to manipulate the legacy boot option order which was keep in Boot Maitainence Manager-Boot Option. UiApp has same user experience with IntelFrameworkModulePkg/Universal/BdsDxe, only change the legacy boot option order change page from BootMaitainenceManager-BootOption to BootMaitainenceManager-LegacyBootOptionsMenu. Eric Dong (3): UiApp code split from IntelFrameworkModulePkg/Universal/BdsDxe driver. Legacy Boot Maintenance UI part code split from IntelFrameworkModulePkg/Universal/BdsDxe driver. Enable NT32 platform to use new UiApp code. .../IntelFrameworkModulePkg.dsc|1 + .../LegacyBootMaintUiLib/LegacyBootMaintUi.c | 1464 ++ .../LegacyBootMaintUiLib/LegacyBootMaintUi.h | 254 .../LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf | 68 + .../LegacyBootMaintUiStrings.uni | Bin 0 - 6318 bytes .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr | 74 + .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h| 84 + MdeModulePkg/Application/UiApp/BootMaint/Bm.vfr| 352 + MdeModulePkg/Application/UiApp/BootMaint/BmLib.c | 369 + .../Application/UiApp/BootMaint/Bmstring.uni | Bin 0 - 41522 bytes .../Application/UiApp/BootMaint/BootMaint.c| 1407 + .../Application/UiApp/BootMaint/BootMaint.h| 1478 ++ .../Application/UiApp/BootMaint/BootOption.c | 1527 +++ .../Application/UiApp/BootMaint/ConsoleOption.c| 995 MdeModulePkg/Application/UiApp/BootMaint/Data.c| 274 MdeModulePkg/Application/UiApp/BootMaint/FE.vfr| 123 ++ .../Application/UiApp/BootMaint/FileExplorer.c | 327 .../Application/UiApp/BootMaint/FormGuid.h | 204 +++ .../Application/UiApp/BootMaint/UpdatePage.c | 1194 +++ .../Application/UiApp/BootMaint/Variable.c | 1068 + .../Application/UiApp/BootMngr/BootManager.c | 385 + .../Application/UiApp/BootMngr/BootManager.h | 112 ++ .../UiApp/BootMngr/BootManagerStrings.uni | Bin 0 - 3532 bytes .../Application/UiApp/BootMngr/BootManagerVfr.Vfr | 50 + .../Application/UiApp/DeviceMngr/DeviceManager.c | 796 ++ .../Application/UiApp/DeviceMngr/DeviceManager.h | 155 ++ .../UiApp/DeviceMngr/DeviceManagerStrings.uni | Bin 0 - 7100 bytes .../UiApp/DeviceMngr/DeviceManagerVfr.Vfr | 102 ++ .../UiApp/DeviceMngr/DriverHealthVfr.Vfr | 45 + MdeModulePkg/Application/UiApp/FormsetGuid.h | 51 + MdeModulePkg/Application/UiApp/FrontPage.c | 1601 MdeModulePkg/Application/UiApp/FrontPage.h | 278 .../Application/UiApp/FrontPageStrings.uni | Bin 0 - 11190 bytes MdeModulePkg/Application/UiApp/FrontPageVfr.Vfr| 149 ++ MdeModulePkg/Application/UiApp/Language.c | 309 MdeModulePkg/Application/UiApp/Language.h | 48 + MdeModulePkg/Application/UiApp/String.c| 67 + MdeModulePkg/Application/UiApp/String.h| 76 + MdeModulePkg/Application/UiApp/Strings.uni | Bin 0 - 4716 bytes MdeModulePkg/Application/UiApp/Ui.h| 179 +++ MdeModulePkg/Application/UiApp/UiApp.inf | 143 ++ .../Include/Guid/HiiBootMaintenanceFormset.h | 33 + MdeModulePkg/MdeModulePkg.dec |3 + MdeModulePkg/MdeModulePkg.dsc |1 + Nt32Pkg/Nt32Pkg.dsc|9 +- Nt32Pkg/Nt32Pkg.fdf|6 +- 46 files changed, 15851 insertions(+), 10 deletions(-) create mode 100644 IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMain tUi.c create mode 100644 IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMain tUi.h create mode 100644 IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMain tUiLib.inf create mode 100644 IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMain tUiStrings.uni create mode 100644 IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMain tUiVfr.Vfr create mode 100644
Re: [edk2] [Patch 0/3] Add UiApp/LegacyBootMaintUiLib used for New BdsDxe code.
On Wed, 2015-07-29 at 16:26 +0800, Eric Dong wrote: After new BdsDxe driver checked in at MdeModulePkg/Universal/BdsDxe, it does not have an UI part code to cowork with this new bds code. Now this UiApp and LegacyBootMaintUiLib is develop to meet this requirement. We split the legacyBootMaintUiLib from UiApp is to make the UiApp are legacy free. It's used to manipulate the legacy boot option order which was keep in Boot Maitainence Manager-Boot Option. UiApp has same user experience with IntelFrameworkModulePkg/Universal/BdsDxe, only change the legacy boot option order change page from BootMaitainenceManager-BootOption to BootMaitainenceManager-LegacyBootOptionsMenu. Does this resolve the issues we had with the BDS and selecting Legacy boot targets, when using SeaBIOS as a CSM? There were a bunch of patches which started to address some of that in http://git.infradead.org/users/dwmw2/edk2.git/shortlog/refs/heads/csm16 (And I'm still mildly annoyed that the EFI_COMPATIBILITY16_TABLE update for the new spec is *still* not merged...) -- 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
[edk2] [Patch 2/2] Update copyright info, use BDS license.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong eric.d...@intel.com --- .../Include/Guid/HiiBootMaintenanceFormset.h | 28 ++ 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h b/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h index 7c809f4..393cc95 100644 --- a/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h +++ b/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h @@ -1,25 +1,21 @@ // -// This file contains 'Framework Code' and is licensed as such -// under the terms of your license agreement with Intel or your -// vendor. This file may not be modified, except as allowed by -// additional terms of your license agreement. -// -/**@file -Constants and declarations that are common accross PEI and DXE. - -Copyright (c) 2011, Intel Corporation. All rights reserved.BR -This software and associated documentation (if any) is furnished -under a license and may only be used or copied in accordance -with the terms of the license. Except as permitted by such -license, no part of this software or documentation may be -reproduced, stored in a retrieval system, or transmitted in any -form or by any means without the express written consent of -Intel Corporation. +/** @file + Guid definition for Boot Maintainence Formset. + +Copyright (c) 2015, Intel Corporation. All rights reserved.BR +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 __HII_BOOT_MAINTENANCE_FORMSET_H__ #define __HII_BOOT_MAINTENANCE_FORMSET_H__ /// /// Guid define to group the item show on the Boot Menaintenance Manager Menu. -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 0/2] Update License Header to use BSD License
Some code error used intel license, this patch update it to use BSD license. Eric Dong (2): Update copyright info, use BDS license. Update copyright info, use BDS license. .../LegacyBootMaintUiLib/LegacyBootMaintUi.c | 19 +++--- .../LegacyBootMaintUiLib/LegacyBootMaintUi.h | 19 +++--- .../LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf | 16 ++-- .../LegacyBootMaintUiStrings.uni | Bin 6318 - 6376 bytes .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.Vfr | 19 +++--- .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h| 19 +++--- .../Include/Guid/HiiBootMaintenanceFormset.h | 28 + 7 files changed, 59 insertions(+), 61 deletions(-) -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] MdeModulePkg: Enhance PciBusDxe to handle high 32bit of MEM64 BAR returns 0
Reviewed-by: Eric Dong eric.d...@intel.com
-Original Message-
From: Ni, Ruiyu
Sent: Thursday, July 30, 2015 11:11 AM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Dong, Eric
Subject: [Patch] MdeModulePkg: Enhance PciBusDxe to handle high 32bit of MEM64
BAR returns 0
According to the PCI spec, when software writes all-one to BAR for size
probing, the value read back should be 0b1...10...0 after masking the BAR type
bits.
But in real world, it's possible that certain device returns 0b0...01...10...0
for MEM64 BAR size probing: some bits in the high 32bit may be 0.
PciBus driver has the code to handle such case. However, it doesn't handle the
case that the high 32bit is totally 0. The patch is to handle the special case.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni ruiyu...@intel.com
Cc: Eric Dong eric.d...@intel.com
---
MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
index 9e7ac74..f46025e 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumeratorSupport.c
@@ -1,7 +1,7 @@
/** @file
PCI emumeration support functions implementation for PCI Bus module.
-Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.BR
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 @@ -1770,14
+1770,19 @@ PciParseBar (
// some device implement MMIO bar with 0 length, need to treat it as
no-bar
//
PciIoDevice-PciBar[BarIndex].BarType = PciBarTypeUnknown;
+ return Offset + 4;
}
-return Offset + 4;
}
//
// Fix the length to support some spefic 64 bit BAR
//
- Value |= ((UINT32)(-1) HighBitSet32 (Value));
+ if (Value == 0) {
+DEBUG ((EFI_D_INFO, [PciBus]BAR probing for upper 32bit of MEM64 BAR
returns 0, change to 0x.\n));
+Value = (UINT32) -1;
+ } else {
+Value |= ((UINT32)(-1) HighBitSet32 (Value));
+ }
//
// Calculate the size of 64bit bar
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 12/12] BaseTools/X86|IA32: move to unified GCC linker script
Jordan: I have verified 4K aligned image build. Test-by: Liming Gao liming.gao@intel Thanks Liming -Original Message- From: Justen, Jordan L Sent: Thursday, July 30, 2015 5:16 AM To: Ard Biesheuvel; edk2-devel@lists.01.org; Liu, Yingke D; Gao, Liming Cc: ler...@redhat.com; leif.lindh...@linaro.org; Ard Biesheuvel Subject: Re: [PATCH v3 12/12] BaseTools/X86|IA32: move to unified GCC linker script Subject prefix: BaseTools/X86|IA32 = BaseTools IA32/X64 What about 1 more step? :) This change starts to make use of the -z common-page-size and --defsym=PECOFF_HEADER_SIZE params, but the description says 'move to unified script'. So, how about first modifying the gcc*-ld-script files to use -z common-page-size and --defsym=PECOFF_HEADER_SIZE and then the last patch is trivial: BaseTools IA32/X64: Use GccBase.lds instead of gcc*-ld-script These scripts all now have the same contents, so we only need to use GccBase.lds. Therefore we can delete gcc-4K-align-ld-script, gcc4.4-ld-script and gcc4.9-ld-script. With that change, the series is Reviewed-by: Jordan Justen jordan.l.jus...@intel.com although, I would like someone to test the changes on a '4k' aligned image build. Liming, do you know who might be able to do that? -Jordan On 2015-07-29 08:12:02, Ard Biesheuvel wrote: Drop the GCC 4.4/X86 and 4.9/X86 specific linker scripts and use the new unified one instead. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- BaseTools/Conf/tools_def.template| 28 +-- BaseTools/Scripts/gcc-4K-align-ld-script | 38 BaseTools/Scripts/gcc4.4-ld-script | 38 BaseTools/Scripts/gcc4.9-ld-script | 38 4 files changed, 26 insertions(+), 116 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index d3dfdc41ada1..eeb488fb3597 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -3847,10 +3847,12 @@ DEFINE GCC_AARCH64_RC_FLAGS= -I binary -O elf64-littleaarch64 -B aarch64 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_IA32_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -m32 -malign-double -fno-stack-protector -D EFI32 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 -DEFINE GCC44_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.4-ld-script +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_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_ASM_FLAGS = DEF(GCC_ASM_FLAGS) DEFINE GCC45_IA32_CC_FLAGS = DEF(GCC44_IA32_CC_FLAGS) @@ -3858,7 +3860,9 @@ 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) +DEFINE GCC45_IA32_DLINK2_FLAGS = DEF(GCC44_IA32_DLINK2_FLAGS) 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 @@ -3866,7 +3870,9 @@ DEFINE GCC46_X64_CC_FLAGS= DEF(GCC45_X64_CC_FLAGS) -Wno-address -Wno 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) +DEFINE GCC46_IA32_DLINK2_FLAGS = DEF(GCC45_IA32_DLINK2_FLAGS) DEFINE GCC46_X64_DLINK_FLAGS = DEF(GCC45_X64_DLINK_FLAGS) +DEFINE GCC46_X64_DLINK2_FLAGS= DEF(GCC45_X64_DLINK2_FLAGS) DEFINE GCC46_ASM_FLAGS = DEF(GCC45_ASM_FLAGS) DEFINE GCC46_ARM_ASM_FLAGS
