Linaro-uefi

linaro-uefi@lists.linaro.org

811 discussions

by Fu Wei

Hi guys, Today, I re-tested the linaro-edk2 tree. So I report it below: First of all, the repo and the branch status info is attached. (1)compile using the latest uefi-tools (ALLPASS) linaro-edk2/master(PASS) linaro-edk2/release-prep(PASS) linaro-edk2/release(PASS) But as I said in last test report, maybe we can add a clean function in uefi-tools to avoid some compile issue. (2)test all binaries linaro-edk2/master(FAIL) linaro-edk2/release-prep(FAIL) The test result is below -------------------- [tekkamanninja@fuwei ~]$ telnet 192.168.1.16 5000 Trying 192.168.1.16... Connected to 192.168.1.16. Escape character is '^]'. Booting trusted firmware boot loader stage 1 Built : 14:39:42, Nov 22 2013 Booting trusted firmware boot loader stage 2 BL2 Built : 14:39:42, Nov 22 2013 Booting trusted firmware boot loader stage 3 BL31 Built : 14:39:43, Nov 22 2013 (just stop here) -------------------- linaro-edk2/release(PASS) Boot successfully into uefi menu. *But the problems described in [Bug 1274126] still exist.* If you feel any test has some problem, please let me know, I will try again. Thanks :-) -- Best regards, Fu Wei Enterprise Server Engineer From Red Hat LEG 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, 8 months

Re: [Linaro-uefi] ARM64: seeing FDT DevicePath node Corruption!!

by Ganapatrao Kulkarni

