Hi Andre, On Wed, 25 Jan 2023 at 05:24, Andre Przywara <andre.przyw...@arm.com> wrote: > > On Tue, 24 Jan 2023 15:44:30 -0700 > Simon Glass <s...@chromium.org> wrote: > > > Hi Samuel, > > > > On Mon, 23 Jan 2023 at 22:22, Samuel Holland <sam...@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 <sam...@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 <sam...@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 <s...@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