[PATCH 00/12] Support to run U-Boot on sc7180 Trogdor Chromebooks

[Stephen Boyd]

Quoting Caleb Connolly (2025-02-26 03:04:29)
>
>
> On 2/25/25 21:49, Stephen Boyd wrote:
>
> > this supposed to work in general? Should I be storing the DTB on disk so
>
> The SystemReady approach is that firmware provides the FDT, if you don't
> pick a DTB then the one that U-Boot itself was using will be passed
> through instead, this ought to work assuming there isn't too much churn
> in the DT upstream (and assuming you keep U-Boot up to date, I'd really
> like to spend some time on LVFS at some point...)
>
> However, acknowledging the limitations of this approach, there's a few
> pieces that move together to try and load the DTB from some well-known
> paths on the ESP:
>
> 1. efi_load_distro_fdt() - this is called into in the "bootefi bootmgr"
> path (which is what you should be using fyi, see also eficonfig) if you
> don't provide an FDT explicitly and will search for $fdtfile in /, /dtb,
> /dtb/current, and /dtbs. This works on a few distros but not e.g. debian
> which puts everything under a versioned path.
>
> 2. $fdtfile - the filename of the DTB to load has to come from
> somewhere, in mach-snapdragon/board.c we have some basic logic in
> configure_env() which tries to piece this together from the root
> compatible array.
>
> The $fdtfile logic is not flawless, it only works on boards that follow
> a specific pattern in their compatible and filename, it just happens to
> work for most of the basic ones. I would be happy to see this logic
> expanded though.

Ok, got it. The way ChromeOS picks the DTB is based on the compatible
string, not the file name. Hard coding the fdtfile sounds like a
solution for now. I can look into writing up some coreboot table based
logic that does what depthcharge does today to find the best matching
compatible later on.