[PATCH v5 0/4] Add support for dynamic MMU configuration

[PATCH v5 0/4] Add support for dynamic MMU configuration

[Anshul Dalal]

Hi all,

In u-boot we only provide a single MMU table for all k3 platforms, this   does
not scale for devices where atf and optee lie outside the range   0x80000000 -
0x80080000 and 0x9e780000 - 0xa0000000 respectively.

There are also issues for devices with < 2GiB of memory (eg am62SiP with 512MiB
of RAM) as the maximum size is hardcoded to 2GiB. Furthermore higher DDR banks
are mapped even for devices with NR_DRAM_BANKS < 2.

Therefore this patch set adds the required functionality to create the MMU table
at runtime with proper configuration for the spl stage as well an added entry
for the framebuffer for supported platforms.

The patch set has been build tested on all effected platforms but boot-tested
only on TI's K3 EVMs and the beagleplay.

The following effected boards have not been boot tested:
 - phycore-am62a
 - phycore-am62x
 - phycore-am64x
 - verdin-am62
 - iot2050

Best Wishes,
Anshul
---
Changes in v5:
 - Don't create carveouts for every reserved-memory node
 - Only create carveouts for ATF/OP-TEE
 - Expand the call to k3_mem_map_init to vendor boards as well
 - Map area for framebuffer for CONFIG_VIDEO=y platforms
v4: https://lore.kernel.org/u-boot/20250618124210.1936140-1-anshuld@ti.com/

Changes for v4:
 - Add call to k3_mem_map_init for beagleplay
 - Mark reserved regions as non-cacheable
 - More debug logs
v3: https://lore.kernel.org/u-boot/20250617135844.2873701-1-anshuld@ti.com/

Changes for v3:
 - Remove unused memory regions in SPL's map
 - Add runtime addition of MMU entry for the framebuffer in SPL
 - Refactor k3_mem_map_init to use standard u-boot APIs
 - Unmap reserved-memory regions instead of keeping them uncached
v2: https://lore.kernel.org/u-boot/20250610160833.1705534-1-anshuld@ti.com/

Changes in v2:
- Removed dependency to:
  https://lore.kernel.org/u-boot/20250522150941.563959-1-anshuld@ti.com/
v1: https://lore.kernel.org/u-boot/20250602120054.1466951-1-anshuld@ti.com/
---
Anshul Dalal (4):
  mach-k3: use minimal MMU table for all k3
  mach-k3: add runtime configuration of MMU table
  mach-k3: add dynamic mmu fixups for SPL stage
  board: add call to k3_mem_map_init for all k3 boards

 arch/arm/mach-k3/arm64/arm64-mmu.c           | 182 ++++++++++++++++---
 arch/arm/mach-k3/common.c                    |  17 +-
 arch/arm/mach-k3/include/mach/k3-ddr.h       |   1 +
 arch/arm/mach-k3/r5/common.c                 |   5 +
 board/beagle/beagleplay/beagleplay.c         |   9 +-
 board/phytec/phycore_am62ax/phycore-am62ax.c |   9 +-
 board/phytec/phycore_am62x/phycore-am62x.c   |   3 +-
 board/phytec/phycore_am64x/phycore-am64x.c   |   3 +-
 board/siemens/iot2050/board.c                |   3 +-
 board/ti/common/k3-ddr.c                     |   9 +-
 board/toradex/verdin-am62/verdin-am62.c      |   3 +-
 11 files changed, 211 insertions(+), 33 deletions(-)

-- 
2.49.0

[PATCH v5 1/4] mach-k3: use minimal MMU table for all k3

[Anshul Dalal]

This patch replaces the existing MMU table with a minimal bootable table
(at least till SPL) that could be modified at runtime as per the
device-tree and the CONFIG_K3_*_LOAD_ADDR.

The 128MiB region starting from SPL_TEXT_BASE is mapped for use by the
A-core SPL. 128MiB provides enough space for future use cases such as
falcon boot from the A-Core SPL etc.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 arch/arm/mach-k3/arm64/arm64-mmu.c | 38 ++++++++++++------------------
 1 file changed, 15 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-k3/arm64/arm64-mmu.c b/arch/arm/mach-k3/arm64/arm64-mmu.c
index 0e07b1b7ce0..5c29df4fe6f 100644
--- a/arch/arm/mach-k3/arm64/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64/arm64-mmu.c
@@ -12,41 +12,33 @@
 #include <asm/system.h>
 #include <asm/armv8/mmu.h>
 
