On Wed, 27 Dec 2023 at 19:48, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Tom,
On Tue, 26 Dec 2023 at 14:07, Tom Rini trini@konsulko.com wrote:
On Tue, Dec 26, 2023 at 09:46:25AM +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
The discussion on this was not resolved and is now important due to the bloblist series from Raymond. So I am sending it again since I believe this is a better starting point than building on OF_BOARD
I really don't like adding another option for "DT is given to us". Why isn't adding another enum to fdt_source_t sufficient, and if we have bloblist enabled, that will look for and use if found? Maybe some other code needs to be restructured and cleaned up too?
Same here. On top of that the bloblist has a few items in there, e.g a TPM eventlog. What are we going to do? Add a Kconfig for each item?
No, but that is just a straw man. The DT is special and U-Boot reports where it comes from.
The story is identical to the EventLog. It's 'special' as well and U-Boot has to pick it up, otherwise the hardware and the EventLog will end up with different values
This has been going back and forth for a while. I've lost count of how many times I repeated the same proposal, but here it goes again. We have OF_BOARD and BLOBLIST options. The bloblist and its properties are scannable at runtime. Can't we use the combination of these 2 can be used to imply we expect things from a bloblist. If we want to be stricter in the future and explicitly expect the DT from a bloblist, we could add a Kconfig option failing the boot if that's missing.
I would like to have that Kconfig option now, not later. In my mind, the boot must be deterministic, so that if OF_BLOBLIST is enabled, the DT must come from there, or it is an error.
And how is what I proposed not deterministic? What prevents us from adding that Kconfig option now? The only difference is that by default, U-Boot will try bloblist -> board-specific method unless a Kconfig option prevents the fallback. I've been working with vendors and helping them implement the firmware handoff spec in their proprietary bootloaders and Raymond contributed the implementation for TF-A. At the same time, I am pretty sure vendors will need time to implement this properly. I don't see how adding an implicit Kconfig option will help them push this forward.
IOW I prefer U-Boot to *always* scan for a bloblist as the first discovery DT method (unless the DT comes bundled with U-Boot), rather than expecting users to turn a Kconfig knob.
Also, repeating it doesn't make the proposal good. We agreed that OF_BOARD would eventually go away, so building on top of it is not setting us up for the future.
No, we didn't [0]. In fact, I said I don't see OF_BOARD *ever* going away. The only thing I suggested was to rename it
[...]
[0] https://lore.kernel.org/u-boot/CAC_iWjKrkTM4spyXpoDDartJ41a553VDE+XM5gz3+jsN...
Thanks /Ilias