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