On Wed, 27 Dec 2023 at 19:48, Simon Glass <s...@chromium.org> wrote: > > 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.
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+jsntfq...@mail.gmail.com/ Thanks /Ilias