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

From: Simon Glass <sjg@chromium.org>
To: Thomas Fitzsimmons <fitzsim@fitzsim.org>
Cc: "Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
	"Tom Rini" <trini@konsulko.com>, "Rick Chen" <rick@andestech.com>,
	Leo <ycliang@andestech.com>, "Bin Meng" <bmeng.cn@gmail.com>,
	"Marek Behún" <marek.behun@nic.cz>,
	"Green Wan" <green.wan@sifive.com>,
	"Sean Anderson" <seanga2@gmail.com>, "Lukas Auer" <lukas@auer.io>,
	"Brad Kim" <brad.kim@semifive.com>,
	"Zong Li" <zong.li@sifive.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"David Abdurachmanov" <david.abdurachmanov@sifive.com>,
	"Dimitri John Ledkov" <dimitri.ledkov@canonical.com>,
	"U-Boot Mailing List" <u-boot@lists.denx.de>,
	"Mark Kettenis" <mark.kettenis@xs4all.nl>
Subject: Re: [PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE
Date: Wed, 13 Oct 2021 12:05:52 -0600	[thread overview]
Message-ID: <CAPnjgZ0Jk9SuFw6m1ag9Gf8H-VHuG278neWhfzgqSnEAXoR5zA@mail.gmail.com> (raw)
In-Reply-To: <m3czo8x1xb.fsf@fitzsim.org>

Hi Thomas,

On Wed, 13 Oct 2021 at 11:36, Thomas Fitzsimmons <fitzsim@fitzsim.org> 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.

OK. Do you think you could submit a patch to do all this, including
some docs about the current situation?

Regards,
Simon

> Thomas