Re: Usage of device-tree for blobs

[Simon Glass <sjg@chromium.org>]

Hi Mark,

On Thu, 26 Aug 2021 at 14:27, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Simon Glass <sjg@chromium.org>
> > Date: Thu, 26 Aug 2021 14:00:12 -0600
> >
> > Hi Mark,
> >
> > On Thu, 26 Aug 2021 at 06:55, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > From: Simon Glass <sjg@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@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?!
>
> I actually invents them.  See the mail I just sent for a reference to
> the code.

OK I see.

>
> > > 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.
>
> Discoverability of what?

Devices that are available / used on the board.

>
> > > 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.
>
> Well, I think U-Boot by its very nature is a giant hack ;).

I'm not even sure where to go with that one...

>
> > 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.
>
> Well, having a generic API will be hard.  It will depend on the
> low-level firmware.  On RISC-V the SBI specification defines such an
> API.  For the Apple M1 I just use the existing code that makes U-Boot
> look like a Linux kernel and use the same API that is used to pass the
> DTB to the kernel.  The Raspberry Pi code does something similar.  In
> the end it just boils down to passing a pointer to the DT in a
> specific register.

Yes that's what I'm talking about. if RISC-V does it, great. Perhaps
ARM can also?

Regards,
Simon