[PATCH v10 05/11] arm: armv8: mmu: add mem_map_from_dram_banks

[Ilias Apalodimas]

On Fri, 17 Oct 2025 at 15:47, Anshul Dalal <anshuld at ti.com> wrote:
>
> Hello Ilias,
>
> On Fri Oct 17, 2025 at 5:39 PM IST, Ilias Apalodimas wrote:
> > Hi Anshul,
> >
> > On Fri, 10 Oct 2025 at 16:44, Anshul Dalal <anshuld at ti.com> wrote:
> >>
> >> For armv8, U-Boot uses a static map defined as 'mem_map' for configuring
> >> the MMU as part of mmu_setup.
> >>
> >> But since the exact configuration of memory banks might not be known at
> >> build time, many platforms such as imx9, versal2 etc. utilize
> >> gd->bd->bi_dram to configure the static map at runtime.
> >>
> >> Therefore this patch adds a new API mem_map_from_dram_banks that
> >> modifies the static map in a similar way. Allowing the caller to map all
> >> dram banks by just passing the index to last entry in their mem_map and
> >> it's length.
> >>
> >> Reviewed-by: Dhruva Gole <d-gole at ti.com>
> >> Signed-off-by: Anshul Dalal <anshuld at ti.com>
> >> Tested-by: Wadim Egorov <w.egorov at phytec.de>
> >> ---
> >>  arch/arm/cpu/armv8/cache_v8.c    | 28 ++++++++++++++++++++++++++++
> >>  arch/arm/include/asm/armv8/mmu.h | 11 +++++++++++
> >>  2 files changed, 39 insertions(+)
> >>
> >> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
> >> index 74c78cb2fb0..9b3c37dae82 100644
> >> --- a/arch/arm/cpu/armv8/cache_v8.c
> >> +++ b/arch/arm/cpu/armv8/cache_v8.c
> >> @@ -58,6 +58,34 @@ static int get_effective_el(void)
> >>         return el;
> >>  }
> >>
> >> +int mem_map_from_dram_banks(unsigned int index, unsigned int len, u64 attrs)
> >> +{
> >> +       unsigned int i;
> >> +       int ret = fdtdec_setup_memory_banksize();
> >> +
> >> +       if (ret) {
> >> +               log_err("%s: Failed to setup dram banks\n", __func__);
> >> +               return ret;
> >> +       }
> >> +
> >> +       if (index + CONFIG_NR_DRAM_BANKS >= len) {
> >> +               log_err("%s: Provided mem_map array has insufficient size for DRAM entries\n",
> >> +                       __func__);
> >> +               return -ENOMEM;
> >> +       }
> >> +
> >> +       for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
> >> +               mem_map[index].virt = gd->bd->bi_dram[i].start;
> >> +               mem_map[index].phys = gd->bd->bi_dram[i].start;
> >> +               mem_map[index].size = gd->bd->bi_dram[i].size;
> >> +               mem_map[index].attrs = attrs;
> >> +               index++;
> >> +       }
> >> +
> >> +       memset(&mem_map[index], 0, sizeof(mem_map[index]));
> >> +
> >> +       return 0;
> >> +}
> >
> > Is there a reason we add all the memory maps now and remove them later
> > with mmu_unmap_reserved_mem(). IOW we could add the DT parsing in this
> > function and not map the 'no-map' addresses to begin with.
> > Unless someone changes the DTB on the fly ?
> >
>
> There are two reasons for doing it this way:
>
> 1. Modifying mem_map directly makes creating multiple carveouts quite
> complex with the logic for handling all the edge cases, for example see
> v4[1] of this series. It's much simpler to use the MMU APIs instead
> after calling mmu_setup with everything mapped in mem_map.
>
> 2. We can't blindly unmap all 'no-map' regions since some regions that
> would be 'no-map' in the kernel's context are required at U-Boot, like
> the memory pools for remote cores that rely on U-Boot to load their
> firmware.

Fair enough. Since you'll send a V11 adding this on the description
helps. Also mention that this should all happen before enabling the
caches, so mapping memory that is marked as no-map; shouldn't cause
any crashes

Thanks
/Ilias
>
> Regards,
> Anshul