-struct mm_region k3_mem_map[] = {
-	{
+/* We need extra 5 entries for:
+ * SoC peripherals, flash, atf-carveout, tee-carveout and the sentinel value.
+ */
+#define K3_MMU_REGIONS_COUNT ((CONFIG_NR_DRAM_BANKS) + 5)
+
+struct mm_region k3_mem_map[K3_MMU_REGIONS_COUNT] = {
+	{ /* SoC Peripherals */
 		.virt = 0x0UL,
 		.phys = 0x0UL,
 		.size = 0x80000000UL,
 		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 			 PTE_BLOCK_NON_SHARE |
 			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
-	}, {
-		.virt = 0x80000000UL,
-		.phys = 0x80000000UL,
-		.size = 0x1e780000UL,
-		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-			 PTE_BLOCK_INNER_SHARE
-	}, {
-		.virt = 0xa0000000UL,
-		.phys = 0xa0000000UL,
-		.size = 0x60000000UL,
-		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-			 PTE_BLOCK_INNER_SHARE
-	}, {
-		.virt = 0x880000000UL,
-		.phys = 0x880000000UL,
-		.size = 0x80000000UL,
-		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-			 PTE_BLOCK_INNER_SHARE
-	}, {
+	}, { /* Flash peripherals */
 		.virt = 0x500000000UL,
 		.phys = 0x500000000UL,
 		.size = 0x380000000UL,
 		.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 			 PTE_BLOCK_NON_SHARE |
 			 PTE_BLOCK_PXN | PTE_BLOCK_UXN
-	}, {
-		/* List terminator */
+	}, { /* Map SPL load region and the next 128MiB as cacheable */
+		.virt = CONFIG_SPL_TEXT_BASE,
+		.phys = CONFIG_SPL_TEXT_BASE,
+		.size = SZ_128M,
+		.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+			 PTE_BLOCK_INNER_SHARE
+	}, { /* List terminator */
 		0,
 	}
 };
-- 
2.49.0

[PATCH v5 2/4] mach-k3: add runtime configuration of MMU table

[Anshul Dalal]

k3_mem_map is used by u-boot to configure the MMU on k3 devices but
currently it's a static array which does not scale for platforms with
non-standard load addresses for ATF and OP-TEE. Additionally on systems
with limited DRAM, more space is mapped than is available on the device.

Therefore this patch adds a new k3_mem_map_init function which can
be called from dram_init to configure the table at runtime where we
can query the required DDR information and reserved regions from the
device-tree.

A dummy implementation is also added in r5/common.c to allow the build
to pass without masking each call to k3_mem_map_init behind an ifdef
CONFIG_ARM64.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 arch/arm/mach-k3/arm64/arm64-mmu.c     | 133 +++++++++++++++++++++++++
 arch/arm/mach-k3/include/mach/k3-ddr.h |   1 +
 arch/arm/mach-k3/r5/common.c           |   5 +
 board/ti/common/k3-ddr.c               |   9 +-
 4 files changed, 147 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/arm64/arm64-mmu.c b/arch/arm/mach-k3/arm64/arm64-mmu.c
index 5c29df4fe6f..49dd6fcb23b 100644
--- a/arch/arm/mach-k3/arm64/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64/arm64-mmu.c
@@ -11,6 +11,9 @@
 
 #include <asm/system.h>
 #include <asm/armv8/mmu.h>
+#include <mach/k3-ddr.h>
+
+DECLARE_GLOBAL_DATA_PTR;
 
 /* We need extra 5 entries for:
  * SoC peripherals, flash, atf-carveout, tee-carveout and the sentinel value.
@@ -44,3 +47,133 @@ struct mm_region k3_mem_map[K3_MMU_REGIONS_COUNT] = {
 };
 
 struct mm_region *mem_map = k3_mem_map;
+
+static void k3_mmu_add_cachable_entry(u64 start, u64 end, unsigned int *map_idx)
+{
+	if (start >= end)
+		return;
+
+	k3_mem_map[*map_idx].virt = start,
+	k3_mem_map[*map_idx].phys = start,
+	k3_mem_map[*map_idx].size = end - start,
+	k3_mem_map[*map_idx].attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+				     PTE_BLOCK_INNER_SHARE;
+	(*map_idx)++;
+}
+
+/* It is assumed that if ATF and OPTEE are loaded in DDR, they are loaded to
+ * first bank only
+ */
+static int k3_setup_first_mem_bank(unsigned int *map_idx)
+{
+	struct fdt_resource mem, atf, tee, rsvd1, rsvd2;
+	void *fdt = (void *)gd->fdt_blob;
+	fdt_size_t size;
+	int ret = 0;
+
+	mem.start = gd->ram_base;
+	mem.end = mem.start + gd->ram_size;
+
+	atf.start = CONFIG_K3_ATF_LOAD_ADDR;
+	ret = fdt_path_offset(fdt, "/reserved-memory/tfa");
+	if (ret < 0)
+		return ret;
+	fdtdec_get_addr_size(fdt, ret, "reg", &size);
+	atf.end = atf.start + size;
+
+	tee.start = CONFIG_K3_OPTEE_LOAD_ADDR;
+	ret = fdt_path_offset(fdt, "/reserved-memory/optee");
+	if (ret < 0)
+		return ret;
+	fdtdec_get_addr_size(fdt, ret, "reg", &size);
+	tee.end = tee.start + size;
+
+	/* set reserved region lower in ddr as rsvd1 and other as rsvd2 */
+	if (atf.start < tee.start)
+		rsvd1 = atf, rsvd2 = tee;
+	else
+		rsvd1 = tee, rsvd2 = atf;
+
+	if (rsvd2.start < mem.start) {
+		/* both reserved regions lie outside DDR */
+		k3_mmu_add_cachable_entry(mem.start, mem.end, map_idx);
+		return 0;
+	}
+
+	if (rsvd1.start >= mem.start) {
+		k3_mmu_add_cachable_entry(mem.start, rsvd1.start, map_idx);
+		k3_mmu_add_cachable_entry(rsvd1.end, rsvd2.start, map_idx);
+	} else {
+		k3_mmu_add_cachable_entry(mem.start, rsvd2.start, map_idx);
+	}
+
+	k3_mmu_add_cachable_entry(rsvd2.end, mem.end, map_idx);
+
+	return 0;
+}
+
+static int k3_setup_extra_mem_banks(unsigned int *map_idx)
+{
+	unsigned int bank;
+	int ret;
+
+	ret = fdtdec_setup_memory_banksize();
+	if (ret)
+		return ret;
+
+	for (bank = 1; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+		k3_mmu_add_cachable_entry(gd->bd->bi_dram[bank].start,
+					  gd->bd->bi_dram[bank].start +
+						  gd->bd->bi_dram[bank].size,
+					  map_idx);
+	}
+
+	return 0;
+}
+
+static int k3_uboot_mem_map_init(unsigned int *map_idx)
+{
+	int ret;
+
+	/* Overwrite the 128MiB SPL entry */
+	(*map_idx)--;
+
+	ret = k3_setup_first_mem_bank(map_idx);
+	if (ret)
+		return ret;
+
+	if (CONFIG_NR_DRAM_BANKS > 1)
+		ret = k3_setup_extra_mem_banks(map_idx);
+
+	return ret;
+}
+
+int k3_mem_map_init(void)
+{
+	int ret = 0;
+	unsigned int map_idx, i;
+
+	for (i = 0; i < K3_MMU_REGIONS_COUNT; i++)
+		if (k3_mem_map[i].virt == CONFIG_SPL_TEXT_BASE)
+			map_idx = i;
+
+	map_idx++;
+
+	ret = k3_uboot_mem_map_init(&map_idx);
+	if (ret)
+		return ret;
+
+	k3_mem_map[map_idx] = (const struct mm_region){ 0 };
+
+	debug("%s: MMU Table configured as:\n", __func__);
+	debug("   |virt start\t\t|virt end\t|phys\t\t|size\t\t|attrs:\n");
+	for (i = 0; i < map_idx; i++) {
+		debug("%2d: 0x%-12llx\t0x%-12llx\t0x%-12llx\t0x%-12llx\t0x%llx\n",
+		      i, k3_mem_map[i].virt,
+		      k3_mem_map[i].virt + k3_mem_map[i].size,
+		      k3_mem_map[i].phys, k3_mem_map[i].size,
+		      k3_mem_map[i].attrs);
+	}
+
+	return 0;
+}
diff --git a/arch/arm/mach-k3/include/mach/k3-ddr.h b/arch/arm/mach-k3/include/mach/k3-ddr.h
index 39e6725bb9b..b3ca6adb6c7 100644
--- a/arch/arm/mach-k3/include/mach/k3-ddr.h
+++ b/arch/arm/mach-k3/include/mach/k3-ddr.h
@@ -13,5 +13,6 @@ int dram_init_banksize(void);
 
 void fixup_ddr_driver_for_ecc(struct spl_image_info *spl_image);
 void fixup_memory_node(struct spl_image_info *spl_image);
+int k3_mem_map_init(void);
 
 #endif /* _K3_DDR_H_ */
diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
index 0b6604039f3..2d9849efb46 100644
--- a/arch/arm/mach-k3/r5/common.c
+++ b/arch/arm/mach-k3/r5/common.c
@@ -136,6 +136,11 @@ void release_resources_for_core_shutdown(void)
 	}
 }
 
