[PATCH 1/3] ARM: cpu: suppress arm_early_mmu_cache_invalidate if dcache enabled
Ahmad Fatoum
a.fatoum at pengutronix.de
Tue Jul 7 10:20:30 PDT 2026
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 |
More information about the barebox
mailing list