SVC32 and SP

Sascha Hauer s.hauer at
Fri May 18 05:41:11 EDT 2012

On Fri, May 18, 2012 at 12:06:00AM +0200, Carlo Caione wrote:
> Hi,
> I was debugging the problem with barebox and qemu-linaro as I
> described in a previous post.
> This is what I have discovered.
> The problem is in the strlen function that seems to get corrupted
> runtime during barebox initialization. The problem seems related to
> the switch to SVC32 mode together with the __mmu_cache_flush
> implementation.
> Before setting the cpu to SVC32 mode, the Stack Pointer is correctly
> set to 0x4020fcb0, but, immediately after the writing in the cpsr
> register (__asm__ __volatile__("msr cpsr, %0" : : "r"(r));) the Stack
> Pointer (now R13_SVC) is in 0x40205cb0 that is in the middle of the
> .text section (and precisely in the middle of the strlen routine).
> The problem is that in the __mmu_cache_flush disassembly I have a huge
> push {r0, r1, r2, r3, r4, r5, r6, r7, r9, r10, r11} that overwrites
> the strlen function and corrupts the code.

Can you try and remove the call to __mmu_cache_flush in start.c?

I think this call shouldn't be there at all. A (pre-) bootloader should
always manage to call the next image with the caches properly flushed,
otherwise we are doomed in barebox anyway.

The problem with the armv7 __mmu_cache_flush implementation is that
it uses the stack which we haven't configured at that time.

I thought I had already wired up a patch for this, but it seems I


Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 |  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

More information about the barebox mailing list