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 of fdtdec_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). -- Tom
signature.asc
Description: PGP signature
