[PATCH master] mach-k3: enable mmu after reserved memory is unmapped

[PATCH master] mach-k3: enable mmu after reserved memory is unmapped

[Anshul Dalal]

Currently the sequence to enable caches for the A53/A72 core on K3
devices looks as follows:

 1. Map entire DDR banks
 2. Setup page tables and enable MMU (done by mmu_setup)
 3. Unmap reserved-memory regions
 4. Enable caches

However there is a brief period of execution between #2 and #3 where the
core can issue speculative accesses to the entire DDR space (including
the reserved-memory regions) despite the caches being disabled.

A firewall exception is triggered whenever such speculative access is
made to secure DDR region of TFA or OP-TEE. This patch fixes the issue
by re-ordering the sequence as follows:

 1. Map entire DDR banks
 2. Setup page tables
 3. Unmap reserved-memory regions
 4. Enable MMU
 5. Enable caches

Fixes: f1c694b8fdde ("mach-k3: map all banks using mem_map_from_dram_banks")
Signed-off-by: Anshul Dalal <anshuld@ti.com>
---
For testing, I had used an AM62p with the following diff to enable
logging from TIFS:

  --- a/board/ti/am62px/board-cfg.yaml
  +++ b/board/ti/am62px/board-cfg.yaml
  @@ -33,5 +33,5 @@ board-cfg:
           subhdr:
               magic: 0x020C
               size: 8
  -        trace_dst_enables: 0x00
  -        trace_src_enables: 0x00
  +        trace_dst_enables: 0xd
  +        trace_src_enables: 0x3f

Without this patch an exception[1] similar to the following is observed
at A53 SPL stage:

  FWL Bit  0x1
  Exception addr  0x45B08000
  FWL Exception  0x1000100
   0x60000
   0x80002880
   0x0
   0x141201
   0x40

[1]: https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/firewall_faq.html#how-do-i-debug-firewall-issues
---
 arch/arm/cpu/armv8/cache_v8.c    |  2 +-
 arch/arm/include/asm/armv8/mmu.h |  1 +
 arch/arm/mach-k3/common.c        | 10 +++++++++-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 39479df7b21..169e68627e1 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -777,7 +777,7 @@ void setup_pgtables(void)
 		add_map(&mem_map[i]);
 }
 
-static void setup_all_pgtables(void)
+void setup_all_pgtables(void)
 {
 	u64 tlb_addr = gd->arch.tlb_addr;
 	u64 tlb_size = gd->arch.tlb_size;
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index 8aa5f9721c4..969f1745445 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -197,6 +197,7 @@ struct mm_region {
 /* Used as the memory map for MMU configuration by mmu_setup */
 extern struct mm_region *mem_map;
 void setup_pgtables(void);
+void setup_all_pgtables(void);
 
 /**
  * mem_map_from_dram_banks() - Populate mem_map with entries corresponding to
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index b0a75988714..a910c6e3725 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -265,8 +265,10 @@ void board_prep_linux(struct bootm_headers *images)
 void enable_caches(void)
 {
 	void *fdt = (void *)gd->fdt_blob;
+	int el = current_el();
 	int ret;
 
+	/* Map all DDR banks as Normal memory */
 	ret = mem_map_from_dram_banks(K3_MEM_MAP_FIRST_BANK_IDX, K3_MEM_MAP_LEN,
 				     PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 					     PTE_BLOCK_INNER_SHARE);
@@ -278,8 +280,11 @@ void enable_caches(void)
 		printf("%s: Failed to perform reserved-memory fixups (%s)\n",
 		       __func__, fdt_strerror(ret));
 
-	mmu_setup();
+	setup_all_pgtables();
+	set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(NULL, NULL),
+			  MEMORY_ATTRIBUTES);
 
+	/* Unmap reserved memory regions */
 	if (CONFIG_K3_ATF_LOAD_ADDR >= CFG_SYS_SDRAM_BASE) {
 		ret = mmu_unmap_reserved_mem("tfa", true);
 		if (ret)
@@ -294,6 +299,9 @@ void enable_caches(void)
 			       __func__, ret);
 	}
 
