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

Tue May 15 05:01:05 PDT 2018

Hi,

I've been debugging some more and I can confirm that it jumps successfully to the ATF but the ATF crashes before it writes anything to the uart, such as its usual version notice information.

Debugging the ATF I've found that it crashes trying to retrieve the chip id via the pm_get_chipid() call in plat/xilinx/zynqmp/aarch64/zynqmp_common.c. This call results in a request to the PMU.

This makes me think maybe something is wrong with the PMU firmware?

Further investigation reveals that the pmu-firmware defined in the rel-v2018.1 branch of meta-xilinx seems to be out of date - it still uses pmu-firmware_2017.3.bb file (see https://github.com/Xilinx/meta-xilinx/tree/rel-v2018.1/meta-xilinx-bsp/recipes-bsp/pmu-firmware) despite the fact that there is clearly a v2018.1 release available with many updates (see https://github.com/Xilinx/embeddedsw/releases/tag/xilinx-v2018.1).

Now, the big question is what happened to the meta-xilinx-bsp layer in the v2018.1 release to break a normally bootable system?

And why didn't Xilinx provide an updated pmu-firmware bb definition for the v2018.1 release in the meta-xilinx-bsp layer?

As it turns out, Xilinx are tossing things around and have introduced a new way of building the pmu-firmware but it forces/requires you to use the meta-xilinx-tools layer!

This new approach uses all the spokes and wheels of the proprietary xilinx toolchain with all sorts of cumbersome tools and components involved (xsdk, X/gtk3, xsct, tcl, yaml, etc.) which makes it quite troublesome to deploy on common build servers.

For this reason we want to avoid using meta-xilinx-tools so I tried simply upgrading the existing pmu-firmware_2017.3.bb to pmu-firmware_2018.1.bb (attached). While it builds fine the ATF software still crashes in the call to pm_get_chipid() so apparently the new PMU firmware made no difference or something is missing or broken in how the PMU firmware is built using the old approach but with updated references to new v2018.1 git version.

Also, is it even possible to use the old v2017.3 pmu-firmware with the 2018.1 released components (u-boot, kernel, etc.)?

Any thoughts?

It would be great to hear from Xilinx on this matter so we can get issue resolved and get back a functional meta-xilinx-bsp layer.

Thanks.

/Martin

________________________________
From: meta-xilinx-bounces at yoctoproject.org <meta-xilinx-bounces at yoctoproject.org> on behalf of Martin Lund <malu at gomspace.com>
Sent: Wednesday, May 9, 2018 3:55:13 PM
To: Andreas Galauner; meta-xilinx at yoctoproject.org
Subject: Re: [meta-xilinx] rel-v2018.1 / zcu102-zynqmp: U-boot crashes with error "fdt_root: FDT_ERR_BADMAGIC"

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/20180515/683af725/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pmu-firmware_2018.1.bb
Type: application/octet-stream
Size: 3608 bytes
Desc: pmu-firmware_2018.1.bb
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20180515/683af725/attachment-0001.obj>