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).
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)?
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".
In any case, I don't believe we could remove non-FIT support, so here we
are :)
Cheers,
Quentin
