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

[Luca Ceresoli]

Hi,

On 07/05/2018 15:43, 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.
>>
>> 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
> +++Bye
> 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                                                                                                             
>  made it
>       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 noticed this thread only now...

The patch was originally for zcu106, Michal Simek (Xilinx) later applied
it for all boards.

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

As per the commit message, you need to pass '-O arm-trusted-firmware' or
it won't trigger the ATF boot path. And yes, this avoids the need for
the Falcon mode hack.

I definitely tested it on zcu106 and it works. I assume Xilinx tested it
internally on the other boards before publishing it. I didn't test this
with yocto, but it's working in the zcu106 patches I sent to Buildroot
[0] [1]: as you can see there's not much magic there.

About your problem, sorry, I have no idea where it comes from. But
apparently Andreas Galauner has a solution. :)

[0] https://patchwork.ozlabs.org/project/buildroot/list/?series=42394
[1] https://github.com/lucaceresoli/buildroot/tree/luca/zcu106

Regards,
-- 
Luca