- boot-architecture - lists.linaro.org

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, 2 months

2
1
0 0

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, 2 months

1
0
0 0

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

by Ryan Harkin

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

12 years, 2 months

2
1
0 0

[RFC] first view: armv7 Linux UEFI runtime services

by Leif Lindholm

Hi all, Following on the previous patch, here is the armv7 UEFI runtime services support, documented on https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/RuntimeServices (Do note - GRUB boot is currently the only way to actually get the UEFI system table into the kernel.) The patches were based off linux-linaro-tracking, and when I tried building for upstream 3.10-rc6 it failed due to a couple of header file changes. I will address that during cleanup before upstream submission later this week. Oh, and there is an accidental remaining edit of an x86 ifdef in init/main.c. That will be fixed tomorrow. Again, early reviewing would be appreciated. / Leif

12 years, 3 months

1
0
0 0

[RFC] first view: armv7 Linux early_ioremap

by Leif Lindholm

Hi all, This is my first, monolithic, stab at an early_ioremap for ARMv7 - taken straight from the head of http://git.linaro.org/gitweb?p=people/leiflindholm/linux-uefi-runtime-servi… I'll be cleaning up, splitting up, documenting and see if I can get it working on non-LPAE in time, and then send it upstream later this week. Early reviewing would be much appreciated. / Leif

12 years, 3 months

1
0
0 0

Re: Possible race condition in multi-core EDK2

by Roy Franz

Hi Oliver, Sorry for the missing information. I am using version 7.1.63 of the A15 fast model. I'm using the ArmVExpress-RTSM-A15_MPCore.dsc dsc file,and building against the linaro-tracking-2013.05 branch of the uefi-next repository. I have been making some changes, mostly debug related. I had made the following changes to the DSC file: gArmPlatformTokenSpaceGuid.PcdCoreCount|1 gArmPlatformTokenSpaceGuid.PcdSendSgiToBringUpSecondaryCores|FALSE This was running fine on a single core until I started removing some debug prints. Roy On 12 June 2013 02:10, Olivier Martin <olivier.martin(a)arm.com> wrote: > Hello Roy,**** > > ** ** > > Which platform are you referring to? Which EDK2 DSC file are you using for > your UEFI firmware?**** > > ** ** > > Thanks,**** > > Olivier**** > > ** ** > > *From:* boot-architecture-bounces(a)lists.linaro.org [mailto: > boot-architecture-bounces(a)lists.linaro.org] *On Behalf Of *Roy Franz > *Sent:* 12 June 2013 03:03 > *To:* boot-architecture(a)lists.linaro.org > *Subject:* Possible race condition in multi-core EDK2**** > > ** ** > > ** ** > > I've been working with the DEBUG build of EDK2, and thought I had changed > the configuration to be 'proper' for a single core, and it ran fine on a > single core simulation. As I started removing debug prints, I started > getting simulator seg faults. I confirmed that the difference between > running and crashing versions were simply debug prints.**** > > Changing the simulation to simulator 2 cores resolved the problem. I > suspect that there may be a race condition or some other multi-core > detection bug that causes this crash.**** > > ** ** > > I don't plan to investigate this further at this point - just wanted to > report this as I was surprised to find that a debug print being removed > would cause the simulator to crash.**** > > ** ** > > Roy**** > > ** ** > > ** ** > > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/boot-architecture > >

12 years, 3 months

2
3
0 0

Re: [PATCH 2/2] ArmPkg/PL390Gic: remove ArmPlatformLib from inf file

by Ryan Harkin

On 12 June 2013 13:07, Olivier Martin <olivier.martin(a)arm.com> wrote: > Here is a copy of what I sent to Ryan earlier: > > > Unfortunately, I cannot remove the ArmPlatformLib from PL390Gic INF file > even if it build in most cases. > The reason is PL390GicSec now uses ArmPlatformIsPrimaryCore() that is > implemented by ArmPlatformLib library. > If one day one module uses PL390GicSec but does not depend itself on > ArmPlatformLib then there is no reason why the engineer should add > ArmPlatformLib to the INF file of this new module to solve PL390GicSec > dependency. > > A reason why it could fail would be you are using a different ArmPlatformLib > implementation than the one you are thinking. > A way to check that is to generate the build report: > build -A ARM -p ... -t ... -y report.log > And check which libraries are used by each module. > > Actually, I am planning to rename 'PL390GicDxe' into 'ArmGicDxe' that will > follow the 'ARM Generic Interrupt Controller Architecture Specification'. > > Cheers, > Olivier > Thanks Olivier! I didn't see this before I replied to your email! This patch will be dropped. We need to find a proper solution for Arndale. I *guess* it should just involve reworking the platform DSC/FDF/etc. files in [PATCH 1/2] to include the right things? > > >> -----Original Message----- >> From: boot-architecture-bounces(a)lists.linaro.org [mailto:boot- >> architecture-bounces(a)lists.linaro.org] On Behalf Of Ryan Harkin >> Sent: 12 June 2013 12:03 >> To: ryan.harkin(a)linaro.org; boot-architecture(a)lists.linaro.org >> Subject: [PATCH 2/2] ArmPkg/PL390Gic: remove ArmPlatformLib from inf >> file >> >> The PL390 GIC driver was including ArmPlatform in PL390GicSecLib.inf. >> >> This change is fine as it, however, when the Arndale platfom is fixed >> to >> remove its duplicated PL390 GIC driver, it hangs unless this library is >> removed. >> >> Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> >> --- >> ArmPkg/Drivers/PL390Gic/PL390GicSecLib.inf | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/ArmPkg/Drivers/PL390Gic/PL390GicSecLib.inf >> b/ArmPkg/Drivers/PL390Gic/PL390GicSecLib.inf >> index 205e503..5851bfe 100644 >> --- a/ArmPkg/Drivers/PL390Gic/PL390GicSecLib.inf >> +++ b/ArmPkg/Drivers/PL390Gic/PL390GicSecLib.inf >> @@ -31,7 +31,6 @@ >> >> [LibraryClasses] >> ArmLib >> - ArmPlatformLib >> DebugLib >> IoLib >> PcdLib >> -- >> 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, 3 months

