[U-Boot] [PATCH 2/2] ARM: qemu-arm: define fdt_addr_r

[Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>]

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