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

angelo angelo70 at gmail.com
Mon May 10 13:09:25 EDT 2010


Hello all,

thanks again for the support,

yes, it's right. I finally found that i have strange issues with the 
SDRAM, i introduced more appropriate ram test, just after the controller 
initialization.
Anyway, some time the SDRAM behave correctly, test pass, then, after 
some time the ram start to give bad values read back amd fail the tests.
I re-soldered some control signal pin, then the test was passing 
correctly. But after some hours i get again bad tests, error on read.

Bus clock is 40 Mhz, so i shouldn't have any wiring issue. Also, i am 
quite sure of the initialization code, other users used it for the same 
memory chip.
I am starting to suspect my memories i get on ebay are faulty.

So i am still fighting again this ghosts.

Thanks for the moment, i will let you know.

Angelo


Lennart Sorensen wrote:
> 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.
>
>   




More information about the uClinux-dev mailing list