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

[Simon Glass]

Hi Ilias,

On Thu, Dec 28, 2023 at 6:53 AM Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> On Wed, 27 Dec 2023 at 19:48, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Ilias,
> >
> > On Wed, Dec 27, 2023 at 6:44 AM Ilias Apalodimas
> > <ilias.apalodimas at linaro.org> wrote:
> > >
> > > Hi Tom,
> > >
> > > On Tue, 26 Dec 2023 at 14:07, Tom Rini <trini at 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 at 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

Why are you talking about event log? Let's stick to the topic at hand.

>
> >
> > >
> > > 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. 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.

>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()

There are too many cooks in this kitchen right now, I'll try another
spin of my patch.

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

Regards,
Simon