1
0
0 0

[PATCH 0/1] Removing GIC driver from Arndale BSP

by Ryan Harkin

These two patches will remove the GIC driver from the Arndale BSP, instead using the official GIC driver from the upstream tree: [PATCH 1/2] Samsung/Arndale: remove GIC400 driver [PATCH 2/2] ArmPkg/PL390Gic: remove ArmPlatformLib from inf file I've already sent the second patch to Olivier for review, but as far as I can see, ArmPlatformLib is incuded in the PL390 sec lib, but it isn't needed. Including it when booting on Arndale hangs the board. I'm guessing there are two issues: 1) if it isn't needed, we can remove it 2) but it shouldn't crash Arndale if it is included, so Arndale is most likely doing something wrong and we should probably work out what that is. However, the general act of replacing Arndale's clone of the GIC driver seems safe. Arndale appears to have simply cloned an old version of the driver without modification. However, a couple of the bit masks may be different, so perhaps there is an underlying problem that I have not discovered? Hence, a review by a few other people is really important. Regards, Ryan. In-Reply-To:

12 years, 3 months

2
3
0 0

Possible race condition in multi-core EDK2

by Roy Franz

I've been working with the DEBUG build of EDK2, and thought I had changed the configuration to be 'proper' for a single core, and it ran fine on a single core simulation. As I started removing debug prints, I started getting simulator seg faults. I confirmed that the difference between running and crashing versions were simply debug prints. Changing the simulation to simulator 2 cores resolved the problem. I suspect that there may be a race condition or some other multi-core detection bug that causes this crash. I don't plan to investigate this further at this point - just wanted to report this as I was surprised to find that a debug print being removed would cause the simulator to crash. Roy

12 years, 3 months

2
1
0 0

uefi-build.sh - bash completion

by Ryan Harkin

Hey all, After my chat with Leif chat on Thurs, one thing I thought about was bash completion for uefi-build.sh. Turns out it's quite easy! I just pushed this commit to uefi-tools.git [1]. It's quite dumb in that you can autocomplete "DEBUG" or "RELEASE" even without the "-b" parameter, but hey, it makes my life easier :-) Cheers, Ryan. commit dc3ba99d46ecb87c529a475d5ff6b840cd2f7c8d Author: Ryan Harkin <ryan.harkin(a)linaro.org> Date: Tue Jun 11 13:00:12 2013 +0100 uefi-build: add bash completion script Copy this script into the bash completion directory to easy entering parameters: $ sudo cp uefi-build.sh.bash_completion \ /etc/bash_completion.d/uefi-build.sh Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> diff --git a/uefi-build.sh.bash_completion b/uefi-build.sh.bash_completion new file mode 100644 index 0000000..f0a5305 --- /dev/null +++ b/uefi-build.sh.bash_completion @@ -0,0 +1,24 @@ +# bash completion for uefi-build.sh +# copy this file to /etc/bash_completion.d/uefi-build.s + +have uefi-build.sh && +_uefi-build.sh() +{ + local cur prev + + COMPREPLY=() + _get_comp_words_by_ref -n = cur + + _expand || return 0 + + COMPREPLY=( $( compgen -W '--help -b --build RELEASE DEBUG a5 a9 tc1 tc2 panda origen arndale rtsm_a9x4 rtsm_a15x1 rtsm_a15mpcore rtsm_aarch6 +} && +complete -F _uefi-build.sh uefi-build.sh + +# Local variables: +# mode: shell-script +# sh-basic-offset: 4 +# sh-indent-comment: t +# indent-tabs-mode: nil +# End: +# ex: ts=4 sw=4 et filetype=sh [1] http://git.linaro.org/gitweb?p=arm/uefi/uefi-tools.git;a=summary

12 years, 3 months

1
0
0 0

[PATCH] This patch fixes the build breakage issue for Arndale BSP due to the patch "ArmPlatformPkg/ArmPlatformLib: Added support for ArmPlatformIsPrimaryCore()"

by Rony Nandy

