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. > 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
signature.asc
Description: PGP signature
