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

[Andre Przywara]

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?

Cheers,
Andre