+__weak int k3_mem_map_init(void)
+{
+	return 0;
+}
+
 void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
 {
 	typedef void __noreturn (*image_entry_noargs_t)(void);
diff --git a/board/ti/common/k3-ddr.c b/board/ti/common/k3-ddr.c
index a8425da8de5..54242734ac9 100644
--- a/board/ti/common/k3-ddr.c
+++ b/board/ti/common/k3-ddr.c
@@ -7,6 +7,7 @@
 #include <dm/uclass.h>
 #include <k3-ddrss.h>
 #include <spl.h>
+#include <mach/k3-ddr.h>
 
 #include "k3-ddr.h"
 
@@ -15,8 +16,14 @@ int dram_init(void)
 	s32 ret;
 
 	ret = fdtdec_setup_mem_size_base_lowest();
-	if (ret)
+	if (ret) {
 		printf("Error setting up mem size and base. %d\n", ret);
+		return ret;
+	}
+
+	ret = k3_mem_map_init();
+	if (ret)
+		printf("Error setting up MMU table. %d\n", ret);
 
 	return ret;
 }
-- 
2.49.0

Re: [PATCH v5 2/4] mach-k3: add runtime configuration of MMU table

[Ilias Apalodimas]

Hi Anshul,

On Thu Jul 3, 2025 at 4:35 PM EEST, Anshul Dalal wrote:
> k3_mem_map is used by u-boot to configure the MMU on k3 devices but
> currently it's a static array which does not scale for platforms with
> non-standard load addresses for ATF and OP-TEE. Additionally on systems
> with limited DRAM, more space is mapped than is available on the device.
>
> Therefore this patch adds a new k3_mem_map_init function which can
> be called from dram_init to configure the table at runtime where we
> can query the required DDR information and reserved regions from the
> device-tree.

Is this a problem for k3 only? This kind of code should be aimed at the mmu
support and improving armv8 overall, not specific platforms