--- .../ArndaleBoardLib/Exynos5250/BoardHelper.S | 25 ++++++++++++++++++++ .../ArndaleBoardPkg/arndale-Exynos5250.dsc | 16 ------------- .../ArndaleBoardPkg/arndale-Exynos5250.fdf | 15 ------------ .../Exynos5250/Drivers/Gic400Dxe/PL390GicSec.c | 3 ++- .../Drivers/Gic400Dxe/PL390GicSecLib.inf | 5 ++-- SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec.c | 5 ++-- .../ExynosPkg/Exynos5250/Sec/Sec.inf | 3 --- .../ExynosPkg/Exynos5250/Sec/SecEntryPoint.S | 25 +++++++++++++------- 8 files changed, 49 insertions(+), 48 deletions(-) diff --git a/SamsungPlatformPkg/ArndaleBoardPkg/Library/ArndaleBoardLib/Exynos5250/BoardHelper.S b/SamsungPlatformPkg/ArndaleBoardPkg/Library/ArndaleBoardLib/Exynos5250/BoardHelper.S index 1975e65..7ee7821 100644 --- a/SamsungPlatformPkg/ArndaleBoardPkg/Library/ArndaleBoardLib/Exynos5250/BoardHelper.S +++ b/SamsungPlatformPkg/ArndaleBoardPkg/Library/ArndaleBoardLib/Exynos5250/BoardHelper.S @@ -14,6 +14,7 @@ #include <AsmMacroIoLib.h> #include <Base.h> #include <Library/PcdLib.h> +#include <Library/ArmLib.h> #include <AutoGen.h> #.include AsmMacroIoLib.inc @@ -23,6 +24,9 @@ .align 2 GCC_ASM_EXPORT(ArmGetCpuCountPerCluster) +GCC_ASM_EXPORT(ArmPlatformGetCorePosition) +GCC_ASM_EXPORT(ArmPlatformIsPrimaryCore) +GCC_ASM_EXPORT(ArmPlatformPeiBootAction) # IN None # OUT r0 = SCU Base Address @@ -68,4 +72,25 @@ _Return: ldmfd SP!, {r1-r2} bx lr +ASM_PFX(ArmPlatformIsPrimaryCore): + #last 2 bit of mpid register in 5250 is CPU ID + ldr r1, =0x3 + and r0, r0, r1 + #id for core0 should be 0 + ldr r1, =0x0 + cmp r0, r1 + moveq r0, #1 + movne r0, #0 + mov pc, lr + +ASM_PFX(ArmPlatformGetCorePosition): + and r1, r0, #0x03 //cpu core mask last 2 bits + and r0, r0, #(0x0f<<8) //cpu cluster mask bit 8-11 + add r0, r1, r0, LSR #7 + mov pc, lr + + +ASM_PFX(ArmPlatformPeiBootAction): + mov pc, lr + ASM_FUNCTION_REMOVE_IF_UNREFERENCED diff --git a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc index 941c6e5..ade2997 100755 --- a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc +++ b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc @@ -56,7 +56,6 @@ [BuildOptions] RVCT:*_*_ARM_PLATFORM_FLAGS == --cpu Cortex-A8 --fpu=softvfp -I$(WORKSPACE)/SamsungPlatformPkg/ExynosPkg/Exynos5250/Include/Platform - #GCC:*_*_ARM_PLATFORM_FLAGS == -mcpu=cortex-a8 -I$(WORKSPACE)/SamsungPlatformPkg/ExynosPkg/Exynos5250/Include/Platform GCC:*_*_ARM_PLATFORM_FLAGS == -march=armv7-a -I$(WORKSPACE)/SamsungPlatformPkg/ExynosPkg/Exynos5250/Include/Platform XCODE:*_*_ARM_PLATFORM_FLAGS == -arch armv7 -I$(WORKSPACE)/SamsungPlatformPkg/ExynosPkg/Exynos5250/Include/Platform @@ -242,7 +241,6 @@ SamsungPlatformPkg/ExynosPkg/Exynos5250/MemoryInitPei/MemoryInitPeim.inf ArmPkg/Drivers/CpuPei/CpuPei.inf IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei.inf - #Nt32Pkg/BootModePei/BootModePei.inf MdeModulePkg/Universal/Variable/Pei/VariablePei.inf MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf { <LibraryClasses> @@ -268,22 +266,17 @@ MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf - #MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf - #MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf - #MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf - #EmbeddedPkg/SerialDxe/SerialDxe.inf MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf - #MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf SamsungPlatformPkg/ArndaleBoardPkg/FvbDxe/FvbDxe.inf SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/TimerDxe/TimerDxe.inf @@ -318,9 +311,6 @@ # # Application # - #SamsungPlatformPkg/Apps/TestApps/HashServicesTest/HashServicesTest.inf - #SamsungPlatformPkg/Apps/TestApps/RngServicesTest/RngServicesTest.inf - # # Bds # @@ -346,9 +336,7 @@ # usb host : ehci + bus + pci_emul + mass_storage # SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/PciEmulation/PciEmulation.inf - #SamsungPlatformPkg/ExynosPkg/Exynos5250/OhciDxe/OhciDxe.inf MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf - #MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf @@ -363,8 +351,6 @@ <LibraryClasses> LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf } - MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.inf - #MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf SamsungPlatformPkg/Apps/Tools/fwupdate/fwupdate_5250.inf @@ -372,9 +358,7 @@ # # Crypto for Exynos # - #SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/HashDxe/HashDxe.inf # # Rng for Exynos # - #SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/RngDxe/RngDxe.inf diff --git a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.fdf b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.fdf index 8b5a5a7..9bccd79 100755 --- a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.fdf +++ b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.fdf @@ -120,7 +120,6 @@ READ_STATUS = TRUE READ_LOCK_CAP = TRUE READ_LOCK_STATUS = TRUE - #INF ArmPlatformPkg/Sec/Sec.inf INF SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec.inf @@ -155,8 +154,6 @@ READ_LOCK_STATUS = TRUE INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf INF MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntimeDxe.inf - #INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf - #INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf INF EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf @@ -166,14 +163,10 @@ READ_LOCK_STATUS = TRUE # Multiple Console IO support # INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf - #INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf INF EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf - #INF EmbeddedPkg/SerialDxe/SerialDxe.inf - INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf - #INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf !ifdef $(EXYNOS5250_EVT1) INF SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/Gic400Dxe/PL390GicDxe.inf @@ -207,9 +200,7 @@ READ_LOCK_STATUS = TRUE # USB HOST STACK # INF SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/PciEmulation/PciEmulation.inf - #INF SamsungPlatformPkg/ExynosPkg/Exynos5250/OhciDxe/OhciDxe.inf INF MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf - #INF MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf INF MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf @@ -223,20 +214,14 @@ READ_LOCK_STATUS = TRUE INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf INF MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf INF MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTablePei/FirmwarePerformancePei.inf - INF MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.inf - #INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf # Crypto for Exynos # - #INF SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/HashDxe/HashDxe.inf - #INF SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/RngDxe/RngDxe.inf # # UEFI application (Shell Embedded Boot Loader) # INF ShellBinPkg/UefiShell/UefiShell.inf - #INF SamsungPlatformPkg/Apps/TestApps/HashServicesTest/HashServicesTest.inf - #INF SamsungPlatformPkg/Apps/TestApps/RngServicesTest/RngServicesTest.inf # # Bds diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/Gic400Dxe/PL390GicSec.c b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/Gic400Dxe/PL390GicSec.c index f7b6d7c..82ecfde 100644 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/Gic400Dxe/PL390GicSec.c +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/Gic400Dxe/PL390GicSec.c @@ -15,6 +15,7 @@ #include <Base.h> #include <Library/ArmLib.h> #include <Library/DebugLib.h> +#include <Library/ArmPlatformLib.h> #include <Library/IoLib.h> #include <Library/ArmGicLib.h> @@ -50,7 +51,7 @@ ArmGicSetupNonSecure ( } // Only the primary core should set the Non Secure bit to the SPIs (Shared Peripheral Interrupt). - if (IS_PRIMARY_CORE(MpId)) { + if (ArmPlatformIsPrimaryCore (MpId)) { // Ensure all GIC interrupts are Non-Secure for (Index = 0; Index < (ArmGicGetMaxNumInterrupts (GicDistributorBase) / 32); Index++) { MmioWrite32 (GicDistributorBase + ARM_GIC_ICDISR + (Index * 4), 0xffffffff); diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/Gic400Dxe/PL390GicSecLib.inf b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/Gic400Dxe/PL390GicSecLib.inf index 9e1fd09..ab399b4 100644 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/Gic400Dxe/PL390GicSecLib.inf +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Drivers/Gic400Dxe/PL390GicSecLib.inf @@ -25,7 +25,9 @@ [Packages] ArmPkg/ArmPkg.dec + ArmPlatformPkg/ArmPlatformPkg.dec MdePkg/MdePkg.dec + MdeModulePkg/MdeModulePkg.dec [LibraryClasses] ArmLib @@ -33,6 +35,3 @@ IoLib PcdLib -[FixedPcd.common] - gArmTokenSpaceGuid.PcdArmPrimaryCoreMask - gArmTokenSpaceGuid.PcdArmPrimaryCore diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec.c b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec.c index 549171b..3c4f498 100644 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec.c +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec.c @@ -21,6 +21,7 @@ #include <Library/ArmGicLib.h> #include <Library/ArmCpuLib.h> #include <Library/IoLib.h> +#include <Library/ArmPlatformLib.h> #include "SecInternal.h" #include "Smc.h" @@ -94,7 +95,7 @@ CEntryPoint ( } // Primary CPU clears out the SCU tag RAMs, secondaries wait - if (IS_PRIMARY_CORE(MpId)) { + if (ArmPlatformIsPrimaryCore (MpId)) { if (ArmIsMpCore()) { // Is UEFI built as it is assumed that TZSW is running? // PcdTrustzoneSupport==1: YES. @@ -174,7 +175,7 @@ TrustedWorldInitialization ( ArmPlatformSecTrustzoneInit (MpId); // Setup the Trustzone Chipsets - if (IS_PRIMARY_CORE(MpId)) { + if (ArmPlatformIsPrimaryCore (MpId)) { if (ArmIsMpCore()) { // Signal the secondary core the Security settings is done (event: EVENT_SECURE_INIT) ArmCallSEV (); diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec.inf b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec.inf index 854b269..1cda8c3 100644 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec.inf +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/Sec.inf @@ -62,9 +62,6 @@ gArmTokenSpaceGuid.PcdArmNsacr gArmTokenSpaceGuid.PcdArmNonSecModeTransition - gArmTokenSpaceGuid.PcdArmPrimaryCoreMask - gArmTokenSpaceGuid.PcdArmPrimaryCore - gArmTokenSpaceGuid.PcdSecureFvBaseAddress gArmTokenSpaceGuid.PcdSecureFvSize diff --git a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S index 08a893c..4dec90b 100644 --- a/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S +++ b/SamsungPlatformPkg/ExynosPkg/Exynos5250/Sec/SecEntryPoint.S @@ -14,12 +14,14 @@ #include <AutoGen.h> #include <AsmMacroIoLib.h> #include <Library/ArmPlatformLib.h> +#include <ArmPlatform.h> #include "SecInternal.h" .text .align 3 GCC_ASM_IMPORT(CEntryPoint) +GCC_ASM_IMPORT(ArmPlatformIsPrimaryCore) GCC_ASM_IMPORT(CopyFirmwareFromEMMC) GCC_ASM_IMPORT(CopyFirmwareFromSDMMC) GCC_ASM_IMPORT(ArmPlatformClockInitialize) @@ -36,6 +38,16 @@ GCC_ASM_EXPORT(_ModuleEntryPoint) SecStartupAddr: .word ASM_PFX(_SecEntryFromTzsw) StartupAddr: .word ASM_PFX(CEntryPoint) +// Convert the (ClusterId,CoreId) into a Core Position +// 0x0F03 is the magic value for ARM_CORE_MASK | ARM_CLUSTER_MASK +//Core is 0-1 bits and cluster is 8-11 bits +#define GetCorePositionFromMpId(Pos, MpId, Tmp) \ + ldr Tmp, =0x0F03 ; \ + and MpId, Tmp ; \ + lsr Pos, MpId, #6 ; \ + and Tmp, MpId, #3 ; \ + add Pos, Pos, Tmp + // Reserve a region at the top of the IRAM Core stack // for Global variables for the XIP phase #define SetiRamStack(StackTop, GlobalSize, Tmp) \ @@ -85,13 +97,13 @@ ASM_PFX(_ModuleEntryPoint): _IdentifyCpu: // Identify CPU ID bl ASM_PFX(ArmReadMpidr) - // Get ID of this CPU in Multicore system - LoadConstantToReg (FixedPcdGet32(PcdArmPrimaryCoreMask), r1) - and r5, r0, r1 + // Keep a copy of the MpId register value + mov r5, r0 // Is it the Primary Core ? - LoadConstantToReg (FixedPcdGet32(PcdArmPrimaryCore), r3) - cmp r5, r3 + bl ASM_PFX(ArmPlatformIsPrimaryCore) + cmp r0, #1 + // Only the primary core initialize the memory (SMC) beq _InitMem @@ -119,9 +131,6 @@ _InitMem: bl ASM_PFX(ArmPlatformSecBootMemoryInit) - // Only Primary CPU could run this line (the secondary cores have jumped from _IdentifyCpu to _SetupStack) - LoadConstantToReg (FixedPcdGet32(PcdArmPrimaryCore), r5) - _SetupPrimaryCoreStack: // Get the top of the primary stacks (and the base of the secondary stacks) LoadConstantToReg (FixedPcdGet32(PcdCPUCoresSecStackBase), r1) -- 1.7.9.5

