boot-architecture

boot-architecture@lists.linaro.org

1 participants
684 discussions

[PATCH v0 0/4] arm: [U]EFI runtime services support

by Leif Lindholm

In systems based on [U]EFI-conformant firmware, runtime services provide a standardised way for the kernel to update firmware environment variables. This is used for example by efibootmgr to update which image should be loaded on next boot. This patchset implements basic support for UEFI runtime services on ARM platforms, as well as the basic underlying EFI support. It also defines a mechanism by which the required information is passed from the bootloader to the kernel via FDT entries. This patchset depends on the previously submitted early_ioremap() patchset. Leif Lindholm (4): Documentation: arm: [U]EFI runtime services x86: efi: break efi_lookup_mapped_addr out to generic code arm: Add [U]EFI runtime services support init: efi: arm: enable (U)EFI runtime services on arm Documentation/arm/00-INDEX | 3 + Documentation/arm/uefi.txt | 39 ++++ arch/arm/Kconfig | 2 + arch/arm/include/asm/efi.h | 22 ++ arch/arm/kernel/Makefile | 2 + arch/arm/kernel/efi.c | 456 +++++++++++++++++++++++++++++++++++++ arch/arm/kernel/efi_phys.S | 59 +++++ arch/arm/kernel/setup.c | 5 + arch/x86/platform/efi/efi.c | 28 --- drivers/firmware/efi/Makefile | 2 +- drivers/firmware/efi/efi-helper.c | 33 +++ init/main.c | 6 + 12 files changed, 628 insertions(+), 29 deletions(-) create mode 100644 Documentation/arm/uefi.txt create mode 100644 arch/arm/include/asm/efi.h create mode 100644 arch/arm/kernel/efi.c create mode 100644 arch/arm/kernel/efi_phys.S create mode 100644 drivers/firmware/efi/efi-helper.c -- 1.7.10.4

12 years, 11 months

[PATCH v0 0/2] arm: add early_ioremap() support

by Leif Lindholm

x86 and ia64 have the early_ioremap()/early_iounmap() functions, which are useful for supporting things like UEFI, ACPI and SMBIOS, where configuration tables need to be parsed before proper memory management is available, regardless of highmem status. This patchset implements a restricted form of early_ioremap(), available before paging_init() only. Like the x86 code on which it is based, it (p)re-uses the fixmap regions for its virtual mapping range. Up to 7 simultaneous mappings of up to 128KB can be accommodated in the available fixmap space. Leif Lindholm (2): Documentation: arm: early_ioremap arm: add early_ioremap support Documentation/arm/00-INDEX | 2 + Documentation/arm/early_ioremap.txt | 12 ++ arch/arm/Kconfig | 20 +++ arch/arm/include/asm/fixmap.h | 31 +++- arch/arm/include/asm/io.h | 13 ++ arch/arm/kernel/setup.c | 3 + arch/arm/mm/Makefile | 1 + arch/arm/mm/early_ioremap.c | 273 +++++++++++++++++++++++++++++++++++ arch/arm/mm/mmu.c | 2 + 9 files changed, 355 insertions(+), 2 deletions(-) create mode 100644 Documentation/arm/early_ioremap.txt create mode 100644 arch/arm/mm/early_ioremap.c -- 1.7.10.4

12 years, 11 months

[PATCH] MdeModulePkg: fix compilation errors

by Ryan Harkin

From: Leif Lindholm <leif.lindholm(a)linaro.org> This patch fixes a minor error that prevents the native ARM compiler from building the code. Signed-off-by: Leif Lindholm <leif.lindholm(a)linaro.org Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> --- .../Universal/SetupBrowserDxe/Expression.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MdeModulePkg/Universal/SetupBrowserDxe/Expression.c b/MdeModulePkg/Universal/SetupBrowserDxe/Expression.c index cd29e29..29de503 100644 --- a/MdeModulePkg/Universal/SetupBrowserDxe/Expression.c +++ b/MdeModulePkg/Universal/SetupBrowserDxe/Expression.c @@ -1511,7 +1511,7 @@ IfrMid ( Result->BufferLen = (UINT16)((BufferLen - Base) < Length ? (BufferLen - Base) : Length); Result->Buffer = AllocateZeroPool (Result->BufferLen); ASSERT (Result->Buffer != NULL); - CopyMem (Result->Buffer, &Value[2].Buffer[Base], Result->BufferLen); + CopyMem (Result->Buffer, &Buffer[Base], Result->BufferLen); } FreePool (Value[2].Buffer); -- 1.7.9.5

