boot-architecture June 2013

boot-architecture@lists.linaro.org

10 participants
25 discussions

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

11 years, 6 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

11 years, 6 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

11 years, 6 months

[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

11 years, 6 months

[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

11 years, 6 months

[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

11 years, 6 months

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 > >

11 years, 6 months

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

11 years, 6 months

[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:

11 years, 6 months

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

11 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture June 2013