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

Wed Nov 15 00:20:12 CET 2023

On Tue, Nov 14, 2023 at 08:09:52PM +0100, Mark Kettenis wrote:
> > From: Simon Glass <sjg at google.com>
> > Date: Fri, 3 Nov 2023 13:17:18 -0600
> > 
> > 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.
> 
> Why would we want to drop it?

Because filename isn't an obvious great idea to encode as ABI? It's not
formally one right now, even with the Linux Kernel installing the ARM=arm
dtb files in a single directory even after re-organizing the source
directory to match ARCH=arm64 with per-vendor directories.

> > 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.
> 
> So you want something more complicated than a simple EFI variable?  Why?

I think part of this all came out of the issues Fedora was having where
they (a) need to override the DTB to ensure the kernel boots and (b)
oops, the logic they had been using wasn't being invoked (unexpected
Fedora-based change).

Some way to say "here is the device tree you should use" needs to come
from somewhere. It would be great if the running device tree was already
correct, but we don't know that it will be, and that's also still not a
U-Boot problem. One of the examples here was that the Pi firmware DTB
wasn't 100% correct. I forget what the exact fixup ended up being there.

So, some sort of hint for the board to say "here is the device tree you
should use". I know you earlier noted that you didn't think U-Boot would
want to know how to read N different UFS formats, and yes, true. Maybe
that just means that it needs to reside on some other filesystem format,
like Linux has to do? I don't know. How to best do that, I don't know.

> > 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.
> 
> Please stop pushing FIT for use cases where it doesn't make sense.

OK, but where is that? At least part of the "we don't want to use FIT"
camp instead has
https://uapi-group.org/specifications/specs/unified_kernel_image/ which
then leaves the details on how to select the right device tree up to
the implementation.  Which, sigh, that's the hard part. And at least as
I understand it part of the motivation is that "everyone" wants a single
file that can be used for UEFI secure boot and include all of the device
trees, so that they can be covered by the signature. Which is something
FIT images have had for forever (minus a "wrap it inside a .data section
so it can be included in a signature).

Life is a lot easier if we know the device's compatible string and then
if needed, load a newer device tree based on that compatible string.
Unfortunately, that too is not an ABI and there's a few examples where
that wouldn't work, and hasn't been fixed yet because so little relies
on the machine compatible string itself today.

> > 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.
> 
> Huh?  U-Boot already knows the name of name of the DT filename.  It is
> what we currently use in the distroboot scripts.  You are free to use
> a U-Boot specific bootflow based on that if you really want to.  But
> many distros (or other OSes like OpenBSD) really don't want to
> maintain support for multiple boot flows.

U-Boot doesn't know the DT filename, we have assorted bits of
board-specific logic to either setenv at runtime, or we hard-code that
filename at build time. We do however "know" the machine compatible
string already because you need that for a valid device tree which you
need for U-Boot today. And yes, if and only if the device tree we get
from the prior stage (or build in) is correct, we don't need to do
anything else, and can pass that to the next stage. But it also doesn't
seem like today any Linux distribution does the same thing another Linux
distribution does (excepting "spins" and so on) when it comes to loading
the kernel and device tree. Not to pick on Fedora (really!) but part of
the issue was that the patch to change where device trees are loaded
from was applied, but then not in the boot command that was being used.

Maybe part of the issue is that enough of us don't know how it works and
haven't experimented. And since at least I learn best by investigating,
should I try pine64_plus_defconfig or rpi_arm64_defconfig (on a 3 B+) on
a fresh SD card to get a better feel for what's going on?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231114/337820f9/attachment-0001.sig>