public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Anshul Dalal <anshuld@ti.com>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Anshul Dalal <anshuld@ti.com>
Cc: <u-boot@lists.denx.de>, <d-gole@ti.com>, <b-padhi@ti.com>,
	<vigneshr@ti.com>, <trini@konsulko.com>, <nm@ti.com>,
	<robertcnelson@gmail.com>, <w.egorov@phytec.de>,
	<francesco.dolcini@toradex.com>, <ggiordano@phytec.com>,
	<m-chawdhry@ti.com>, <afd@ti.com>, <bb@ti.com>, <u-kumar1@ti.com>,
	<devarsht@ti.com>, <xypron.glpk@gmx.de>
Subject: Re: [PATCH v10 05/11] arm: armv8: mmu: add mem_map_from_dram_banks
Date: Fri, 17 Oct 2025 18:17:09 +0530	[thread overview]
Message-ID: <DDKLWVUX1CPJ.3EMPE1DELU070@ti.com> (raw)
In-Reply-To: <CAC_iWj+pyDhYnaJE+eX8LP+Czu13+oH+H1XfMbH4wWgVqY6k2w@mail.gmail.com>

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@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@ti.com>
>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> Tested-by: Wadim Egorov <w.egorov@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.

Regards,
Anshul

  reply	other threads:[~2025-10-17 12:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-10 13:44 [PATCH v10 00/11] Add support for dynamic MMU configuration Anshul Dalal
2025-10-10 13:44 ` [PATCH v10 01/11] mach-k3: use minimal memory map for all K3 Anshul Dalal
2025-10-10 13:44 ` [PATCH v10 02/11] mach-k3: use custom enable_cache Anshul Dalal
2025-10-10 13:44 ` [PATCH v10 03/11] arm: armv8: mmu: export mmu_setup Anshul Dalal
2025-10-10 13:44 ` [PATCH v10 04/11] arm: armv8: invalidate dcache entries on dcache_enable Anshul Dalal
2025-10-10 13:44 ` [PATCH v10 05/11] arm: armv8: mmu: add mem_map_from_dram_banks Anshul Dalal
2025-10-17 12:09   ` Ilias Apalodimas
2025-10-17 12:47     ` Anshul Dalal [this message]
2025-10-17 13:00       ` Ilias Apalodimas
2025-10-10 13:44 ` [PATCH v10 06/11] mach-k3: map all banks using mem_map_from_dram_banks Anshul Dalal
2025-10-10 13:44 ` [PATCH v10 07/11] arm: armv8: mmu: add mmu_unmap_reserved_mem Anshul Dalal
2025-10-17 12:34   ` Ilias Apalodimas
2025-10-17 12:50     ` Anshul Dalal
2025-10-10 13:44 ` [PATCH v10 08/11] spl: split spl_board_fixups to arch/board specific Anshul Dalal
2025-10-10 13:44 ` [PATCH v10 09/11] mach-k3: add reserved memory fixups for next boot stage Anshul Dalal
2025-10-10 13:44 ` [PATCH v10 10/11] mach-k3: add carveouts for TFA and optee Anshul Dalal
2025-10-10 13:44 ` [PATCH v10 11/11] arm: mach-k3: reserve space for page table entries Anshul Dalal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DDKLWVUX1CPJ.3EMPE1DELU070@ti.com \
    --to=anshuld@ti.com \
    --cc=afd@ti.com \
    --cc=b-padhi@ti.com \
    --cc=bb@ti.com \
    --cc=d-gole@ti.com \
    --cc=devarsht@ti.com \
    --cc=francesco.dolcini@toradex.com \
    --cc=ggiordano@phytec.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=m-chawdhry@ti.com \
    --cc=nm@ti.com \
    --cc=robertcnelson@gmail.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=u-kumar1@ti.com \
    --cc=vigneshr@ti.com \
    --cc=w.egorov@phytec.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox