[PATCH 3/5] pxe_utils: Allow the FDT to be missing

[Simon Glass]

Hi Quentin,

On Wed, 15 Jan 2025 at 04:59, Quentin Schulz <quentin.schulz at 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.schulz at 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