SVC32 and SP

SVC32 and SP

[Carlo Caione]

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.

I'm using:
arm-none-eabi-gcc (Sourcery CodeBench Lite 2011.09-69) 4.6.1
QEMU emulator version 1.0.91 (qemu-linaro from git)

--
Carlo Caione

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: SVC32 and SP

[Sascha Hauer]

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
haven't.

Sascha

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: SVC32 and SP

[Carlo Caione]

On Fri, May 18, 2012 at 11:41 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> 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?

Everything is fine if I comment out __mmu_cache_flush()

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: SVC32 and SP

[Sascha Hauer]

On Mon, May 21, 2012 at 09:31:51PM +0200, Carlo Caione wrote:
> On Fri, May 18, 2012 at 11:41 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > 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?
> 
> Everything is fine if I comment out __mmu_cache_flush()

Ok, thanks for testing. I'll prepare a patch for this

Sascha


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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox