Hi Thomas,
On Wed, 13 Oct 2021 at 10:22, Thomas Fitzsimmons fitzsim@fitzsim.org wrote:
Hi Simon,
Simon Glass sjg@chromium.org writes:
Hi Mark,
On Sat, 25 Sept 2021 at 11:27, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@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@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