[PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE
fitzsim at fitzsim.org
Fri Oct 15 18:19:16 CEST 2021
Tom Rini <trini at konsulko.com> writes:
> On Wed, Oct 13, 2021 at 01:36:00PM -0400, Thomas Fitzsimmons wrote:
>> Simon Glass <sjg at chromium.org> writes:
>> > On Wed, 13 Oct 2021 at 10:26, Thomas Fitzsimmons <fitzsim at fitzsim.org> wrote:
>> >> Simon Glass <sjg at chromium.org> writes:
>> >> [...]
>> >> >> > 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.
>> >> >>
>> >> >> For now it's easier getting rid of OF_PRIOR_STAGE than OF_BOARD.
>> >> >> Once we unify OF_PRIOR_STAGE/OF_BOARD and OF_HOSTFILE, then
>> >> >> I can send a patch on top of that, which removes the board_fdt_blob_setup()
>> >> >> and just stores the address in a similar fashion to the removed
>> >> >> 'prior_stage_fdt_address'. That way we can get rid of architecture
>> >> >> specific constructs wrt to DT in gd. The callback is a bit more of a pain to
>> >> >> maintain for multiple boards but is more flexible than an address in a
>> >> >> register. In any case we can do something along the lines of:
>> >> >>
>> >> >> Check register (or blob list or whatever)
>> >> >> if (valid dtb)
>> >> >> fixup/amend/use (depending on what we decide)
>> >> >> else
>> >> >> arch specific callback
>> >> >>
>> >> >> That should give us enough flexibility to deal with future boards (famous
>> >> >> last words).
>> >> >
>> >> > SGTM
>> >> This sounds like a good generalization that would still work for the
>> >> bcm7445 and bcm7260 boards. I'll test this approach on the evaluation
>> >> boards I have.
>> >> For the BCM7445 I may be able to import the evaluation board device tree
>> >> that Broadcom publishes as part of stblinux. At runtime I may need to
>> >> merge some of the in-memory items generated by BOLT, but I'll try to
>> >> make this work.
>> > That would be good.
>> >> The BCM7260 DTS is not publicly available though, as far as I know.
>> > Presumably it can be dumped from U-Boot?
>> Technically, yes, but I wouldn't want to publish the result for various
>> reasons; e.g., it would be specific to the evaluation boards I have, and
>> it may contain vendor-specific fields. I'd much rather this one remain
>> a stub, until/unless Broadcom publishes a generic BCM7260 DTS under a
>> free license.
> Also note that the notion that the U-Boot source tree _must_ contain a
> dts for a given board is something we're very much debating still, in
> another thread, if you're inclined to read and chime in there as well
> with more details about the broadcom use case and technical/legal
> limitations. Thanks!
Sure. I read through ; here are my thoughts from the BCM7445/BCM7260
First of all, for background, BCM7445 and BCM7260 are partial ports of
U-Boot. They're meant to allow using nice U-Boot features like hush and
FIT image loading on these platforms. But they do not handle low-level
initialization -- that's done by BOLT, the proprietary
first-and-second-stage bootloader -- and they don't support configuring
all of the hardware on these boards. Instead these ports include a
small set of drivers (e.g., SPI, eMMC, serial) and configuration that is
needed to make use of the higher level features.
At the time I contributed the BCM7445 support, README called OF_CONTROL
an experimental feature, and device driver configuration was
alternatively allowed to live in board-specific header files. My
initial local implementation did that, but then I switched to OF_CONTROL
before submitting the patches, since then I could get some of U-Boot's
driver configuration from the prior stage (BOLT) dynamically, instead of
hard-coding addresses in U-Boot source code. The proposed new policy
would require me to (re-)add these hard-coded values, albeit in a DTS,
not a header file. IMO that's probably a good/fair requirement for the
non-technical reasons in .
The second section of  says: "Every board in U-Boot must include a
devicetree sufficient to build and boot that board on suitable hardware
(or emulation)." I initially read that as "boot to Linux", and so I was
thinking the device tree checked into the U-Boot tree had to be
sufficient to boot Linux and configure every device that Linux supports.
One of Simon's responses  clarified for me that the policy proposal
was about the control DTB for U-Boot.
Now I believe the intent of the proposed policy (stated in the
"Devicetree source" section of ) is something like "each port in
U-Boot must have an in-tree device tree that is sufficient to boot/run
*U-Boot itself* on at least one representative board designed around
that SoC". That would make sense to me; it would permit not-full-Linux
device trees that configure only the device drivers that the port needs
to support a subset of U-Boot features. This would allow boards like
BCM7260, which have no publicly available Linux DTS, to have a small,
generic device tree just for configuring reused, GPL'd U-Boot drivers.
This is in contrast to the policy mandating or encouraging dumping to
DTS binary-only proprietary Linux DTBs from prior stage bootloaders or
ROMs, as a precondition to the port being included in U-Boot.
The policy proposal (assuming I'm understanding it correctly now) would
have been clearer if one of the first two sections in devicetree.rst
explicitly mentioned "control DTB for U-Boot", i.e., the fact that the
policy is about U-Boot's own much simpler DTB usage, not Linux's, even
though the two projects largely share the same DTSs.
More information about the U-Boot