[edk2] PrePi.c:DecompressFirstFv() Use Conditions
Hi, I'm working on the BeagleBoneBlack port for UEFI. I am using the PrePi as the entry point, and need some help with the call to DecompressFirstFv(). I figure that FwVol.c:FfsAnyFvFindFirstFile() loops through each FV it gets from the FV HOB and searches for `EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE`, but I don't understand the difference between searching for 'Next Volume' and 'Next File of the type FIRMWARE_VOLUME_IMAGE'. Are we assuming a definite layout of the FD for this to work? Thanks, Varad -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [RFC 0/2] Introduce Mp Service protocol to UefiCpuPkg
On Tue, 2014-07-22 at 01:32 +, Fan, Jeff wrote: > Fan, > > If you want to promote this feature into EDKII UefiCpuPkg, please re-create > the patch based on the current revision of EDK2 like Scott said. Then we > could give further comments based on the new patch. Thanks your contribution! > OK, I will re-create the patch and send them in the near future. Thanks for your suggestion. Chen > Jeff > -Original Message- > From: Scott Duplichan [mailto:sc...@notabs.org] > Sent: Tuesday, July 22, 2014 12:16 AM > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] [RFC 0/2] Introduce Mp Service protocol to UefiCpuPkg > > Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] wrote: > > ]This series patches is base on Jljusten's tree: > ]https://github.com/jljusten/edk2/tree/ap-startup-example > > ]this patches tried to implement Mp Service protocol in UefiCpuPkg, ]there > was only startup APs in previous code, so add some initialization ]to let all > APs work up, this Mp Service protocol's implementation ]use EmulatorPkg/Mp > service for reference. > ] > ]and I used Ovmf and StartCorePkg to test this Mp Service protocol, ]it > seemed good. > > Hello Chen Fan, > > It looks like this patch is for application to Jljustin's branch > of EDK2. Shouldn't the patch be formatted so that it can apply to a recent > revision of the official EDK2 tree instead? > > Thanks, > Scott > > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck Code Sight > - the same software that powers the world's largest code search on Ohloh, the > Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [RFC 0/2] Introduce Mp Service protocol to UefiCpuPkg
Fan, If you want to promote this feature into EDKII UefiCpuPkg, please re-create the patch based on the current revision of EDK2 like Scott said. Then we could give further comments based on the new patch. Thanks your contribution! Jeff -Original Message- From: Scott Duplichan [mailto:sc...@notabs.org] Sent: Tuesday, July 22, 2014 12:16 AM To: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] [RFC 0/2] Introduce Mp Service protocol to UefiCpuPkg Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] wrote: ]This series patches is base on Jljusten's tree: ]https://github.com/jljusten/edk2/tree/ap-startup-example ]this patches tried to implement Mp Service protocol in UefiCpuPkg, ]there was only startup APs in previous code, so add some initialization ]to let all APs work up, this Mp Service protocol's implementation ]use EmulatorPkg/Mp service for reference. ] ]and I used Ovmf and StartCorePkg to test this Mp Service protocol, ]it seemed good. Hello Chen Fan, It looks like this patch is for application to Jljustin's branch of EDK2. Shouldn't the patch be formatted so that it can apply to a recent revision of the official EDK2 tree instead? Thanks, Scott -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] "orderedlist" grammar inconsistency
Tim, Thanks for you to report this issue, I will follow up to fix it. Thanks, Eric From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Tuesday, July 22, 2014 1:24 AM To: edk2-devel@lists.sourceforge.net Subject: [edk2] "orderedlist" grammar inconsistency The "flags" "=" portion of the VFR grammar currently does not allow a "," after it, which is different from all of the other questions. It should, at least, allow it to make it consistent with the other questions. Tim -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH 2/3] OvmfPkg/build.sh: Add support for GCC49 toolchain
On 07/21/14 23:48, Jordan Justen wrote: > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jordan Justen > --- > OvmfPkg/build.sh | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh > index 5bfee72..c3cc72e 100755 > --- a/OvmfPkg/build.sh > +++ b/OvmfPkg/build.sh > @@ -85,9 +85,12 @@ case `uname` in >4.7.*) > TARGET_TOOLS=GCC47 > ;; > - 4.[8-9].*) > + 4.8.*) > TARGET_TOOLS=GCC48 > ;; > + 4.9.*|4.1[0-9].*) Always the optimist, huh? :) > +TARGET_TOOLS=GCC49 > +;; >*) > TARGET_TOOLS=GCC44 > ;; > Reviewed-by: Laszlo Ersek -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] GCC 4.9 build issue - Re: Error building OvmfPkg
On Jul 21, 2014, at 2:55 PM, Jordan Justen wrote: > On Mon, Jul 21, 2014 at 2:44 PM, Andrew Fish wrote: >> On Jul 21, 2014, at 2:42 PM, Jordan Justen wrote: >>> On Sun, Jul 20, 2014 at 9:28 AM, Andrew Fish wrote: On Jul 19, 2014, at 9:42 PM, Jordan Justen wrote: > Anyway, I figured out what the issue is, but I don't have a solution yet. > https://gcc.gnu.org/ml/gcc-help/2014-07/msg00075.html > > Basically GCC 4.9 creates a 64-byte aligned section in the elf image, > but we instruct the linker to use 32 byte alignment. Then GenFw (which > also assumes 32 byte alignment) complains while trying to convert the > ELF image to PE/COFF. > The default alignment for image (PE/COFF, ELF, etc.) sections is usually 4K (page aligned). We cranked the alignment down to 32 bytes (0x20) to make the images smaller. There is nothing magic about 32 bytes, it was just the smallest alignment we could make work with VC++. I think if you set the section alignment to 64 bytes everything would just work. I think that means you would need a different linker script fro GCC 4.9. https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Scripts/gcc4.4-ld-script >>> >>> Ok. I'll do this. >>> >>> If we find a way to get GCC 4.9 to cap the alignment at 32 bytes, then >>> we can adjust the toolchain to save some space. >> >> Is it all CPU architectures? Maybe you only need to change the ones that >> fail? > > I checked it for IA32 & X64. > > I think this can be checked using the simple command I mentioned in: > https://gcc.gnu.org/ml/gcc-help/2014-07/msg00075.html > > The patch I just sent will only update the linker alignment on IA32 & > X64 builds. > OK thanks for the info. Looks like some kind of cache alignment performance enhancement? Thanks, Andrew Fish > -Jordan -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] GCC 4.9 build issue - Re: Error building OvmfPkg
On Mon, Jul 21, 2014 at 2:44 PM, Andrew Fish wrote: > On Jul 21, 2014, at 2:42 PM, Jordan Justen wrote: >> On Sun, Jul 20, 2014 at 9:28 AM, Andrew Fish wrote: >>> On Jul 19, 2014, at 9:42 PM, Jordan Justen wrote: Anyway, I figured out what the issue is, but I don't have a solution yet. https://gcc.gnu.org/ml/gcc-help/2014-07/msg00075.html Basically GCC 4.9 creates a 64-byte aligned section in the elf image, but we instruct the linker to use 32 byte alignment. Then GenFw (which also assumes 32 byte alignment) complains while trying to convert the ELF image to PE/COFF. >>> >>> The default alignment for image (PE/COFF, ELF, etc.) sections is usually >>> 4K (page aligned). We cranked the alignment down to 32 bytes (0x20) to >>> make the images smaller. There is nothing magic about 32 bytes, it was >>> just the smallest alignment we could make work with VC++. >>> >>> I think if you set the section alignment to 64 bytes everything would just >>> work. >>> >>> I think that means you would need a different linker script fro GCC 4.9. >>> https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Scripts/gcc4.4-ld-script >> >> Ok. I'll do this. >> >> If we find a way to get GCC 4.9 to cap the alignment at 32 bytes, then >> we can adjust the toolchain to save some space. > > Is it all CPU architectures? Maybe you only need to change the ones that fail? I checked it for IA32 & X64. I think this can be checked using the simple command I mentioned in: https://gcc.gnu.org/ml/gcc-help/2014-07/msg00075.html The patch I just sent will only update the linker alignment on IA32 & X64 builds. -Jordan -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 2/3] OvmfPkg/build.sh: Add support for GCC49 toolchain
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen --- OvmfPkg/build.sh | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/OvmfPkg/build.sh b/OvmfPkg/build.sh index 5bfee72..c3cc72e 100755 --- a/OvmfPkg/build.sh +++ b/OvmfPkg/build.sh @@ -85,9 +85,12 @@ case `uname` in 4.7.*) TARGET_TOOLS=GCC47 ;; - 4.[8-9].*) + 4.8.*) TARGET_TOOLS=GCC48 ;; + 4.9.*|4.1[0-9].*) +TARGET_TOOLS=GCC49 +;; *) TARGET_TOOLS=GCC44 ;; -- 2.0.1 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 3/3] EmulatorPkg: Add support for GCC48 & GCC49 toolchains
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen --- EmulatorPkg/Unix/Host/Host.inf | 2 ++ EmulatorPkg/build.sh | 8 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/EmulatorPkg/Unix/Host/Host.inf b/EmulatorPkg/Unix/Host/Host.inf index 814a8c3..dee2e0d 100644 --- a/EmulatorPkg/Unix/Host/Host.inf +++ b/EmulatorPkg/Unix/Host/Host.inf @@ -127,6 +127,8 @@ GCC:*_GCC45_X64_CC_FLAGS = "-DEFIAPI=__attribute__((ms_abi))" GCC:*_GCC46_X64_CC_FLAGS = "-DEFIAPI=__attribute__((ms_abi))" GCC:*_GCC47_X64_CC_FLAGS = "-DEFIAPI=__attribute__((ms_abi))" + GCC:*_GCC48_X64_CC_FLAGS = "-DEFIAPI=__attribute__((ms_abi))" + GCC:*_GCC49_X64_CC_FLAGS = "-DEFIAPI=__attribute__((ms_abi))" GCC:*_*_X64_PP_FLAGS == -m64 -E -x assembler-with-cpp -include $(DEST_DIR_DEBUG)/AutoGen.h GCC:*_*_X64_ASM_FLAGS == -m64 -c -x assembler -imacros $(DEST_DIR_DEBUG)/AutoGen.h diff --git a/EmulatorPkg/build.sh b/EmulatorPkg/build.sh index 67648f5..fc8ae49 100755 --- a/EmulatorPkg/build.sh +++ b/EmulatorPkg/build.sh @@ -90,9 +90,15 @@ case `uname` in 4.6.*) TARGET_TOOLS=GCC46 ;; - 4.[789].*) + 4.7.*) TARGET_TOOLS=GCC47 ;; + 4.8.*) +TARGET_TOOLS=GCC48 +;; + 4.9.*|4.1[0-9].*) +TARGET_TOOLS=GCC49 +;; *) TARGET_TOOLS=GCC44 ;; -- 2.0.1 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH 1/3] BaseTools: Add GCC49 toolchain; align data sections to 0x40
GCC 4.9 may use 64-byte (0x40) alignment for data sections. Therefore we use a different link script for GCC 4.9. The only difference from the gcc4.4-ld-script is the alignment for data sections. When using the GCC48 toolchain with GCC 4.9, this error would be encountered by GenFw: > GenFw: ERROR 3000: Invalid > Unsupported section alignment. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen Cc: edk2-buildtools-de...@lists.sourceforge.net Cc: Alain Kalker Cc: Keshav Amburay Cc: "Mendyke, DanielX" --- These patches are available in the gcc-4.9 branch of: https://github.com/jljusten/edk2.git BaseTools/Conf/tools_def.template | 145 + BaseTools/Scripts/gcc4.9-ld-script | 44 +++ 2 files changed, 189 insertions(+) create mode 100644 BaseTools/Scripts/gcc4.9-ld-script diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index f99ddf6..f9e1e6c 100644 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -162,6 +162,9 @@ DEFINE GCC47_X64_PREFIX= /usr/bin/ DEFINE GCC48_IA32_PREFIX = /usr/bin/ DEFINE GCC48_X64_PREFIX= /usr/bin/ +DEFINE GCC49_IA32_PREFIX = /usr/bin/ +DEFINE GCC49_X64_PREFIX= /usr/bin/ + DEFINE UNIX_IASL_BIN = ENV(IASL_PREFIX)iasl DEFINE WIN_ASL_BIN_DIR = C:\ASL DEFINE WIN_IASL_BIN= DEF(WIN_ASL_BIN_DIR)\iasl.exe @@ -307,6 +310,12 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program Files/CodeSourcery/Sourcery G # Required to build platforms or ACPI tables: # Intel(r) ACPI Compiler v20101013 from # http://www.acpica.org/downloads/previous_releases.php +# GCC49 -Linux- Requires: +# GCC 4.9 +#Optional: +# Required to build platforms or ACPI tables: +# Intel(r) ACPI Compiler v20101013 from +# http://www.acpica.org/downloads/previous_releases.php # ELFGCC -Linux- Requires: # GCC(this tool chain uses whatever version of gcc and binutils that is installed in /usr/bin) #Optional: @@ -3216,6 +3225,22 @@ DEFINE GCC48_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) DEFINE GCC48_ARM_ASLDLINK_FLAGS = DEF(GCC47_ARM_ASLDLINK_FLAGS) DEFINE GCC48_AARCH64_ASLDLINK_FLAGS = DEF(GCC_ARM_AARCH64_ASLDLINK_FLAGS) +DEFINE GCC49_IA32_CC_FLAGS = DEF(GCC48_IA32_CC_FLAGS) +DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS) +DEFINE GCC49_IA32_X64_DLINK_COMMON = -nostdlib -n -q --gc-sections --script=$(EDK_TOOLS_PATH)/Scripts/gcc4.9-ld-script +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_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) -melf_x86_64 --oformat=elf64-x86-64 +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(GCC_ARM_AARCH64_DLINK_COMMON) +DEFINE GCC49_ARM_ASLDLINK_FLAGS = DEF(GCC48_ARM_ASLDLINK_FLAGS) +DEFINE GCC49_AARCH64_ASLDLINK_FLAGS = DEF(GCC_ARM_AARCH64_ASLDLINK_FLAGS) + # # Unix GCC And Intel Linux ACPI Compiler @@ -3769,6 +3794,126 @@ RELEASE_GCC48_AARCH64_CC_FLAGS = DEF(GCC48_AARCH64_CC_FLAGS) -Wno-unused-but-s # +# GCC 4.9 - This configuration is used to compile under Linux to produce +# PE/COFF binaries using GCC 4.9. +# + +*_GCC49_*_*_FAMILY = GCC + +*_GCC49_*_MAKE_PATH= make +*_GCC49_*_ASL_PATH = DEF(UNIX_IASL_BIN) + +*_GCC49_*_PP_FLAGS = DEF(GCC_PP_FLAGS) +*_GCC49_*_ASLPP_FLAGS = DEF(GCC_ASLPP_FLAGS) +*_GCC49_*_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) +*_GCC49_*_VFRPP_FLAGS = DEF(GCC_VFRPP_FLAGS) +*_GCC49_*_APP_FLAGS= +*_GCC49_*_ASL_FLAGS= DEF(IASL_FLAGS) +*_GCC49_*_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS) + +## +# GCC49 IA32 defi
Re: [edk2] GCC 4.9 build issue - Re: Error building OvmfPkg
On Jul 21, 2014, at 2:42 PM, Jordan Justen wrote: > On Sun, Jul 20, 2014 at 9:28 AM, Andrew Fish wrote: >> On Jul 19, 2014, at 9:42 PM, Jordan Justen wrote: >>> Anyway, I figured out what the issue is, but I don't have a solution yet. >>> https://gcc.gnu.org/ml/gcc-help/2014-07/msg00075.html >>> >>> Basically GCC 4.9 creates a 64-byte aligned section in the elf image, >>> but we instruct the linker to use 32 byte alignment. Then GenFw (which >>> also assumes 32 byte alignment) complains while trying to convert the >>> ELF image to PE/COFF. >>> >> >> The default alignment for image (PE/COFF, ELF, etc.) sections is usually 4K >> (page aligned). We cranked the alignment down to 32 bytes (0x20) to make >> the images smaller. There is nothing magic about 32 bytes, it was just the >> smallest alignment we could make work with VC++. >> >> I think if you set the section alignment to 64 bytes everything would just >> work. >> >> I think that means you would need a different linker script fro GCC 4.9. >> https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Scripts/gcc4.4-ld-script > > Ok. I'll do this. > > If we find a way to get GCC 4.9 to cap the alignment at 32 bytes, then > we can adjust the toolchain to save some space. > Is it all CPU architectures? Maybe you only need to change the ones that fail? Thanks, Andrew Fish > Thanks, > > -Jordan -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] GCC 4.9 build issue - Re: Error building OvmfPkg
On Sun, Jul 20, 2014 at 9:28 AM, Andrew Fish wrote: > On Jul 19, 2014, at 9:42 PM, Jordan Justen wrote: >> Anyway, I figured out what the issue is, but I don't have a solution yet. >> https://gcc.gnu.org/ml/gcc-help/2014-07/msg00075.html >> >> Basically GCC 4.9 creates a 64-byte aligned section in the elf image, >> but we instruct the linker to use 32 byte alignment. Then GenFw (which >> also assumes 32 byte alignment) complains while trying to convert the >> ELF image to PE/COFF. >> > > The default alignment for image (PE/COFF, ELF, etc.) sections is usually 4K > (page aligned). We cranked the alignment down to 32 bytes (0x20) to make the > images smaller. There is nothing magic about 32 bytes, it was just the > smallest alignment we could make work with VC++. > > I think if you set the section alignment to 64 bytes everything would just > work. > > I think that means you would need a different linker script fro GCC 4.9. > https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Scripts/gcc4.4-ld-script Ok. I'll do this. If we find a way to get GCC 4.9 to cap the alignment at 32 bytes, then we can adjust the toolchain to save some space. Thanks, -Jordan -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [edk2-buildtools] [RFC] Proposal to retire edk2-buildtools sub-project
Hi, Thank you to everyone who provided feedback. There were no comments against this proposal, and there was feedback to make some refinements and clarifications. The detailed proposal with these updates is shown below. We will start the transition this week. We may need help from the EDK II community on some of the OS specific scripts to build BaseTools from sources and scripts to pull BaseTools binaries from https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/. Proposed steps: === 1) Create new sub-project for BaseTools binaries a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/ b. Status: Done. 2) Intel to provide Build System for BaseTools Win32 binaries a. SVN Link: https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/Win32/ b. Build Frequency: Once per day, but only if there are source changes since last build. Incremental build c. Build Time: 3 AM PDT d. Daily builds are incremental. This means that different tool binaries may have different versions based on the source control system revision used to perform incremental builds. e. Clean builds of BaseTools will only be done when a release branch is created or on-request if there are issues found with incremental build. d. If build fails for any reason, then build server sends build log to edk2-devel@lists.sourceforge.net and no new binaries are checked into https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/. e. If build succeeds then new binaries are checked into https://svn.code.sf.net/p/edk2-toolbinaries/code/trunk/. A build report in ReadMe.txt. is checked into the OS specific sub-directory. f. Initial Build System configuration ### Build System Information ### OS_Name = Windows Server 2008 R2 Enterprise (X64) OS_Version= 6.1.7601 Service Pack SP1 Build 7601 Visual Studio = Microsoft Visual Studio Team System 2008 Team Suite SP 1 Python= 2.7.3 (32bit) cxFreeze = 4.2.3 antlr3= 3.1.3 McAfee VirusScan Enterprise 8.8 f. Status: In progress. Need a few more validation steps. 3) Delete Win32 binaries from EDK II BaseTools and replace with an SVN extern. a. Default will continue to pull Win32 binaries b. Developers that do not want Win32 binaries can opt-out by ignoring externs. c. Date: TBD. Goal is immediately after Build System for BaseTools Win32 binaries is stable. 4) Merge sources from Edk2-buildtools to EDK II BaseTools a. Date: TBD. Goal is immediately after Build System for BaseTools Win32 binaries is stable. 5) Change permissions on Edk2-buildtools sub-project to read-only and mark sub-project as inactive. a. Date: TBD. Goal is immediately after EDK II BaseTools is synced with EDK2-buildtools. 6) Retire edk2-buildtools-comm...@lists.sourceforge.net mailing list. All commits to BaseTools sources will show up on edk2-comm...@lists.sourceforge.net. 7) Retire edk2-buildtools-de...@lists.sourceforge.net and move all BaseTools related discussions to edk2-devel@lists.sourceforge.net 8) Update edksetup.* to optionally build BaseTools from sources or pull BaseTools binaries from source control a. edksetup.* detects if binaries are present or not b. If BaseTools binaries not present, and no flags provided, then edksetup.* displays help for building BaseTools from sources or pulling BaseTools binaries from source control if applicable. c. If binaries not present, and flag to build BaseTools from sources specified, then build BaseTools from sources. d. If binaries not present, and flag to pull BaseTools binaries from source control specified, then use command line source control tools to pull BaseTools binaries from source control. e. edksetup.* to support optional flag to specify an alternate BaseTools binary directory to avoid potential source control system conflicts with BaseTools\Bin. This would allow a developer to have binaries build by Build System and locally build binaries present in the same workspace. f. Date: TBD. Goal is immediately after all tasks above have been completed. Work on the updates scripts has been started and proposed flags and details will be shared this week. g. NOTE: There are additional discussions on binaries from alternate distribution locations. Edksetup.* may need additional updates/maintenance to detect and pull from these alternate distribution locations as required. Thanks, Mike -Original Message- From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] Sent: Thursday, July 10, 2014 4:12 PM To: edk2-devel@lists.sourceforge.net; edk2-buildtools-de...@lists.sourceforge.net Subject: [edk2-buildtools] [edk2][RFC] Proposal to ret
[edk2] "orderedlist" grammar inconsistency
The "flags" "=" portion of the VFR grammar currently does not allow a "," after it, which is different from all of the other questions. It should, at least, allow it to make it consistent with the other questions. Tim -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [RFC 0/2] Introduce Mp Service protocol to UefiCpuPkg
Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] wrote: ]This series patches is base on Jljusten's tree: ]https://github.com/jljusten/edk2/tree/ap-startup-example ]this patches tried to implement Mp Service protocol in UefiCpuPkg, ]there was only startup APs in previous code, so add some initialization ]to let all APs work up, this Mp Service protocol's implementation ]use EmulatorPkg/Mp service for reference. ] ]and I used Ovmf and StartCorePkg to test this Mp Service protocol, ]it seemed good. Hello Chen Fan, It looks like this patch is for application to Jljustin's branch of EDK2. Shouldn't the patch be formatted so that it can apply to a recent revision of the official EDK2 tree instead? Thanks, Scott -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [RFC 2/2] UefiCpuPkg/CpuMp: Introduce Mp Service protocol
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen Fan
---
UefiCpuPkg/CpuDxe/ApStartup.c |9 +-
UefiCpuPkg/CpuDxe/CpuDxe.inf |4 +
UefiCpuPkg/CpuDxe/CpuMp.c | 1126 -
UefiCpuPkg/CpuDxe/CpuMp.h | 62 ++-
UefiCpuPkg/UefiCpuPkg.dec |2 +-
5 files changed, 1195 insertions(+), 8 deletions(-)
diff --git a/UefiCpuPkg/CpuDxe/ApStartup.c b/UefiCpuPkg/CpuDxe/ApStartup.c
index 27abe7a..de08dd9 100644
--- a/UefiCpuPkg/CpuDxe/ApStartup.c
+++ b/UefiCpuPkg/CpuDxe/ApStartup.c
@@ -149,7 +149,8 @@ STARTUP_CODE mStartupCodeTemplate = {
EFI_STATUS
StartApsStackless (
- IN STACKLESS_AP_ENTRY_POINT ApEntryPoint
+ IN STACKLESS_AP_ENTRY_POINT ApEntryPoint,
+ OUT UINTN *CountCPUs
)
{
EFI_STATUSStatus;
@@ -202,14 +203,12 @@ StartApsStackless (
Status = EFI_TIMEOUT;
}
+ *CountCPUs = CurrentCPUs;
+
DEBUG ((EFI_D_INFO, "Found CPU Count: %d\n", CurrentCPUs));
gBS->FreePages (StartAddress, EFI_SIZE_TO_PAGES (sizeof (*StartupCode)));
- if (CurrentCPUs == 1) {
-return EFI_SUCCESS;
- }
-
return Status;
}
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.inf b/UefiCpuPkg/CpuDxe/CpuDxe.inf
index cb20425..143531b 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.inf
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.inf
@@ -65,11 +65,15 @@
[Protocols]
gEfiCpuArchProtocolGuid
+ gEfiMpServiceProtocolGuid
[Guids]
gIdleLoopEventGuid## CONSUMES ## GUID
gEfiVectorHandoffTableGuid## CONSUMES ## Configuration
Table
+[Pcd]
+ gUefiCpuPkgTokenSpaceGuid.PcdCpuMpServicesPollingInterval
+
[Depex]
TRUE
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index e46de49..a5b0742 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -24,6 +24,10 @@ IA32_DESCRIPTOR gIdtr;
extern UINT32 ProcessorIdx;
extern UINT32 ProcessorIds[];
+MP_SYSTEM_DATAgMPSystem;
+EFI_HANDLEmpServiceHandle = NULL;
+UINTN gPollInterval;
+
VOID
EFIAPI
ApEntryPointInit (
@@ -54,12 +58,1117 @@ ApEntryPointInit (
ProcessorIdx++;
}
+VOID
+SendCallFuncIpi(
+ IN UINT64 cpu
+ )
+{
+ SendFixedIpi(cpu, CALL_FUNCTION_VECTOR);
+}
+
+PROCESSOR_STATE
+GetApState (
+ IN PROCESSOR_DATA_BLOCK *Processor
+ )
+{
+ PROCESSOR_STATE State;
+
+ while (!AcquireSpinLockOrFail (&Processor->ProcedureLock)) {
+CpuPause();
+ }
+ State = Processor->State;
+ ReleaseSpinLock (&Processor->ProcedureLock);
+
+ return State;
+}
+
+VOID
+SetApState (
+ IN PROCESSOR_DATA_BLOCK *Processor,
+ IN PROCESSOR_STATEState
+ )
+{
+ while (!AcquireSpinLockOrFail (&Processor->ProcedureLock)) {
+CpuPause();
+ }
+ Processor->State = State;
+ ReleaseSpinLock (&Processor->ProcedureLock);
+}
+
+VOID
+SetApProcedure (
+ IN PROCESSOR_DATA_BLOCK *Processor,
+ IN EFI_AP_PROCEDURE Procedure,
+ IN VOID *ProcedureArgument
+ )
+{
+ while (!AcquireSpinLockOrFail (&Processor->ProcedureLock)) {
+CpuPause();
+ }
+ Processor->Parameter = ProcedureArgument;
+ Processor->Procedure = Procedure;
+ ReleaseSpinLock (&Processor->ProcedureLock);
+}
+
+
+BOOLEAN
+IsBSP (
+ VOID
+ )
+{
+ UINTN ApicId;
+
+ ApicId = GetApicId();
+ if (ApicId == 0) {
+return TRUE;
+ } else {
+return FALSE;
+ }
+}
+
+/**
+ This service lets the caller get one enabled AP to execute a caller-provided
+ function. The caller can request the BSP to either wait for the completion
+ of the AP or just proceed with the next task by using the EFI event
mechanism.
+ See EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() for more details on non-blocking
+ execution support. This service may only be called from the BSP.
+
+ This function is used to dispatch one enabled AP to the function specified by
+ Procedure passing in the argument specified by ProcedureArgument. If
WaitEvent
+ is NULL, execution is in blocking mode. The BSP waits until the AP finishes
or
+ TimeoutInMicroSecondss expires. Otherwise, execution is in non-blocking mode.
+ BSP proceeds to the next task without waiting for the AP. If a non-blocking
mode
+ is requested after the UEFI Event EFI_EVENT_GROUP_READY_TO_BOOT is signaled,
+ then EFI_UNSUPPORTED must be returned.
+
+ If the timeout specified by TimeoutInMicroseconds expires before the AP
returns
+ from Procedure, then execution of Procedure by the AP is terminated. The AP
is
+ available for subsequent calls to EFI_MP_SERVICES_PROTOCOL.StartupAllAPs()
and
+ EFI_MP_SERVICES_PROTOCOL.StartupThisAP().
+
+ @param[in] ThisA pointer to the EFI_MP_SERVICES_PROTOCOL
+ instance.
+ @param[in] Procedure A pointer to the function to be run on
+ enabled APs of the system. See type
+ EFI_AP_PROCEDURE.
+ @param[i
[edk2] [RFC 0/2] Introduce Mp Service protocol to UefiCpuPkg
This series patches is base on Jljusten's tree: https://github.com/jljusten/edk2/tree/ap-startup-example this patches tried to implement Mp Service protocol in UefiCpuPkg, there was only startup APs in previous code, so add some initialization to let all APs work up, this Mp Service protocol's implementation use EmulatorPkg/Mp service for reference. and I used Ovmf and StartCorePkg to test this Mp Service protocol, it seemed good. Chen Fan (2): UefiCpuPkg/CpuDxe: Detect all APs UefiCpuPkg/CpuMp: Introduce Mp Service protocol UefiCpuPkg/CpuDxe/ApStartup.c | 29 +- UefiCpuPkg/CpuDxe/CpuDxe.inf |4 + UefiCpuPkg/CpuDxe/CpuMp.c | 1162 +++- UefiCpuPkg/CpuDxe/CpuMp.h | 62 +- UefiCpuPkg/CpuDxe/X64/MpAsm.S |9 +- UefiCpuPkg/Include/Library/LocalApicLib.h |8 +- UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c | 14 + UefiCpuPkg/UefiCpuPkg.dec |2 +- 8 files changed, 1277 insertions(+), 13 deletions(-) -- 1.9.3 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [RFC 1/2] UefiCpuPkg/CpuDxe: Detect all APs
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen Fan
---
UefiCpuPkg/CpuDxe/ApStartup.c | 28 +---
UefiCpuPkg/CpuDxe/CpuMp.c | 36 --
UefiCpuPkg/CpuDxe/X64/MpAsm.S | 9 +--
UefiCpuPkg/Include/Library/LocalApicLib.h | 8 +-
UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c | 14 ++
5 files changed, 86 insertions(+), 9 deletions(-)
diff --git a/UefiCpuPkg/CpuDxe/ApStartup.c b/UefiCpuPkg/CpuDxe/ApStartup.c
index b911fca..27abe7a 100644
--- a/UefiCpuPkg/CpuDxe/ApStartup.c
+++ b/UefiCpuPkg/CpuDxe/ApStartup.c
@@ -16,6 +16,9 @@
#include "CpuGdt.h"
#include "CpuMp.h"
+UINT32 ProcessorIdx = 1;
+UINT32 ProcessorIds[255];
+
#pragma pack(1)
typedef struct {
@@ -153,6 +156,8 @@ StartApsStackless (
volatile STARTUP_CODE *StartupCode;
IA32_DESCRIPTOR Gdtr;
EFI_PHYSICAL_ADDRESS StartAddress;
+ UINTN CurrentCPUs;
+ UINTN TimeCount;
StartAddress = BASE_1MB;
Status = gBS->AllocatePages (
@@ -182,14 +187,29 @@ StartApsStackless (
StartupCode->LongJmpOffset += (UINT32) StartAddress;
#endif
+ CurrentCPUs = 1;
+
SendInitSipiSipiAllExcludingSelf ((UINT32)(UINTN)(VOID*) StartupCode);
- DisableInterrupts ();
- CpuSleep ();
- CpuDeadLoop ();
+ for (TimeCount = 0; TimeCount < 100; TimeCount++) {
+CurrentCPUs = ProcessorIdx;
+gBS->Stall(10); // 100ms
+ }
+
+ Status = EFI_SUCCESS;
+
+ if (CurrentCPUs != (ProcessorIdx)) {
+Status = EFI_TIMEOUT;
+ }
+
+ DEBUG ((EFI_D_INFO, "Found CPU Count: %d\n", CurrentCPUs));
gBS->FreePages (StartAddress, EFI_SIZE_TO_PAGES (sizeof (*StartupCode)));
- return EFI_SUCCESS;
+ if (CurrentCPUs == 1) {
+return EFI_SUCCESS;
+ }
+
+ return Status;
}
diff --git a/UefiCpuPkg/CpuDxe/CpuMp.c b/UefiCpuPkg/CpuDxe/CpuMp.c
index 01805c3..e46de49 100644
--- a/UefiCpuPkg/CpuDxe/CpuMp.c
+++ b/UefiCpuPkg/CpuDxe/CpuMp.c
@@ -17,15 +17,41 @@
VOID *mCommonStack = 0;
VOID *mTopOfApCommonStack = 0;
+VOID *OldTopOfApCommonStack = 0;
+IA32_DESCRIPTOR gIdtr;
+
+extern UINT32 ProcessorIdx;
+extern UINT32 ProcessorIds[];
VOID
EFIAPI
-ApEntryPointInC (
+ApEntryPointInit (
VOID
)
{
- DEBUG ((EFI_D_INFO, "Hello from AP! (Apic ID %d)\n", GetApicId ()));
+ UINT32ProcessorId;
+ VOID *CommonStack;
+
+ // update ESP
+ CommonStack = AllocatePages (EFI_SIZE_TO_PAGES (SIZE_64KB));
+ if (CommonStack == NULL) {
+ mTopOfApCommonStack = 0;
+ return;
+ }
+
+ mTopOfApCommonStack = (VOID*) ((UINTN)CommonStack + SIZE_64KB);
+
+ // Update idtr
+ AsmWriteIdtr (&gIdtr);
+ // Enable Spurious intrrupt
+ EnableSpuriousInterrupt();
+
+ ProcessorId = GetApicId();
+
+ ProcessorIds[ProcessorIdx] = ProcessorId;
+
+ ProcessorIdx++;
}
@@ -39,8 +65,14 @@ InitializeMpSupport (
if (mCommonStack == NULL) {
return;
}
+ OldTopOfApCommonStack = mTopOfApCommonStack;
+
DEBUG ((EFI_D_INFO, "mTopOfApCommonStack: %p\n", mTopOfApCommonStack));
+ AsmReadIdtr (&gIdtr);
+
StartApsStackless (AsmApEntryPoint);
+
+ gBS->FreePages ((EFI_PHYSICAL_ADDRESS)mCommonStack,
EFI_SIZE_TO_PAGES(SIZE_64KB));
}
diff --git a/UefiCpuPkg/CpuDxe/X64/MpAsm.S b/UefiCpuPkg/CpuDxe/X64/MpAsm.S
index cfad551..c20d985 100644
--- a/UefiCpuPkg/CpuDxe/X64/MpAsm.S
+++ b/UefiCpuPkg/CpuDxe/X64/MpAsm.S
@@ -33,8 +33,10 @@ lock btsl $0, ApStackLock
pause
jc AsmApEntryPointAcquireLock
+movq(ASM_PFX(OldTopOfApCommonStack)), %rsp
+callASM_PFX(ApEntryPointInit)
+
movq(ASM_PFX(mTopOfApCommonStack)), %rsp
-callASM_PFX(ApEntryPointInC)
cli
@@ -46,7 +48,10 @@ AsmApEntryPointShareLock:
decl%eax
jnz AsmApEntryPointShareLock
-jmp ASM_PFX(AsmApEntryPoint)
+sti
+loop:
+hlt
+jmp loop
#--
# VOID
diff --git a/UefiCpuPkg/Include/Library/LocalApicLib.h
b/UefiCpuPkg/Include/Library/LocalApicLib.h
index 8960204..82ced0e 100644
--- a/UefiCpuPkg/Include/Library/LocalApicLib.h
+++ b/UefiCpuPkg/Include/Library/LocalApicLib.h
@@ -393,6 +393,12 @@ GetApicMsiValue (
IN BOOLEAN LevelTriggered,
IN BOOLEAN AssertionLevel
);
-
+
+VOID
+EFIAPI
+EnableSpuriousInterrupt(
+ VOID
+ );
+
#endif
diff --git a/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c
b/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c
index bd97fae..2e3613f 100644
--- a/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c
+++ b/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c
@@ -820,3 +820,17 @@ GetApicMsiValue (
}
return MsiData.Uint64;
}
+
+VOID
+EFIAPI
+EnableSpuriousInterrupt(
+ VOID
+ )
+{
+ LOCAL_APIC_SVR Svr;
+
+ Svr.Uint32 = ReadLocalApicReg (XAPIC_SPURIOUS_VECTOR_OFFSET);
+ Svr.Bits.SpuriousVector = 0xf;
+ Svr.Bits.SoftwareEnable = 1;
+ WriteLocalApicReg (XAPIC_SPURIOUS_VECTOR_OFFSET, Svr
