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

[Simon Glass]

Hi Peter,

On Mon, 27 Sept 2021 at 10:50, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Mon, 27 Sept 2021 at 17:04, Simon Glass <sjg@chromium.org> wrote:
> > On Mon, 27 Sept 2021 at 09:46, Peter Maydell <peter.maydell@linaro.org> 
> > wrote:
>
> > > 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.
> >
> > Well this is how U-Boot works. Since it doesn't have a user-space
> > program to provide configuration / policy, nor a command line to
> > provide parameters (except with sandbox[1]), device tree is what it
> > uses. All of its driver model and configuration comes from there The
> > 'describe the hardware' thing has been discussed to death but U-Boot
> > needs board- and arch-specific policy information about the hardware
> > so it can actually boot successfully on real systems.
> >
> > It has been like this since U-Boot started using device tree, some 9
> > years ago! I can't imagine it changing.
>
> > As to a separate blob, isn't that what I am suggesting with this
> > patch? QEMU doesn't support passing two separate dtb blobs to U-Boot,
> > nor is there an API for that.
>
> You're suggesting "QEMU should have machinery for taking two
> blobs and combining them and passing one blob to the guest".
> I'm suggesting "the guest should combine them" (and the second
> blob could be provided via several different existing mechanisms
> that amount to 'QEMU provides some ways to load data into guest
> ROM or RAM'), because as far as I know no other guest has this
> "combine two different bits of dtb for me" requirement.

I think you are misunderstanding my patch and that may be the problem here.

Where QEMU is provided with a dtb (-dtb) it uses that and passes it
on. This is absolutely fine and I have tested that this works well
with U-Boot. No issues.

Where QEMU creates its own dtb on the fly the -dtb parameter is
actually ignored and there is no way to adjust what QEMU passes on,
without recompiling QEMU. It is quite inflexible, actually. Even just
creating a new device for development purposes is not possible. That
is the problem I am trying to solve.

There is certainly no intent to combine two bits of dtb with my patch.
We could easily do that externally to QEMU.

The only current working option is to just pass the U-Boot dtb through
and not use QEMU's on-the-fly-generated dtb at all. But I am assuming
there is a reason why QEMU generates that dtb, so that would not be
desirable?

>
> > Even if we did that it would require
> > code very early in U-Boot to process, which would make it infeasible
> > for anything other than QEMU. Ideally QEMU should work the same way as
> > other boards.
>
> Well, real hardware doesn't provide device tree blobs of any
> form to u-boot, right? u-boot is just compiled into flash, or
> perhaps launched from some other boot ROM, as I understand it.
> Where does it get its dtb from then ?

The dtb is compiled as part of the U-Boot build. but exists as a
separate file. The mechanism for providing the dtb to U-Boot at
runtime is somewhat board-specific and we are working on standardising
it more. On the rpi for example, it is provided by a FAT file system
and first-stage firmware loads that and passes it along to U-Boot.
Some systems use TF-A which does a similar thing. Some use U-Boot as a
first-stage loader in which case SPL may select a DTB (out of many
built by the build) to pass to U-Boot proper.

There is also a tool called binman which packages the firmware as it
is getting quite complicated:

https://u-boot.readthedocs.io/en/latest/develop/package/binman.html

>
> > As a related point, I am looking at how we pass things between
> > firmware components.  If we wanted to pass in some initiate state in
> > some sort of blob, is it possible to set that up in memory (along with
> > the binary) for when QEMU starts emulating? The code and RAM might be
> > quite a long way apart so using a single image would involve a lot of
> > zeroes.
>
> The generic-loader is quite good for this sort of thing:
> https://qemu-project.gitlab.io/qemu/system/generic-loader.html
> You can load raw data files to specific addresses; or you can
> load ELF files (which can have multiple segments which get loaded
> as the ELF header specifies). You can specify -device generic-loader,...
> as many times as you need to to load multiple blobs.

OK great, thank you, that looks very useful.

One more question...other than dtb, does QEMU typically add support
for data structures needed by particular projects or groups of
projects? It looks like dtb was supported for ARM Linux originally? I
am looking at supporting bloblist as a way of communicating
information between firmware (basically a simple way of packaging
multiple blobs).

https://github.com/ni/u-boot/blob/master/doc/README.bloblist

Regards,
Simon