Hi Tom, On Tue, 11 Feb 2025 at 07:08, Tom Rini <tr...@konsulko.com> wrote: > > On Tue, Feb 11, 2025 at 06:09:03AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 10 Feb 2025 at 07:33, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Sun, Feb 09, 2025 at 02:14:56PM -0700, Simon Glass wrote: > > > > > > > Where the bloblist is located in internal memory and TF-A's BL31 blob > > > > removes access to this memory, the best option seems to be to relocate > > > > the bloblist just before running TF-A. > > > > > > > > We can do the relocation in board-specific code, but need an option to > > > > pick up the correct address within U-Boot proper. > > > > > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > > > --- > > > > > > > > Changes in v2: > > > > - Move the actual relocation code to a previous board-specific patch > > > > > > > > common/Kconfig | 20 ++++++++++++++++++++ > > > > common/bloblist.c | 15 ++++++++++++++- > > > > 2 files changed, 34 insertions(+), 1 deletion(-) > > > > > > I'm going to NAK this whole concept. The whole nightmare thread about > > > these platforms comes from using a fixed address. We need to pass in a > > > bloblist or see that one is not passed to us, via register. And then use > > > that mechanism to pass the bloblist to the next phase. When we don't > > > have a bloblist passed to us, we allocate one, and not at a fixed > > > location. > > > > Well I understand that Linaro may be doing some work to head in that > > direction. > > Are they? I don't know. I know Raymond was doing some clean up based on > the idea of treating bloblist and standard passage as two separate > things. Which I think is a terrible idea, despite suggesting it. But I > think it's also the only way to make progress now that you've decided > you can't work with them anymore.
Can't work with who? Linaro? If you don't allow me to create patches for bloblist within your tree, what am I to do? > > > The 'piror-stage' stuff is what has made this all too hard and > > confusing. We should think of things from a U-Boot perspective and > > make that work. The new case can be handled by standard passage, along > > the lines that Raymond suggested, i.e. just checking for it first. > > > > For x86 we don't need this path as there is no bloblist in TPL, i.e. > > it can be placed in DRAM from the start. > > A fixed address is a bad API for the U-Boot case and is what makes this > all so confusing. And no, we can't put it in DRAM on x86 either, that's > what had coral broke until I put it back in CAR. > > Please explain why a fixed address is a better API than passing a known > valid location via register, for the U-Boot case. I don't like it > because it means that we cannot always safely check if it exists. > > -- > Tom Yes I would rather pass the location via register using standard passage, at least on ARM, where we have a suitable protocol. For now this is the only way for me to provide a series where VBE actually works in the lab. Regards, Simon
