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: [email protected] <[email protected]> on behalf of Andreas Galauner <[email protected]> Sent: Monday, May 7, 2018 3:56:27 PM To: [email protected] 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
-- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
