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.
