On Thu, Apr 17, 2025 at 04:28:42PM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 17 Apr 2025 at 16:14, Tom Rini <tr...@konsulko.com> wrote: > > > > 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 <tr...@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 <tr...@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 <tr...@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 <tr...@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 > > > > > > > > > > > <tr...@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 > > > > > > > > > > > > > <tr...@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 > > > > > > > > > > > > > > > <tr...@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 > > > > > > > > > > > > > > > > > <tr...@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....@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 14:18, Simon > > > > > > > > > > > > > > > > > > > > Glass <s...@chromium.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Raymond, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 07:13, Raymond > > > > > > > > > > > > > > > > > > > > > Mao <raymond....@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 3 Apr 2025 at 13:57, Simon > > > > > > > > > > > > > > > > > > > > > > Glass <s...@chromium.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Raymond, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 4 Apr 2025 at 03:09, > > > > > > > > > > > > > > > > > > > > > > > Raymond Mao > > > > > > > > > > > > > > > > > > > > > > > <raymond....@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 28 Mar 2025 at 11:44, > > > > > > > > > > > > > > > > > > > > > > > > Simon Glass <s...@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. > > Yes, I suggested plumbing through a setting to ignore SYS_BOOTM_LEN > and use 4x the compressed size instead. If you are OK with that then I > can incorporate it.
I'd prefer to take the existing code we have in cmd/booti.c and migrate that similar to your patch for bootz, so that we don't change expected behavior and can evaluate any later cleanups by themselves and not related to fixing regressions. -- Tom
signature.asc
Description: PGP signature
