At least the iMX6 boot rom seems to jump into barebox with a non
invalidated d-cache which causes data corruption when
v7_mmu_cache_flush() executed by arm_early_mmu_cache_flush() overrides
stack or other valid data.
That's why the cache must be invalided for this processors explicitly
(e.g. in barebox_arm_reset_vector()). Operation differs from flush only
in one instruction so that patch modifies the existing
v7_mmu_cache_flush() function slightly by adding an optional argument.
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Registers 'r0' till 'r3' are scratch registers and do not need to be
restored.
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Although conclusions in 50d1b2de8e "ARM
v7: Fix register corruption in v7_mmu_cache_off" are correct, the
implemented fix is not complete because the following failure can
happen:
1. d-cache contains the cache line around 'sp'
2. v7_mmu_cache_off() disables cache
3. early v7_mmu_cache_flush() pushes 'lr' on uncached stack
4. v7_mmu_cache_flush() flushes d-cache and can override stack written
by step 3.
5. v7_mmu_cache_flush() pops 'lr' out of cache and jumps to it which
might be random data now.
Patch avoids step 3 which is easy because 'lr' is never modified by the
function. By using the 'r12' scratch register instead of 'r10', the
whole initial 'push' can be avoided.
Patch moves also the 'DMB' operation so that it is executed after data
has been pushed on stack.
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
v7_mmu_cache_flush stores registers on the stack and restores
them afterwards. Additionally v7_mmu_cache_flush is called
from v7_mmu_cache_off *after* disabling the MMU. With this
the following can happen:
- v7_mmu_cache_off disables the MMU. From now on no new values
go to the data cache.
- v7_mmu_cache_off calls v7_mmu_cache_flush which in turn puts
registers on the stack. Due to the MMU being disabled they
do not go into the data cache.
- In v7_mmu_cache_flush the memory the stack is pointing to is
overwritten with the values currently being in the cache.
- v7_mmu_cache_flush restores the registers from the stack with
values from the cache and not the memory where the values have
previously been written to.
Fix this by storing the registers on the stack *before* we disable
the MMU and restore them after we have called v7_mmu_cache_flush.
This way v7_mmu_cache_flush still restores corrupt register values
for the case when the MMU has been disabled, but we will restore
correct values afterwards.
This has been first observed when switching to gcc-4.7.2 when compiling
in Thumb2 mode, but could explain earlier problems also. The result
here was that the register holding the kernel address in start_linux()
was corrupted so that the kernel could not be started.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The different ARM architectures need different cache functions. This
patch makes them selectable during runtime.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Save/restore the registers used in __mmu_cache_* so that they can
be called as regular C functions.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Traditionally we call __mmu_cache_flush in early startup. There
is a problem with armv7 and hierarchical caches though, on these
systems __mmu_cache_flush uses the stack. Appearantly this was
seldomly a problem, because most of these systems have a ROM
bootloader which sets up some stack, but on a special i.MX6 system
this failed badly. We should not have to flush caches here. Every
sane system should pass control to the bootloader without stale
entries in the caches *), so it should be a safe assumption that the
cache flush can be removed.
Since __mmu_cache_flush is not called from early code anymore we can
also move it to the regular text section.
Be brave and give it a try.
*) omap3 seems to be a exception to this, but this has a cache flush
in arch_init_lowlevel already
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The armv7 specific __mmu_cache_on function accidently sets
the page table pointer with the unitialized value of r3. It seems
that often enough r3 still held the correct value from a previous
call to mmu_init allowing this bug to remain uncovered for longer.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
and make init.h availlable for assembly too
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Instead of having seperate cache flush functions in the startup code
we want to call the generic functions. To accomplish this they have
to be in the bare_init section.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
These cache functions have been extracted from
arch/arm/boot/compressed/head.S. The old code only worked
properly on ARMv4. Tested on ARMv4, ARMv5, ARMv6 hardware.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Enrico Scholz
Sascha Hauer
Jean-Christophe PLAGNIOL-VILLARD