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

[Martin Lund]

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


Short follow up  - I tried enabling the new u-boot SPL ATF framework in u-boot-xlnx (xilinx-v2018.1) by enabling CONFIG_SPL_ATF and I also applied the following patch to meta-xilinx to produce a valid atf-boot.ub of type "AArch64 ARM Trusted Firmware Kernel Image (uncompressed)":

diff --git a/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc b/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
index 7f13507..2f1343e 100644
--- a/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
+++ b/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
@@ -59,7 +59,7 @@ do_deploy() {

        # Get the entry point address from the elf.
        BL31_BASE_ADDR=$(${READELF} -h ${OUTPUT_DIR}/bl31/bl31.elf | egrep -m 1 -i "entry point.*?0x" | sed -r 's/.*?(0x.*?)/\1/g')
-       mkimage -A arm64 -O linux -T kernel -C none \
+       mkimage -A arm64 -O arm-trusted-firmware -C none \
                -a $BL31_BASE_ADDR -e $BL31_BASE_ADDR \
                -d ${OUTPUT_DIR}/bl31.bin ${DEPLOYDIR}/${ATF_BASE_NAME}.ub
        ln -sf ${ATF_BASE_NAME}.ub ${DEPLOYDIR}/${PN}.ub


However, using the new SPL ATF framework, it crashes in the exact same way as with my attempt trying to boot it the old hacky way.

The last thing I see with u-boot debug enabled is:
"Jumping to U-Boot via ARM Trusted Firmware"

and then it gets stuck at the same reset vector:

xsct% stop
Info: Cortex-A53 #0 (target 9) Stopped at 0xfffea928 (External Debug Request)

xsct% rrd
      r0: 00000000ff300004        r1: 0000000000010000
      r2: 0000000000010000        r3: 00000000ff300000
      r4: 000000000000000c        r5: 00000000ff990400
      r6: 00000000ff9905d8        r7: 0000000000000188
      r8: 00000000ffff7c90        r9: 00000000fffea09c
     r10: 00000000ffff08e8       r11: 0000000000000006
     r12: 000000000001869f       r13: 000000000000000c
     r14: 000000000000000a       r15: 00000000ffffffff
     r16: 280c860380080c00       r17: 00000000ffff07b8
     r18: 0000000000000004       r19: 00000000ffffe000
     r20: 00000000ffff6b98       r21: 00000000ffff6c08
     r22: 00000000ffff26a0       r23: 0000000000000002
     r24: 00000000fffda84e       r25: 00000000fffe0000
     r26: 00000000deadbeef       r27: 81cf122302800303
     r28: 82019000260d0c12       r29: 00000000ffff6b30
     r30: 00000000fffecf94        sp: 00000000ffff6b30
      pc: 00000000fffea928      cpsr:         000002cc
     vfp                         sys
acpu_gic

xsct% bt
    0  0xfffea928
    1  0xfffecf94
    2  0xfffed0b4
    3  0xfffeb364
    4  0xffff05d0
    5  0xfffea2a8
    6  0xfffea0a8
    7  0x60000000

I suspect it might be an issue with the atf-uboot.ub but I'm not sure.


Recently Xilinx have been working on enabling the new u-boot ATF framework as they have signed-off on this patch:
https://github.com/Xilinx/u-boot-xlnx/commit/949e5cb9a736bac32ea8886e3953da55bdd30754#diff-96969e0a4f8df761977a2ba066314ed3

I assume Xilinx tested this feature - it would be great if Xilinx could disclose the details on how to get the new u-boot SPL ATF framework working with the xilinx v2018.1 release on the zcu102 board. Perhaps we are missing some important detail or patch.


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