Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree

[Peter Maydell <peter.maydell@linaro.org>]

On Mon, 27 Sept 2021 at 16:18, Simon Glass <sjg@chromium.org> wrote:
> On Mon, 27 Sept 2021 at 02:48, Peter Maydell <peter.maydell@linaro.org> wrote:
> > So what is missing in the QEMU-provided DTB that it needs?
>
> Quite a lot. Here are some examples:
>
> U-Boot has limited pre-relocation memory so tries to avoid
> binding/probing devices that are not used before relocation:
>
> https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#pre-relocation-support

It's up to u-boot to decide what it wants to touch and
what it does not. QEMU tells u-boot what all the available
devices are; I don't think we should have extra stuff saying
"and if you are u-boot, do something odd".

> There is a configuration node (which is likely to change form in
> future releases, but will still be there)
>
> https://github.com/u-boot/u-boot/blob/master/doc/device-tree-bindings/config.txt

I think u-boot should be storing this kind of thing somewhere
else (e.g. as part of the binary blob that is u-boot itself,
or stored in flash or RAM as a separate blob).

> Then there are various features which put things in U-Boot's control
> dtb, such as verified boot, which adds public keys during signing:
>
> https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L135
>
> More generally, the U-Boot tree has hundreds of files which add
> properties for each board, since we try to keep the U-Boot-specific
> things out of the Linux tree:
>
> $ find . -name *u-boot.dtsi |wc -l
> 398

If any of this is actual information about the hardware then you
should sort out getting the bindings documented officially
(which I think is still in the Linux tree), and then QEMU can
provide them.

> Quite a bit of this is to do with SPL and so far it seems that QEMU
> mostly runs U-Boot proper only, although I see that SPL is starting to
> creep in too in the U-Boot CI.
>
> So at present QEMU is not able to support U-Boot fully.

My take is that this is u-boot doing weird custom things with
the DTB that aren't "describe the hardware". You should be able
to boot u-boot by putting those custom DTB extra things in a
separate blob and having u-boot combine that with the
actual DTB when it starts.

-- PMM