[PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE

[Thomas Fitzsimmons]

Hi Simon,

Simon Glass <sjg at chromium.org> writes:

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

The situation Mark described is the same as the one I was addressing by
introducing CONFIG_OF_PRIOR_STAGE for these BOLT-using Broadcom boards.
BOLT is a Broadcom proprietary first- and second-stage bootloader.  On
these boards, the DTB that BOLT generates in-memory and provides to the
Linux kernel is meant to be authoritative.

I would much prefer if Broadcom provided native U-Boot support as an
alternative to BOLT, including maintaining free software device trees.
But in the absence of that, given that I wanted U-Boot features on these
boards, I made U-Boot an intermediate (third) stage and used the
BOLT-provided DTB.  One reason I had for contributing the changes is
that I was faintly hoping to nudge Broadcom to support these and future
boards in U-Boot.

My understanding is that the DTB design intent does allow things like
loading a DTB from ROM, so I'm sort of treating the BOLT-provided DTB
that way.  But I also understand that not having U-Boot and Linux in
full control of device trees for boards they support is annoying.  That
said, I'm glad the consensus here seems to be that it's preferable to
have U-Boot accommodate/still be usable on no-DTS boards.

Thomas