From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Sascha Hauer <s.hauer@pengutronix.de>,
Ahmad Fatoum <a.fatoum@barebox.org>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] mmu: explicitly map executable non-SDRAM regions with MAP_CODE
Date: Fri, 20 Jun 2025 17:45:45 +0200 [thread overview]
Message-ID: <0c5b58a4-bc8a-4775-a265-f1bb2b46eea0@pengutronix.de> (raw)
In-Reply-To: <aFVYBJikCmjGpupI@pengutronix.de>
On 20.06.25 14:45, Sascha Hauer wrote:
> On Wed, Jun 18, 2025 at 02:36:42PM +0200, Ahmad Fatoum wrote:
>> So far we have been setting eXecute Never on MAP_UNCACHED regions and
>> left it out for the default MAP_CACHED region.
>>
>> We have at least three places, which depend on this to remap non-SDRAM
>> regions executable, so ROM code or newly uploaded code can be run.
>>
>> Switch them over to use a new MAP_CODE mapping type. For now, this is
>> equivalent to MAP_CACHED, but with the addition of W^X support in
>> barebox, this will be required to avoid a prefetch abort when MMU
>> attributes are used.
>>
>> Signed-off-by: Ahmad Fatoum <a.fatoum@barebox.org>
>> ---
>> Sascha, I think this should be ordered before your MMU patches to avoid
>> the known regressions. Let's see what else there is. :)
>> ---
>> arch/arm/mach-imx/romapi.c | 3 ++-
>> drivers/firmware/socfpga.c | 3 ++-
>> drivers/hab/habv4.c | 2 +-
>> include/mmu.h | 1 +
>> 4 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-imx/romapi.c b/arch/arm/mach-imx/romapi.c
>> index 10af42f28a76..a4143d372ae8 100644
>> --- a/arch/arm/mach-imx/romapi.c
>> +++ b/arch/arm/mach-imx/romapi.c
>> @@ -299,7 +299,8 @@ void imx93_bootsource(void)
>> goto out;
>> }
>>
>> - arch_remap_range((void *)rom.start, rom.start, resource_size(&rom), MAP_CACHED);
>> + /* TODO: restore uncached mapping once we no longer need this? */
>> + arch_remap_range((void *)rom.start, rom.start, resource_size(&rom), MAP_CODE);
>>
>> OPTIMIZER_HIDE_VAR(rom_api);
>>
>> diff --git a/drivers/firmware/socfpga.c b/drivers/firmware/socfpga.c
>> index 0f7d11abb588..4b10ca009798 100644
>> --- a/drivers/firmware/socfpga.c
>> +++ b/drivers/firmware/socfpga.c
>> @@ -353,7 +353,8 @@ static int socfpga_fpgamgr_program_finish(struct firmware_handler *fh)
>> return status;
>> }
>>
>> - remap_range((void *)CYCLONE5_OCRAM_ADDRESS, PAGE_SIZE, MAP_CACHED);
>> + /* TODO: restore uncached mapping once we no longer need this? */
>> + remap_range((void *)CYCLONE5_OCRAM_ADDRESS, PAGE_SIZE, MAP_CODE);
>
> This is done before the code is copied to this page. I moved it after
> the fncpy call to avoid writing to readonly memory.
fncpy calls memcpy internally though, so we should either leave the MAP_CACHED
as is and add a further MAP_CODE after the fncpy or introduce a fncpy_toio
that calls memcpy_toio internally.
What do you think?
> While at it I also added the remapping to MAP_UNCACHED.
Thanks,
Ahmad
>
> Sascha
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2025-06-20 16:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-18 12:36 Ahmad Fatoum
2025-06-20 12:45 ` Sascha Hauer
2025-06-20 15:45 ` Ahmad Fatoum [this message]
2025-06-20 12:46 ` Sascha Hauer
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=0c5b58a4-bc8a-4775-a265-f1bb2b46eea0@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=a.fatoum@barebox.org \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@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