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.
_______________________________________________
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
