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

[Tuomas Tynkkynen]

On Thu, 18 Oct 2018 09:25:04 +0200
Alexander Graf <agraf at suse.de> wrote:

> On 18.10.18 00:25, Tuomas Tynkkynen wrote:
> > Hi Alexander,
> > 
> > On Tue, 16 Oct 2018 15:04:26 +0200
> > Alexander Graf <agraf at 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>" :)  
> 
> Well - IIRC $soc and $board should also always be defined ;). So yet
> another thing to fix in the QEMU port.

As far as I know $soc is only used for computing the default $fdtfile,
but we explicitly don't want to compute one for qemu_arm.

> >   
> >> 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  
> 
> That's something that we seriously as a community need to get sorted
> out. We're pushing hard for it in the EBBR context. The fact that
> people are afraid of putting *hardware desciption* into their
> firmware is just mind boggling.

But until/if that is solved anyone trying to rely on $fdtcontroladdr
will get burned, or at least that's what the experience for sunxi
sounds like where stuff like adding new regulators to DT breaks  
old kernels that lack the regulator driver. (And where the proposed
solution to that was some hack that just uses fixed regulators instead,
throwing the hardware description aspect out the window).

And it doesn't look like an isolated situation, you'd have got equally
hosed e.g when RPi switched to using the sdhost IP in place of the
other MMC controller, or when Tegra landed USB3 driver support thus
switched the .dts to using the XUSB controllers over the USB2 ones.

> > 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  
> 
> These case should really be the minority. And if you see those, please
> fix them.

Well, for the case of Tegra124, being able to use a recent
unmodified .dts from Linux for U-Boot would require writing an USB3
driver in order to not break USB functionality. That's not exactly a
simple fix.

> > additions break it for Linux, or where the .dts used is wrong for
> > the  
> 
> I've never seen a case where a U-Boot addition broke the DT for Linux.
> 

See e.g. 96a82d33f8c5bd3e90098b540349b7b9e43e27da fixing such instances.

> > specific hardware revision but close enough for U-Boot's purposes,
> > and so on...  
> 
> Again, something that just needs fixing. Device trees belong to the
> entity that knows hardware, not to the OS. Otherwise you lose the
> abstraction layer that DT gives you and you lose the ability to run
> "generic" kernels. And of course you break the ecosystem, because now
> good luck running BSD, your own little toy OS, etc ;)
> 

It's been possible to make generic images using the U-Boot distro stuff
(where U-Boot knows just the .dtb filename to load from the ones
installed by kernel's `make dtbs_install`) for over three years now.

Sure it doesn't fulfill the "DT doesn't belong to the OS" goal... but
given that features (incl. DT bindings) get developed in vendor kernels
first but upstream won't typically accept then unchanged, having a
single .dtb that satisfies both has been a logical impossibility so far.

- Tuomas