On Mon, Oct 23, 2023 at 05:37:34PM +0200, Mark Kettenis wrote: > > From: Simon Glass <s...@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? -- Tom
signature.asc
Description: PGP signature
