[PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE

[Simon Glass]

Hi Mark,

On Sat, 25 Sept 2021 at 11:27, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Simon Glass <sjg at chromium.org>
> > Date: Fri, 24 Sep 2021 07:57:00 -0600
> >
> > Hi Ilias,
> >
> > On Fri, 24 Sept 2021 at 07:10, Ilias Apalodimas
> > <ilias.apalodimas at linaro.org> wrote:
> > >
> > > At some point back in 2018 prior_stage_fdt_address and OF_PRIOR_STAGE got
> > > introduced,  in order to support a DTB handed over by an earlier stage boot
> > > loader.  However we have another option in the Kconfig (OF_BOARD) which has
> > > identical semantics.
> > >
> > > A good example of this is RISC-V boards which during their startup,
> > > pick up the DTB from a1 and copy it in their private gd_t.  Apart from that
> > > they also copy it to prior_stage_fdt_address,  if the Kconfig option is
> > > selected,  which seems unnecessary(??).
> > >
> > > This is mostly an RFC,  trying to figure out if I am missing some subtle
> > > functionality,  which would justify having 2 Kconfig options doing similar
> > > things present.
> > >
> > > - Should we do this?
> >
> > I think one option is better than two. I have a slight preference for
> > OF_PRIOR_STAGE because it is board-agnostic, but I'm not sure it
> > matters, since some of these boards are doing strange things anyway
> > and cannot use OF_PRIOR_STAGE. So let's go with this.
> >
> > > - Doesn't OF_BOARD and OF_PRIOR_STAGE practically mean "Someone else is
> > >   going to pass me my DTB".  Why should we care if that someone is a prior
> > >   bootloader or runtime memory generated on the fly by U-Boot?  It all
> > >   boils down to having a *board* specific callback for that.
> >
> > More generally, I think OF_BOARD is basically 'opt out of the normal
> > flow and do something special'.
> >
> > So at some point I would like to define what 'normal' is. At present,
> > normal is OF_SEPARATE which means that the devicetree is packed with
> > U-Boot.
> >
> > Really we want to add a second 'normal', to permit a devicetree (and
> > perhaps other stuff) to be passed in. I think this should be that a
> > bloblist is passed in, which can contain a devicetree. If it does,
> > then the one in U-Boot is ignored.
> >
> > There should be a standard way to do this with U-Boot. Apart from the
> > arch-specific selection of machine registers, the standard way should
> > work for all boards, at some indeterminate point in the future.
>
> There are well-established ABIs here that you can't really change.
> One of those ABIs is how the Linux kernel expects to be called.  On
> both riscv and arm64 Linux expects to find a pointer to the DTB in a
> register.
>
> Several U-Boot platforms take advantage of this by pretending to be a
> Linux kernel.  This way they can be loaded by prior stage firmware
> that was designed to directly load a Linux kernel.  This is what I do
> for the Apple M1, but this is also how chainloading works on some
> chromebooks, and there are a few platforms where a proprietary closed
> source first stage bootloader is used.
>
> So once again, U-Boot should be flexible here.  We can certainly
> recommend a certain approach to folks that are building a firmware
> stack for new platforms, but we can't really enforce it.

Indeed.

We can nudge people along by providing useful features. Private
firmware does not seem to be going away.

Regards,
Simon