[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