Linaro-uefi

linaro-uefi@lists.linaro.org

811 discussions

Fwd: The first version of multiboot support patch for aarch64

by Fu Wei

-------- Original Message -------- Subject: The first version of multiboot support patch for aarch64 Date: Wed, 12 Mar 2014 15:52:06 +0800 From: Fu Wei <fu.wei(a)linaro.org> Reply-To: Fu Wei <fu.wei(a)linaro.org> Organization: Linaro To: Leif Lindholm <leif.lindholm(a)linaro.org> CC: Roy Franz <roy.franz(a)linaro.org>, "anmar.oueja(a)linaro.org" <anmar.oueja(a)linaro.org> Hi Leif The The first version of multiboot support patch is attached! It bases on the master branch of upstream git repo. I have sorted out the code, and I have tested it locally, it works fine for me. Could you please help me to review it. And give me some suggestion? BTW, in LEG team, what I should do when I have a patch? Using "git review" or sent the patch to you directly ?? :-) Thank you very much! -- Best regards, Fu Wei LAVA Engineer From Red Hat LAVA Team Linaro.org | Open source software for ARM SoCs Ph: +86 186 2020 4684 (mobile) IRC: fuwei Skype: tekkamanninja Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021

10 years, 9 months

Fwd: The first version of multiboot support patch for aarch64

by Fu Wei

10 years, 9 months

Tianocore now supports Android FastBoot

by Olivier Martin

Dear all, Android FastBoot support has been added to Tianocore into SVN 15317 (2014-03-05). Android Fastboot is a protocol to update the flash and/or boot filesystem on Android devices from a host over USB. The fastboot utility is part of the Android SDK. This support is architecture independent. An abstraction layer has been added to allow devices that do not have USB client support to use another transport mechanism (eg: TCP). We actually have support internally for this TCP transport layer we are planning to send upstream soon (after the internal review has been completed). These patches are available on request. The support has been validated on ARM Versatile Express using USB (and ethernet). A tutorial is available here: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EmbeddedPkg/ AndroidFastBoot Regards, Olivier

10 years, 9 months

Re: [Linaro-uefi] [edk2] Pandaboard LCD driver

by Olivier Martin

Hi, As you said Pandaboard support currently lives in Linaro repository. You can send your patch to linaro-uefi(a)lists.linaro.org Thanks, Olivier From: valeri2(a)inbox.ru [mailto:valeri2@inbox.ru] Sent: 10 March 2014 16:11 To: edk2-devel(a)lists.sourceforge.net Subject: [edk2] Pandaboard LCD driver Hi all. I have developed a patch Omap44xxPkg/LcdGraphicsOutputDxe driver for it to work properly on the Pandaboard. Can I somehow publish it in Linaro UEFI tree?

10 years, 9 months

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

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

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

10 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

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

10 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

10 years, 10 months

← Newer
1
...
74
75
76
77
78
79
80
81
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-uefi