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

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

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.

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

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

-- PMM