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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > > > > > > 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 > > > > > > > > > > > <[email protected]> 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 > > > > > > > > > > > > > <[email protected]> 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 > > > > > > > > > > > > > > > <[email protected]> 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 > > > > > > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon Glass > > > > > > > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Raymond, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond Mao > > > > > > > > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon > > > > > > > > > > > > > > > > > > > > Glass <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Raymond, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, Raymond > > > > > > > > > > > > > > > > > > > > > Mao <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, Simon > > > > > > > > > > > > > > > > > > > > > > Glass <[email protected]> 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
signature.asc
Description: PGP signature
