[U-Boot] [PATCH 2/2] arm64: mvebu: a8k: autodetect RAM size

[Baruch Siach]

Hi Stefan,

On Wed, Oct 31, 2018 at 02:29:50PM +0100, Stefan Roese wrote:
> On 28.10.18 13:30, Baruch Siach wrote:
> > Some Armada 8K boards like Macchiatobin and Clearfog GT-8K use RAM from
> > external DIMM. Hard coding the RAM size in the device-tree is not
> > convenient. Fortunately, the ATF that initializes the RAM knows the size
> > of RAM, and U-Boot can query the ATF using a SMC call.
> > 
> > This code in this commit is mostly taken from downstream Marvell U-Boot
> > code by Grzegorz Jaszczyk.
> > 
> > CONFIG_NR_DRAM_BANKS must be set to 2 to use more than 3GB RAM.
> > 
> > Cc: Grzegorz Jaszczyk <jaz at semihalf.com>
> > Signed-off-by: Baruch Siach <baruch at tkos.co.il>
> > ---
> >   arch/arm/mach-mvebu/arm64-common.c | 47 +++++++++++++++++++++++++++++-
> >   1 file changed, 46 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c
> > index f47273fde9c6..7ba7301c7a8c 100644
> > --- a/arch/arm/mach-mvebu/arm64-common.c
> > +++ b/arch/arm/mach-mvebu/arm64-common.c
> > @@ -7,6 +7,7 @@
> >   #include <dm.h>
> >   #include <fdtdec.h>
> >   #include <linux/libfdt.h>
> > +#include <linux/sizes.h>
> >   #include <pci.h>
> >   #include <asm/io.h>
> >   #include <asm/system.h>
> > @@ -45,15 +46,59 @@ const struct mbus_dram_target_info *mvebu_mbus_dram_info(void)
> >   /* DRAM init code ... */
> > +#define MV_SIP_DRAM_SIZE	0x82000010
> > +
> > +static u64 a8k_dram_scan_ap_sz(void)
> > +{
> > +	struct pt_regs pregs;
> > +
> > +	pregs.regs[0] = MV_SIP_DRAM_SIZE;
> > +	pregs.regs[1] = SOC_REGS_PHY_BASE;
> > +	smc_call(&pregs);
> > +
> > +	return pregs.regs[0];
> > +}
> > +
> > +static void a8k_dram_init_banksize(void)
> > +{
> > +	/*
> > +	 * Config 2 DRAM banks:
> > +	 * Bank 0 - max size 4G - 1G
> > +	 * Bank 1 - ram size - 4G + 1G
> > +	 */
> > +	phys_size_t max_bank0_size = SZ_4G - SZ_1G;
> > +
> > +	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> > +	if (gd->ram_size <= max_bank0_size) {
> > +		gd->bd->bi_dram[0].size = gd->ram_size;
> > +		return;
> > +	}
> > +
> > +	gd->bd->bi_dram[0].size = max_bank0_size;
> > +	if (CONFIG_NR_DRAM_BANKS > 1) {
> > +		gd->bd->bi_dram[1].start = SZ_4G;
> > +		gd->bd->bi_dram[1].size = gd->ram_size - max_bank0_size;
> > +	}
> 
> Is CONFIG_NR_DRAM_BANKS > 2 possible on one of these platforms?

I tested with a 16GB SO-DIMM on Clearfog GT-8K. Before this change only 2GB 
were visible to Linux. With this change, and with CONFIG_NR_DRAM_BANKS=2, I am 
able to lock 15.5GB of RAM for write/read using the memtester utility.

I didn't test on Macchaitobin because I don't have a >3GB DIMM handy.

> Also I find the splitting of the available RAM size (detected via ATF)
> onto the multiple banks not intuitive. Could you please explain the
> 1GiB hole in the bi_dram[x] struct? I suspect that this might have
> something to do with the internal register address space. But I fail
> to see, if this should be reflected in these bi_dram[x] values.

As I understand, that is how the ATF code configures the hardware address 
space. Peripheral devices registers are in the 0xFxxxxxxx area, as you can see 
in the Armada 8040 components .dtsi.

Is there any other way to transfer this information to the kernel?

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -