Mismatch in device-tree found by U-Boot and deployed

Question

We are currently in the process of migrating a yocto project from whatever is compatible with Xilinx v2020.2 to whatever is compatible with Xilinx v2022.2. One particular problem is the mismatch between the device-tree deployed by the yocto and the device-tree name in the uEnv.txt:

In the deployed uEnv.txt, the following lines appear:

...
devicetree_image=system-top.dtb
...
loaddtb=fatload mmc ${devnum} ${devicetree_load_address} ${devicetree_image}
...
bootkernel=... && loaddtb && booti ...

So U-Boot tries to load a device-tree named system-top.dtb. However, this device-tree does not exist as is evident by looking at the content of the SD-Card:

ZynqMP> ls mmc 0:1
 21092864   Image
    57479   system.dtb
 36131600   BOOT.bin
      653   uEnv.txt
     4045   boot.scr
      214   boot.md5

I have found out that the mismatch is due to the u-boot-zynqmp-uenv recipe:

def uenv_populate(d):
    # populate the environment values
    env = {}

    ...
    env["devicetree_image"] = boot_files_dtb_filepath(d)
    ...

    return env

The function boot_files_dtb_filepath gets the name system-top.dtb, because this is the first name that appears in the IMAGE_BOOT_FILES variable:

$ bitbake-getvar IMAGE_BOOT_FILES
...
IMAGE_BOOT_FILES="Image u-boot.bin devicetree/*.dtb zynqmp-zcu111-revA.dtb              uEnv.txt          atf-uboot.ub             system.dtb              boot.scr                "

The contents of deploy/devicetree/*.dtb are only system-top.dtb.

I'm not sure what other information to include here as the system is very convoluted. But I will update if more information is needed.

What is the correct way to specify the device-tree that U-Boot should use? Relying on the first entry of the IMAGE_BOOT_FILES variable doesn't seem to be a solid choice as there are at least three different dab files in there.

Answer 1

Turns out that the problem was at an entirely different place. When flashing the SD-Card, we have a script that essentially does something like

cp $DEVICETREE_IMAGE $FLASH_TARGET_DIR/system.dtb

where system.dtb is hard-coded. In the process of the migration, the name of the device-tree blob changed but it was still hard-coded to system.dtb. Simply changing this to system-top.dtb resolved the issue (though a more robust solution would obviously be advantageous)