>
> A dummy implementation is also added in r5/common.c to allow the build
> to pass without masking each call to k3_mem_map_init behind an ifdef
> CONFIG_ARM64.
>
> Signed-off-by: Anshul Dalal <anshuld@ti.com>

[...]

> +
> +static void k3_mmu_add_cachable_entry(u64 start, u64 end, unsigned int *map_idx)
> +{
> +	if (start >= end)
> +		return;
> +
> +	k3_mem_map[*map_idx].virt = start,
> +	k3_mem_map[*map_idx].phys = start,
> +	k3_mem_map[*map_idx].size = end - start,
> +	k3_mem_map[*map_idx].attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> +				     PTE_BLOCK_INNER_SHARE;
> +	(*map_idx)++;
> +}

Doesn't this need a break-before-make?
Also why does it have to be a board specific function? Is there something mmu_change_region_attr()
doesn't do ?

> +
> +/* It is assumed that if ATF and OPTEE are loaded in DDR, they are loaded to
> + * first bank only
> +
> +static int k3_setup_extra_mem_banks(unsigned int *map_idx)
> +{
> +	unsigned int bank;
> +	int ret;
> +
> +	ret = fdtdec_setup_memory_banksize();
> +	if (ret)
> +		return ret;
> +
> +	for (bank = 1; bank < CONFIG_NR_DRAM_BANKS; bank++) {
> +		k3_mmu_add_cachable_entry(gd->bd->bi_dram[bank].start,
> +					  gd->bd->bi_dram[bank].start +
> +						  gd->bd->bi_dram[bank].size,
> +					  map_idx);
> +	}
> +

ditto

> +static int k3_uboot_mem_map_init(unsigned int *map_idx)
> +{
> +	int ret;
> +
> +	/* Overwrite the 128MiB SPL entry */
> +	(*map_idx)--;
> +
> +	ret = k3_setup_first_mem_bank(map_idx);
> +	if (ret)
> +		return ret;
> +
> +	if (CONFIG_NR_DRAM_BANKS > 1)
> +		ret = k3_setup_extra_mem_banks(map_idx);
> +
> +	return ret;
> +}
> +
> diff --git a/arch/arm/mach-k3/include/mach/k3-ddr.h b/arch/arm/mach-k3/include/mach/k3-ddr.h

[..]

Thanks
/Ilias

Re: [PATCH v5 2/4] mach-k3: add runtime configuration of MMU table

[Anshul Dalal]

On Tue Jul 8, 2025 at 1:45 AM IST, Ilias Apalodimas wrote:
> Hi Anshul,
>
> On Thu Jul 3, 2025 at 4:35 PM EEST, Anshul Dalal wrote:
>> k3_mem_map is used by u-boot to configure the MMU on k3 devices but
>> currently it's a static array which does not scale for platforms with
>> non-standard load addresses for ATF and OP-TEE. Additionally on systems
>> with limited DRAM, more space is mapped than is available on the device.
>>
>> Therefore this patch adds a new k3_mem_map_init function which can
>> be called from dram_init to configure the table at runtime where we
>> can query the required DDR information and reserved regions from the
>> device-tree.
>
> Is this a problem for k3 only? This kind of code should be aimed at the mmu
> support and improving armv8 overall, not specific platforms
>

In K3 we try to support a wide array of SoCs with a single memory map.
Since the requirements are similar across all K3 devices i.e:

1. Map all DDR banks
2. Create carveouts for ATF and OPTEE
3. At SPL stage, map framebuffer region for VIDEO enabled devices

Of the 3 here, #1 and #3 could be useful for ARMv8 overall but #2 is
quite specific to the platform's boot flow.

As I see it, since most of the existing platforms are using a static map
and thus won't benefit from a generic way to handle #1 and #3. The few
that do have runtime fixups for the memory map, only seem to have #1 in
common (imx and renesas).

>>
>> A dummy implementation is also added in r5/common.c to allow the build
>> to pass without masking each call to k3_mem_map_init behind an ifdef
>> CONFIG_ARM64.
>>
>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>
> [...]
>
>> +
>> +static void k3_mmu_add_cachable_entry(u64 start, u64 end, unsigned int *map_idx)
>> +{
>> +	if (start >= end)
>> +		return;
>> +
>> +	k3_mem_map[*map_idx].virt = start,
>> +	k3_mem_map[*map_idx].phys = start,
>> +	k3_mem_map[*map_idx].size = end - start,
>> +	k3_mem_map[*map_idx].attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>> +				     PTE_BLOCK_INNER_SHARE;
>> +	(*map_idx)++;
>> +}
>
> Doesn't this need a break-before-make?
> Also why does it have to be a board specific function? Is there something mmu_change_region_attr()
> doesn't do ?
>

Oh, I wasn't aware of that API, I'll update in my next revision.

Thanks for the review,
Anshul

Re: [PATCH v5 2/4] mach-k3: add runtime configuration of MMU table

[Ilias Apalodimas]