+	/* enable the mmu */
+	set_sctlr(get_sctlr() | CR_M);
+
 	icache_enable();
 	dcache_enable();
 }

---
base-commit: 525ef034e5bed619c0f822da5373ed1fdadc8501
change-id: 20260512-am62_firewall_exception_fix-20a335cca769

Best regards,
--  
Anshul Dalal <anshuld@ti.com>

Re: [PATCH master] mach-k3: enable mmu after reserved memory is unmapped

[Anshul Dalal]

On Tue May 12, 2026 at 4:33 PM IST, Anshul Dalal wrote:
> Currently the sequence to enable caches for the A53/A72 core on K3
> devices looks as follows:
>
>  1. Map entire DDR banks
>  2. Setup page tables and enable MMU (done by mmu_setup)
>  3. Unmap reserved-memory regions
>  4. Enable caches
>
> However there is a brief period of execution between #2 and #3 where the
> core can issue speculative accesses to the entire DDR space (including
> the reserved-memory regions) despite the caches being disabled.
>
> A firewall exception is triggered whenever such speculative access is
> made to secure DDR region of TFA or OP-TEE. This patch fixes the issue
> by re-ordering the sequence as follows:
>
>  1. Map entire DDR banks
>  2. Setup page tables
>  3. Unmap reserved-memory regions
>  4. Enable MMU
>  5. Enable caches
>
> Fixes: f1c694b8fdde ("mach-k3: map all banks using mem_map_from_dram_banks")
> Signed-off-by: Anshul Dalal <anshuld@ti.com>

Forgot to add:

  Reported-by: Suhaas Joshi <s-joshi@ti.com>

--
Anshul Dalal <anshuld@ti.com>

Re: [PATCH master] mach-k3: enable mmu after reserved memory is unmapped

[Ilias Apalodimas]

Hi Anshul

On Tue, 12 May 2026 at 14:03, Anshul Dalal <anshuld@ti.com> wrote:
>
> Currently the sequence to enable caches for the A53/A72 core on K3
> devices looks as follows:
>
>  1. Map entire DDR banks
>  2. Setup page tables and enable MMU (done by mmu_setup)
>  3. Unmap reserved-memory regions
>  4. Enable caches
>
> However there is a brief period of execution between #2 and #3 where the
> core can issue speculative accesses to the entire DDR space (including
> the reserved-memory regions) despite the caches being disabled.

This is indeed a problem and the fix looks correct.
What worries me though is that the mmu is common across v8 boards. Is
there a way to generalize this instead of adding per board variants?

Thanks
/Ilias

