Hi Greg and all,
infinite thanks for the support, trying to comment out the line that set
VBR i understood that the $pc point was variable, and mostly was
happening just after the jump in SDRAM.
So i thought that some months ago i had the kernel partially loaded, and
the only difference was in SDRAM initialization code.
And that was ! I replaced days ago some part of the initialization with
the one sent me from a guy, but that code was not exactly for my SDRAM /
clock.
Dumping SDRAM with kernel loaded was looking ok, but for the MCF5307
execution/instructions fetch someway it wasn't.
So i rolled back to my previous initialization code, and it works !
I am very very happy. Now i am trying to get a working image. Seems my
flash SST 39BF3201B is not correctly detected.
Linux version 2.6.29-uc0001 (r...@angel7) (gcc version 4.2.4) #61 Sun
May 23 23:59:24 CEST 2010
uClinux/COLDFIRE(m5307)
COLDFIRE port done by Greg Ungerer, g...@snapgear.com
Modified for M5307 by Dave Miller, dmil...@intellistor.com
Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064
Kernel command line:
PID hash table entries: 64 (order: 6, 256 bytes)
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory available: 15072k/16384k RAM, (1010k kernel code, 140k data)
SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay loop... 52.83 BogoMIPS (lpj=264192)
Mount-cache hash table entries: 512
bio: create slab <bio-0> at 0
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
ColdFire internal UART serial driver
ttyS0 at MMIO 0x100001c0 (irq = 73) is a ColdFire UART
console [ttyS0] enabled
ttyS1 at MMIO 0x10000200 (irq = 74) is a ColdFire UART
mice: PS/2 mouse device common for all mice
List of all partitions:
No filesystem could mount root, tried: jffs2
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
Regards,
Angelo
On 21/05/2010 07:41, Greg Ungerer wrote:
Hi Angelo,
angelo wrote:
i have some additional info from the fault, setting VBR,
An exception for invalid instruction seems to be thrown, but in any
case, the same instruction shouldn't cause any exception at all.
As you said, this could seems an SDRAM issue, but actually i solved
the issues with it, memory test at startup pass always.
What sort of memory tests do you run?
How well do they check the RAM?
Do you run the memory tests with cache on as well as of?
I checked,
1) the opcode, it is legal, correct, as per 5307 manual
movec %a7, %VBR correspond exactly to "4e7bf801" opcode in the manual.
This should exclude any toolchain or any -mCPU issue.
How far does execution get if you comment out that movec line?
2) before jumping to 0x400 i am checking the SDRAM, reading the code
just copied in memory. Here is what i am doing:
I don't really know Colilo well, but the processor is still
in supervisor mode when it passes control to the newly loaded
kernel isn't it?
Regards
Greg
Sysam AMCORE boot...
colilo>l 400 0
load: Sysam AMCORE download to 400
Downloaded 1129472 bytes
colilo>m 0
00000000: 00000000 ffc00400 ffc0045e ffc0045e
00000010: ffc0045e ffc0045e ffc0045e ffc0045e
00000020: ffc0045e ffc0045e ffc0045e ffc0045e
00000030: ffc0045e ffc0045e ffc0045e ffc0045e
00000040: ffc0045e ffc0045e ffc0045e ffc0045e
00000050: ffc0045e ffc0045e ffc0045e ffc0045e
00000060: ffc0045e ffc0045e ffc0045e ffc0045e
00000070: ffc0045e ffc0045e ffc0045e ffc0045e
00000080: ffc0045e ffc0045e ffc0045e ffc0045e
00000090: ffc0045e ffc0045e ffc0045e ffc0045e
000000a0: ffc0045e ffc0045e ffc0045e ffc0045e
000000b0: ffc0045e ffc0045e ffc0045e ffc0045e
000000c0: ffc0045e ffc0045e ffc0045e ffc0045e
000000d0: ffc0045e ffc0045e ffc0045e ffc0045e
000000e0: ffc0045e ffc0045e ffc0045e ffc0045e
000000f0: ffc0045e ffc0045e ffc0045e ffc0045e
...
colilo>m 400
00000400: 4e7146fc 27002e7c 00000000 4e7bf801
00000410: 23cf000f ce3c2e7c 00000000 23cf000f
00000420: ce38203c 01000000 d08f23c0 000fce44
00000430: 203c0100 00004e7b 00024e71 203c0000
00000440: c0204e7b 00047000 4e7b0005 203ca000
00000450: 02004e7b 00024e71 43f90012 012023c9
00000460: 000fce40 41f90011 400043f9 00120120
00000470: 428020c0 b3c86600 fffa41f9 0010a000
00000480: 4fe81000 4eb90010 b4744efa fffe0000
00000490: 4e56ffa0 48d70c3c 266e0008 200f0280
000004a0: fffff000 20402a28 00104ab9 0011400c
000004b0: 660000fa 4e932800 4ab90011 400c667a
000004c0: 42001d40 ffc04a84 671072ed b284670a
000004d0: 4ab90011 400c6600 0136240f 0282ffff
000004e0: f0002442 baaa0010 671c4878 00404879
000004f0: 000eeb6c 486effc0 4eb90008 de482545
colilo>g 400
Vector table still contain offsets for the colilo "_fault" handler
routine.
Anyway, even if everything is correct in memory, jumping to 0x400 i
get the exception
setting VBR (@ offset 0x40C).
I am now suspecting of a kind of bad fetching instructions from the
SDRAM, like if 16bit (2bytes)opcodes are read correctly, but not the
longer opcodes.
I am really without any other ideas here.
Thanks,
Angelo
On 18/05/2010 23:52, angelo wrote:
brianW,
thanks for the reply,
i am not using %a7, it is the uClinux kernel that use the stack
pointer as a temporary register. It is quite impossible that head.S
of the kernel have issues open.
#CONFIG_VECTORBASE is 0x00000000
Anyway, i replaced %a7 with %d0, just for test. Issue happen exactly
there, at the same line, setting VBR.
I have read that movec can trig an "illegal instruction" exception,
and i guess this is exactly what's happening here.
I had already the kernel running some months ago, one of the things
i changed is the toolchain, but also the version of the uClinux
distribution.
I am starting to have some doubts on the toolchain.
Regards,
Angelo
On 18/05/2010 23:38, wi...@ecs.csus.edu wrote:
[...]
At reset, the "colilo" bootloader test the SDRAM memory, than
start up
correctly giving the prompt.
Kernel 2.6 has been prepared with sdram start at 0x00000000, vector
start at 0x00000000, kernel code start at 0x400.
I load now through colilo "load" command the kernel (linux.bin) at
0x400
(SDRAM, flash is remapped at 0xffc00000 from colilo at reset).
Once i run the code from 0x400, after some instructions the $pc
jump to
the "colilo" "_fault" routine.
I inserted a loop in
linux-2.6.x/arch/m68knommu/platform/coldfire/head.S, to find the
exact
point where the jump happen, as below:
_start:
nop /* filler */
movew #0x2700, %sr /* no interrupts */
/*
* Do any platform or board specific setup now. Most boards
* don't need anything. Those exceptions are define this in
* their board specific includes.
*/
PLATFORM_SETUP
/*
* Create basic memory configuration. Set VBR accordingly,
* and size memory.
*/
movel #CONFIG_VECTORBASE,%a7
_loop: jmp _loop
movec %a7,%VBR /* set vectors addr */ *<<-- this
line cause
the jump to _fault*
movel %a7,_ramvec
Angelo --
Here is my guess. I did MC68010 programming _many_ years ago.
Why are you using A7 as your address reg? It is the stack pointer!
If you have interrupts enabled ( which you don't ), that is a
very good place to crash. What could happen instead, anytime
you BSR ( call a subr ), pushing the return address will
corrupt your memory. If CONFIG_VECTORBASE is a Flash address,
then you will not get back the return address on RET .
Could you use A0 instead of A7 (SP) ?
anyway, I hope that helps,
*brianW
Now i know the SDRAM is working correctly, but i am still stucked
here.
Any help is really appreciated.
Many Thanks,
Angelo
------------------------------------------------------------------------
_______________________________________________
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
_______________________________________________
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
