From: Anshul Dalal <anshuld@ti.com>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Anshul Dalal <anshuld@ti.com>
Cc: <u-boot@lists.denx.de>, Tom Rini <trini@konsulko.com>,
Dhruva Gole <d-gole@ti.com>, Mark Kettenis <kettenis@openbsd.org>,
Patrice Chotard <patrice.chotard@foss.st.com>,
Moteen Shah <m-shah@ti.com>, Beleswar Padhi <b-padhi@ti.com>,
Wadim Egorov <w.egorov@phytec.de>,
Chintan Vankar <c-vankar@ti.com>
Subject: Re: [PATCH master] mach-k3: enable mmu after reserved memory is unmapped
Date: Mon, 18 May 2026 14:42:17 +0530 [thread overview]
Message-ID: <DILOQEO4WE9D.AVK6J4D35NY4@ti.com> (raw)
In-Reply-To: <CAC_iWjJHnzfgMThnUnzd=s_21wndWX57pinNMoq9As+e_TSOOQ@mail.gmail.com>
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]
next prev parent reply other threads:[~2026-05-18 9:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 11:03 [PATCH master] mach-k3: enable mmu after reserved memory is unmapped Anshul Dalal
2026-05-13 4:51 ` Anshul Dalal
2026-05-18 8:04 ` Ilias Apalodimas
2026-05-18 9:12 ` Anshul Dalal [this message]
2026-05-18 9:48 ` Ilias Apalodimas
2026-05-18 10:08 ` 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=DILOQEO4WE9D.AVK6J4D35NY4@ti.com \
--to=anshuld@ti.com \
--cc=b-padhi@ti.com \
--cc=c-vankar@ti.com \
--cc=d-gole@ti.com \
--cc=ilias.apalodimas@linaro.org \
--cc=kettenis@openbsd.org \
--cc=m-shah@ti.com \
--cc=patrice.chotard@foss.st.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=w.egorov@phytec.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