On Thu, 14 Aug 2025 at 17:12, Anshul Dalal <anshuld@ti.com> wrote:
>
> On Tue Jul 8, 2025 at 1:45 AM IST, Ilias Apalodimas wrote:
> > Hi Anshul,
> >
> > On Thu Jul 3, 2025 at 4:35 PM EEST, Anshul Dalal wrote:
> >> k3_mem_map is used by u-boot to configure the MMU on k3 devices but
> >> currently it's a static array which does not scale for platforms with
> >> non-standard load addresses for ATF and OP-TEE. Additionally on systems
> >> with limited DRAM, more space is mapped than is available on the device.
> >>
> >> Therefore this patch adds a new k3_mem_map_init function which can
> >> be called from dram_init to configure the table at runtime where we
> >> can query the required DDR information and reserved regions from the
> >> device-tree.
> >
> > Is this a problem for k3 only? This kind of code should be aimed at the mmu
> > support and improving armv8 overall, not specific platforms
> >
>
> In K3 we try to support a wide array of SoCs with a single memory map.
> Since the requirements are similar across all K3 devices i.e:
>
> 1. Map all DDR banks
> 2. Create carveouts for ATF and OPTEE
> 3. At SPL stage, map framebuffer region for VIDEO enabled devices
>
> Of the 3 here, #1 and #3 could be useful for ARMv8 overall but #2 is
> quite specific to the platform's boot flow.

Option is also very common across platforms. I don't remember the
details, but we do have code adding op-tee reserved-memory nodes etc.

>
> As I see it, since most of the existing platforms are using a static map
> and thus won't benefit from a generic way to handle #1 and #3.

 I think this is just a limitation of the current code. I've seen
enough platforms only mapping one of their banks for example.
I am not asking you to fix the entire codebase, just extend it to the
part were k3 is supported, but anyone who wishes to do something
similar can re-use your work

> The few
> that do have runtime fixups for the memory map, only seem to have #1 in
> common (imx and renesas).
>
> >>
> >> A dummy implementation is also added in r5/common.c to allow the build
> >> to pass without masking each call to k3_mem_map_init behind an ifdef
> >> CONFIG_ARM64.
> >>
> >> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> >
> > [...]
> >
> >> +
> >> +static void k3_mmu_add_cachable_entry(u64 start, u64 end, unsigned int *map_idx)
> >> +{
> >> +    if (start >= end)
> >> +            return;
> >> +
> >> +    k3_mem_map[*map_idx].virt = start,
> >> +    k3_mem_map[*map_idx].phys = start,
> >> +    k3_mem_map[*map_idx].size = end - start,
> >> +    k3_mem_map[*map_idx].attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> >> +                                 PTE_BLOCK_INNER_SHARE;
> >> +    (*map_idx)++;
> >> +}
> >
> > Doesn't this need a break-before-make?
> > Also why does it have to be a board specific function? Is there something mmu_change_region_attr()
> > doesn't do ?
> >
>
> Oh, I wasn't aware of that API, I'll update in my next revision.

Great, thanks.

>
> Thanks for the review,

yw
/Ilias
> Anshul

[PATCH v5 3/4] mach-k3: add dynamic mmu fixups for SPL stage

[Anshul Dalal]

On platforms with spl splash support such as 62p and 62x
(CONFIG_VIDEO=y), the top of DDR is reserved for the framebuffer.

The size of the framebuffer is computed at runtime by video_reserve.
During the MMU configuration an entry corresponding to the framebuffer
should be dynamically created to properly allocate the required space
for the framebuffer.

Therefore this patch adds k3_spl_mem_map_init which adds the required
MMU entry by querying the gd after the framebuffer size has been
computed in spl_reserve_video_from_ram_top.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 arch/arm/mach-k3/arm64/arm64-mmu.c | 13 ++++++++++++-
 arch/arm/mach-k3/common.c          | 17 ++++++++++++++---
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-k3/arm64/arm64-mmu.c b/arch/arm/mach-k3/arm64/arm64-mmu.c
index 49dd6fcb23b..b1b287f2114 100644
--- a/arch/arm/mach-k3/arm64/arm64-mmu.c
+++ b/arch/arm/mach-k3/arm64/arm64-mmu.c
@@ -131,6 +131,13 @@ static int k3_setup_extra_mem_banks(unsigned int *map_idx)
 	return 0;
 }
 
