[PATCH v4] fdt: Allow the devicetree to come from a bloblist

[Simon Glass]

Hi Ilias,

On Thu, Dec 28, 2023 at 1:58 PM Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> [...]
>
> > > > >
> > > > > 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
> >
> > Why are you talking about event log? Let's stick to the topic at hand.
>
> We are. The reason I bring this up is pretty obvious. It has identical
> properties to the DT, and I *dont* want a Kconfig option to enable or
> disable it.

It is completely different to the devicetree. I don't even know how to
respond to this, or what properties might be common between a
devicetree and a TPL log.

>
> >
> > >
> > > >
> > > > >
> > > > > 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.
> >
> > It is the 'unless the DT comes bundled with U-Boot' which I am talking
> > about, but I now have a better understanding of the problem here.
> >
> > I don't want CONFIG_BLOBLIST to mean that the DT comes from a
> > bloblist.
>
> But it doesn't mean that. It means 'try to scan the bloblist for a DT first'.

I'm OK with that and it is how the v5 patch works.

>
> > Simply put, I want to be able to use the U-Boot DT during
> > development, without needing to rebuild some prior stage or update
> > some other project. So I would like the use of bloblist to be behind
> > an OF_BLOBLIST option.
>
> That's easy instead of OF_BOARD use OF_EMBED or OF_SEPARATE?

OF_EMBED doesn't help - things have moved on a lot from those days (e.g. Binman)
OF_SEPARATE is already enabled

>
> >
> > From Tom's email and your other reply, it seems that we could all live
> > with an OF_BLOBLIST option to enable DT-in-bloblist, making it
> > optional but default 'y'?
> >
> > >
> > > >
> > > > 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
> >
> > Well I'm just not sure what is going on. Use of bloblist should not
> > require board-specific code. It should be a generic mechanism, in
> > fdtdec_setup()
>
> It doesn't, we never asked for that. There's even code in a previous
> iteration from me showing exactly what I had in mind. We always said
> scan for a bloblist if OF_BOARD is selected, in priority, and if you
> don't find a DT try a board-specific method (and add a Kconfig option
> to fail the boot if required).
>
> >
> > There are too many cooks in this kitchen right now, I'll try another
> > spin of my patch.
>
> I really don't like another OF_XXXXXXX for determining where the DT
> comes from, but I've explained my opinion way too many times.  I'll
> let you and Tom decide on this

I sent a v5 patch which I believe provides what we both want, so PTAL.

[..]


> > > [0] https://lore.kernel.org/u-boot/CAC_iWjKrkTM4spyXpoDDartJ41a553VDE+XM5gz3+jsNTFqtbg@mail.gmail.com/

Regards,
Simon