From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: mfe@pengutronix.de, Holger Assmann <has@pengutronix.de>,
Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH 2/2] ARM: i.MX8M: romapi: skip zero_page_access() if MMU is disabled
Date: Tue, 28 Oct 2025 15:32:35 +0100 [thread overview]
Message-ID: <20251028143238.1782982-2-a.fatoum@pengutronix.de> (raw)
In-Reply-To: <20251028143238.1782982-1-a.fatoum@pengutronix.de>
imx8m_get_bootrom_log() anticipates three situations in which it can be
called:
1) From PBL running in EL3
2) From barebox proper running in EL2
3) From barebox proper hacked to run in EL3 without TF-A
No board makes use of situation 3), but it's occasionally useful
in debugging. To handle that last case, commit b0d0ac502c49
("ARM: i.MX8M: bootrom: access OCRAM directly if running in EL3")
remaps the zero page as it would overlay the BootROM, which is located
at physical address 0.
This worked fine for a while, because zero page control was not
available in the PBL, but this changed with commit
99944ef03dc1 ("ARM: mmu: provide zero page control in PBL") leading to
buggy behavior for situation 1): zero_page_access() would now remap the
zero page, even though barebox never initialized the TTBR.
This was observed to crash TF-A (presumably, because when it unmasks
exceptions) on an i.MX8MP.
Fix by only calling zero_page_access/faulting when our newly dynamic
zero_page_remappable() returns true.
Fixes: 99944ef03dc1 ("ARM: mmu: provide zero page control in PBL")
Reported-by: Holger Assmann <has@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
This issue is IMO worth an entry in the migration guide, once the fix
makes it into master.
---
arch/arm/mach-imx/romapi.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/romapi.c b/arch/arm/mach-imx/romapi.c
index a4143d372ae8..eaaadc661cc8 100644
--- a/arch/arm/mach-imx/romapi.c
+++ b/arch/arm/mach-imx/romapi.c
@@ -237,14 +237,19 @@ int imx93_romapi_load_image(void *adr)
const u32 *imx8m_get_bootrom_log(void)
{
if (current_el() == 3) {
+ bool remap_zero_page = zero_page_remappable();
ulong *rom_log_addr_offset = (void *)0x9e0;
ulong rom_log_addr;
OPTIMIZER_HIDE_VAR(rom_log_addr_offset);
- zero_page_access();
+ if (remap_zero_page)
+ zero_page_access();
+
rom_log_addr = *rom_log_addr_offset;
- zero_page_faulting();
+
+ if (remap_zero_page)
+ zero_page_faulting();
if (rom_log_addr < MX8M_OCRAM_BASE_ADDR ||
rom_log_addr >= MX8M_OCRAM_BASE_ADDR + MX8M_OCRAM_MAX_SIZE ||
--
2.47.3
prev parent reply other threads:[~2025-10-28 14:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-28 14:32 [PATCH 1/2] ARM: mmu: have zero_page_remappable() check MMU status Ahmad Fatoum
2025-10-28 14:32 ` Ahmad Fatoum [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=20251028143238.1782982-2-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=has@pengutronix.de \
--cc=mfe@pengutronix.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