12 years, 11 months

Re: [edk2] [PATCH 1/9] ArmPlatformPkg/ArmVExpressPkg: Add support for EDK2_OUT_DIR build parameter

by Tom Rini

On 06/21/2013 02:21 PM, Olivier Martin wrote: > > >> -----Original Message----- >> From: Andrew Fish [mailto:afish@apple.com] >> Sent: 21 June 2013 19:01 >> To: ryan.harkin(a)linaro.org >> Cc: Olivier Martin; boot-architecture(a)lists.linaro.org; edk2- >> devel(a)lists.sourceforge.net; patches(a)linaro.org >> Subject: Re: [edk2] [PATCH 1/9] ArmPlatformPkg/ArmVExpressPkg: Add >> support for EDK2_OUT_DIR build parameter >> >> >> >> On Jun 21, 2013, at 10:36 AM, Ryan Harkin <ryan.harkin(a)linaro.org> >> wrote: >> >>> On 21 June 2013 17:12, Andrew Fish <afish(a)apple.com> wrote: >>>> >>>> On Jun 21, 2013, at 4:23 AM, Ryan Harkin <ryan.harkin(a)linaro.org> >> wrote: >>>> >>>>> On 21 June 2013 11:15, Olivier Martin <olivier.martin(a)arm.com> >> wrote: >>>>>> I am not convinced by this patch. >>>>>> The use case you gave is the automated build system. Nothing >> prevent you to >>>>>> do a move the folder around after building it. >>>>> >>>>> That's not quite suitable for our CI builds, but I see your point. >>>>> >>>> >>>> If you build from a script you should be able to do anything you >> want? "You can solve every problem with another level of indirection, >> except for the problem of too many levels of indirection". >>>> >>>> So you could post process with a mv or preprocess the .dsc file, and >> restore it from a build script wrapper. >>>> >>> >>> Hacking the build system is not a solution to my problem. >>> >> >> I guess I'm not as opposed to this idea as a lot of platforms in the >> real world have pre and post build steps that are driven by a script or >> makefile. So if you already have a script or a makefile that you have >> to build from adding another step to it does not seem as bad. >> >> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EmulatorPkg/bu >> ild.sh >> >>> >>>>> >>>>>> Instead of changing all the DSC files of EDK2, I would prefer to >> see a patch >>>>>> that changes the 'build' command to allow to overwrite the Build >> directory >>>>>> defined in the DSC file. >>>>> >>>> >>>> The build command already has a lot of options. I'm not sure adding >> an option is the right thing to do? >>> >>> So if hacking the DSC file in no good, hacking the build system is no >>> good and hacking the build command is no good, is there a sane way to >>> get the EDKII build environment to support a configurable output >>> directory? >>> >> >> >> The build systems design assumes that there may need to be pre and post >> build phases that will done via a script or makefile. For example the >> FD may need to get signed and the the signing process would be a post >> processing step. >> >> Given what we have today I think the simplest thing to do is make Build >> directory a symbolic link to the location you really want the output to >> go to. This works assuming your build script has permissions to write >> to this directory. >> >> The more I think about it we need to change something on the edk2 side >> I think the best thing would be to add the argument to build like >> Olivier suggested. >> >> Thanks, >> >> Andrew Fish >> > > Another solution would be to introduce an environment variable (eg: > EDK_BUILD_PATH) set by edksetup.(sh|bat) with a default value equal to > $(WORKSPACE) that can be overwritten. I suspect this would work for everyones use cases. > But I am not sure to fully understand the motivation behind changing the > default build directory. If you cannot add pre/post action to your build > system then it should not take a long time to receive a new request to > change the UEFI firmware filename ;-) Allowing for user-specified output directories helps a lot of different use cases. My favourite is when debugging builds and bisecting a problem to throw each build into foo.rev so that I can if needed compare objects, etc, etc, without having to think about moving stuff around. -- Tom

12 years, 11 months

Re: [PATCH 1/9] ArmPlatformPkg/ArmVExpressPkg: Add support for EDK2_OUT_DIR build parameter

by Ryan Harkin

