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

[Stefan Roese]

Hi Baruch,

On 31.10.18 15:50, Baruch Siach wrote:
> 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?

It seems that I was wrong with my assumption that the DT blob
fixup in U-Boot is made on the base of gd->ram_size. The changes
to bi_dram[] are necessary for this DT fixup.

It would be great though, if you could add a comment mentioning
the reason for the necessary gap in the memory layout in the commit
text and the comment in the code though.

Thanks,
Stefan