Re: [PATCH] airoha: rework RAM size handling to support multiple RAM size

[Christian Marangi <ansuelsmth@gmail.com>]

On Sun, Jul 27, 2025 at 03:03:30PM +0300, Mikhail Kshevetskiy wrote:
> 
> On 27.07.2025 14:58, Christian Marangi wrote:
> > On Thu, Jul 24, 2025 at 01:30:45PM +0300, Mikhail Kshevetskiy wrote:
> >> On 22.07.2025 21:44, Christian Marangi wrote:
> >>> There are multiple version of the same reference board with different
> >>> RAM size and it's not enough to base the RAM size entirely from DT. To
> >>> better support it use the get_ram_size way to scan for the actual RAM
> >>> size of Airoha SoC and increase the size of the memory map.
> >>>
> >>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> >>> ---
> >>>  arch/arm/mach-airoha/an7581/init.c | 23 +++++++++++++++++++----
> >>>  1 file changed, 19 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-airoha/an7581/init.c b/arch/arm/mach-airoha/an7581/init.c
> >>> index d149e0ee3c8..0f72365c4ab 100644
> >>> --- a/arch/arm/mach-airoha/an7581/init.c
> >>> +++ b/arch/arm/mach-airoha/an7581/init.c
> >>> @@ -2,10 +2,14 @@
> >>>  
> >>>  #include <fdtdec.h>
> >>>  #include <init.h>
> >>> +#include <linux/sizes.h>
> >>>  #include <sysreset.h>
> >>>  #include <asm/armv8/mmu.h>
> >>> +#include <asm/global_data.h>
> >>>  #include <asm/system.h>
> >>>  
> >>> +DECLARE_GLOBAL_DATA_PTR;
> >>> +
> >>>  int print_cpuinfo(void)
> >>>  {
> >>>  	printf("CPU:   Airoha AN7581\n");
> >>> @@ -14,12 +18,23 @@ int print_cpuinfo(void)
> >>>  
> >>>  int dram_init(void)
> >>>  {
> >>> -	return fdtdec_setup_mem_size_base();
> >>> +	int ret;
> >>> +
> >>> +	ret = fdtdec_setup_mem_size_base();
> >>> +	if (ret)
> >>> +		return ret;
> >>> +
> >>> +	gd->ram_size = get_ram_size((void *)gd->ram_base, SZ_8G);
> >> Can we use a memory size passed by airoha trusted firmware instead of
> >> playing with  get_ram_size()?
> >>
> > Hi I received some feedback from Airoha about this and sadly it's not
> > possible. There are too much version of ATF and only some of them
> > provide RAM size in some way or another. Also there isn't an exact HW
> > trap to read to know the RAM size hence raw testing the ram and not
> > depending externally is the only solution :(
> >
> > I will address all the other comments.
> great.
> >>> +
> >>> +	return 0;
> >>>  }
> >>>  
> >>>  int dram_init_banksize(void)
> >>>  {
> >>> -	return fdtdec_setup_memory_banksize();
> >>> +	gd->bd->bi_dram[0].start = gd->ram_base;
> >>> +	gd->bd->bi_dram[0].size = gd->ram_size;
> >> as I know u-boot can safely use only 2Gb of memory, thus it's better
> >>
> >>         #define CFG_MAX_MEM_MAPPED  SZ_2G
> >>

Sorry for coming back on this but by declaring CFG_MAX_MEM_MAPPED 
aren't we limiting the memory to 2gb? Also these info are passed to the
kernel so we are limiting the RAM also there. Am I wrong?

Also I notice the weak function dram_init_banksize is exactly the
current one with the usage of effective ram so I guess I can drop it
entirely?

Can you help me understand the usage of MAX_MEM_MAPPED and confirm this
doesn't limit the total RAM when loading the kernel? (we don't use ATAGS
as we use FDT)

> >> and replace above line with
> >>
> >>         gd->bd->bi_dram[0].size = get_effective_memsize();
> >>
> >>> +
> >>> +	return 0;
> >>>  }
> >>>  
> >>>  void reset_cpu(void)
> >>> @@ -32,12 +47,12 @@ static struct mm_region an7581_mem_map[] = {
> >>>  		/* DDR */
> >>>  		.virt = 0x80000000UL,
> >>>  		.phys = 0x80000000UL,
> >>> -		.size = 0x80000000UL,
> >>> +		.size = 0x200000000ULL,
> >>>  		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_OUTER_SHARE,
> >>>  	}, {
> >>>  		.virt = 0x00000000UL,
> >>>  		.phys = 0x00000000UL,
> >>> -		.size = 0x20000000UL,
> >>> +		.size = 0x40000000UL,
> >>>  		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> >>>  			 PTE_BLOCK_NON_SHARE |
> >>>  			 PTE_BLOCK_PXN | PTE_BLOCK_UXN

-- 
	Ansuel