12 years, 3 months

1
0
0 0

[PATCH 0/1] How to fix your ARM UEFI BSP to work with the latest upstream Tianocore code

by Ryan Harkin

[PATCH 1/2] TC1: Fix TC1 build for latest upstream changes [PATCH 2/2] VEA5: Fix A5 build for latest upstream changes The two platforms are relatively simple to fix because they follow the TC2 and A9 BSPs very closely. Perhaps close enough to some more code to be moved to common areas ;-) These examples will show you the simple steps you will need to take to get your BSP working. However, your BSP may be using old functionality that my BSPs were not. The main change to watch out for is the deletion of the macro IS_PRIMARY_CORE() which has been replaced with a function that the BSP must provide. The change came about with this commit: -------------------------------------------------------------------------------- commit bebda7ceec3d3024c76b3c2ed0c9b4e502a13d61 Author: oliviermartin <oliviermartin@6f19259b-4bc3-4df7-8a09-765794883524> Date: Fri May 10 12:41:27 2013 +0000 ArmPlatformPkg/ArmPlatformLib: Added support for ArmPlatformIsPrimaryCore() Checking if a core if the primary/boot core used to be done with the macro IS_PRIMARY_CORE(). Some platforms exposes configuration registers to change the primary core. Replacing the macro IS_PRIMARY_CORE() by ArmPlatformIsPrimaryCore() allows some flexibility in the way to check the primary core. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin(a)arm.com> Reviewed-by: Leif Lindholm <leif.lindholm(a)linaro.org> Acked-by: Ryan Harkin <ryan.harkin(a)linaro.org> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14344 6f19259b-4bc3-4df7-8a09-765794883524 -------------------------------------------------------------------------------- My examples provide this function in a way that works for them, however, your platforms may use different mechanisms. I have no specific code that was using the IS_PRIMARY_CORE() macro, so these patches will not give an example of how you deal with those changes, but Olivier's original patch should help a lot there. Regards, Ryan. [1] https://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=summary

