Hi, On Thu, Dec 28, 2023 at 2:24 PM Tom Rini <tr...@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 <s...@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