[PATCH v2 1/1] efi_loader: expose the device-tree file name

[Simon Glass]

Hi,

On Mon, 23 Oct 2023 at 11:06, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > Date: Mon, 23 Oct 2023 12:34:55 -0400
> > From: Tom Rini <trini at konsulko.com>
> >
> > On Mon, Oct 23, 2023 at 05:37:34PM +0200, Mark Kettenis wrote:
> > > > From: Simon Glass <sjg at google.com>
> > > > Date: Mon, 23 Oct 2023 00:08:40 -0700
> > > >
> > > > > > fdt_node_check_compatible() does most of the work...then you need to
> > > > > > check which FDT has the most specific match (i.e. latest in the string
> > > > > > list). That handles things like board revisions, variants, etc.
> > > > > >
> > > > > > My concern is about adding a feature when there is already a defined
> > > > > > spec and mechanism for this to work. What happens when we load the
> > > > > > file and the compatible is wrong?
> > > > > >
> > > > > > At best, I see the filename as a hint.
> > > > > >
> > > > > > [Perhaps this is the wrong time to ask, but why are kernels +DT not
> > > > > > shipped in FIT on ARM?]
> > > > >
> > > > > FIT is U-Boot specific. For Linux distributions it is easier to use a
> > > > > firmware agnostic method of booting.
> > > >
> > > > I'd like to suggest that distros use both. Then U-Boot can work as it
> > > > was designed and we can avoid these work-arounds.
> > > >
> > > > FIT is actually implemented in various other bootloaders. In fact
> > > > perhaps grub is the only one that doesn't? I can't think of any
> > > > others.
> > >
> > > Simon, please stop pushing this.  OpenBSD's bootloader does not
> > > support FIT and we have no interest in supporting it.  Our users
> > > expect to be able to just copy a new kernel in place and use it and
> > > our OS upgrade procedure depends on this as well.  And this is
> > > incompatble with FIT.  I've explained this about a dozen times to you
> > > now.
> >
> > In the context of this thread, genuinely, how will OpenBSD (and the rest
> > of the BSD families) operate? I agree U-Boot doesn't want to have to
> > know all of the UFSes, so that means the SCT will be populated either by
> > the DT passed to U-Boot, or the DT we were built with. Is it that since
> > the next stage is an EFI app, it will check that variable and use that
> > hint?
>
> Yes, that is exactly what I want to do.  Hopefully the DT that is
> passed to U-Boot or that U-Boot was built with will be good enough in
> most cases.  But when it isn't users can use the OpenBSD bootloader
> (which is an EFI app) to load an updated DT.
>
> I can't speak for the other BSDs, but I think both FreeBSD and NetBSD
> have a very similar boot mechanism.

I've been thinking about this patch a bit more, and I have grave misgivings.

I predict that if we take this, it will become an ABI from U-Boot and
we will not be able to drop it.

Here is what I suggest instead: provide a protocol for U-Boot to
provide the DT over EFI. Provide any information needed by U-Boot,
such as the directory containing the files.

We already have the ability to put a DT in the system table. We
already have a way to package DT into a FIT and allow U-Boot to select
the correct one.

With something like this it will be impossible for U-Boot to boot a
distro without using grub, etc. since it won't know what DT to use.
This information would be held in a script somewhere which no one can
figure out without executing it.

I think we need to carefully think about the design of this.

Regards,
Simon