[microblaze-uclinux] Still Having Kernel Panic Problem

OK,

Yes I do have 32MB of DDR. I re-built the kernel with almost all the defaults; I still get almost the same error. My board is the same as the Vanilla board but:

1). I have cache turned off (I turned off in Kernel)

2). Turned off Multiplier

3). I do not have a network contoller (yet). But I left in all the networking stuff.

I have the latest uC Build and toolchain.

I fixed the crypt_old issue with the patch.

Here is what I get:

Linux version 2.4.27-uc1 (root@localhost) (gcc version 2.95.3-4 Xilinx EDK 6.2.1
Build EDK_Gm.12.3) #3 Sat Feb 5 14:35:28 MST 2005
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
CPU: MICROBLAZE
Console: xmbserial on UARTLite
Kernel command line:
Ca! librating delay loop... 4.33 BogoMIPS
Memory: 32MB = 32MB total
Memory: 30580KB available (1120K code, 706K data, 44K init)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2,
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Microblaze UARTlite se! rial driver version 1.00
ttyS0 at 0xffff2000 (irq = 1) is a Microblaze UARTlite
ttyS1 at 0xffff4000 (irq = 2) is a Microblaze UARTlite
Starting kswapd
xgpio #0 at 0xFFFF5000 mapped to 0xFFFF5000
Xilinx GPIO registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
eth0: Xilinx EMAC #0 at 0xC0000000 mapped to 0xC0000000, irq=3
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 2048)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Cannot open root device "" or 00:00
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 00:00

Steve Sanders <akasanders@yahoo.com> wrote:

Do you really have 32MB of RAM?

--- Greg Miller wrote:

> All,
>
> OK I figured out the issue. I had the DDR Data bits reversed (duh!).
> Now I have a different problem. I can now boot with the minimal
> Kernel from Steve... However when I did my own, I get the following
> Kernel Panic: (Please help)
>
> Linux version 2.4.27-uc1 (root@localhost) (gcc version 2.95.3-4
> Xilinx EDK 6.2.1
>
> Build EDK_Gm.12.3) #2 Sun Jan 30 13:20:24 MST 2005
>
> On node 0 totalpages: 8192
> zone(0): 8192 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> CPU: MICROBLAZE
> Console: xmbserial on UARTLite
> Kernel command line:
> Calibrating delay loop... 4.33 BogoMIPS
> Memory: 32MB = 32MB total
> Memory: 31388KB available (58! 0K code, 435K data, 32K init)
> Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
> Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
> Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
> Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
> POSIX conformance testing by UNIFIX
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Microblaze UARTlite serial driver version 1.00
> ttyS0 at 0xffff2000 (irq = 1) is a Microblaze UARTlite
> ttyS1 at 0xffff4000 (irq = 2) is a Microblaze UARTlite
> Starting kswapd
> xgpio #0 at 0xFFFF5000 mapped to 0xFFFF5000
> Xilinx GPIO registered
> uclinux[mtd]: RAM probe address=0x800c3888 size=0x3b000
> uclinux[mtd]: root filesystem index=0
> Kernel panic: VFS: Unable to mount r! oot fs on 1f:00
>
> Greg Miller wrote:
>
> Hello,
>
> I am using an Avnet board running MB. It is a similar setup the
> MB_Vanilla. I also have SRAM on the board that works fine with the
> Kernel Steve did (min). I am now trying to run out of DDR. When I do
> It will start to run, but I get a corrupted output:
>
> 4uL nexsvor i.n.274u21-(cs nseasddrb@ae-ibn)r(rc gecsvor
> i.n52394.X-l n
>
>
> i iDx E.K.6 2u1lB iDd_EmK1G..)2#36 1a2 Sat J9n12: 1445 :T4
> U0C52n0nOd o ezone(
>
> 5):zone(5): 5 pages<
>
> >4
>
> .4ez5n:(5)p g sa
>
> e4<.><
>
> >4<6>CPU: MICROBLAZEConsole: xmbserial on UARTLit<
>
> >4deKernel command line:<
>
> >4n Calibrating delay loop... RMemory:P5 B6rM 5MBBB BM 5MBBB BM 5MBBB
> BM 5MBB7 M
>
> 18B MM 8! MBMB MM 0284M 4MBMB MM 0284M 0284M 0284M 0284M 0284M 0284M
> 0284M 0284M 0
>
> 284M 0284M 0284M 0284M 0284M 0284M 0284M 4MBMB MM 4MBMB MM 4MBMB MM
> 4MBMB MM 4MB
>
> MB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM
> 4MBMB MM 4M
>
> BMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM
> 4MBMB MM 4
>
> MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB
> MM 4MBMB MM
>
> 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB
> MM 4MBMB MM
>
> 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB
> MM 4MBMB M
>
> M 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM
> 4MBMB MM 4MBMB
>
> MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM
> 4MBMB MM 4MBMB
>
> MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB! MM 4MBMB MM
> 4MBMB MM 4MBM
>
> B MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM
> 4MBMB MM 4MB
>
> MB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM
> 4MBMB MM 4M
>
> BMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM
> 4MBMB MM 4
>
> MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBMB MM 4MBM Mre:o4y4
> B0aKa lvbi
>
> ea(l5 K4c6d ,o4e9 6aKad t2, 8nKti
>
> i4<)>.kee nUl BtGsaa .l:b1c10
>
> 34
>
> ***- Another Clue. If I take a regular test program and target the
> DDR space, it seems to run except the commands are 'reversed' :
>
> ADS> help
>
> Unrecognized command "ehpl".
>
> ADS> cls
>
> Unrecognized command "lc".
>
> ADS>
>
> It seems to reverse the commands as shown above. Also, if there is
> only a three letter command, it does not pick up the first letter.
> This same program runs out of BRAM just fine.
>
> Now, I have tested the DDR and it passes in software with a random
> data test. I have also reduced the clock by half and it still does
> the same thing. Am I missing something simple? Has anyone else seen
> this?
>
>
>
> Thanks,
>
> Apco25
>
>

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/