Hi Ilias, On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas <ilias.apalodi...@linaro.org> wrote: > > Hi Tom, > > On Tue, 26 Dec 2023 at 14:07, Tom Rini <tr...@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 <s...@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. > > 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. 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. Regards, Simon