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

Reply via email to