+static void k3_spl_mem_map_init(unsigned int *map_idx)
+{
+	if (CONFIG_IS_ENABLED(VIDEO))
+		k3_mmu_add_cachable_entry(gd_video_bottom(), gd_video_top(),
+					  map_idx);
+}
+
 static int k3_uboot_mem_map_init(unsigned int *map_idx)
 {
 	int ret;
@@ -159,7 +166,11 @@ int k3_mem_map_init(void)
 
 	map_idx++;
 
-	ret = k3_uboot_mem_map_init(&map_idx);
+	if (xpl_phase() == PHASE_SPL)
+		k3_spl_mem_map_init(&map_idx);
+	else
+		ret = k3_uboot_mem_map_init(&map_idx);
+
 	if (ret)
 		return ret;
 
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index fc230f180d0..e72413b9803 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -32,6 +32,7 @@
 #include <dm/device-internal.h>
 
 #include <asm/arch/k3-qos.h>
+#include <mach/k3-ddr.h>
 
 struct ti_sci_handle *get_ti_sci_handle(void)
 {
@@ -224,16 +225,26 @@ void spl_enable_cache(void)
 
 	dram_init();
 
-	/* reserve TLB table */
-	gd->arch.tlb_size = PGTABLE_SIZE;
-
 	gd->ram_top += get_effective_memsize();
+	/* keep ram_top in the 32-bit address space */
+	if (gd->ram_top >= 0x100000000)
+		gd->ram_top = (phys_addr_t)0x100000000;
+
 	gd->relocaddr = gd->ram_top;
 
 	ret = spl_reserve_video_from_ram_top();
 	if (ret)
 		panic("Failed to reserve framebuffer memory (%d)\n", ret);
 
+	if (IS_ENABLED(CONFIG_ARM64)) {
+		ret = k3_mem_map_init();
+		if (ret)
+			panic("Failed to setup MMU table (%d)\n", ret);
+	}
+
+	/* reserve TLB table */
+	gd->arch.tlb_size = PGTABLE_SIZE;
+
 	gd->arch.tlb_addr = gd->relocaddr - gd->arch.tlb_size;
 	gd->arch.tlb_addr &= ~(0x10000 - 1);
 	debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
-- 
2.49.0

Re: [PATCH v5 3/4] mach-k3: add dynamic mmu fixups for SPL stage

[Ilias Apalodimas]

Hi Anshul,

On Thu Jul 3, 2025 at 4:35 PM EEST, Anshul Dalal wrote:
> On platforms with spl splash support such as 62p and 62x
> (CONFIG_VIDEO=y), the top of DDR is reserved for the framebuffer.
>
> The size of the framebuffer is computed at runtime by video_reserve.
> During the MMU configuration an entry corresponding to the framebuffer
> should be dynamically created to properly allocate the required space
> for the framebuffer.
>
> Therefore this patch adds k3_spl_mem_map_init which adds the required
> MMU entry by querying the gd after the framebuffer size has been
> computed in spl_reserve_video_from_ram_top.
>
> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> ---
>  arch/arm/mach-k3/arm64/arm64-mmu.c | 13 ++++++++++++-
>  arch/arm/mach-k3/common.c          | 17 ++++++++++++++---
>  2 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-k3/arm64/arm64-mmu.c b/arch/arm/mach-k3/arm64/arm64-mmu.c
> index 49dd6fcb23b..b1b287f2114 100644
> --- a/arch/arm/mach-k3/arm64/arm64-mmu.c
> +++ b/arch/arm/mach-k3/arm64/arm64-mmu.c
> @@ -131,6 +131,13 @@ static int k3_setup_extra_mem_banks(unsigned int *map_idx)
>  	return 0;
>  }
>
> +static void k3_spl_mem_map_init(unsigned int *map_idx)
> +{
> +	if (CONFIG_IS_ENABLED(VIDEO))
> +		k3_mmu_add_cachable_entry(gd_video_bottom(), gd_video_top(),
> +					  map_idx);
> +}
> +

I don't know wnough details for this board, but generally speaking we should be doing
this commonly for all arm64 platforms. There's mmu code for that. Can you explain why
this is only useful to k3?

Thanks
/Ilias
>  static int k3_uboot_mem_map_init(unsigned int *map_idx)
>  {
>  	int ret;
> @@ -159,7 +166,11 @@ int k3_mem_map_init(void)
>
>  	map_idx++;
>
> -	ret = k3_uboot_mem_map_init(&map_idx);
> +	if (xpl_phase() == PHASE_SPL)
> +		k3_spl_mem_map_init(&map_idx);
> +	else
> +		ret = k3_uboot_mem_map_init(&map_idx);
> +
>  	if (ret)
>  		return ret;
>
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index fc230f180d0..e72413b9803 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -32,6 +32,7 @@
>  #include <dm/device-internal.h>
>
>  #include <asm/arch/k3-qos.h>
> +#include <mach/k3-ddr.h>
>
>  struct ti_sci_handle *get_ti_sci_handle(void)
>  {
> @@ -224,16 +225,26 @@ void spl_enable_cache(void)
>
>  	dram_init();
>
> -	/* reserve TLB table */
> -	gd->arch.tlb_size = PGTABLE_SIZE;
> -
>  	gd->ram_top += get_effective_memsize();
> +	/* keep ram_top in the 32-bit address space */
> +	if (gd->ram_top >= 0x100000000)
> +		gd->ram_top = (phys_addr_t)0x100000000;
> +
>  	gd->relocaddr = gd->ram_top;
>
>  	ret = spl_reserve_video_from_ram_top();
>  	if (ret)
>  		panic("Failed to reserve framebuffer memory (%d)\n", ret);
>
> +	if (IS_ENABLED(CONFIG_ARM64)) {
> +		ret = k3_mem_map_init();
> +		if (ret)
> +			panic("Failed to setup MMU table (%d)\n", ret);
> +	}
> +
> +	/* reserve TLB table */
> +	gd->arch.tlb_size = PGTABLE_SIZE;
> +
>  	gd->arch.tlb_addr = gd->relocaddr - gd->arch.tlb_size;
>  	gd->arch.tlb_addr &= ~(0x10000 - 1);
>  	debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,

Re: [PATCH v5 3/4] mach-k3: add dynamic mmu fixups for SPL stage

[Anshul Dalal]

Hello Ilias,

On Tue Jul 8, 2025 at 1:39 AM IST, Ilias Apalodimas wrote:
> Hi Anshul,
>
> On Thu Jul 3, 2025 at 4:35 PM EEST, Anshul Dalal wrote:
>> On platforms with spl splash support such as 62p and 62x
>> (CONFIG_VIDEO=y), the top of DDR is reserved for the framebuffer.
>>
>> The size of the framebuffer is computed at runtime by video_reserve.
>> During the MMU configuration an entry corresponding to the framebuffer
>> should be dynamically created to properly allocate the required space
>> for the framebuffer.
>>
>> Therefore this patch adds k3_spl_mem_map_init which adds the required
>> MMU entry by querying the gd after the framebuffer size has been
>> computed in spl_reserve_video_from_ram_top.
>>
>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> ---
>>  arch/arm/mach-k3/arm64/arm64-mmu.c | 13 ++++++++++++-
>>  arch/arm/mach-k3/common.c          | 17 ++++++++++++++---
>>  2 files changed, 26 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-k3/arm64/arm64-mmu.c b/arch/arm/mach-k3/arm64/arm64-mmu.c
>> index 49dd6fcb23b..b1b287f2114 100644
>> --- a/arch/arm/mach-k3/arm64/arm64-mmu.c
>> +++ b/arch/arm/mach-k3/arm64/arm64-mmu.c
>> @@ -131,6 +131,13 @@ static int k3_setup_extra_mem_banks(unsigned int *map_idx)
>>  	return 0;
>>  }
>>
>> +static void k3_spl_mem_map_init(unsigned int *map_idx)
>> +{
>> +	if (CONFIG_IS_ENABLED(VIDEO))
>> +		k3_mmu_add_cachable_entry(gd_video_bottom(), gd_video_top(),
>> +					  map_idx);
>> +}
>> +
>
> I don't know wnough details for this board, but generally speaking we should be doing
> this commonly for all arm64 platforms. There's mmu code for that. Can you explain why
> this is only useful to k3?
>

Could you point me to the relevant mmu code for it, from what I know
U-Boot doesn't map the framebuffer region at SPL stage by itself. Though
I'll replace k3_mmu_add_cachable_entry with something like
mmu_map_region in the next revision.

Regards,
Anshul

Re: [PATCH v5 3/4] mach-k3: add dynamic mmu fixups for SPL stage

[Ilias Apalodimas]

On Thu, 14 Aug 2025 at 17:52, Anshul Dalal <anshuld@ti.com> wrote:
>
> Hello Ilias,
>
> On Tue Jul 8, 2025 at 1:39 AM IST, Ilias Apalodimas wrote:
> > Hi Anshul,
> >
> > On Thu Jul 3, 2025 at 4:35 PM EEST, Anshul Dalal wrote:
> >> On platforms with spl splash support such as 62p and 62x
> >> (CONFIG_VIDEO=y), the top of DDR is reserved for the framebuffer.
> >>
> >> The size of the framebuffer is computed at runtime by video_reserve.
> >> During the MMU configuration an entry corresponding to the framebuffer
> >> should be dynamically created to properly allocate the required space
> >> for the framebuffer.
> >>
> >> Therefore this patch adds k3_spl_mem_map_init which adds the required
> >> MMU entry by querying the gd after the framebuffer size has been
> >> computed in spl_reserve_video_from_ram_top.
> >>
> >> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> >> ---
> >>  arch/arm/mach-k3/arm64/arm64-mmu.c | 13 ++++++++++++-
> >>  arch/arm/mach-k3/common.c          | 17 ++++++++++++++---
> >>  2 files changed, 26 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-k3/arm64/arm64-mmu.c b/arch/arm/mach-k3/arm64/arm64-mmu.c
> >> index 49dd6fcb23b..b1b287f2114 100644
> >> --- a/arch/arm/mach-k3/arm64/arm64-mmu.c
> >> +++ b/arch/arm/mach-k3/arm64/arm64-mmu.c
> >> @@ -131,6 +131,13 @@ static int k3_setup_extra_mem_banks(unsigned int *map_idx)
> >>      return 0;
> >>  }
> >>
> >> +static void k3_spl_mem_map_init(unsigned int *map_idx)
> >> +{
> >> +    if (CONFIG_IS_ENABLED(VIDEO))
> >> +            k3_mmu_add_cachable_entry(gd_video_bottom(), gd_video_top(),
> >> +                                      map_idx);
> >> +}
> >> +
> >
> > I don't know wnough details for this board, but generally speaking we should be doing
> > this commonly for all arm64 platforms. There's mmu code for that. Can you explain why
> > this is only useful to k3?
> >
>
> Could you point me to the relevant mmu code for it, from what I know
> U-Boot doesn't map the framebuffer region at SPL stage by itself. Though
> I'll replace k3_mmu_add_cachable_entry with something like
> mmu_map_region in the next revision.

We have functions like mmu_set_region_dcache_behaviour(),
mmu_map_region(), mmu_change_region_attr() etc. If you are missing
some configuration for the MMU, we are better off adding it for all
Arm platforms, not k3 specifically.

Thanks
/Ilias
>
> Regards,
> Anshul

[PATCH v5 4/4] board: add call to k3_mem_map_init for all k3 boards

[Anshul Dalal]

k3_mem_map_init configures the MMU at runtime by querying the
device-tree for DDR size for each bank as well as creating carveouts for
OPTEE and ATF in the first bank.

Therefore add a call to k3_mem_map_init in dram_init for all k3 vendor
boards.

Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
 board/beagle/beagleplay/beagleplay.c         | 9 ++++++++-
 board/phytec/phycore_am62ax/phycore-am62ax.c | 9 ++++++++-
 board/phytec/phycore_am62x/phycore-am62x.c   | 3 ++-
 board/phytec/phycore_am64x/phycore-am64x.c   | 3 ++-
 board/siemens/iot2050/board.c                | 3 ++-
 board/toradex/verdin-am62/verdin-am62.c      | 3 ++-
 6 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/board/beagle/beagleplay/beagleplay.c b/board/beagle/beagleplay/beagleplay.c
index 78635810585..c87ed925da8 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -13,6 +13,7 @@
 #include <spl.h>
 
 #include <asm/arch/hardware.h>
+#include <mach/k3-ddr.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -48,7 +49,13 @@ int board_init(void)
 
 int dram_init(void)
 {
-	return fdtdec_setup_mem_size_base();
+	int ret;
+
+	ret = fdtdec_setup_mem_size_base();
+	if (ret)
+		return ret;
+
+	return k3_mem_map_init();
 }
 
 int dram_init_banksize(void)
diff --git a/board/phytec/phycore_am62ax/phycore-am62ax.c b/board/phytec/phycore_am62ax/phycore-am62ax.c
index 14b8959c07a..5d61866d556 100644
--- a/board/phytec/phycore_am62ax/phycore-am62ax.c
+++ b/board/phytec/phycore_am62ax/phycore-am62ax.c
@@ -8,6 +8,7 @@
 #include <asm/io.h>
 #include <spl.h>
 #include <fdt_support.h>
+#include <mach/k3-ddr.h>
 
 #include "../common/am6_som_detection.h"
 
@@ -18,7 +19,13 @@ int board_init(void)
 
 int dram_init(void)
 {
-	return fdtdec_setup_mem_size_base();
+	int ret;
+
+	ret = fdtdec_setup_mem_size_base();
+	if (ret)
+		return ret;
+
+	return k3_mem_map_init();
 }
 
 int dram_init_banksize(void)
diff --git a/board/phytec/phycore_am62x/phycore-am62x.c b/board/phytec/phycore_am62x/phycore-am62x.c
index b199fdaa59b..ebf7697709d 100644
--- a/board/phytec/phycore_am62x/phycore-am62x.c
+++ b/board/phytec/phycore_am62x/phycore-am62x.c
@@ -9,6 +9,7 @@
 #include <spl.h>
 #include <asm/arch/k3-ddr.h>
 #include <fdt_support.h>
+#include <mach/k3-ddr.h>
 
 #include "phycore-ddr-data.h"
 #include "../common/k3/k3_ddrss_patch.h"
@@ -81,7 +82,7 @@ int dram_init(void)
 		gd->ram_size = 0x80000000;
 	}
 