>
> A firewall exception is triggered whenever such speculative access is
> made to secure DDR region of TFA or OP-TEE. This patch fixes the issue
> by re-ordering the sequence as follows:
>
>  1. Map entire DDR banks
>  2. Setup page tables
>  3. Unmap reserved-memory regions
>  4. Enable MMU
>  5. Enable caches
>
> Fixes: f1c694b8fdde ("mach-k3: map all banks using mem_map_from_dram_banks")
> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> ---
> For testing, I had used an AM62p with the following diff to enable
> logging from TIFS:
>
>   --- a/board/ti/am62px/board-cfg.yaml
>   +++ b/board/ti/am62px/board-cfg.yaml
>   @@ -33,5 +33,5 @@ board-cfg:
>            subhdr:
>                magic: 0x020C
>                size: 8
>   -        trace_dst_enables: 0x00
>   -        trace_src_enables: 0x00
>   +        trace_dst_enables: 0xd
>   +        trace_src_enables: 0x3f
>
> Without this patch an exception[1] similar to the following is observed
> at A53 SPL stage:
>
>   FWL Bit  0x1
>   Exception addr  0x45B08000
>   FWL Exception  0x1000100
>    0x60000
>    0x80002880
>    0x0
>    0x141201
>    0x40
>
> [1]: https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/firewall_faq.html#how-do-i-debug-firewall-issues
> ---
>  arch/arm/cpu/armv8/cache_v8.c    |  2 +-
>  arch/arm/include/asm/armv8/mmu.h |  1 +
>  arch/arm/mach-k3/common.c        | 10 +++++++++-
>  3 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
> index 39479df7b21..169e68627e1 100644
> --- a/arch/arm/cpu/armv8/cache_v8.c
> +++ b/arch/arm/cpu/armv8/cache_v8.c
> @@ -777,7 +777,7 @@ void setup_pgtables(void)
>                 add_map(&mem_map[i]);
>  }
>
> -static void setup_all_pgtables(void)
> +void setup_all_pgtables(void)
>  {
>         u64 tlb_addr = gd->arch.tlb_addr;
>         u64 tlb_size = gd->arch.tlb_size;
> diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
> index 8aa5f9721c4..969f1745445 100644
> --- a/arch/arm/include/asm/armv8/mmu.h
> +++ b/arch/arm/include/asm/armv8/mmu.h
> @@ -197,6 +197,7 @@ struct mm_region {
>  /* Used as the memory map for MMU configuration by mmu_setup */
>  extern struct mm_region *mem_map;
>  void setup_pgtables(void);
> +void setup_all_pgtables(void);
>
>  /**
>   * mem_map_from_dram_banks() - Populate mem_map with entries corresponding to
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index b0a75988714..a910c6e3725 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -265,8 +265,10 @@ void board_prep_linux(struct bootm_headers *images)
>  void enable_caches(void)
>  {
>         void *fdt = (void *)gd->fdt_blob;
> +       int el = current_el();
>         int ret;
>
> +       /* Map all DDR banks as Normal memory */
>         ret = mem_map_from_dram_banks(K3_MEM_MAP_FIRST_BANK_IDX, K3_MEM_MAP_LEN,
>                                      PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>                                              PTE_BLOCK_INNER_SHARE);
> @@ -278,8 +280,11 @@ void enable_caches(void)
>                 printf("%s: Failed to perform reserved-memory fixups (%s)\n",
>                        __func__, fdt_strerror(ret));
>
> -       mmu_setup();
> +       setup_all_pgtables();
> +       set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(NULL, NULL),
> +                         MEMORY_ATTRIBUTES);
>
> +       /* Unmap reserved memory regions */
>         if (CONFIG_K3_ATF_LOAD_ADDR >= CFG_SYS_SDRAM_BASE) {
>                 ret = mmu_unmap_reserved_mem("tfa", true);
>                 if (ret)
> @@ -294,6 +299,9 @@ void enable_caches(void)
>                                __func__, ret);
>         }
>
> +       /* enable the mmu */
> +       set_sctlr(get_sctlr() | CR_M);
> +
>         icache_enable();
>         dcache_enable();
>  }
>
> ---
> base-commit: 525ef034e5bed619c0f822da5373ed1fdadc8501
> change-id: 20260512-am62_firewall_exception_fix-20a335cca769
>
> Best regards,
> --
> Anshul Dalal <anshuld@ti.com>
>

Re: [PATCH master] mach-k3: enable mmu after reserved memory is unmapped

[Anshul Dalal]

On Mon May 18, 2026 at 1:34 PM IST, Ilias Apalodimas wrote:
> Hi Anshul
>
> On Tue, 12 May 2026 at 14:03, Anshul Dalal <anshuld@ti.com> wrote:
>>
>> Currently the sequence to enable caches for the A53/A72 core on K3
>> devices looks as follows:
>>
>>  1. Map entire DDR banks
>>  2. Setup page tables and enable MMU (done by mmu_setup)
>>  3. Unmap reserved-memory regions
>>  4. Enable caches
>>
>> However there is a brief period of execution between #2 and #3 where the
>> core can issue speculative accesses to the entire DDR space (including
>> the reserved-memory regions) despite the caches being disabled.
>
> This is indeed a problem and the fix looks correct.
> What worries me though is that the mmu is common across v8 boards. Is
> there a way to generalize this instead of adding per board variants?
>

I think the issue here is that mmu_setup does two things, first it sets
up the page tables and then it enables the MMU right after that.

