Re: [PATCH 0/4] bloblist: fdt: Clean up the code

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 12931 bytes --]

On Thu, Apr 17, 2025 at 04:02:20PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 17 Apr 2025 at 15:58, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Apr 17, 2025 at 03:24:17PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 17 Apr 2025 at 08:14, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Apr 17, 2025 at 07:14:35AM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 14 Apr 2025 at 14:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Apr 14, 2025 at 01:34:10PM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 7 Apr 2025 at 08:31, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Apr 07, 2025 at 12:35:15PM +1200, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 7 Apr 2025 at 10:38, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Apr 07, 2025 at 10:06:07AM +1200, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Sat, 5 Apr 2025 at 06:57, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, Apr 05, 2025 at 06:39:39AM +1300, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 4 Apr 2025 at 11:51, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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@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@linaro.org> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Raymond,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond Mao <raymond.mao@linaro.org> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Simon,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon Glass <sjg@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.
> > > > > > > > > > > > >
> > > > > > > > > > > > > For me, OF_BLOBLIST is needed for x86 devices which don't pass the
> > > > > > > > > > > > > devicetree in the bloblist.
> > > > > > > > > > > >
> > > > > > > > > > > > I don't understand why that would become the case when it's not true
> > > > > > > > > > > > today.
> > > > > > > > > > >
> > > > > > > > > > > If you look at the top obbfdtdec_setup() in your tree you can see the
> > > > > > > > > > > special-case code related to TPL, that I'm wanting to get rid of.
> > > > > > > > > >
> > > > > > > > > > OK, but all of that too is for the case of a fixed bloblist being in
> > > > > > > > > > uninitialized memory. Which is why I don't like BLOBLIST_FIXED and want
> > > > > > > > > > to see passing of the bloblist from xPL -> PPL be implemented and so xPL
> > > > > > > > > > can allocate a bloblist (or grow a passed one if needed).
> > > > > > > > >
> > > > > > > > > We are going around in circles though. Having it is registers doesn't
> > > > > > > > > help with the problem that there isn't an FDT in the bloblist.
> > > > > > > >
> > > > > > > > Sure it does. If we're passed a bloblist in a register we can then see
> > > > > > > > if it has a DT (and use it) or not (and move to the next DT location).
> > > > > > > >
> > > > > > > > > Also, I thought you decided that I could maintain bloblist. Have you
> > > > > > > > > changed your mind?
> > > > > > > >
> > > > > > > > You just mis-understood me. Yes, you can maintain bloblist. But also,
> > > > > > > > Yes, I need to understand what you're doing. The root of the OF_BLOBLIST
> > > > > > > > problems is that no one understood you.
> > > > > > >
> > > > > > > No, that's not actually true. The problem is that no one would listen
> > > > > > > and everyone was sure I was wrong.
> > > > > >
> > > > > > That's another way of saying "no one understood you", IMO.
> > > > > >
> > > > > > > I sent the series on the basis that you were open to my maintaining
> > > > > > > bloblist in your tree. I didn't know there were extra conditions. So
> > > > > > > please let me know which way you want to go on this.
> > > > > >
> > > > > > I thought we had made progress on the community call, but now you're
> > > > > > sending this so I don't know?
> > > > > >
> > > > > > You need to:
> > > > > > - Not break handoff spec. Raymond is telling you how to get a QEMU that
> > > > > >   uses that now, and I'm actively waiting on Harrison Mutai to answer
> > > > > >   one last question I had before adding vexpress_fvp to our CI. So this
> > > > > >   should be a reasonable requirement.
> > > > > > - You were going to add register passing of bloblist location for x86,
> > > > > >   and then add register passing of bloblist between U-Boot phases
> > > > > >   without relying on BLOBLIST_FiXED.
> > > > > > - Some amount of un-tangling "do we have a bloblist" from "did we get a
> > > > > >   bloblist" is needed, so we can just check "Did we get a bloblist? Y/N"
> > > > > >   in lib/fdtdec.c::fdtdec_setup(). With that, we can add OF_BLOBLIST as
> > > > > >   a choice with OF_SEPARATE / OF_EMBEDED and we can remove a bunch of
> > > > > >   the logic at the top of lib/fdtdec.c::fdtdec_setup() too.
> > > > >
> > > > > That seems very much like a list of instructions. So in fact you still
> > > > > want to be the maintainer?
> > > >
> > > > I mean, I'm the project maintainer. No, I'm not going to sit over your
> > > > shoulder and tell you how to do that. But I am telling you what is and
> > > > isn't acceptable. I don't just blindly take patches from anyone. You are
> > > > not being singled out here.
> > >
> > > Heaven forbid. Although I see that you reverted the PXE stuff rather
> > > than taking my fix-up patch. That's different from what you did with
> > > all the lmb breakage.
> >
> > Because you said I should just revert it since I didn't "support" it.
> > And didn't look in to booti. So yes, that series needs a re-baking to
> > also fix booti as it has a similar set of handling things outside the
> > bootm state machine, and really re-checking nothing else got missed.
> 
> If you want the series I'm happy to resend it with the fix integrated.
> Yes I carefully checked that nothing else got missed. Still, I did
> that the first time and still missed something.
> 
> Just let me know.

The "booti" code still needs to be fixed too, that was the first of the
bug reports.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]