12 years, 3 months

1
2
0 0

linaro-uefi-2013.06-rc1 is out

by Ryan Harkin

Hello UEFI folks, I spent the day with Leif going through maintainer stuff and together we produced the 2013.06 iteration of the Linaro UEFI tree [1]. Highlights include: - A5, TC1, Panda, Origen and Arndale no longer build (I will be fixing A5 and TC1 as part of -rc2, unless something else urgent comes in and needs an -rc2) - The -menu and -local-fdt topics have been merged into one -bds topic to simplify upstreaming, reviewing and merging - All topics are rebased to the latest Tianocore upstream code - Some of our patches have made it upstream - yay! - and thus have been removed from our topic branches - There are more patches that we think are ready to go upstream now. I'll start this after -rc2 Regards, Ryan. [1] https://git.linaro.org/gitweb?p=arm/uefi/uefi-next.git;a=summary

12 years, 3 months

1
0
0 0

Re: Looking at Maintainer Tasks Today And Tomorrow

by Steven Kinney

Hi Ryan, Thanks for the patch system and I will follow the same methodology. BR, Steve On 4 June 2013 10:50, Ryan Harkin <ryan.harkin(a)linaro.org> wrote: > Hi Steve, > > Further to our phone call, I pushed out my patch system git repo: > > ssh:// > linaro-private.git.linaro.org/srv/linaro-private.git.linaro.org/uefi/patche… > > Hope it helps! > > Cheers, > Ryan. > > On 3 June 2013 16:23, Steven Kinney <steven.kinney(a)linaro.org> wrote: > > Hi Ryan, > > > > I am focusing on maintainer tasks today and tomorrow; > > before I start on 64-bit SCT integration. I talked to Grant on my > one-on-one > > Friday and he suggested applying the patches within a local repository, > > maybe within my git.linaro.org folder, and working with you regarding > > merging and other GIT tasks. Of course, if you have ant suggestions to > > start getting me up so that I can be more of use to you, please let me > know. > > Also, Grant wanted me to start giving suggestions regarding the coding, > and > > I see some areas that can be commented on, but I would like to make sure > we > > are in sync before I start yammering on commented out code blocks and > such. > > > > Anyway, I look forward to learning about this area and > > will ping you from time to time over the next few days to get some > specific > > advice. Thanks for you patience and help! > > > > BR, > > > > Steve >

