[PATCH v2 2/4] sunxi: binman: Move BL31 and SCP firmware addresses to Kconfig

[Simon Glass]

Hi Andre,

On Wed, 25 Jan 2023 at 05:24, Andre Przywara <andre.przywara at arm.com> wrote:
>
> On Tue, 24 Jan 2023 15:44:30 -0700
> Simon Glass <sjg at chromium.org> wrote:
>
> > Hi Samuel,
> >
> > On Mon, 23 Jan 2023 at 22:22, Samuel Holland <samuel at sholland.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On 1/23/23 12:42, Simon Glass wrote:
> > > > HI Samuel,
> > > >
> > > > On Sun, 22 Jan 2023 at 14:16, Samuel Holland <samuel at sholland.org> wrote:
> > > >>
> > > >> This is easier to read than the #ifdef staircase, provides better
> > > >> visibility into the memory map (alongside the other Kconfig
> > > >> definitions), and allows these addresses to be reused from code.
> > > >>
> > > >> Signed-off-by: Samuel Holland <samuel at sholland.org>
> > > >> ---
> > > >>
> > > >> Changes in v2:
> > > >>  - New patch for v2, split from the .dtsi changes
> > > >>
> > > >>  arch/arm/dts/sunxi-u-boot.dtsi | 24 +++++++-----------------
> > > >>  arch/arm/mach-sunxi/Kconfig    | 17 +++++++++++++++++
> > > >>  2 files changed, 24 insertions(+), 17 deletions(-)
> > > >
> > > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > > >
> > > > Is this info not in the device tree?
> > >
> > > It is not. These values do not correspond to any hardware property. For
> > > example, on A64/H5/H6, BL31 and SCP share a single "SRAM A2" region. The
> > > division of the SRAM between them was chosen arbitrarily (though now it
> > > is ABI). How would you represent this in the devicetree?
> >
> > I would probably add a new node for the SRAM, with partition
> > information within that, as is done for MTD.
>
> I am probably missing something, but why would we want to do that? Looks a
> bit like a solution looking for a problem to me.
> The split and assignment of the SRAM regions is an agreement between BL31,
> crust and U-Boot, with U-Boot taking the lead here, because it's the
> initial loader of those components, and does the packaging.
> So what would putting those addresses in the generic DT bring us, aside
> from more complicated code to look them up?

Well I just answered the question. I'm not necessarily advocating for it.

We could perhaps use the new Transfer List to pass this info instead.
But if separate projects have implicit hard-coded values it is going
to lead to pain when they conflict. It is better to set this all up at
packaging time.

Regards,
Simon