thanks olivier and Leif. ganapat On Wed, Apr 2, 2014 at 11:08 PM, Olivier Martin <olivier.martin(a)arm.com>wrote: > Hi Ganapat, > > The issue is actually in GetEnvironmentVariable(). The function should > have copied the default value to reflect the behaviour of value loaded from > RUNTIME_SERVICES.GetVariable(). > > I fixed the issue in SVN rev 15427 (2nd April 2014). > > Thanks a lot for having reported the issue, > > Olivier > > > > *From:* linaro-uefi-bounces(a)lists.linaro.org [mailto: > linaro-uefi-bounces(a)lists.linaro.org] *On Behalf Of *Ganapatrao Kulkarni > *Sent:* 01 April 2014 06:57 > *To:* linaro-uefi(a)lists.linaro.org > *Subject:* Re: [Linaro-uefi] ARM64: seeing FDT DevicePath node > Corruption!! > > > > any comments? > > > > > > On Mon, Mar 24, 2014 at 5:10 PM, Ganapatrao Kulkarni <gpkulkarni(a)gmail.com> > wrote: > > In my case, both variables DefaultFdtDevicePath and FdtDevicePath are > holding the same address. > this is because the function gRT->GetVariable (as called from > GetEnvironmentVariable) returing status as 14(EFI_NOT_FOUND) > and hence code setting FdtDevicePath same as DefaultFdtDevicePath > (This is rootcause for the issue what i explained in previous email). > > IMHO, it is a potential bug to execute FreePool (DefaultFdtDevicePath) > unconditionally. > > the probable fix could be, > > diff --git a/ArmPlatformPkg/Bds/BootOption.c > b/ArmPlatformPkg/Bds/BootOption.c > index edd193e..be93d28 100644 > --- a/ArmPlatformPkg/Bds/BootOption.c > +++ b/ArmPlatformPkg/Bds/BootOption.c > @@ -90,6 +90,7 @@ BootOptionStart ( > Status = GetEnvironmentVariable ((CHAR16 *)L"Fdt", > &gArmGlobalVariableGuid, > DefaultFdtDevicePath, &FdtDevicePathSize, (VOID > **)&FdtDevicePath); > ASSERT_EFI_ERROR(Status); > + if (DefaultFdtDevicePath != FdtDevicePath) > FreePool (DefaultFdtDevicePath); > } > Status = BdsBootLinuxFdt (BootOption->FilePathList, > > > please comment? > > regards > Ganapat > > > > > On Sun, Mar 23, 2014 at 11:50 PM, Ganapatrao Kulkarni > <gpkulkarni(a)gmail.com> wrote: > > Hi, > > > > I am trying to port edk2 to our ARM64 platform simulator and seeing > > strange behaviour. > > > > I see the content of FdtDevicePath is getting changed, after executing > > the function > > BdsLoadImage() to load the Linux Image file. > > Because of this, when BdsLoadImage function is called to load the > > fdt.dtb file, the execution goes in infinite loop. > > > > After debugging, i am seeing that, it is happenig due to corrution of > > FDT device path. > > > > Before the BdsLoadImage() called to load Linux Image file, > > the FDT device path(0xFBC8B918) content is valid, ie > > DevicePathFdt->Type = 1. > > DevicePathFdt ->SubType= 4. > > DevicePathFdt->Lenght[0] = 20. > > > > After the Linux Image is loaded, it is changes as below, > > DevicePathFdt->Type = 112 > > DevicePathFdt ->SubType= 111 > > DevicePathFdt->Lenght[0] = 100 > > > > further debugging, i see this happening by below lines of code, in > function > > CoreLocateHandle(), MdeModulePkg/Core/Dxe/Hand/Locate.c > > > > // > > // Increase the resulting buffer size, and if this handle > > // fits return it > > // > > ResultSize += sizeof(Handle); > > if (ResultSize <= *BufferSize) { > > *ResultBuffer = Handle; <= this line is corrupting the > > devicepath of FDT. > > ResultBuffer += 1; > > } > > } > > > > Not able to understand what causing this corruption. > > Any clue on what is going wrong? > > Any suggestions for further debugging? > > > > BTW, I am using edk2 source from > > git://git.linaro.org/uefi/linaro-edk2.git, branch master > > > > > > thanks > > Ganapat > > >

10 years, 8 months

ARM64: seeing FDT DevicePath node Corruption!!

by Ganapatrao Kulkarni

Hi, I am trying to port edk2 to our ARM64 platform simulator and seeing strange behaviour. I see the content of FdtDevicePath is getting changed, after executing the function BdsLoadImage() to load the Linux Image file. Because of this, when BdsLoadImage function is called to load the fdt.dtb file, the execution goes in infinite loop. After debugging, i am seeing that, it is happenig due to corrution of FDT device path. Before the BdsLoadImage() called to load Linux Image file, the FDT device path(0xFBC8B918) content is valid, ie DevicePathFdt->Type = 1. DevicePathFdt ->SubType= 4. DevicePathFdt->Lenght[0] = 20. After the Linux Image is loaded, it is changes as below, DevicePathFdt->Type = 112 DevicePathFdt ->SubType= 111 DevicePathFdt->Lenght[0] = 100 further debugging, i see this happening by below lines of code, in function CoreLocateHandle(), MdeModulePkg/Core/Dxe/Hand/Locate.c // // Increase the resulting buffer size, and if this handle // fits return it // ResultSize += sizeof(Handle); if (ResultSize <= *BufferSize) { *ResultBuffer = Handle; <= this line is corrupting the devicepath of FDT. ResultBuffer += 1; } } Not able to understand what causing this corruption. Any clue on what is going wrong? Any suggestions for further debugging? BTW, I am using edk2 source from git://git.linaro.org/uefi/linaro-edk2.git, branch master thanks Ganapat

10 years, 8 months

Fwd: TianoCore KVM Port: Status Update

by Leif Lindholm

---------- Forwarded message ---------- From: Michael Casadevall <michael.casadevall(a)linaro.org> Date: 28 March 2014 08:26 Subject: TianoCore KVM Port: Status Update To: linaro-dev(a)lists.linaro.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As I've made a fair bit of headway since LinaroConnect, I wanted to drop a line on my current progress with porting TianoCore to KVM Summary (tl;dr version): KVM can start TianoCore, and boot all the way to shell, and access HDDs via VirtioBlk. We can start grub and successfully retrieve files from ext partitions, load a device tree, and start the kernel. The kernel runs through most of the EFI stub, but falls over during ExitBootServices() Long Version: So, after much blood sweat and tears, we're finally at the point of trying to actually start a kernel, though this (for the moment) remains an elusive goal. The current problem is that once we call EBS(), we get an exception from EFI with no Image information, which means the exception handler doesn't know where it came from. After several seconds, we get a second exception from within DxeCore, and then EFI falls over. Debugging EFI is difficult and error prone, combined with limited debug facilities from the gdb-stub in QEMU (no breakpoints), and no decent way to load all of EFI itself (you have to run add-symbol-file manually with the output of commands printed on the console; supposedly its possible to generate a giant GdbSyms.dll file to import in a single go, but I haven't succeeded at this). This is further complicated that it appears we're asserting somewhere in a driver, and short of adding printfs to *every* driver, its impossible to know which is asseting. Previous attempts to debug assets shows that EFI does "odd" things to the stack when we hit an exception, making walking it with GDB impossible. I need to figure out what madness EFI does with my SP so I can get the entire stack on an explosion, but this remains at best hopeful thinking. Further complicating things is that during EBS, my print debugging goes away. I might just cheat and roll a simple assembly function to bang out messages through serial without calling anything else. Ugly as sin, but this should let me get useful debug output through the EBS framework. Complicating matters is that I need to locate each and all EBS() event functions, which are spread *everywhere* in TianoCore, and then debug them each individually. I'm open to ideas on how best to accomplish this. On a larger scale, there are a couple of other bugs and odds and ends which currently affect us: * wfi doesn't work THis is probably the biggest w.r.t. to functionality that should work, but doesn't. The EFI event loop is built on checking the timer, then calling wfi to check the timer later. The problem here is we call wfi ... and UEFI never comes back despite events firing (I can put print code in the interrupt handler to confirm this). This may be related to the VGIC errors I get running kvm under foundation, but haven't taken the time to properly nail down the bug here. This was worked around by commenting out the wfi, turning event loop into a busy loop, but this has to be resolved before we can ever consider merging it * No RTC I looked through virt.c in KVM, and as best I can tell, I've got no RTC at all (no PL031). It also appears that the kernel can't get RTC as running a kernel gets me a 1970 clock. I'm not sure if this is by design or not, but it causes GetTime() to return EFI_ERROR, and I suspect may be one of the exceptions I'm getting avoid (Shell prints a ton of warnings that GetTime is busted). * No terminfo support (not ARM specific) EFI assumes its working against a real console or terminal. As such, it doesn't respect anything like termcap or such, and output gets jumbled due to incorrect escape sequencies and such. This isn't specific to ARM as I get identical behavior with OVMF running on stdio or over telnet. Backspace for instance requires me to type ^H into the console manually As we expect to have this usable remotely, we need to determine how to handle the terminal and escape sequences properly so we're not printing garbage to the screen. A "dumb" mode might just be the best way to handle this, but something like grub do display fancy graphics. Ideas welcome. If anyone wants to play with it, my code is on git, but requires a bit of setup to get running, and you need a patch to KVM to successfully start UEFI at the moment. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTNTJTAAoJEGKVRgSEnX1Qm2YH/jzWQjB/DPSHdv33hUlxVuIm j2AGElid7HM+3gp5U/ILdXvCyP9LFg8RATsvUa7bSHdwFZxRdAqYUWzm/Jxg6ZYV kyTzTDuPhbXp8koVLF14H/oGlpwnEH5rhzNa3UeRZTNYnNp3UMeZ1NXgGu9ziCfk hMGGteTMfV/6fGD6AETtlpD99KKwFiprD198QAil2rpVRi4WZBcgp7Y9/c/+cLfy sJD7p+zN8jBh9r9njpxh0o5rrQoG3N1NAemPGbSAc+qMMYCDOmjasGLwYiJuuMDy apRBM9+pbYsEgBGxM1z3XGywBJWBaLGzizk8vfPN2kN70/F7RW89X1rqG/95Ais= =OwC0 -----END PGP SIGNATURE----- _______________________________________________ linaro-dev mailing list linaro-dev(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev

10 years, 8 months

EFI tree updates

by Roy Franz

Hi Leif, I have updated your new-uefi-for-upstream to work with the x86 mixed mode patchset that Matt Fleming posted. He added a new patch on top of that to add a macro to invoke the efi_early stuff, and it looks like that will go in. (it got pulled into tip, and Matt verified no object code changes.) If that goes in then we get to avoid changing x86 code in our patchset. (And if it doesn't, we should just base ours on his since his will surely go into 3.16.) I have pushed the tag rfranz-efi-for-leif-201400327 to git://git.linaro.org/people/roy.franz/linux.git The patches of interest are, in order: e74db1227..f81084ad84 These are Matt's 13 mixed mode patches. Some of the x86 bits didn't fully apply - I left some changes out. x86 compiles, but is likely not correct code. All common bits applied cleanly. 5373b9eb Matt's new code adding efi_call_early macro (existing series here. There were some minor merge conflicts on a couple of patches here.) 0949132b Here I add the arm64 version of the efi_call_early macro 8e97160b80b This patch adds the new non-shared helper functions that were added in the mixed-mode patch series. The last two should likely be squashed into the "arm64: add EFI stub" patch, but I wanted to leave them separate for internal review first. Roy

10 years, 8 months

Re: [Linaro-uefi] Any plans to support GICv3 on UEFI

by Olivier Martin

Please find the attached patches that should add GICv3 support to UEFI. This patchset has been validated on SVN rev15402 (27th March 2014). The testing and review have been limited (reason why these patches have not been pushed to EDK2 repository). I do not have any ETA. The GicDxe support GICv2 and GICv3 without requiring to be rebuilt. Feedbacks and comments are welcome. > -----Original Message----- > From: linaro-uefi-bounces(a)lists.linaro.org [mailto:linaro-uefi- > bounces(a)lists.linaro.org] On Behalf Of Olivier Martin > Sent: 17 March 2014 17:47 > To: 'Ganapatrao Kulkarni'; Leif Lindholm > Cc: linaro-uefi(a)lists.linaro.org > Subject: Re: [Linaro-uefi] Any plans to support GICv3 on UEFI > > I started to work on a UEFI GICv3 driver last year. It is almost > working but > I had to switch to higher priority tasks since then. > I have the plan to clean and publish this driver soon. I would say by > then > of April, but I do not want to commit to any date. > If it is blocking you then I can send an early version of the patch. > > Olivier > > > -----Original Message----- > > From: linaro-uefi-bounces(a)lists.linaro.org [mailto:linaro-uefi- > > bounces(a)lists.linaro.org] On Behalf Of Ganapatrao Kulkarni > > Sent: 15 March 2014 06:58 > > To: Leif Lindholm > > Cc: linaro-uefi(a)lists.linaro.org > > Subject: Re: [Linaro-uefi] Any plans to support GICv3 on UEFI > > > > Thanks Leif > > > > On Sat, Mar 15, 2014 at 12:31 AM, Leif Lindholm > > <leif.lindholm(a)linaro.org> wrote: > > > Hi Ganapat, > > > > > > On Fri, Mar 14, 2014 at 08:01:34PM +0530, Ganapatrao Kulkarni > wrote: > > >> I am using git://git.linaro.org/uefi/linaro-edk2.git and i see the > > >> comments saying > > >> /* Initialize GICv3 to expose it as a GICv2 as UEFI does not > support > > >> GICv3 yet */ > > >> > > >> Anyone is working/plan to add GICv3 driver? > > > > > > This is part of the architectural support, and pulled in that way > > > from Tianocore. It supports using a GICv3 in "legacy" GICv2 mode. > > > > > > I expect ARM will provide a non-legacy GICv3 driver at some point, > > > but I do not know the exact roadmap. > > > > > > Regards, > > > > > > Leif > > > > _______________________________________________ > > Linaro-uefi mailing list > > Linaro-uefi(a)lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-uefi > > > > > > _______________________________________________ > Linaro-uefi mailing list > Linaro-uefi(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-uefi

10 years, 9 months

Fwd: [PATCH] uefi-build: update TOOLCHAIN configuration

by Ryan Harkin

Hi Leif, So, speaking to Olivier yesterday, I worked out what he meant about using GCC48 these days. I've taken his ideas and added them to the uefi-build.sh script locally and tested them. Patch below. You mentioned that you'd rather just use "GCC". Generally, I agree with you. The definitions for GCC44 through to GCC48 are currently the same anyway. However, there are no definitions for plain old GCC, so tools_def.template would need hacking again. In the meantime, with the absence of GCC hacks, do you see any problems with my patch? Olivier, One big problem I see with the differing toolchains is that the output dir changes every time I build with a different toolchain. I can't really see an advantage to having different sub-dirs for each toolchain. I really don't believe we'll build the same BSP with more than one toolchain without cleaning the repo first. At least, I reckon you'd be mad to to not clean first ;-) Do you see a use-case for having the toolchain naming in the output dir name? If not, how on earth would we hack the codebase so it just outputs to DEBUG/RELEASE instead? Cheers, Ryan. ------------------------------------------------------------ [PATCH] uefi-build: update TOOLCHAIN configuration Using ARMGCC vs ARMLINUXGCC causes various problems. Switching to GCC4x causes other problems, but seems cleaner than either of the previous two options. Signed-off-by: Ryan Harkin <ryan.harkin(a)linaro.org> --- uefi-build.sh | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/uefi-build.sh b/uefi-build.sh index f376496..5cf38ca 100755 --- a/uefi-build.sh +++ b/uefi-build.sh @@ -81,15 +81,41 @@ function build_platform TARGETS=( RELEASE ) fi + if [ "$TOOLCHAIN" == "" ]; then + gcc_version=$(${CROSS_COMPILE}gcc -v 2>&1 | tail -1 | awk '{print $3}') + case $gcc_version in + 4.6.*) + export TOOLCHAIN=GCC46 + export GCC46_ARM_PREFIX=$CROSS_COMPILE + export GCC46_AARCH64_PREFIX=$CROSS_COMPILE + ;; + 4.7.*) + export TOOLCHAIN=GCC47 + export GCC47_ARM_PREFIX=$CROSS_COMPILE + export GCC47_AARCH64_PREFIX=$CROSS_COMPILE + ;; + 4.[8-9].*) + export TOOLCHAIN=GCC48 + export GCC48_ARM_PREFIX=$CROSS_COMPILE + export GCC48_AARCH64_PREFIX=$CROSS_COMPILE + ;; + *) + echo "Unsupported toolchain" + exit 1 + ;; + esac + fi + echo "TOOLCHAIN=$TOOLCHAIN" + for target in "${TARGETS[@]}" ; do if [ X"$PLATFORM_PREBUILD_CMDS" != X"" ]; then echo "Run pre build commands" eval ${PLATFORM_PREBUILD_CMDS} fi if [ X"$PLATFORM_BUILDCMD" == X"" ]; then - echo CROSS_COMPILE="$TEMP_CROSS_COMPILE" build -a "$PLATFORM_ARCH" -t ARMGCC -p "$PLATFORM_DSC" -b "$target" \ + echo CROSS_COMPILE="$TEMP_CROSS_COMPILE" build -a "$PLATFORM_ARCH" -t ${TOOLCHAIN} -p "$PLATFORM_DSC" -b "$target" \ ${PLATFORM_BUILDFLAGS} - CROSS_COMPILE="$TEMP_CROSS_COMPILE" build -a "$PLATFORM_ARCH" -t ARMGCC -p "$PLATFORM_DSC" -b "$target" \ + CROSS_COMPILE="$TEMP_CROSS_COMPILE" build -a "$PLATFORM_ARCH" -t ${TOOLCHAIN} -p "$PLATFORM_DSC" -b "$target" \ ${PLATFORM_BUILDFLAGS} else ${PLATFORM_BUILDCMD} -b "$target" ${PLATFORM_BUILDFLAGS} @@ -115,7 +141,6 @@ function uefishell esac export ARCH echo "Setting up shell for building UEFI" - export TOOLCHAIN=ARMGCC export EDK_TOOLS_PATH=`pwd`/BaseTools . edksetup.sh BaseTools make -C $EDK_TOOLS_PATH -- 1.8.3.2