12 years, 3 months

1
0
0 0

Fast Model for testing

by Steven Kinney

Ryan, Which Fast Model would you recommend for SCT testing and testing in general. -Steve

12 years, 3 months

2
2
0 0

Re: Detect SMBIOS table

by Grant Likely

[cc'ing the boot architecture list; this conversation should be in public] On Wed, May 29, 2013 at 11:19 AM, Leif Lindholm <leif.lindholm(a)linaro.org> wrote: > Hi Yi, > > On 28 May 2013 15:52, Li Yi <yi.li(a)linaro.org> wrote: >> just modify linux loader , add SMBIOS address information into fdt. then >> I will modify the dmidecode to parse the /dev/devicetree to find SMBIOS >> table pointer. Maybe this way can skip grub and kernel's modification. > > Ok, yes, that should work. > >> the only problem I care about is the address wrote into fdt ,it is a >> real physical address, does dmidecode (tool) can read this address ,and do >> the right thing? it need to be proved. > > Yes - UEFI is guaranteed to run with a 1:1 mapping, so the address you see it > at in the UEFI linux loader is the physical address. > >> Grant: if kernel will use the SMBIOS's region memory, can I reserve the >> 64M memory from the top total ,then kernel will know it's reserved ,will not >> use the region again ,right? > > That should be enough. Yes, but you shouldn't even need to do that. I just looked at the LinuxLoader code, in particular the UEFI FDT code, and I've noticed that the reserved regions should already be set up. Look in ArmPkg/Library/BdsLib/BdsLinuxFdt.c, about line 420. The function PrepareFdt() retrieves the UEFI memory map and calls fdt_add_mem_rsv() for each region. It does use the function IsLinuxReservedRegion() to filter the regions, so if SMBIOS uses a different region type then you'll need to add that type to the list. So, if I'm correct, it should be sufficient to merely enable SMBIOS support in UEFI and the kernel will automatically mark the SMBIOS region as reserved. You can verify this by adding "memblock=debug" to the kernel command line and looking at the kernel boot output. You'll see something like this: memblock_reserve: [0x00000000008400-0x0000000042e98c] arm_memblock_init+0x4c/0x150 memblock_reserve: [0x00000004000000-0x0000000452f400] arm_memblock_init+0xcc/0x150 memblock_reserve: [0x00000000004000-0x00000000008000] arm_memblock_init+0xf0/0x150 memblock_reserve: [0x00000004530000-0x00000004537350] arm_dt_memblock_reserve+0x30/0xb0 MEMBLOCK configuration: memory size = 0x8000000 reserved size = 0x960cdc memory.cnt = 0x1 memory[0x0] [0x00000000000000-0x00000007ffffff], 0x8000000 bytes reserved.cnt = 0x4 reserved[0x0] [0x00000000004000-0x00000000007fff], 0x4000 bytes reserved[0x1] [0x00000000008400-0x0000000042e98b], 0x42658c bytes reserved[0x2] [0x00000004000000-0x0000000452f3ff], 0x52f400 bytes reserved[0x3] [0x00000004530000-0x0000000453734f], 0x7350 bytes Memory policy: ECC disabled, Data cache writeback memblock_reserve: [0x00000007fff000-0x00000008000000] memblock_alloc_base_nid+0x68/0x84 memblock_reserve: [0x00000007ffe000-0x00000007fff000] memblock_alloc_base_nid+0x68/0x84 memblock_reserve: [0x00000007ffdf10-0x00000007ffe000] memblock_alloc_base_nid+0x68/0x84 memblock_reserve: [0x00000007ffc000-0x00000007ffd000] memblock_alloc_base_nid+0x68/0x84 memblock_reserve: [0x00000007ffb000-0x00000007ffc000] memblock_alloc_base_nid+0x68/0x84 memblock_reserve: [0x00000007ffa000-0x00000007ffb000] memblock_alloc_base_nid+0x68/0x84 Note: this only works with the UEFI LinuxLoader. The GRUB code doesn't currently add the UEFI reserved regions to the FDT reserved map. g.

12 years, 3 months

1
0
0 0

EFI_STUB notes

by Grant Likely

Hi Roy, Here are some very quick notes on what I found on writing UEFI applications. I found a library called "gnuefi" which allows building EFI applications apart from the Tianocore build tree. It looks interesting, but has not been ported to ARM. I don't yet know if it is worthwhile pursuing. http://gnu-efi.sourceforge.net/ As mentioned, the Linux kernel has an EFI stub already. I could tell you which files to look at, but really just doing a "git grep EFI_STUB" in the kernel tree will show you all the files that you need to care about. :-) You'll need to figure out how to get a UEFI PE-COFF header into the LInux kernel zImage wrapper. It shouldn't be too hard. You'll need to look at the startup code in arch/arm/boot/compressed/head.S. The PE-COFF header will need to go somewhere after the start: label. You should be able to see the existing LInux kernel "header" (not much of a header, more of a magic number) about 10 lines down from the start label. That's all I can write at the moment. We can talk more tomorrow. g.

12 years, 4 months

1
0
0 0

ARMv7-A UEFI runtime services support in Linux

by Leif Lindholm

Terse information, more engineering notes than documentation, and links to sources can be found at: https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/RuntimeServices Contains a few known bugs, and will need some fundamental discussions/reengineering, but lets us start experimenting. / Leif

12 years, 4 months

2
3
0 0

PXE for arndale

by Rony Nandy

To boot linux kernel using TFTP in Arndale. Following is the steps: 1. Apply the patches 13.03 branch. (on top of Olivers Ethernet patches,If Olivier's patches doesn't apply, then do it manually) 2. Compile and boot as usual. 3. Wait till USB initialization and then do as shown below: The default boot selection will start in 1 seconds UsbEnumeratePort: Device Connect/Disconnect Normally UsbEnumeratePort: Device Connect/Disconnect Normally UsbEnumeratePort: Device Connect/Disconnect Normally EhcExecTransfer: transfer failed with 8 EhcControlTransfer: error - Device Error, transfer - 8 0x9F6BDA90: Allocate pNicDevice, 792 bytes 0x9F4DCD10: Allocated timer Installed: gEfiCallerIdGuid on 0x9F4DE390 Installed: gEfiSimpleNetworkProtocolGuid on 0x9F4DE390 MnpSyncSendPacket: No network cable detected. MnpSyncSendPacket: No network cable detected. MnpSyncSendPacket: No network cable detected. MnpSyncSendPacket: No network cable detected. ERROR: Did not find Linux kernel. [1] SD-MMC Booting - PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/IPv4(192.168.1.1)/uImage - Arguments: root=/dev/mmcblk1p2 rw rootwait console=ttySAC2,115200n8 init --no-log - LoaderType: Linux kernel with global FDT ----------------------- Global FDT Config - VenHw(3A02E7FE-0649-4FB4-BE4F-A862CA1872A9)/HD(2,MBR,0x000039F9,0x2000,0x1A000)/exynos5250-arndale.dtb ----------------------- [a] Boot Manager [b] Shell Start: a [1] Add Boot Device Entry [2] Update Boot Device Entry [3] Remove Boot Device Entry [4] Update FDT path [5] Return to main menu Choice: 1 Installed Fat filesystem on 9E63E190 [1] boot (51 MB) - VenHw(3A02E7FE-0649-4FB4-BE4F-A862CA1872A9)/HD(2,MBR,0x000039F9,0x2000,0x1A000) [2] VenHw(B615F1F5-5088-43CD-809C-A16E52487D00) - VenHw(B615F1F5-5088-43CD-809C-A16E52487D00) [3] PXE on MAC Address: 00:40:5C:26:0A:5B - PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0) [4] TFTP on MAC Address: 00:40:5C:26:0A:5B - PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0) Select the Boot Device: 4 Get the IP address from DHCP: [y/n] y Get the TFTP server IP address: 192.168.1.1 File path of the EFI Application or the kernel : uImage Is an EFI Application? [y/n] n Boot Type: [a] ATAGS, [g] Global FDT or [l] Local FDT? [a/g/l] g Add an initrd: [y/n] n Arguments to pass to the binary: root=/dev/mmcblk1p2 rw rootwait console=ttySAC2,115200n8 init --no-log Description for this new Entry: tftp [1] Add Boot Device Entry [2] Update Boot Device Entry [3] Remove Boot Device Entry [4] Update FDT path [5] Return to main menu Choice: 5 [1] SD-MMC Booting - PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/IPv4(192.168.1.1)/uImage - Arguments: root=/dev/mmcblk1p2 rw rootwait console=ttySAC2,115200n8 init --no-log - LoaderType: Linux kernel with global FDT [2] tftp - PciRoot(0x0)/Pci(0x0,0x0)/USB(0x2,0x0)/USB(0x1,0x0)/USB(0x3,0x0)/IPv4(192.168.1.1)/uImage - Arguments: root=/dev/mmcblk1p2 rw rootwait console=ttySAC2,115200n8 init --no-log - LoaderType: Linux kernel with global FDT ----------------------- Global FDT Config - VenHw(3A02E7FE-0649-4FB4-BE4F-A862CA1872A9)/HD(2,MBR,0x000039F9,0x2000,0x1A000)/exynos5250-arndale.dtb ----------------------- [a] Boot Manager [b] Shell Start: 2

