Usage of device-tree for blobs

[Simon Glass]

Hi Mark,

On Thu, 26 Aug 2021 at 06:55, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Simon Glass <sjg at chromium.org>
> > Date: Wed, 25 Aug 2021 21:15:00 -0600
> >
> > Hi Heinrich,
> >
> > On Wed, 25 Aug 2021 at 02:05, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > >
> > > Hello Simon,
> > >
> > > some boards like qemu-riscv64_defconfig do not use any device-tree at
> > > build time. A device-tree is only supplied at runtime by the prior boot
> > > stage (CONFIG_OF_PRIOR_STAGE=y).
> > >
> > > In doc/develop/devicetree/intro.rst you suggest to put binary blobs into
> > > the device-tree.
> > >
> > > Could you, please, update the documentation to explain how adding blobs
> > > to the device-tree works in the different scenarios depending on the
> > > values of:
> > >
> > > CONFIG_OF_EMBED
> > > CONFIG_OF_SEPARATE
> > > CONFIG_OF_BOARD
> > > CONFIG_OF_HOSTFILE
> > > CONFIG_OF_PRIOR_STAGE
> > >
> > > It would be especially important to understand how one can develop a
> > > board independent feature which works for all of these settings.
> >
> > OK I will take a crack at this tomorrow.
> >
> > But I think there is a disconnect here, since the only options that
> > matter within U-Boot are OF_SEPARATE and OF_HOSTFILE, which both use a
> > u-boot.dtb file. There is nothing tricky here.
> >
> > The OF_BOARD business is for when the board does special things.
> > Presumably signing will do special things too. We cannot really know
> > what those things are because the board as 'opted out' of the standard
> > options.
> >
> > >
> > > Please, describe CONFIG_OF_PRIOR_STAGE in
> > > doc/develop/devicetree/control.rst.
> >
> > So I'm not allowed to delete that option? :-) It seems to me to be
> > extremely sparse on documentation. We need an explanation of what it
> > means and what effect it has on the build system, U-Boot and some
> > discussion of how qemu works. It seems to have been added as part of
> > an unrelated broadcom commit. The tags were incorrect so I doubt
> > anyone noticed it. Since then it has apparently proved useful
> > elsewhere, but no one has added more docs.
> >
> > So perhaps you can help me with my doc by explaining how
> > OF_PRIOR_STAGE works in qmeu, why the DT in U-Boot cannot be used, and
> > which project actually hosts the DT that qemu provides? Armed with
> > that information, I might be able to make sense of it all.
>
> Well, QEMU allows configuration of (emulated/paravirtualised) devices
> from the command line.  So it is pretty much impossible for U-Boot to
> provide a DT that matches that configuration without adding a lot of
> code the dynamically build it from some sort of configuration
> specification provided by QEMU to U-Boot.  But at that point QEMU
> might as well provide the DT itself, don't you agree?

Don't these devices have a DT in U-Boot? Is qemu enabling them (status
= "okay") or actually inventing them?!

>
> Anyway, replying to this thread since for the Apple M1 support that
> I'm working on we're in a somewhat similar situation.  The Asahi Linux
> project has implemented m1n1 as a bootloader and plans to use U-Boot
> as a "payload" to implement booting a standard Linux distribution (and
> other OSes).  In this scenario m1n1 actually provides the DT since it
> parses Apple's version of the DT (which isn't in the standard DT
> format) and adds/updates certain properties that depend on the actual
> hardware it is running on.

Yes I see. Still I'd like a basic DT in U-Boot, even if just for
discoverability.

>
> For this code I use CONFIG_OF_BOARD and implement
> board_fdt_blob_setup() to simple return a pointer to the DT that m1n1
> set up.  But that seems to be exactly what CONFIG_OF_PRIOR_STAGE
> does...

Right, and neither is really documented to the level that people can
understand the purpose. They just come across as hacks to me.

I'd like to see an API for passing a info (including DT) to U-Boot. I
think riscv has it? I suggest we use a register that points to a
bloblist.

Regards,
Simon