On 21 June 2013 11:15, Olivier Martin <olivier.martin(a)arm.com> wrote: > I am not convinced by this patch. > The use case you gave is the automated build system. Nothing prevent you to > do a move the folder around after building it. That's not quite suitable for our CI builds, but I see your point. > Instead of changing all the DSC files of EDK2, I would prefer to see a patch > that changes the 'build' command to allow to overwrite the Build directory > defined in the DSC file. That's a preferable option, although it would involve me hacking in python - shudder ;-) I'll look into the build script if I get some time. Meanwhile, this patch can live in my tree. > >> -----Original Message----- >> From: Ryan Harkin [mailto:ryan.harkin@linaro.org] >> Sent: 21 June 2013 09:05 >> To: ryan.harkin(a)linaro.org; edk2-devel(a)lists.sourceforge.net; >> patches(a)linaro.org; boot-architecture(a)lists.linaro.org; Olivier Martin >> Subject: [PATCH 1/9] ArmPlatformPkg/ArmVExpressPkg: Add support for >> EDK2_OUT_DIR build parameter >> >> Add support to the build config to allow the user to specify a custom >> output >> directory to the build. >> >> This is particularly useful for automated build systems. >> >> Eg. >> build -a ARM -p ArmPlatformPkg/ArmVExpressPkg/ArmVExpress- >> CTA9x4.dsc >> -t ARMLINUXGCC \ >> -D EDK2_ARMVE_STANDALONE=1 \ >> -D EDK2_OUT_DIR=Build/vea9 >> >> Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> >> --- >> .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc | 4 ++++ >> .../ArmVExpressPkg/ArmVExpress-CTA9x4.dsc | 4 ++-- >> .../ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc | 4 ++++ >> .../ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc | 4 ++++ >> .../ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc | 4 ++++ >> 5 files changed, 18 insertions(+), 2 deletions(-) >> >> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc >> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc >> index 17aba33..c8b637a 100644 >> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc >> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc >> @@ -21,7 +21,11 @@ >> PLATFORM_GUID = 0b511920-978d-4b34-acc0- >> 3d9f8e6f9d81 >> PLATFORM_VERSION = 0.1 >> DSC_SPECIFICATION = 0x00010005 >> +!ifdef $(EDK2_OUT_DIR) >> + OUTPUT_DIRECTORY = $(EDK2_OUT_DIR) >> +!else >> OUTPUT_DIRECTORY = Build/ArmVExpress-CTA15-A7 >> +!endif >> SUPPORTED_ARCHITECTURES = ARM >> BUILD_TARGETS = DEBUG|RELEASE >> SKUID_IDENTIFIER = DEFAULT >> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc >> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc >> index 3f9654f..b4040c2 100644 >> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc >> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc >> @@ -21,8 +21,8 @@ >> PLATFORM_GUID = eb2bd5ff-2379-4a06-9c12- >> db905cdee9ea >> PLATFORM_VERSION = 0.1 >> DSC_SPECIFICATION = 0x00010005 >> -!ifdef $(EDK2_ARMVE_STANDALONE) >> - OUTPUT_DIRECTORY = Build/ArmVExpress-CTA9x4-Standalone >> +!ifdef $(EDK2_OUT_DIR) >> + OUTPUT_DIRECTORY = $(EDK2_OUT_DIR) >> !else >> OUTPUT_DIRECTORY = Build/ArmVExpress-CTA9x4 >> !endif >> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc >> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc >> index 548eee5..16271b0 100644 >> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc >> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15.dsc >> @@ -21,7 +21,11 @@ >> PLATFORM_GUID = 1665b5b1-529d-4ba1-bd51- >> c3c9b29a2274 >> PLATFORM_VERSION = 0.1 >> DSC_SPECIFICATION = 0x00010005 >> +!ifdef $(EDK2_OUT_DIR) >> + OUTPUT_DIRECTORY = $(EDK2_OUT_DIR) >> +!else >> OUTPUT_DIRECTORY = Build/ArmVExpress-RTSM-A15 >> +!endif >> SUPPORTED_ARCHITECTURES = ARM >> BUILD_TARGETS = DEBUG|RELEASE >> SKUID_IDENTIFIER = DEFAULT >> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM- >> A15_MPCore.dsc b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM- >> A15_MPCore.dsc >> index 0001f8a..c0940ae 100644 >> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc >> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A15_MPCore.dsc >> @@ -21,7 +21,11 @@ >> PLATFORM_GUID = 3a91a0f8-3af4-409d-a71d- >> a199dc134357 >> PLATFORM_VERSION = 0.1 >> DSC_SPECIFICATION = 0x00010005 >> +!ifdef $(EDK2_OUT_DIR) >> + OUTPUT_DIRECTORY = $(EDK2_OUT_DIR) >> +!else >> OUTPUT_DIRECTORY = Build/ArmVExpress-RTSM-A15_MPCore >> +!endif >> SUPPORTED_ARCHITECTURES = ARM >> BUILD_TARGETS = DEBUG|RELEASE >> SKUID_IDENTIFIER = DEFAULT >> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc >> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc >> index 4315179..bdc2697 100644 >> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc >> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-RTSM-A9x4.dsc >> @@ -21,7 +21,11 @@ >> PLATFORM_GUID = e46039e0-5bb3-11e0-a9d6- >> 0002a5d5c51b >> PLATFORM_VERSION = 0.1 >> DSC_SPECIFICATION = 0x00010005 >> +!ifdef $(EDK2_OUT_DIR) >> + OUTPUT_DIRECTORY = $(EDK2_OUT_DIR) >> +!else >> OUTPUT_DIRECTORY = Build/ArmVExpress-RTSM-A9x4 >> +!endif >> SUPPORTED_ARCHITECTURES = ARM >> BUILD_TARGETS = DEBUG|RELEASE >> SKUID_IDENTIFIER = DEFAULT >> -- >> 1.7.9.5 >> > > > > > > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/boot-architecture

