Hi Alexander,
On Tue, 16 Oct 2018 15:04:26 +0200
Alexander Graf <ag...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
