[PATCH 1/2] bloblist: Introduce BLOBLIST_PRIOR_STAGE options

[Tom Rini]

On Fri, Dec 13, 2024 at 07:32:24AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 12 Dec 2024 at 08:11, Tom Rini <trini at konsulko.com> wrote:
> >
> > Introduce an option to control if we expect that a prior stage has
> > created a bloblist already and thus it is safe to scan the address. We
> > need to have this be configurable because we do not (and cannot) know if
> > the address at CONFIG_BLOBLIST_ADDR is in regular DRAM or some special
> > on-chip memory and so it may or may not be safe to read from this
> > address this early.
> >
> > Signed-off-by: Tom Rini <trini at konsulko.com>
> > ---
> > Cc: Simon Glass <sjg at chromium.org>
> > ---
> >  common/Kconfig | 32 ++++++++++++++++++++++++++++++++
> >  lib/fdtdec.c   | 11 +++--------
> >  2 files changed, 35 insertions(+), 8 deletions(-)
> >
> 
> Since this is the essentially the same as my OF_BLOBLIST patch, which
> was rejected:
> 
> NAK
> 
> The issue is not whether some 'previous stage' set up a bloblist. For
> example, if VPL_BLOBLIST_PRIOR_STAGE is enabled, that presumably means
> that TPL set it up. But it doesn't mean that TPL put the FDT in there.

This is wrong. The root problem is saying that the bloblist is in
possibly uninitialized memory. The code is quite happy to NOT find the
device tree in the bloblist and continue searching other paths.

An alternative here would be to better document the requirements of
BLOBLIST_ADDR, and then just disable it on chromebook_coral until
someone is inclined to move DDR init in to TPL, or someone finds a
non-main-memory address to use for BLOBLIST_ADDR or switches to using
BLOBLIST_ALLOC.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241213/00d76e2b/attachment.sig>