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-boun...@yoctoproject.org <meta-xilinx-boun...@yoctoproject.org> on behalf of Martin Lund <m...@gomspace.com> Sent: Wednesday, May 9, 2018 3:55:13 PM To: Andreas Galauner; meta-xilinx@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-boun...@yoctoproject.org <meta-xilinx-boun...@yoctoproject.org> on behalf of Andreas Galauner <andr...@galauner.de> Sent: Monday, May 7, 2018 3:56:27 PM To: meta-xilinx@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
pmu-firmware_2018.1.bb
Description: pmu-firmware_2018.1.bb
-- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
