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