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

Attachment: signature.asc
Description: PGP signature

Reply via email to