[PATCH 4/8] Revert "fdt: Allow the devicetree to come from a bloblist"

Simon Glass sjg at chromium.org
Tue Dec 3 01:22:35 CET 2024


Hi Tom,

On Mon, 2 Dec 2024 at 09:22, Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Dec 02, 2024 at 09:26:42AM -0500, Raymond Mao wrote:
> > Hi Simon,
> >
> > On Sun, 1 Dec 2024 at 09:43, Simon Glass <sjg at chromium.org> wrote:
> >
> > > This stops coral, bob and kevin from booting.
> > >
> > > The correct way to do this was always to use a Kconfig option, so let's
> > > first revert this broken idea.
> > >
> > > OF_BOARD and BLOBLIST should be general and hardware agnostic,
> > do you have more information on why they don't work for a few boards?
> > Maybe the way to handle these logic within certain boards should be
> > changed other than to revert this?
>
> Yes, I'd like to understand the whole problem better since we had a
> forever-and-ever thread, compromised to what's in tree now and now you
> want to revert the compromise and bring is back to what was argued
> against for forever-and-ever, at least from a very quick read.

I'm sorry but I believe I have explained the problem in that forever
and-ever thread, so I don't really want to re-run it. It may be that I
was right all along?

Raymond, I cannot pass the DT in the bloblist from TPL to SPL on x86.
There is not enough cache-as-RAM, for a start. Plus the DT is in the
memory-mapped SPI flash, so it makes no sense...

The primary issue here (I believe) is the Linaro idea that U-Boot
should not have its own devicetree, because there is always a prior
stage of closed-source firmware (e.g. TF-A*). Perhaps I am wrong about
that, but that is the way I understand it now, as it explains why
OF_BLOBLIST caused such friction.

Regards,
Simon

* I've seen quite a few vendor-specific source trees and none has been
upstreamed


More information about the U-Boot mailing list