[uClinux-dev] kernel load issue, jump to _fault vector

Lennart Sorensen lsorense at csclub.uwaterloo.ca
Mon May 10 10:27:47 EDT 2010


On Sat, May 08, 2010 at 04:50:56PM +0200, angelo wrote:
> Hi all,
>
> well i have some news with this coldfire 5307 issue,
>
> i disassembled and put some loop as opcodes here and there in the kernel  
> (4ef9 0000 XXXX  jmp XXXX ) as a very rude debug.
>
> The issue is just at the beginning:
>
> Dump of assembler code for function _text:
> 0x00000400 <_text+0>:    nop
> 0x00000402 <_text+2>:    movew #9984,%sr
> 0x00000406 <_text+6>:    moveal #0,%sp              <--- Issue is here
> 0x0000040c <_text+12>:    movec %sp,%vbr
> 0x00000410 <_text+16>:    movel %sp,0xe8944 <_ramvec>
> 0x00000416 <_text+22>:    moveal #0,%sp
> 0x0000041c <_text+28>:    movel %sp,0xe8940 <_sdata>
> 0x00000422 <_text+34>:    movel #16777216,%d0
> 0x00000428 <_text+40>:    addl %sp,%d0
> 0x0000042a <_text+42>:    movel %d0,0xe894c <_ramend>
> 0x00000430 <_text+48>:    movel #16777216,%d0
> 0x00000436 <_text+54>:    movec %d0,%cacr
> 0x0000043a <_text+58>:    nop
> 0x0000043c <_text+60>:    movel #49184,%d0
> 0x00000442 <_text+66>:    movec %d0,%itt0
> 0x00000446 <_text+70>:    moveq #0,%d0
> 0x00000448 <_text+72>:    movec %d0,%itt1
> 0x0000044c <_text+76>:    movel #-1610612224,%d0
> 0x00000452 <_text+82>:    movec %d0,%cacr
> 0x00000456 <_text+86>:    nop
> 0x00000458 <_text+88>:    lea 0x11c250,%a1
> 0x0000045e <_text+94>:    movel %a1,0xe8948 <_ramstart>
> 0x00000464 <_text+100>:    lea 0xff000 <system_state>,%a0
> 0x0000046a <_text+106>:    lea 0x11c250,%a1
> 0x00000470 <_text+112>:    clrl %d0
>
> Seems that after setting stack frame to 0 the code jump to the interrupt  
> vector _fault routine.
>
> Probably i should set to the stack frame a more appropriate value for my  
> custom board, near the top of the SDRAM, or in the internal SRAM  
> probably should be better, but i am not finding if there is some custom  
> .c or makefile for this.
>
> Every help is appreciated,

It reminds me a lot of a uboot problem I had.  In my case uboot ran
perfectly until it moved itself to ram.  Then it died.

In my case I eventually found out that the memory controller was not
correctly initialized so it failed when it tried to use ram.  The code to
do it was right, but unfortunately since I was using gcc 4.3 which had
actually started to optimize coldfire code, it reordered memory access
(which uboot had failed to mark in any way as being critical to order
as written), which made the memory controller initialization not work.
A couple of memory write barriers in the memory controller setup code
solved the problem and it no longer failed.

So my point is: Make absolutely sure you initialized the memory controller
correctly.

-- 
Len Sorensen



More information about the uClinux-dev mailing list