12 years, 5 months

1
0
0 0

boot Ubuntu using PXE from U-Boot on the Samsung XE303C12-A01US Chromebook

by Mario

Hello. I'm trying to boot Ubuntu using PXE from U-Boot on the Samsung XE303C12-A01US Chromebook. I would like to understand better the point 5 of the tutorial here : https://wiki.linaro.org/Boards/Arndale/Setup/PXEBoot it says : "At the u-boot prompt, set the environmental variables "serverip" and "ipaddr" as per the board and host PC configuration. Now set the following environmental variables as mentioned..." the problem is that the Samsung XE303C12-A01US does not have a serial port and I can't stop the u-boot booting and set the enviromental variables manually. I would like to know how can I embed them inside u-boot. Also because there is not a configuration file like boot.cmd/boot.scr like there is on the pandaboard that can be used to pass the parameters. Thanks. -- Mario.

12 years, 5 months

2
1
0 0

[PATCH 1/2] Samsung/Arndale: Enable component name protocol

by Shivamurthy Shastri

Component Name Protocol been enabled to make sure the shell commands like drivers, devtree and devices shows the device name and other features properly. Signed-off-by: Shivamurthy Shastri <shiva.murthy(a)samsung.com> Signed-off-by: Rony Nandy <rony.nandy(a)linaro.org> --- SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc index fe574af..941c6e5 100755 --- a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc +++ b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc @@ -69,6 +69,11 @@ ################################################################################ [PcdsFeatureFlag.common] + gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|FALSE + gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE + gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|FALSE + gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE + !ifdef $(EDK2_SKIP_PEICORE) gArmPlatformTokenSpaceGuid.PcdSystemMemoryInitializeInSec|TRUE gArmPlatformTokenSpaceGuid.PcdSendSgiToBringUpSecondaryCores|TRUE -- 1.8.2

