mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Lucas Stach <l.stach@pengutronix.de>, barebox@lists.infradead.org
Subject: Re: [PATCH 1/3] ARM: cpu: suppress arm_early_mmu_cache_invalidate if dcache enabled
Date: Tue, 7 Jul 2026 19:20:30 +0200	[thread overview]
Message-ID: <ba9e9ab0-b16e-44b2-91e6-fb036d0e66f0@pengutronix.de> (raw)
In-Reply-To: <491622cd3262aaf95d5ed3f45044c29cdffed696.camel@pengutronix.de>

Hello Lucas,

On 7/7/26 5:22 PM, Lucas Stach wrote:
> Am Dienstag, dem 07.07.2026 um 10:05 +0200 schrieb Ahmad Fatoum:
>> barebox built as EFI payload on ARM invalidates the data caches inside
>> barebox_arm_entry(), which may lead to memory corruption.
>>
>> Generally, calling arm_early_mmu_cache_invalidate() while the caches are
>> enabled is a bad idea, so add a function that protects against that and
>> use it in common code.
>>
>> Fixes: 742e78976dd4 ("ARM64: add optional EFI stub")

>> +/**
>> + * dcache_invalidate_stale - invalidate data cache prior to enabling it
>> + *
>> + * Some SoCs can come up with invalid entries, but with the valid bit set.
>> + * This function discards them, as that would lead to memory corruption
>> + * otherwise.
>> + */
>> +void dcache_invalidate_stale(void)
> 
> I don't like the naming of this function, as
> arm_early_mmu_cache_invalidate() invalidates both the D and I cache, as
> well as a unified cache after the PoU if it's part of the architected
> hierarchy. This is the desired behavior, as both the I and D side can
> come up with invalid entries.

Ah, I had not thought much about the I cache having invalid entries as well.

How about cache_invalidate_stale()?

> It's okay to only check for CR_C, as invalidating the I side when there
> are already cached entries only has a minor impact on performance, but
> won't affect correctness.

I thought that it might be too surprising to change the semantics of
this function in such a way, especially as it has a number of users in
low level board code.

But yes, if we don't see a legitimate use case for calling the function
with caches enabled, we can also just turn it into a no-op in that case.

> Also, by moving the call to a later point in the init flow later in the
> series, are you sure that the invalidate happens before the I cache
> gets enabled in arm_cpu_lowlevel_init()?

arm_cpu_lowlevel_init() invalidates I cache on ARMv6 and ARMv7.
I believe on ARMv8, it's not necessary?

Interestingly, for ARMv8, I-Cache looks like it is only enabled early
for EL3, but for EL2/1, it's enabled in mmu_early_enable(). Any reason
for that?

Thanks,
Ahmad

> 
> Regards,
> Lucas
> 
>> +{
>> +	/* if caches are already enabled, don't cause data loss */
>> +	if (get_cr() & CR_C)
>> +		return;
>> +
>> +	arm_early_mmu_cache_invalidate();
>> +}
>> +
>>  void pbl_barebox_break(void)
>>  {
>>  	__asm__ __volatile__ (
>> diff --git a/arch/arm/cpu/entry_ll_32.S b/arch/arm/cpu/entry_ll_32.S
>> index 0d4c47c1c870..eb1793b54e66 100644
>> --- a/arch/arm/cpu/entry_ll_32.S
>> +++ b/arch/arm/cpu/entry_ll_32.S
>> @@ -15,7 +15,7 @@ ENTRY(__barebox_arm_entry)
>>  	mov	r4, r0
>>  	mov	r5, r1
>>  	mov	r6, r2
>> -	bl	arm_early_mmu_cache_invalidate
>> +	bl	dcache_invalidate_stale
>>  	mov	r0, r4
>>  	mov	r1, r5
>>  	mov	r2, r6
>> diff --git a/arch/arm/cpu/entry_ll_64.S b/arch/arm/cpu/entry_ll_64.S
>> index 5eb6efed5baf..3404f6d05802 100644
>> --- a/arch/arm/cpu/entry_ll_64.S
>> +++ b/arch/arm/cpu/entry_ll_64.S
>> @@ -15,7 +15,7 @@ ENTRY(__barebox_arm_entry)
>>  	mov	x19, x0
>>  	mov	x20, x1
>>  	mov	x21, x2
>> -	bl	arm_early_mmu_cache_invalidate
>> +	bl	dcache_invalidate_stale
>>  	mov	x0, x19
>>  	mov	x1, x20
>>  	mov	x2, x21
>> diff --git a/arch/arm/include/asm/cache.h b/arch/arm/include/asm/cache.h
>> index ea78ae123aec..64f369f865db 100644
>> --- a/arch/arm/include/asm/cache.h
>> +++ b/arch/arm/include/asm/cache.h
>> @@ -26,6 +26,9 @@ static inline void icache_invalidate(void)
>>  #endif
>>  }
>>  
>> +
>> +void dcache_invalidate_stale(void);
>> +
>>  void arm_early_mmu_cache_flush(void);
>>  void arm_early_mmu_cache_invalidate(void);
>>  
> 

-- 
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 |




      reply	other threads:[~2026-07-07 17:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07  8:05 Ahmad Fatoum
2026-07-07  8:05 ` [PATCH 2/3] ARM: v7r: factor out armv7r_cache_enable Ahmad Fatoum
2026-07-07  8:05 ` [PATCH 3/3] ARM: always call dcache_invalidate_stale before enabling D-Cache Ahmad Fatoum
2026-07-07 15:22 ` [PATCH 1/3] ARM: cpu: suppress arm_early_mmu_cache_invalidate if dcache enabled Lucas Stach
2026-07-07 17:20   ` 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=ba9e9ab0-b16e-44b2-91e6-fb036d0e66f0@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=l.stach@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