> From: Simon Glass <s...@chromium.org> > Date: Fri, 24 Sep 2021 07:57:00 -0600 > > Hi Ilias, > > On Fri, 24 Sept 2021 at 07:10, Ilias Apalodimas > <ilias.apalodi...@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.