We could modify mmu_setup so that it only does the former as follows:

	--- a/arch/arm/cpu/armv8/cache_v8.c
	+++ b/arch/arm/cpu/armv8/cache_v8.c
	@@ -801,20 +801,20 @@ static void setup_all_pgtables(void)
	 /* to activate the MMU we need to set up virtual memory */
	 __weak void mmu_setup(void)
	 {
		int el;

	+       /* disable the mmu */
	+       set_sctlr(get_sctlr() & ~CR_M);
	+
		/* Set up page tables only once */
		if (!gd->arch.tlb_fillptr)
			setup_all_pgtables();

		el = current_el();
		set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(NULL, NULL),
				  MEMORY_ATTRIBUTES);
	-
	-       /* enable the mmu */
	-       set_sctlr(get_sctlr() | CR_M);
	 }

Then we can have an `mmu_enable` to explicitly enable the MMU:

	void mmu_enable(void) {
		/* enable the mmu */
		set_sctlr(get_sctlr() | CR_M);
	}

Regards,
Anshul

>
>>
>> A firewall exception is triggered whenever such speculative access is
>> made to secure DDR region of TFA or OP-TEE. This patch fixes the issue
>> by re-ordering the sequence as follows:
>>
>>  1. Map entire DDR banks
>>  2. Setup page tables
>>  3. Unmap reserved-memory regions
>>  4. Enable MMU
>>  5. Enable caches
>>
>> Fixes: f1c694b8fdde ("mach-k3: map all banks using mem_map_from_dram_banks")
>> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> ---

[snip]

Re: [PATCH master] mach-k3: enable mmu after reserved memory is unmapped

[Ilias Apalodimas]

On Mon, 18 May 2026 at 12:12, Anshul Dalal <anshuld@ti.com> wrote:
>
> On Mon May 18, 2026 at 1:34 PM IST, Ilias Apalodimas wrote:
> > Hi Anshul
> >
> > On Tue, 12 May 2026 at 14:03, Anshul Dalal <anshuld@ti.com> wrote:
> >>
> >> Currently the sequence to enable caches for the A53/A72 core on K3
> >> devices looks as follows:
> >>
> >>  1. Map entire DDR banks
> >>  2. Setup page tables and enable MMU (done by mmu_setup)
> >>  3. Unmap reserved-memory regions
> >>  4. Enable caches
> >>
> >> However there is a brief period of execution between #2 and #3 where the
> >> core can issue speculative accesses to the entire DDR space (including
> >> the reserved-memory regions) despite the caches being disabled.
> >
> > This is indeed a problem and the fix looks correct.
> > What worries me though is that the mmu is common across v8 boards. Is
> > there a way to generalize this instead of adding per board variants?
> >
>
> I think the issue here is that mmu_setup does two things, first it sets
> up the page tables and then it enables the MMU right after that.
>
> We could modify mmu_setup so that it only does the former as follows:
>
>         --- a/arch/arm/cpu/armv8/cache_v8.c
>         +++ b/arch/arm/cpu/armv8/cache_v8.c
>         @@ -801,20 +801,20 @@ static void setup_all_pgtables(void)
>          /* to activate the MMU we need to set up virtual memory */
>          __weak void mmu_setup(void)
>          {
>                 int el;
>
>         +       /* disable the mmu */
>         +       set_sctlr(get_sctlr() & ~CR_M);
>         +
>                 /* Set up page tables only once */
>                 if (!gd->arch.tlb_fillptr)
>                         setup_all_pgtables();
>
>                 el = current_el();
>                 set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(NULL, NULL),
>                                   MEMORY_ATTRIBUTES);
>         -
>         -       /* enable the mmu */
>         -       set_sctlr(get_sctlr() | CR_M);
>          }
>
> Then we can have an `mmu_enable` to explicitly enable the MMU:
>
>         void mmu_enable(void) {
>                 /* enable the mmu */
>                 set_sctlr(get_sctlr() | CR_M);
>         }

Ok that sounds reasonable. I greped for mmu_setup() and
dcache_enable(), but I can't estimate how intrusive this is going to
be to include all v8 boards.

