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 _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
