Hi Alexander,
On Tue, 16 Oct 2018 15:04:26 +0200 Alexander Graf agraf@suse.de wrote:
...
Glancing at cmd/pxe.c, there is a problem though, in that if ${fdt_addr_r} were defined, a PXE file using the FDTDIR directive would attempt loading a dtb file named "<NULL>-qemu-arm.dtb" instead of falling back to using ${fdt_addr}. That bug would need to be fixed first before applying this patch.
Well, and that load will fail and everyone's happy, no?
No, because currently if DTB loading from the filesystem/tftp is attempted and it fails, it aborts the boot. It doesn't matter if it's via a 'FDT' or 'FDTDIR' directive. In the case of typical hardware that's probably the desired behaviour.
I guess the qemu_arm + FDTDIR case can be fixed by not attempting a .dtb load if the default fdtfile is not known due to $soc or $board being unset. At least I doubt that some other board could be relying on a filename containing literally "<NULL>" :)
IMHO we should fall back to $fdtcontroladdr always
FWIW, to me the idea of passing $fdtcontroladdr to the OS has always filled me with dread. On top of the usual backwards- and forwards-compatibility problems that happen when mixing and matching kernels and DTBs from different releases, you now have to deal with issues like U-Boot specific .dts that are majorly diverged from Linux ones, or where the .dts is otherwise from Linux but the U-Boot specific additions break it for Linux, or where the .dts used is wrong for the specific hardware revision but close enough for U-Boot's purposes, and so on...
- Tuomas