10 years, 9 months

[WIKI]How to boot Xen with GRUB on AArch64 FVP_base model

by Fu Wei

Hi all, I have written a simple wiki about "boot Xen with GRUB on AArch64 FVP_base model", the link is below: https://wiki.linaro.org/LEG/Engineering/Grub2/Xen_booting_on_FVP_Base_AEMv8A It is a draft, I will go on improve it. If you have any thought or suggestion, Please let me know, I will improve it ASAP. 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

Re: [Linaro-uefi] Any plans to support GICv3 on UEFI

by Ganapatrao Kulkarni

Thanks Olivier. Can you please share the early version? Ganapat On Mon, Mar 17, 2014 at 11:17 PM, Olivier Martin <olivier.martin(a)arm.com> wrote: > I started to work on a UEFI GICv3 driver last year. It is almost working but > I had to switch to higher priority tasks since then. > I have the plan to clean and publish this driver soon. I would say by then > of April, but I do not want to commit to any date. > If it is blocking you then I can send an early version of the patch. > > Olivier > >> -----Original Message----- >> From: linaro-uefi-bounces(a)lists.linaro.org [mailto:linaro-uefi- >> bounces(a)lists.linaro.org] On Behalf Of Ganapatrao Kulkarni >> Sent: 15 March 2014 06:58 >> To: Leif Lindholm >> Cc: linaro-uefi(a)lists.linaro.org >> Subject: Re: [Linaro-uefi] Any plans to support GICv3 on UEFI >> >> Thanks Leif >> >> On Sat, Mar 15, 2014 at 12:31 AM, Leif Lindholm >> <leif.lindholm(a)linaro.org> wrote: >> > Hi Ganapat, >> > >> > On Fri, Mar 14, 2014 at 08:01:34PM +0530, Ganapatrao Kulkarni wrote: >> >> I am using git://git.linaro.org/uefi/linaro-edk2.git and i see the >> >> comments saying >> >> /* Initialize GICv3 to expose it as a GICv2 as UEFI does not support >> >> GICv3 yet */ >> >> >> >> Anyone is working/plan to add GICv3 driver? >> > >> > This is part of the architectural support, and pulled in that way >> > from Tianocore. It supports using a GICv3 in "legacy" GICv2 mode. >> > >> > I expect ARM will provide a non-legacy GICv3 driver at some point, >> > but I do not know the exact roadmap. >> > >> > Regards, >> > >> > Leif >> >> _______________________________________________ >> Linaro-uefi mailing list >> Linaro-uefi(a)lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-uefi > > > >

10 years, 9 months

Any plans to support GICv3 on UEFI

by Ganapatrao Kulkarni

Hi, I am using git://git.linaro.org/uefi/linaro-edk2.git and i see the comments saying /* Initialize GICv3 to expose it as a GICv2 as UEFI does not support GICv3 yet */ Anyone is working/plan to add GICv3 driver? thanks, Ganapat

10 years, 9 months

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-uefi