On Mon, Oct 23, 2023 at 4:55 PM Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@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.
For reference Fedora and related ecosystems have no interest in supporting FIT either, we have enough moving targets, we're not supporting more, it's very much why we're focused on UEFI, it provides one way, one kernel, for booting all various different devices we actively support in main Fedora, it's very much the way the x86 ecosystem has gone as well as the aarch64 server ecosystem. Fedora has no interest in using FIT in this context either.
Peter