[PATCH v6] fdt: Allow the devicetree to come from a bloblist

Simon Glass sjg at chromium.org
Sun Dec 31 13:47:30 CET 2023


Hi,

On Thu, Dec 28, 2023 at 2:24 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Dec 28, 2023 at 07:47:25PM +0000, Simon Glass wrote:
>
> > Standard passage provides for a bloblist to be passed from one firmware
> > phase to the next. That can be used to pass the devicetree along as well.
> > Add an option to support this.
> >
> > Tests for this will be added as part of the Universal Payload work.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> [snip]
> > diff --git a/dts/Kconfig b/dts/Kconfig
> > index 00c0aeff893..ae451b9caf7 100644
> > --- a/dts/Kconfig
> > +++ b/dts/Kconfig
> > @@ -105,6 +105,19 @@ config OF_EMBED
> >
> >  endchoice
> >
> > +config OF_BLOBLIST
> > +     bool "Provided by a bloblist at runtime"
> > +     depends on BLOBLIST && OF_SEPARATE
>
> This is now even more confusing, frankly. The help for OF_SEPARATE says:
> If this option is enabled, the device tree will be built and placed as a
> separate u-boot.dtb file alongside the U-Boot image.
>
> So why would you enable that to then have a device tree passed via
> bloblist instead?

Historical....

>
> We should probably start by fixing all of this confusing naming / logic
> and then correct things such that:
> - OF_EMBED wins if set. This is the override-has-been-set we-must-use-it
>   switch. First choice, not last choice. If binman needs tweaks so that
>   it will still generate images for platforms in this case, that needs
>   to happen.

Perhaps we should rename this to OF_EMBED_DEBUG ? Really it should not
be used by any board.

> - If we have a bloblist, we scan the bloblist for DT and if found, use
>   it.

unless we don't want to, e.g. because that DT has a bug or we want to
use a different one during development.

> - If it looks like we've been booted as a fake Linux kernel, and we can
>   start with just aarch64 and let riscv come in as a follow up, so
>   what's documented within
>   https://www.kernel.org/doc/html/latest/arch/arm64/booting.html#call-the-kernel-image
>   then we use that device tree.

Eek, really? Is this the rpi case and you are trying to make it
generic? I would rather that be a board-specific thing, calling into a
generic implementation. We should encourage bloblist.

>   - This _may_ just end up having to be "Does x0 (or similar) point to a
>     valid DT?" as I don't know how correct everything using this method
>     today is too what the spec above lists.

OK, well a generic impl would be good I suppose, but dereferencing
pointers to look for a magic number might not end well.

> - If we have a dtb appended to use by what we call today OF_SEPARATE but
>   should really stop calling it that we use that.

Yes it is a complete misnomer now. I will try to think of a better
name. It really just controls generation of u-boot.dtb and what goes
in u-boot.bin so perhaps we can just drop it and have OF_EMBED be
false in the normal case. Or rename to OF_STANDARD ?

>
> At that point, we can probably have zero "totally board specific kludge
> for device tree location", and kill off OF_HAS_PRIOR_STAGE too (since
> that's really just bloblist or fake-linux-kernel). We'll also be able to
> support migration from fake-linux-kernel to bloblist

OF_HAS_PRIOR_STAGE controls things like building the DT and OF_BOARD
... which from what you say above can perhaps go away. But there are
quite a lot of board_fdt_blob_setup() functions...it doesn't look like
they are all the same.

Automatic is OK I suppose. I just want to make sure that these things
can be disabled easily so it is possible to use the DT built by U-Boot
without hacking the code. That is my goal with having a Kconfig to
enable this mechanisms.

Regards,
Simon


More information about the U-Boot mailing list