Hi Quentin, On Wed, 15 Jan 2025 at 04:59, Quentin Schulz <quentin.sch...@cherry.de> wrote: > > Hi Simon, > > On 1/15/25 2:16 AM, Simon Glass wrote: > > Hi Quentin, > > > > On Tue, 14 Jan 2025 at 08:13, Quentin Schulz <quentin.sch...@cherry.de> > > wrote: > >> > >> Hi Simon, > >> > >> On 12/20/24 5:01 AM, Simon Glass wrote: > >>> The devicetree file may not be provided, so avoid a failure in that > >>> case. > >>> > >> > >> Can you provide a bit more information on when/why this shouldn't be a > >> failure? I assume likely x86? or Aarch64 with ACPI instead of OF? > > > > Yes, either of those, but also, even on platforms which use a > > devicetree, some don't have it in the extlinux file. For example rpi > > passes it through to U-Boot from its own closed-source firmware. > > > > Ah yes, I had forgotten about platforms using one DTB and passing it > through stages, I believe Qualcomm does this as well? > > Could you please add what you just said to the commit log so that we > have an idea which scenario this intends to support (for future > reference if this introduces a regression or we want to do refactoring > in the future).
OK > > I'm wondering if this isn't going to allow booting FDT systems without > an FDT at all, which really isn't great? Is there something we > could/should do to prevent that from happening (or at least notify the > user of such a scenario so it's easier to debug)? It shouldn't make any difference to the current code. Passing a bootflow just allows the information to be recorded. The logic of whether to use the FDT is not changed by this patch. > > > Somewhat related: my opinion with extlinux (and EFI for that matter) > > is that we should be using FIT. > > > > FIT images are not really developer-friendly though :/ I've been asked > to ditch FIT images to allow easy replacement of customer Device > Trees/kernel images. Much easier to say "copy your file there, modify > extlinux.conf to point at the new filepath for the FDT" rather than "so > this is the ITS, change the path here, and there, don't forget to have > those binaries in the current path, use mkimage, then copy this itb file > there". Yes we need to keep that flow working, of course. Re FIT, well, we could write a tool. Would that help? If someone did that, what would it look like? I've been happy with FIT for a long time, but particularly recently due to all the workarounds and gymnastics people are doing to make single files work, e.g. figuring out which devicetree to use. There is 'u-boot-menu' which works on the running system. > > In any case, I don't believe we could remove non-FIT support, so here we > are :) Regards, SImon