-	return 0;
+	return k3_mem_map_init();
 }
 
 phys_size_t board_get_usable_ram_top(phys_size_t total_size)
diff --git a/board/phytec/phycore_am64x/phycore-am64x.c b/board/phytec/phycore_am64x/phycore-am64x.c
index f14c87f5c72..4cd44d6e538 100644
--- a/board/phytec/phycore_am64x/phycore-am64x.c
+++ b/board/phytec/phycore_am64x/phycore-am64x.c
@@ -16,6 +16,7 @@
 #include <asm/arch/hardware.h>
 
 #include "../common/am6_som_detection.h"
+#include <mach/k3-ddr.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -64,7 +65,7 @@ int dram_init(void)
 		gd->ram_size = 0x80000000;
 	}
 
-	return 0;
+	return k3_mem_map_init();
 }
 
 int dram_init_banksize(void)
diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index d827f728a08..fca8270fda9 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -24,6 +24,7 @@
 #include <asm/arch/hardware.h>
 #include <asm/gpio.h>
 #include <asm/io.h>
+#include <mach/k3-ddr.h>
 
 #include "../../../../drivers/sysinfo/iot2050.h"
 
@@ -383,7 +384,7 @@ int dram_init(void)
 
 	gd->ram_size = ((phys_size_t)(ddr_size_mb)) << 20;
 
-	return 0;
+	return k3_mem_map_init();
 }
 
 ulong board_get_usable_ram_top(ulong total_size)
diff --git a/board/toradex/verdin-am62/verdin-am62.c b/board/toradex/verdin-am62/verdin-am62.c
index 7b2eecbf659..4c900663506 100644
--- a/board/toradex/verdin-am62/verdin-am62.c
+++ b/board/toradex/verdin-am62/verdin-am62.c
@@ -16,6 +16,7 @@
 #include <k3-ddrss.h>
 #include <spl.h>
 #include <asm/arch/k3-ddr.h>
+#include <mach/k3-ddr.h>
 
 #include "../common/tdx-cfg-block.h"
 
@@ -33,7 +34,7 @@ int dram_init(void)
 	if (gd->ram_size < SZ_512M)
 		puts("## WARNING: Less than 512MB RAM detected\n");
 
-	return 0;
+	return k3_mem_map_init();
 }
 
 int dram_init_banksize(void)
-- 
2.49.0