Re: [PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]

On Wed, Oct 13, 2021 at 01:36:00PM -0400, Thomas Fitzsimmons wrote:
> Simon Glass <sjg@chromium.org> writes:
> 
> [...]
> 
> > On Wed, 13 Oct 2021 at 10:26, Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:
> >>
> >> Simon Glass <sjg@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!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]