[meta-xilinx] rel-v2018.1 / zcu102-zynqmp: U-boot crashes with error "fdt_root: FDT_ERR_BADMAGIC"

Martin Lund malu at gomspace.com
Wed May 9 06:55:13 PDT 2018


Hi Andy,

Thank you for your patches - good stuff.

I have applied your xlnx.patch succesfully on the u-boot xilinx-v2018.1 branch.

I have also added your .bb changes to u-boot-xlnx_2018.1.bb which seems to result in a valid u-boot.itb:


$ mkimage -l build/tmp/deploy/images/zcu102-zynqmp/u-boot.itb
FIT description: FIT image with U-Boot proper, ATF bl31, DTB
Created:         Wed May  9 14:33:54 2018
 Image 0 (uboot)
  Description:  U-Boot (64-bit)
  Created:      Wed May  9 14:33:54 2018
  Type:         Standalone Program
  Compression:  uncompressed
  Data Size:    unavailable
  Architecture: AArch64
  Load Address: 0x08000000
  Entry Point:  unavailable
 Image 1 (atf)
  Description:  ARM Trusted Firmware
  Created:      Wed May  9 14:33:54 2018
  Type:         Firmware
  Compression:  uncompressed
  Data Size:    unavailable
  Architecture: AArch64
  Load Address: 0xfffea000
 Image 2 (fdt)
  Description:  ZynqMP flat device-tree
  Created:      Wed May  9 14:33:54 2018
  Type:         Flat Device Tree
  Compression:  uncompressed
  Data Size:    unavailable
  Architecture: Unknown Architecture
 Default Configuration: 'conf'
 Configuration 0 (conf)
  Description:  Xilinx ZynqMP board with ATF, main u-boot and dtb
  Kernel:       unavailable
  FDT:          fdt
  Loadables:    uboot



However, it seems it is still getting stuck when jumping to the ATF:


<debug_uart> Debug uart enabled

U-Boot SPL 2018.01 (May 09 2018 - 14:17:05)
EL Level:       EL3
Trying to boot from MMC1
reading u-boot.itb
reading u-boot.itb
reading u-boot.itb
reading u-boot.itb
reading u-boot.itb
Board_fit_config_name_match: Xilinx ZynqMP board with ATF, main u-boot and dtb
Selecting config 'Xilinx ZynqMP board with ATF, main u-boot and dtb'board_fit_config_name_match: Xilinx ZynqMP board with ATF, main u-boot and dtb
Selecting config 'Xilinx ZynqMP board with ATF, main u-boot and dtb'loadables: 'uboot'
board_fit_config_name_match: Xilinx ZynqMP board with ATF, main u-boot and dtb
Selecting config 'Xilinx ZynqMP board with ATF, main u-boot and dtb'no string for index 1
Jumping to U-Boot via ARM Trusted Firmware
spl_fit_images_get_entry: entry point 0x8000000

At this point it has crashed looping in the reset vector at 0xfffea928 again.


I have to trace the code path more - perhaps it is jumping to the wrong address when jumping to the ATF entry point. I don't know why that would be the case though, the fit configuration looks pretty straightforward.


/Martin


________________________________
From: meta-xilinx-bounces at yoctoproject.org <meta-xilinx-bounces at yoctoproject.org> on behalf of Andreas Galauner <andreas at galauner.de>
Sent: Monday, May 7, 2018 3:56:27 PM
To: meta-xilinx at yoctoproject.org
Subject: Re: [meta-xilinx] rel-v2018.1 / zcu102-zynqmp: U-boot crashes with error "fdt_root: FDT_ERR_BADMAGIC"

On 07.05.2018 12:23, Martin Lund wrote:
> Inspired by your last post I tried adding an #undef CONFIG_ARM64 in
> arch/arm/lib/spl.c to force it to jump to the ATF without dropping to
> EL2 first. That is, to try to mimic the old hacky way of booting the ATF.
>
> Unfortunately this hack seems to be insufficient as it gets stuck at
> address 0xfffea928 so I assume the ATF has crashed ending up in a reset
> vector - probably because some preconditions not being fulfilled.

Yes, it's missing the handoff data and complains by panicing there.


> In the end, perhaps the best way forward is to try use the new ATF
> framework in u-boot but as you point out the information is sparse on
> that point.
>
> Hopefully someone out there can provide us with the missing information
> so that we can get the zynqmp booting without using the horrible xilinx
> toolchain.

I made it work. I have it working in the current mainline git HEAD of
u-boot and the xilinx fork.

I only tested it on an Ultrazed so far, because that is the only ZynqMP
board I have. Also, it's really bare bones. Still no BL32 support etc.

With the mainline u-boot, I didn't boot Linux yet, because I was too
lazy to write a proper boot script. This one contains a different
environment compared to the Xilinx fork. The xilinx fork works and boots
Linux.

Another problem is building a FIT image containing u-boot, ATF and the
DTB from within yocto. You can specify a .its file for this, but this
mechanism breaks when you build u-boot with yocto, because this feature
totally doesn't like the build dir to be different from the source dir
because relative paths are used in this file.
I have two hacks in place in the u-boot Makefile itself and the u-boot
yocto recipe, because I couldn't find a better way how to deal with it.
This should be looked at before it is upstreamed. I couldn't find an
easy general solution to this.

Both patches are attached.
Now, where would I upstream something like this? Mainline u-boot? If
somebody wants to take care of that, please go ahead.

For your boards (ZCU102 etc.), you need to change the u-boot defconfig
slightly:
CONFIG_SPL_OS_BOOT needs to be off
CONFIG_SPL_ATF_NO_PLATFORM_PARAM needs to be on
and
CONFIG_SPL_FIT_SOURCE="board/xilinx/zynqmp/fit_spl_atf.its"

That should be it. In your bitbake recipe (or bbappend) for the u-boot,
add the patch and these lines:

> # Copy the ATF BL31 into the u-boot source directory
> do_compile_zynqmp[depends] += "arm-trusted-firmware:do_deploy"
> do_compile_prepend_zynqmp() {
>         cp ${DEPLOY_DIR_IMAGE}/arm-trusted-firmware.bin ${B}/bl31.bin
>
>         #Fix paths in zynqmp its file for u-boot. This is a hack but works for now
>         sed -i -e 's#../../../#../../../../build/#g' ${S}/board/xilinx/zynqmp/fit_spl_atf.its
> }
>
> # Hack to build itb file instead of bin
> UBOOT_SUFFIX = "itb"
> UBOOT_BINARY = "u-boot.itb"
> UBOOT_MAKE_TARGET = "all u-boot.itb"

After that do a clean build and you should have a boot.bin with the SPL
+ PMUFW and a u-boot.itb containing ATF, u-boot and the appropriate DTB.

- Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20180509/f027e61d/attachment.html>


More information about the meta-xilinx mailing list