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

[Ilias Apalodimas]

Hi Tom,

[...]

> >
> > 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.
>
> Determinism doesn't require a CONFIG option, it just requires an if/else
> tree where we say what the "correct" priority list should be and then
> set a flag so that we can tell the user where we found it too. This also
> means that we can get whatever is going to use this mechanism to
> migrate over, and have less of a chicken-and-egg type of problem.
>
> > 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.
>
> I wonder if OF_BOARD will ever go away, and I'm not convinced it will
> either.

It won't :) -- ever. You will still have hardware that reads it from
an EEPROM for example, or something like that.
People usually keep the first-stage bootloaders simple, so adding more
drivers to read something is usually deferred to later, richer
bootloaders, unless necessary

> Unless you just mean re-naming it and making a few ad-hoc
> standards more easily re-usable, which also will need to happen
> regardless.

Yes, that was what I initially suggested.

Thanks
/Ilias
>
> --
> Tom