[PATCH] arm: init: add an option to use FDT from previous bootloader

Simon Glass sjg at chromium.org
Sat Nov 4 20:43:25 CET 2023


Hi Mark,

On Wed, 25 Oct 2023 at 08:05, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Simon Glass <sjg at chromium.org>
> > Date: Tue, 24 Oct 2023 12:34:39 -0700
> >
> > > This mechanism of retrieving the DTB is also used on the apple M1 I
> > > think, and any other board where we're booting U-Boot as a drop-in for
> > > the kernel on arm64.
> >
> > I believe M1 is an open source project so perhaps they could adopt
> > firmware handoff when it is finalised.
>
> Hi Simon,
>
> I'll repeat what I've said before; handoff for M1 is deliberately 100%
> compatible with handoff to the Linux kernel such that it is possible
> to bypass U-Boot and directly boot a Linux kernel.  This is a feature
> the Asahi Linux developers depend on.
>
> If you want us to make changes here, you need to convince the Linux
> kernel developers to adjust Documentation/arch/arm64/bootig.rst to
> allow for the firmware handoff convention.

I don't have an infinite memory. In fact it does not extend all that
far back, so I appreciate you mentioning this again.

What is U-Boot for, if Asahi boots Linux directly?

In any case, firmware handoff needs to be treated separately from
Linux handoff. If you are trying to push the Linux approach into
firmware, it will cause all sorts of things to become impossible,
including universal payload. We can handle this with magic values in
the registers, if needed.

Of course, I have to mention that if we used a sensible format with
metadata for Linux (like FIT) programs would *know* what they are
booting, and be able to set things up correctly accordingly. It is
high time we started thinking about this a bit more holistically,
instead of going for the lower common denominator.

Regards,
Simon


More information about the U-Boot mailing list