Hi Thomas, On Wed, 13 Oct 2021 at 10:22, Thomas Fitzsimmons <fitz...@fitzsim.org> wrote: > > Hi Simon, > > Simon Glass <s...@chromium.org> writes: > > > Hi Mark, > > > > On Sat, 25 Sept 2021 at 11:27, Mark Kettenis <mark.kette...@xs4all.nl> > > wrote: > >> > >> > 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. > > > > 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.
There seems to be some genetic quirk in humans that makes them want to invent their own bootloader. I have seen it a lot in my life. > > 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. Yes, that seems clear. Regards, Simon
