[PATCH 0/4] bloblist: fdt: Clean up the code
Tom Rini
trini at konsulko.com
Fri Apr 4 00:50:58 CEST 2025
On Fri, Apr 04, 2025 at 11:41:08AM +1300, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 4 Apr 2025 at 10:52, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Apr 04, 2025 at 09:40:29AM +1300, Simon Glass wrote:
> > > Hi Raymond,
> > >
> > > On Fri, 4 Apr 2025 at 08:54, Raymond Mao <raymond.mao at linaro.org> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg at chromium.org> wrote:
> > > > >
> > > > > Hi Raymond,
> > > > >
> > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao at linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg at chromium.org> wrote:
> > > > > > >
> > > > > > > Hi Raymond,
> > > > > > >
> > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao at linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon,
> > > > > > > >
> > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg at chromium.org> wrote:
> > > > > > > > >
> > > > > > > > > The bloblist code took what I consider to be a wrong turn a year or so
> > > > > > > > > ago. As discussed with Tom, this series proposes a way to arrange things
> > > > > > > > > so that it is simpler to understand and manage.
> > > > > > > > >
> > > > > > > > > - Unwind some of the nesting in bloblist_init()
> > > > > > > > > - Avoid needing to init the bloblist just to get the FDT
> > > > > > > > > - Create a deterministic OF_BLOBLIST option rather than using guesswork
> > > > > > > > >
> > > > > > > > We now have a kconfig BLOBLIST_PASSAGE_MANDATORY which means
> > > > > > > > mandatorily use bloblist to hand over everything between boot stages
> > > > > > > > including fdt, creating OF_BLOBLIST is not necessary.
> > > > > > >
> > > > > > > Yes, I noticed that, but BLOBLIST_PASSAGE_MANDATORY indicates that
> > > > > > > there must be a bloblist, not that it must contain a devicetree. So I
> > > > > > > wasn't sure about removing it.
> > > > > > >
> > > > > >
> > > > > > See my comments to your [2/4] patch, if BLOBLIST_PASSAGE_MANDATORY is
> > > > > > selected, we can override any fdt from board or env with the one from
> > > > > > the bloblist.
> > > > >
> > > > > Yes, but we should be explicit about what is going on here. With
> > > > > OF_BLOBLIST we indicate that the devicetree is coming from the
> > > > > bloblist. It becomes one of the sources for devicetree, like
> > > > > OF_SEPARATE and OF_EMBED
> > > > >
> > > >
> > > > BLOBLIST_PASSAGE_MANDATORY indicates the fdt from bloblist will be
> > > > mandatorily used and override other fdt sources like from the board or
> > > > env variables.
> > >
> > > So long as you are OK with OF_BLOBLIST as well, I have no objection to
> > > keeping BLOBLIST_PASSAGE_MANDATORY, although I don't like the name
> > > very much. But I can see why it is called that as my standard passage
> > > series was actually never applied. So I suppose I'll need to have
> > > another try at that.
> > >
> > > So to be clear, I want a separate option for devicetree, called
> > > OF_BLOBLIST, which I can enable/disable as needed, without affecting
> > > your option.
> >
> > Sigh. Can I ask what the use case for this will be? And we are going to
> > get rid of BLOBLIST_FIXED at some point, yes?
>
> I thought we agreed that this was acceptable. We argued the toss for
> months on this point and I would rather not revisit it.
>
> Yes, I will look at removing BLOBLIST_FIXED once this is in. I'm
> pretty sure it can be done. The only tricky bit is coming up with a
> bloblist protocol for x86.
Yes, I'm stuck between being "flexible and saying yes" and how long we
have to live with what I also think are bad designs.
So maybe the pre-requisite here is that with "bloblist" and "standard
passage" being divorced, what is the requirement for bloblist again?
Because in practice, all of the problems we've had come down to looking
in fixed address locations before they're valid. You want to handle this
by saying "Ah, we won't look before it's valid with other CONFIG flags"
and I say we should handle this by not using a fixed address to start
with.
If we have to add OF_BLOBLIST now and delete it in a few months, sigh,
OK. But it shouldn't need to exist long term.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250403/9f0e7aa4/attachment.sig>
More information about the U-Boot
mailing list