U-Boot Archive on lore.kernel.org
 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>, 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 15:38:54 +0530	[thread overview]
Message-ID: <DILPXRDLFPM0.1YN1BKZR69L95@ti.com> (raw)
In-Reply-To: <CAC_iWjJ9qhN8an2Z=J6+7-N+wPQ31gPAimBSEdHGLkiU5BR_NQ@mail.gmail.com>

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]


      reply	other threads:[~2026-05-18 10:09 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
2026-05-18  9:48     ` Ilias Apalodimas
2026-05-18 10:08       ` Anshul Dalal [this message]

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=DILPXRDLFPM0.1YN1BKZR69L95@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