12 years, 11 months

ARM specific patches from Linaro

by Ryan Harkin

Linaro have been carrying a few small patches in our tree for some months now; they have proven valuable and stable, so we'd like to push them upstream. The first few patches configure the platforms with some simple default values and some extra build options. [PATCH 1/9] ArmPlatformPkg/ArmVExpressPkg: Add support for EDK2_OUT_DIR build parameter [PATCH 2/9] ArmPlatformPkg/ArmVExpressPkg: CTA15-A7: Allow EDK2_SKIP_PEICORE to be specified at build time [PATCH 3/9] ArmPlatformPkg/ArmVExpressPkg: CTA9x4: default to EDK2_ARMVE_STANDALONE=1 There is a patch to fix shutdown on Versatile Express platforms: [PATCH 4/9] ArmPlatformPkg/ArmVExpressPkg: add Shutdown support There is a small fix for a case sensitivity problem in the ARM BDS: [PATCH 5/9] ArmPlatformPkg/Bds: Make ".EFI" files recognizable as Then there are some small improvements to the menu options in ARM BDS: [PATCH 6/9] ArmPlatformPkg/Bds: use letters for hard coded boot menu [PATCH 7/9] ArmPlatformPkg/Bds: Add Reboot and Shutdown options to main menu [PATCH 8/9] ArmPlatformPkg/Bds: show global FDT config in main menu Finally, there is a larger patch to allow each boot configuration to specify it's own Flattened Device Tree binary. This is important in our automated build systems, because as the DTB evolves, our "master" image may end up with a different DTB than the image under test. [PATCH 9/9] ArmPlatformPkg/Bds: add local FDT config Regards, Ryan. In-Reply-To:

12 years, 11 months

Re: [PATCH 3/9] ArmPlatformPkg/ArmVExpressPkg: CTA9x4: default to EDK2_ARMVE_STANDALONE=1

by Ryan Harkin

