Petalinux 2020.1 build project does not flash on ZCU 102 Rev1.1, but does on Rev1.0

[peta_n00b]

I'm transitioning a 2019.2 Petalinux project to a 2020.1 one in order to run the project on the ZCU102 rev1.0 and 1.1s. I obtained a hardware description .xsa built by a colleague that was built from the same source for our 2019.2 project. I've copied the configurations from that project into a new one, including a custom amba_pl definition in my system-user.dtsi file:

  9     amba_pl: amba_pl@0 {
 10         #address-cells = <1>;
 11         #size-cells = <1>;
 12         compatible = "simple-bus";
 13         ranges ;
 14 
 15         M_AXI_HPM0_LPD: M_AXI_HPM0_LPD@80000000 {
 16             compatible = "generic-uio";
 17             reg = <0x80000000 0x1000000>;
 18         };

When attempting to build the petalinux project, I got the following error about not finding the amba_pl node:

Failed to find amba_pl node !!!
ERROR: [Hsi 55-1545] Problem running tcl command ::sw_device_tree::generate : Failed to find amba_pl node !!!

I found this forum post which suggested using a patch to bypass the AXI bus generation. While applying the patch did successfully build the project, the built images cause my rev1.1 boards to not boot (no boot stream at all). The rev1.0 boards successfully boot and I'm able to access the registers defined by the system-user.dtsi file.

Is there another method I'm to use to successfully build with a custom XSA file to support both ZCU102 Rev1.0s and Rev1.1s? My current guess is that bypassing the AXI bus generation is not what I want and that my project now does not see my system-user.dtsi device tree definitions.

[peta_n00b]

I was able to bypass applying the patch using the following configs:

CONFIG_SUBSYSTEM_DEVICETREE_FLAGS=""

#CONFIG_SUBSYSTEM_DTB_OVERLAY is not set

CONFIG_SUBSYSTEM_REMOVE_PL_DTB=y

The system still won't boot on rev1.1, so there must be something else. I was able to boot on both systems using the Xilinx provided XSA file, will compare mine with that.

[peta_n00b · Accepted solution]

We were able to resolve this issue by digging into the FSBL source. In this post (https://www.xilinx.com/support/answers/71961.html), it details how the FSBL is meant to check the SPD of the SODIMM to determine if its the older or newer part and configure it appropriately. By examining our project in Vitis and comparing its FSBL application code to the Xilinx 2020 zcu102 BSP project, we found that our project was missing some ifdef's that enabled this behavior. Likely this is due to our project being originally from 2018.2 (right before the FSBL change) and for some reason the source code wasn't re-generated when we ported the project.

Ultimately we needed to use a fresh 2020 project and port over all of our project configurations to enable booting on the 1.1 boards. While annoying, we were able to resolve this issue.

Hope this helps anyone who runs across a similar issue in the future.