12 years, 6 months

4
7
0 0

lists.linaro.org maintenance completed

by IT Services

This is to let you know that the migration of lists.linaro.org has been successfully completed. As per the email I sent on Wednesday, it may take some time for the new address of the server to be seen by your computer. You can check this by trying to connect to the web site: http://lists.linaro.org/ If you are able to connect and you do not get an error, this means you are connecting to the new server and you can send email to the lists. If you experience any problems after the weekend and you find that you still cannot connect to the server, please reply to this email to let us know. Regards Philip IT Services Manager Linaro

12 years, 6 months

1
0
0 0

OMAP4 PandaBoard 4430 vs PandaBoardES 4460

by Péter Ujfalusi

Hi, First of all I'm not sure if this is the right list to post this, but I thought boot-architecture might be the best list to post. Currently we have one hwpack for PandaBoard4430 and PandaBoardES 4460 which means that when we install the hwpack on PandaBoardES the kernel thinks it is running on PandaBoard 4430. However there is a HW difference between the two boards: Audio routing is different (for capture path). Also the hdmi pin muxing need to be different (according to the DTS files). I can see two ways of dealing with the different versions: 1. create separate hwpacks for the revisions where only the included DTB file is different: PandaBoard 4430: omap4-panda.dtb PandaBoardES: omap4-panda-es.dtb 2. Or to have single hwpack for Panda: With the included patch in u-boot Include both omap4-panda.dtb and omap4-panda-es.dtb files to the boot partition. Modify the boot.txt to load different dtb based on the board: if is_pandaES; then setenv bootcmd "fatload mmc 0:1 0x80200000 uImage; fatload mmc 0:1 0x81600000 uInitrd; fatload mmc 0:1 0x815f0000 omap4-panda-es.dtb; bootm 0x80200000 0x81600000 0x815f0000"; else setenv bootcmd "fatload mmc 0:1 0x80200000 uImage; fatload mmc 0:1 0x81600000 uInitrd; fatload mmc 0:1 0x815f0000 omap4-panda.dtb; bootm 0x80200000 0x81600000 0x815f0000"; fi; For audio we need to tell the difference between the two revision and this is done via different DTB blob. Thank you, Péter

12 years, 6 months

1
0
0 0

Planned maintenance - lists.linaro.org

by IT Services

Hello You are receiving this email because you are subscribed to one or more mailing lists provided by the lists.linaro.org server. IT Services are announcing planned maintenance for this server scheduled for *Friday 15th March 2013, starting at 2pm GMT*. The purpose of the work is to move the service to another server. There will be some disruption during this maintenance. In order to ensure that you do not accidentally try to use the service while it is being moved, the current server will be shut down at 2pm. A further email will be sent on Friday afternoon to confirm that the migration of the service is completed. However, due to the way servers are found, it may take a while before your computer is able to connect to the relocated service. After the old server has been shut down, email sent to any of the lists will be queued, but it is possible that the sending server will still trying to deliver the email to the old server rather than the new one when it is started. It is therefore *strongly* recommended that you do not send any email to an @lists.linaro.org email address until you can connect to the new service, which you will be able to test by trying to use a web browser to connect to http://lists.linaro.org after you receive the email confirming that the migration has been completed. Since the old service will be shut down, if you are able to connect, you can be sure you have connected to the new service. If by Monday you are still unable to connect to the service or you are not able to send email to an @lists.linaro.org email address, please send an email to its(a)linaro.org. Thank you. Regards Philip IT Services Manager Linaro

12 years, 6 months

1
0
0 0

[PATCH] Samsung/Arndale: Enable component name protocol

by Shivamurthy Shastri

Component Name Protocol been enabled to make sure the shell commands like drivers, devtree and devices shows the device name and other features properly. Signed-off-by: Shivamurthy Shastri <shiva.murthy(a)samsung.com> Signed-off-by: Rony Nandy <rony.nandy(a)linaro.org> --- SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc index a545e80..519b7f8 100755 --- a/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc +++ b/SamsungPlatformPkg/ArndaleBoardPkg/arndale-Exynos5250.dsc @@ -68,6 +68,11 @@ ################################################################################ [PcdsFeatureFlag.common] + gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|FALSE + gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE + gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|FALSE + gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE + !ifdef $(EDK2_SKIP_PEICORE) gArmPlatformTokenSpaceGuid.PcdSystemMemoryInitializeInSec|TRUE gArmPlatformTokenSpaceGuid.PcdSendSgiToBringUpSecondaryCores|TRUE -- 1.8.1.1

12 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture