Linaro-uefi February 2014

linaro-uefi@lists.linaro.org

7 participants
9 discussions

[ARM-UEFI]not find cci-400 settings in uefi code

by TigerLiu＠via-alliance.com

Hi, experts: Not find any cci-400 settings in current uefi code. So, Not need to set cci-400 registers in uefi code? Because ArmVExpress-CTA15-A7 supports big.LITTLE, so: It should set cci-400 in its code. Best wishes,

11 years, 9 months

[ARM-UEFI] which platform including display driver?

by TigerLiu＠via-alliance.com

Hi, experts: Linaro UEFI currently supports: Origen / Arndale / PandaBoard So, which platform include display driver?(touch panel or LCD panel) So, it could display logo or picture during UEFI boot procedure. Best wishes,

11 years, 9 months

Re: [Linaro-uefi] [PATCH 1/3] Mnp Error handling

by Roy Franz

Hi Olivier, This patch is only required because of your patch - without your patch this change is not required, and the changes to the Lan9X* files are sufficient to fix the network driver initialization problems that were present in the 2014.01 release. I do not think that your proposed patch is correct. All the fields in the snpmode structure are supposed to be discovered during driver initialization, which in the case of the lan9xxx drivers, this is the driver entry point. The "mediapresent" value which the comment refers to may not reflect actual media state if the GetStatus() call returns an error, but that is OK. The rest of the values in the structure are valid at that point - the NULL check is sufficient. Thanks, Roy On Mon, Feb 24, 2014 at 10:00 AM, Olivier Martin <olivier.martin(a)arm.com> wrote: > Hi Roy, > I have just pinged the MdeModulePkg maintainer for the MnpDxe patch I sent 7 > months ago. > If I am lucky my patch might get some consideration from the maintainer and > get merged... > > Have a look at the EDK2 mailing-list, you might have a chance to get your > change after mine. > Your patch looks correct, but I am not the maintainer of this package. > > Thanks, > Olivier > > >> -----Original Message----- >> From: Roy Franz [mailto:roy.franz@linaro.org] >> Sent: 07 February 2014 04:53 >> To: linaro-uefi(a)lists.linaro.org; Olivier Martin >> Cc: Roy Franz >> Subject: [PATCH 1/3] Mnp Error handling >> >> Change MnpGetModeData() handling of return status from >> SnpStatus to not consider EFI_NOT_STARTED an error, >> similar to how Ip4ConfigDriverBindingStart() handles it. >> >> Without this change, Ip4ConfigDriverBindingStart() considers >> the Mnp->GetModeData successful even though the SnpMode parameter >> is unchanged, and is full of unitialized stack data. >> >> If this change is not correct, then other error handling changes >> need to be made in Ip4ConfigDriverBindingStart() so that >> uninitialized data from the stack is not used. >> >> >> Signed-off-by: Roy Franz <roy.franz(a)linaro.org> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> --- >> MdeModulePkg/Universal/Network/MnpDxe/MnpMain.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/MdeModulePkg/Universal/Network/MnpDxe/MnpMain.c >> b/MdeModulePkg/Universal/Network/MnpDxe/MnpMain.c >> index 795f063..c628991 100644 >> --- a/MdeModulePkg/Universal/Network/MnpDxe/MnpMain.c >> +++ b/MdeModulePkg/Universal/Network/MnpDxe/MnpMain.c >> @@ -80,7 +80,7 @@ MnpGetModeData ( >> // will be updated to reflect any change of media status >> // >> Status = Snp->GetStatus (Snp, &InterruptStatus, NULL); >> - if (!EFI_ERROR (Status)) { >> + if (!EFI_ERROR (Status) || (Status == EFI_NOT_STARTED)) { >> CopyMem (SnpModeData, Snp->Mode, sizeof (*SnpModeData)); >> } >> } >> -- >> 1.7.10.4 >> > > >

11 years, 10 months

[PATCH 0/3] RFC: Fix network initialization

by Roy Franz

I'd like some feedback on this approach before I send this to the EDK2 list. Networking initialization broke in 2014.01 due reliance on a specific ordering of driver initialization that is not enforced. In particular, networking only worked if the Ip4ConfigDriverBinding protocol was started after the ArpDriverBinding protocol. This was due to the Arp driver startup causing the initialization of the LAN9xxx driver. These two binding protocols have equal "versions", which control the ordering, so it seems that the ordering between the two is arbitrary. (I have not tracked down exactly why the ordering is different in the two releases.) There were two different problems in the failing case: 1) The MnpGetModeData() function would not update the SnpMode structure it was passed if the SNP driver was not started, even though the Ip4Config caller did not treat EFI_NOT_STARTED as an error. Ip4ConfigDriverBindingStart() would then proceed to use a SnpMode structure with unitialized stack data. The first patch in the series updates MnpGetModeData() to not treat EFI_NOT_STARTED as an error and to update the SnpMode structure in this case. With this fix, networking initialization is still broken, but at least no unitialized data is used. 2) The LAN9xxx drivers did not update the SnpMode MAC addresses until the driver was started or initialized (they each did it differently.) The next 2 patches update the driver to set the SnpMode MAC addresses at driver entry, so they are available at the time the Ip4Config driver binds with the LAN9xxx driver. Roy Franz (3): Mnp Error handling LAN9118: set SNP MAC in entry function LAN91x: Set SNP current MAC address in entry function ArmPlatformPkg/Drivers/LAN9118Dxe/LAN9118Dxe.c | 9 +++------ ArmPlatformPkg/Drivers/LAN91xDxe/LAN91xDxe.c | 3 +-- MdeModulePkg/Universal/Network/MnpDxe/MnpMain.c | 2 +- 3 files changed, 5 insertions(+), 9 deletions(-) -- 1.7.10.4

11 years, 10 months

Re: [Linaro-uefi] [edk2] Upstream EDK2 broken with latest Linaro toolchain (13.12 onwards)

by Ryan Harkin

On 21 February 2014 18:44, Andrew Fish <afish(a)apple.com> wrote: > > On Feb 21, 2014, at 10:17 AM, Laszlo Ersek <lersek(a)redhat.com> wrote: > > On 02/21/14 16:12, Ryan Harkin wrote: > > Hi Olivier, > > I've just noticed that the upstream EDK2 repository for the FVP AEMv8 > model is broken when built with Linaro GCC 13.12 onwards. > > The error I see is: > > UEFI firmware (version built at 14:54:24 on Feb 21 2014) > add-symbol-file > > /linaro/uefi/master/upstream/edk2.git/Build/ArmVExpress-FVP-AArch64/DEBUG_ARMGCC/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll > 0x88000780 > Decompress Failed - Not Found > > ASSERT_EFI_ERROR (Status = Not Found) > ASSERT > /linaro/uefi/master/upstream/edk2.git/ArmPlatformPkg/PrePi/PrePi.c(194): > !EFI_ERROR (Status) > > I've tracked the bug as far as function "FfsProcessSection" [1] where > at line 373, it calls into function "ExtractGuidedSectionDecode" [2] > which then calls into "SavedData->ExtractDecodeHandlerTable [Index]". > At that point, I can't work out where it goes. > > I can "fix" the problem if I re-org the variables at the top of > FfsProcessSection so that DstBuffer is at the start of the > declarations. That is obviously not a fix. But it will probably hint > at why the subsequent code is broken. > > Cheers, > Ryan > > [1] EmbeddedPkg/Library/PrePiLib/FwVol.c, line 285 > [2] > EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:166 > > > Here's a random shot (could be completely unrelated): > > > EFI_STATUS > FfsProcessSection ( > IN EFI_SECTION_TYPE SectionType, > IN EFI_COMMON_SECTION_HEADER *Section, > IN UINTN SectionSize, > OUT VOID **OutputBuffer > ) > { > /* ... */ > UINTN DstBufferSize; > /* ... */ > > You're on AArch64, so UINTN means UINT64. > > Note that this "auto" variable is not initialized, hence its contents are > indeterminate. Fast forward to the next use: > > Status = UefiDecompressGetInfo ( > (UINT8 *) ((EFI_COMPRESSION_SECTION *) Section + 1), > (UINT32) SectionLength - sizeof > (EFI_COMPRESSION_SECTION), > (UINT32 *) &DstBufferSize, > &ScratchBufferSize > ); > } else if (Section->Type == EFI_SECTION_GUID_DEFINED) { > Status = ExtractGuidedSectionGetInfo ( > Section, > (UINT32 *) &DstBufferSize, > &ScratchBufferSize, > &SectionAttribute > ); > > Whichever of these functions is invoked, it fills in only four bytes > (UINT32). Then, > > DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES > (DstBufferSize) + 1); > > etc etc etc. > > By reordering the local variables, you could be limiting the nonzero > garbage in "DstBufferSize" to those four bytes that *are* ultimately > overwritten. > > I guess initing DstBufferSize to zero is easy enough to try... :) > > As you guessed, it was easy to try and it does indeed fix the problem. However.... > > > Why not just make it UINT32 and remove the casts. A real fix! > That looks like the correct solution to me. And yes, it works also. Andrew, would you like to submit a patch as it's your change? I'm very happy to do it, so whichever you'd prefer. Thanks for your help, both! Cheers, Ryan. > > Thanks, > > Andrew Fish > > Thanks > Laszlo > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > edk2-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > > > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > edk2-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > >

11 years, 10 months

Upstream EDK2 broken with latest Linaro toolchain (13.12 onwards)

by Ryan Harkin

Hi Olivier, I've just noticed that the upstream EDK2 repository for the FVP AEMv8 model is broken when built with Linaro GCC 13.12 onwards. The error I see is: UEFI firmware (version built at 14:54:24 on Feb 21 2014) add-symbol-file /linaro/uefi/master/upstream/edk2.git/Build/ArmVExpress-FVP-AArch64/DEBUG_ARMGCC/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll 0x88000780 Decompress Failed - Not Found ASSERT_EFI_ERROR (Status = Not Found) ASSERT /linaro/uefi/master/upstream/edk2.git/ArmPlatformPkg/PrePi/PrePi.c(194): !EFI_ERROR (Status) I've tracked the bug as far as function "FfsProcessSection" [1] where at line 373, it calls into function "ExtractGuidedSectionDecode" [2] which then calls into "SavedData->ExtractDecodeHandlerTable [Index]". At that point, I can't work out where it goes. I can "fix" the problem if I re-org the variables at the top of FfsProcessSection so that DstBuffer is at the start of the declarations. That is obviously not a fix. But it will probably hint at why the subsequent code is broken. Cheers, Ryan [1] EmbeddedPkg/Library/PrePiLib/FwVol.c, line 285 [2] EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:166

11 years, 10 months

Re: [Linaro-uefi] uefi code has included fastboot implementation?

by TigerLiu＠via-alliance.com

Hi, Oliver: Thanks a lot! >ARM Ltd has been working on a UEFI implementation of Android FastBoot. We are >planning to publish this implementation in the next 10 days. It's a good news! Best wishes,

11 years, 10 months

uefi code has included fastboot implementation?

by TigerLiu＠via-alliance.com

Hi, ryan: Does the current uefi code released by linaro include android fastboot implementation? In this websiste : https://wiki.linaro.org/ARM/UEFI/FastBoot It seemed an engineer has implemented it on a PandaBoard. Best wishes,

11 years, 10 months

Removing colour codes

by Ryan Harkin

Hi Fu Wei, Here's the patch for the FVP Base model to remove colour codes. It's very simple. By default, the behaviour isn't changed. But if you build the code with "-D EDK2_SIMPLE_CONSOLE", it will remove the colour code. This patch was based on an old version of our tree, but it should apply. If not, you can see the changed needed and they are very small. Cheers, Ryan.

11 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-uefi February 2014