Hi,
On 07.07.22 12:57, Ahmad Fatoum wrote:
> On 07.07.22 12:41, Steffen Trumtrar wrote:
>> Signed-off-by: Steffen Trumtrar <s.trumtrar@xxxxxxxxxxxxxx>
[snip]
>> +static noinline void aa1_start(void)
>> +{
>> + int pbl_index = 0;
>> + int barebox = 0;
>> + int bitstream = 0;
>> +
>> + arm_early_mmu_cache_invalidate();
>
> Is this really required? If MMU is enabled by the time you
> enter here, you risk executing garbage before hitting
> this line anyway and if it's disabled, caches will be invalidated
> just before MMU is enabled already.
>
>> +
>> + relocate_to_current_adr();
I see now that I was mistaken here, because relocate_to_current_adr()
called directly after will call sync_for_execution(), which will clean
D$ and invalidate I$. If we happen to have stale dirty D$ entries,
these will be flushed and corrupt memory, which
arm_early_mmu_cache_invalidate() avoided. I still think we shouldn't
expect board code to call arm_early_mmu_cache_invalidate(), rather
sync_caches_for_execution() should take care to only invalidate I$,
when caches are disabled.
My "ARM: sync_caches_for_execution: don't flush disabled data cache"
patch from earlier today should resolve this. You'll probably want
to cherry pick it..
Cheers,
Ahmad
--
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 |
