Hello,
When I was using U-Boot with a dart_6ul board I occasionally had fitimages that U-Boot would attempt to boot just fine, but the kernel wouldn't actually boot. Debugging found that this was correlated with the header length of the fitImage. Then I noticed this remark in doc/usage/environment.rst about fdt_high:
If this is set to the special value 0xffffffff (32-bit machines) or 0xffffffffffffffff (64-bit machines) then the fdt will not be copied at all on boot. For this to work it must reside in writable memory, have sufficient padding on the end of it for u-boot to add the information it needs into it, and the memory must be accessible by the kernel. This usage is strongly discouraged however as it also stops U-Boot from ensuring the device tree starting address is properly aligned and a misaligned tree will cause OS failures.
And indeed, fdt_high is set to 0xffffffff in the include/configs/dart_6ul.h that I was using. Since mkimage only guarantees 32-bit alignment of the device tree blob within the fitimage, and not the 64-bit alignment that Linux requires, this is basically a 50/50 coin flip. Something simple like adding a few characters to the description string in the fitimage header can make or break the alignment.
Personally I fixed this by removing the fdt_high altogether, which makes U-Boot copy the device tree to an appropriate location. I assume this only works in my situation because I only have half a GiB of RAM and therefore do not have any high memory. I can imagine my fix would be problematic for board variants with more RAM, the setting doesn't exist without a reason of course.
It looks like this issue is not limited to my board; the same usage of fdt_high can be found in many other board configs. I'm not going to suggest what the best fix is because I lack detailed knowledge, but I will pitch that perhaps omitting fdt_high by default is at least preferable to a value that is "strongly discouraged" and causes Linux boot failures somewhat arbitrarily.
Kind regards,
Tim