07-30-2020 09:13 AM - edited 07-30-2020 09:17 AM
Out team has been working on basing a product on the ZCU106, and we've been using the qemu emulator shipped with the PetaLinux SDK as one of our development tools.
Due to specific peripheral requirements we decided to build our own fork of the Xilinx fork of qemu. The customization for our fork are still in planning, so we are effectively only running our own unmodified build of Xilinx's qemu fork. Up until now we have been basing our software on the v2019.2 meta-xilinx and meta-xilinx-tools Yocto layers and we are in the process of migrating to v2020.1. We wanted to migrate to the v2020.1 branch of Xilinx qemu, however we have been running into a problem.
Our build of the v2019.2 branch of xilinx qemu works well with our software based on the v2019.2 meta-xilinx and meta-xilinx-tools layers, however if we try to run our own build of the v2020.1 branch of xilinx qemu with v2020.1 meta-xilinx and meta-xilinx-tools layers, we run into two problems; The boot stalls during the ATF->U-Boot handoff or if we use the v2019.2 ATF, PMU, and U-Boot binaries the kernel boots but ends up stalling sometime after console or DMA initialization (the point at which the kernel stalls appears to be random).
Has anyone else here experienced this problem or something similar for the v2020.1 release? If so, has anyone found any workarounds? I've attached boot logs for both scenarios described.
- Brian M.
08-06-2020 07:45 AM
I quickly checked the ZCU106 BSP with Petalinux 2020.1 and QEMU booted to u-boot with the pre-built images. This suggests there's nothing wrong with the release itself. I also booted to Linux w/o issues.
I suggest trying a reference Yocto build for the ZCU106 using all vanilla Xilinx repos (firmware & meta-layers) tagged at 2020.1. Effectively re-build the default BSP. This should boot and provide a baseline to compare against. It could help identify something in your own build that's become out-of-sync between 2019.2 and 2020.1. There are a lot dependencies between FSBL/PMU-W/ATF/u-boot and no guaranteed backwards compatibility so it's important to keep all that code in sync. And in this case that extends to the kernel as well since the version changed between 2019.x and 2020.x.
09-01-2020 07:26 AM
We determined that adding "cpuidle.off=1" to the kernel command-line solved the issue for us, in QEMU. But it's not clear what side-effects this might have if included on actual hardware. Any insight?
09-03-2020 06:13 AM
That disables a Linux power management feature. On hardware it's common to do this for debug to prevent Linux from idling CPUs while debugging (i.e. interfacing of JTAG). But by default it should be on for improved power management.