[PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE

[Mark Kettenis]

> 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.