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

[Alexander Graf]

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.

> 
>> 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.

> 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.

> 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.

> 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 ;)


Alex