Thanks
/Ilias
>
> Regards,
> Anshul
>
> >
> >>
> >> A firewall exception is triggered whenever such speculative access is
> >> made to secure DDR region of TFA or OP-TEE. This patch fixes the issue
> >> by re-ordering the sequence as follows:
> >>
> >>  1. Map entire DDR banks
> >>  2. Setup page tables
> >>  3. Unmap reserved-memory regions
> >>  4. Enable MMU
> >>  5. Enable caches
> >>
> >> Fixes: f1c694b8fdde ("mach-k3: map all banks using mem_map_from_dram_banks")
> >> Signed-off-by: Anshul Dalal <anshuld@ti.com>
> >> ---
>
> [snip]

Re: [PATCH master] mach-k3: enable mmu after reserved memory is unmapped

[Anshul Dalal]

On Mon May 18, 2026 at 3:18 PM IST, Ilias Apalodimas wrote:
> On Mon, 18 May 2026 at 12:12, Anshul Dalal <anshuld@ti.com> wrote:
>>
>> On Mon May 18, 2026 at 1:34 PM IST, Ilias Apalodimas wrote:
>> > Hi Anshul
>> >
>> > On Tue, 12 May 2026 at 14:03, Anshul Dalal <anshuld@ti.com> wrote:
>> >>
>> >> Currently the sequence to enable caches for the A53/A72 core on K3
>> >> devices looks as follows:
>> >>
>> >>  1. Map entire DDR banks
>> >>  2. Setup page tables and enable MMU (done by mmu_setup)
>> >>  3. Unmap reserved-memory regions
>> >>  4. Enable caches
>> >>
>> >> However there is a brief period of execution between #2 and #3 where the
>> >> core can issue speculative accesses to the entire DDR space (including
>> >> the reserved-memory regions) despite the caches being disabled.
>> >
>> > This is indeed a problem and the fix looks correct.
>> > What worries me though is that the mmu is common across v8 boards. Is
>> > there a way to generalize this instead of adding per board variants?
>> >
>>
>> I think the issue here is that mmu_setup does two things, first it sets
>> up the page tables and then it enables the MMU right after that.
>>
>> We could modify mmu_setup so that it only does the former as follows:
>>
>>         --- a/arch/arm/cpu/armv8/cache_v8.c
>>         +++ b/arch/arm/cpu/armv8/cache_v8.c
>>         @@ -801,20 +801,20 @@ static void setup_all_pgtables(void)
>>          /* to activate the MMU we need to set up virtual memory */
>>          __weak void mmu_setup(void)
>>          {
>>                 int el;
>>
>>         +       /* disable the mmu */
>>         +       set_sctlr(get_sctlr() & ~CR_M);
>>         +
>>                 /* Set up page tables only once */
>>                 if (!gd->arch.tlb_fillptr)
>>                         setup_all_pgtables();
>>
>>                 el = current_el();
>>                 set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(NULL, NULL),
>>                                   MEMORY_ATTRIBUTES);
>>         -
>>         -       /* enable the mmu */
>>         -       set_sctlr(get_sctlr() | CR_M);
>>          }
>>
>> Then we can have an `mmu_enable` to explicitly enable the MMU:
>>
>>         void mmu_enable(void) {
>>                 /* enable the mmu */
>>                 set_sctlr(get_sctlr() | CR_M);
>>         }
>
> Ok that sounds reasonable. I greped for mmu_setup() and
> dcache_enable(), but I can't estimate how intrusive this is going to
> be to include all v8 boards.
>

From what I can see, mach-k3 is the only user that explicitly calls
default mmu_setup whereas others just override the weak definition.

I'll test the next revision on several K3 boards and post the fix.

Thanks!

>> >
>> >>
>> >> A firewall exception is triggered whenever such speculative access is
>> >> made to secure DDR region of TFA or OP-TEE. This patch fixes the issue
>> >> by re-ordering the sequence as follows:
>> >>
>> >>  1. Map entire DDR banks
>> >>  2. Setup page tables
>> >>  3. Unmap reserved-memory regions
>> >>  4. Enable MMU
>> >>  5. Enable caches
>> >>
>> >> Fixes: f1c694b8fdde ("mach-k3: map all banks using mem_map_from_dram_banks")
>> >> Signed-off-by: Anshul Dalal <anshuld@ti.com>
>> >> ---
>>
>> [snip]