On 21 June 2013 12:11, Olivier Martin <olivier.martin(a)arm.com> wrote: > In your patch, I fixed (Revision 14439): > - the !ifndef syntax to use '!ifndef EDK2_ARMVE_STANDALONE' Thanks! > - Moved the previous condition that uses EDK2_ARMVE_STANDALONE after your > definition Surely if you want to change the OUTPUT_DIRECTORY, you should update the build script to allow you to over-ride the value in the DSC file ;-) (I'll hide now :-)) > > > > >> -----Original Message----- >> From: Ryan Harkin [mailto:ryan.harkin@linaro.org] >> Sent: 21 June 2013 09:05 >> To: ryan.harkin(a)linaro.org; edk2-devel(a)lists.sourceforge.net; >> patches(a)linaro.org; boot-architecture(a)lists.linaro.org; Olivier Martin >> Subject: [PATCH 3/9] ArmPlatformPkg/ArmVExpressPkg: CTA9x4: default to >> EDK2_ARMVE_STANDALONE=1 >> >> This patch changes the Versatile Express A9 BSP to build with >> EDK2_ARMVE_STANDALONE=1 as the default option. >> >> The user may then specify zero if they wish to build the non-standalone >> version. >> >> Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> >> --- >> .../ArmVExpressPkg/ArmVExpress-CTA9x4.dsc | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc >> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc >> index b4040c2..e805b57 100644 >> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc >> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc >> @@ -30,6 +30,9 @@ >> BUILD_TARGETS = DEBUG|RELEASE >> SKUID_IDENTIFIER = DEFAULT >> FLASH_DEFINITION = >> ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.fdf >> +!ifndef $(EDK2_ARMVE_STANDALONE) >> + DEFINE EDK2_ARMVE_STANDALONE=1 >> +!endif >> >> !include ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc >> >> -- >> 1.7.9.5 >> > > > > > > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/boot-architecture

12 years, 11 months

Re: [PATCH 5/9] ArmPlatformPkg/Bds: Make ".EFI" files recognizable as EFI applications.

by Ryan Harkin

On 21 June 2013 11:02, Olivier Martin <olivier.martin(a)arm.com> wrote: > I committed this change after fixing the coding style (revision 14437). Yes, your revised version is more appropriate. Thanks. > >> -----Original Message----- >> From: Ryan Harkin [mailto:ryan.harkin@linaro.org] >> Sent: 21 June 2013 09:05 >> To: ryan.harkin(a)linaro.org; edk2-devel(a)lists.sourceforge.net; >> patches(a)linaro.org; boot-architecture(a)lists.linaro.org; Olivier Martin >> Subject: [PATCH 5/9] ArmPlatformPkg/Bds: Make ".EFI" files recognizable >> as EFI applications. >> >> From: Leif Lindholm <leif.lindholm(a)linaro.org> >> >> Currently, only ".efi" files are recognized as valid ARM UEFI >> applications by BDS. This patch also makes ".EFI" files recognised. >> >> Signed-off-by: Leif Lindholm <leif.lindholm(a)linaro.org> >> --- >> ArmPlatformPkg/Bds/BdsHelper.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/ArmPlatformPkg/Bds/BdsHelper.c >> b/ArmPlatformPkg/Bds/BdsHelper.c >> index fa3026c..d1889f4 100644 >> --- a/ArmPlatformPkg/Bds/BdsHelper.c >> +++ b/ArmPlatformPkg/Bds/BdsHelper.c >> @@ -205,6 +205,9 @@ HasFilePathEfiExtension ( >> IN CHAR16* FilePath >> ) >> { >> + if (StrCmp (FilePath + (StrSize(FilePath)/sizeof(CHAR16)) - 5, >> L".EFI") == 0) >> + return 1; >> + >> return (StrCmp (FilePath + (StrSize(FilePath)/sizeof(CHAR16)) - 5, >> L".efi") == 0); >> } >> >> -- >> 1.7.9.5 >> > > > > > > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/boot-architecture

12 years, 11 months

Re: [PATCH 2/9] ArmPlatformPkg/ArmVExpressPkg: CTA15-A7: Allow EDK2_SKIP_PEICORE to be specified at build time

by Ryan Harkin

On 21 June 2013 10:51, Olivier Martin <olivier.martin(a)arm.com> wrote: > If you want to use PEI Core (EDK2_SKIP_PEICORE=0) in CTA15-A7, you would > need to add support ... Which is not the case today! > Have a look at the macro EDK2_SKIP_PEICORE usage in RTSM-A9x4 DSC and FDF > file. Oh, I don't want to add support ;-) but I was using this patch a long time ago when I was attempting to do such crazy things due to various bugs we found interacting with Boot Monitor, etc... So I ended up keeping this patch, even though it is never used. But as you say, the skip support isn't there, so perhaps I should just drop this one? > >> -----Original Message----- >> From: Ryan Harkin [mailto:ryan.harkin@linaro.org] >> Sent: 21 June 2013 09:05 >> To: ryan.harkin(a)linaro.org; edk2-devel(a)lists.sourceforge.net; >> patches(a)linaro.org; boot-architecture(a)lists.linaro.org; Olivier Martin >> Subject: [PATCH 2/9] ArmPlatformPkg/ArmVExpressPkg: CTA15-A7: Allow >> EDK2_SKIP_PEICORE to be specified at build time >> >> The original BSP for TC2 hard codes EDK2_SKIP_PEICORE=1, but this >> change >> allows the user to over-ride the value at build time. >> >> Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> >> --- >> .../ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc >> b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc >> index c8b637a..58e1689 100644 >> --- a/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc >> +++ b/ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.dsc >> @@ -30,7 +30,9 @@ >> BUILD_TARGETS = DEBUG|RELEASE >> SKUID_IDENTIFIER = DEFAULT >> FLASH_DEFINITION = >> ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA15-A7.fdf >> +!ifndef $(EDK2_SKIP_PEICORE) >> DEFINE EDK2_SKIP_PEICORE=1 >> +!endif >> >> !include ArmPlatformPkg/ArmVExpressPkg/ArmVExpress.dsc.inc >> >> -- >> 1.7.9.5 >> > > > > > > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/boot-architecture

12 years, 11 months

Re: [PATCH 1/1] BaseTools: Apply ARM GenFv patch

by Ryan Harkin

On 21 June 2013 10:13, Olivier Martin <olivier.martin(a)arm.com> wrote: > I also offered a patch to the BaseTools project to fix the firmware when > linked at 0x0 in the past. > But my patch has been rejected and a new keyword has been introduced to fix > this BaseTools limitation. > > In your Versatile Express A5 FDF file you have to replace: > > [FV.FVMAIN_SEC] > FvAlignment = 8 > > By: > [FV.FVMAIN_SEC] > FvBaseAddress = 0x0 > FvForceRebase = TRUE > FvAlignment = 8 > > Thanks Olivier, I'll try it and rework my branches! I wasn't aware of this and I've been carrying this patch, thinking I still needed it. >> -----Original Message----- >> From: boot-architecture-bounces(a)lists.linaro.org [mailto:boot- >> architecture-bounces(a)lists.linaro.org] On Behalf Of Ryan Harkin >> Sent: 21 June 2013 08:44 >> To: ryan.harkin(a)linaro.org; edk2-devel(a)lists.sourceforge.net; edk2- >> buildtools-devel(a)lists.sourceforge.net; patches(a)linaro.org; boot- >> architecture(a)lists.linaro.org >> Subject: [PATCH 1/1] BaseTools: Apply ARM GenFv patch >> >> This patch is needed to fixup some builds, such as Versatile Express >> A5, >> otherwise they hang on boot due to the first instruction being zero. >> >> Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> >> --- >> BaseTools/Source/C/GenFv/GenFv.c | 7 +--- >> BaseTools/Source/C/GenFv/GenFvInternalLib.c | 48 +++++++++++-------- >> -------- >> 2 files changed, 21 insertions(+), 34 deletions(-) >> >> diff --git a/BaseTools/Source/C/GenFv/GenFv.c >> b/BaseTools/Source/C/GenFv/GenFv.c >> index fa86d00..a68c7b8 100644 >> --- a/BaseTools/Source/C/GenFv/GenFv.c >> +++ b/BaseTools/Source/C/GenFv/GenFv.c >> @@ -623,12 +623,7 @@ Returns: >> ); >> } else { >> VerboseMsg ("Create Fv image and its map file"); >> - // >> - // Will take rebase action at below situation: >> - // 1. ForceRebase Flag specified to TRUE; >> - // 2. ForceRebase Flag not specified, BaseAddress greater than >> zero. >> - // >> - if (((mFvDataInfo.BaseAddress > 0) && (mFvDataInfo.ForceRebase == >> -1)) || (mFvDataInfo.ForceRebase == 1)) { >> + if (mFvDataInfo.BaseAddressSet) { >> VerboseMsg ("FvImage Rebase Address is 0x%llX", (unsigned long >> long) mFvDataInfo.BaseAddress); >> } >> // >> diff --git a/BaseTools/Source/C/GenFv/GenFvInternalLib.c >> b/BaseTools/Source/C/GenFv/GenFvInternalLib.c >> index c01e504..d143040 100644 >> --- a/BaseTools/Source/C/GenFv/GenFvInternalLib.c >> +++ b/BaseTools/Source/C/GenFv/GenFvInternalLib.c >> @@ -506,6 +506,7 @@ Returns: >> >> EFI_STATUS >> AddPadFile ( >> + IN FV_INFO *FvInfo, >> IN OUT MEMORY_FILE *FvImage, >> IN UINT32 DataAlignment, >> IN VOID *FvEnd, >> @@ -537,6 +538,8 @@ Returns: >> { >> EFI_FFS_FILE_HEADER *PadFile; >> UINTN PadFileSize; >> + UINTN PadFileOffset; >> + UINTN ExtHeaderSize; >> >> // >> // Verify input parameters. >> @@ -559,32 +562,29 @@ Returns: >> // This is the earliest possible valid offset (current plus pad file >> header >> // plus the next file header) >> // >> - PadFileSize = (UINTN) FvImage->CurrentFilePointer - (UINTN) FvImage- >> >FileImage + (sizeof (EFI_FFS_FILE_HEADER) * 2); >> + // The padding is added into its own FFS file (which requires a >> header) added before the aligned file: >> + // | ... FV data before AlignedFile ... | Pad File FFS Header | >> Padding | AlignedFile FFS Header (+ ExtHeader) | AlignedData >> >> // >> - // Add whatever it takes to get to the next aligned address >> + // Calculate the Offset of the Pad File from the beginning of the FV >> file >> // >> - while ((PadFileSize % DataAlignment) != 0) { >> - PadFileSize++; >> - } >> - // >> - // Subtract the next file header size >> - // >> - PadFileSize -= sizeof (EFI_FFS_FILE_HEADER); >> - >> - // >> - // Subtract the starting offset to get size >> - // >> - PadFileSize -= (UINTN) FvImage->CurrentFilePointer - (UINTN) >> FvImage->FileImage; >> + PadFileOffset = (UINTN) FvImage->CurrentFilePointer - (UINTN) >> FvImage->FileImage; >> >> // >> - // Append extension header size >> + // Get the size of the extension header if exists >> // >> if (ExtHeader != NULL) { >> - PadFileSize = PadFileSize + ExtHeader->ExtHeaderSize; >> + ExtHeaderSize = ExtHeader->ExtHeaderSize; >> + } else { >> + ExtHeaderSize = 0; >> } >> >> // >> + // Calculate the Size of the Padding to ensure the alignment of the >> data of the Next file >> + // >> + PadFileSize = DataAlignment - ((FvInfo->BaseAddress + PadFileOffset >> + sizeof (EFI_FFS_FILE_HEADER) + ExtHeaderSize) & (DataAlignment - 1)); >> + >> + // >> // Verify that we have enough space for the file header >> // >> if (((UINTN) FvImage->CurrentFilePointer + PadFileSize) > (UINTN) >> FvEnd) { >> @@ -1115,7 +1115,7 @@ Returns: >> // >> // Add pad file if necessary >> // >> - Status = AddPadFile (FvImage, 1 << CurrentFileAlignment, >> *VtfFileImage, NULL); >> + Status = AddPadFile (FvInfo, FvImage, 1 << CurrentFileAlignment, >> *VtfFileImage, NULL); >> if (EFI_ERROR (Status)) { >> Error (NULL, 0, 4002, "Resource", "FV space is full, could not add >> pad file for data alignment property."); >> free (FileBuffer); >> @@ -2304,7 +2304,7 @@ Returns: >> // >> // Add FV Extended Header contents to the FV as a PAD file >> // >> - AddPadFile (&FvImageMemoryFile, 4, VtfFileImage, FvExtHeader); >> + AddPadFile (&mFvDataInfo, &FvImageMemoryFile, 4, VtfFileImage, >> FvExtHeader); >> >> // >> // Fv Extension header change update Fv Header Check sum >> @@ -2825,19 +2825,11 @@ Returns: >> PeFileBuffer = NULL; >> >> // >> - // Don't need to relocate image when BaseAddress is zero and no >> ForceRebase Flag specified. >> + // Don't need to relocate image when BaseAddress is not set. >> // >> - if ((FvInfo->BaseAddress == 0) && (FvInfo->ForceRebase == -1)) { >> + if (FvInfo->BaseAddressSet == FALSE) { >> return EFI_SUCCESS; >> } >> - >> - // >> - // If ForceRebase Flag specified to FALSE, will always not take >> rebase action. >> - // >> - if (FvInfo->ForceRebase == 0) { >> - return EFI_SUCCESS; >> - } >> - >> >> XipBase = FvInfo->BaseAddress + XipOffset; >> >> -- >> 1.7.9.5 >> >> >> _______________________________________________ >> boot-architecture mailing list >> boot-architecture(a)lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/boot-architecture > > > > > > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/boot-architecture

12 years, 11 months

← Newer
1
...
53
54
55
56
57
58
59
...
69
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture