HELP! VFS: Unable to mount root fs on unknown-block(1,0) - Embedded

This is a discussion on HELP! VFS: Unable to mount root fs on unknown-block(1,0) - Embedded ; hi there, first of all, let me just thank anyone who has taken the time to read this post ... and also i apologise for being naivety, i'm just crossing over to linux from unix :> needless to say, i'm ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: HELP! VFS: Unable to mount root fs on unknown-block(1,0)

  1. HELP! VFS: Unable to mount root fs on unknown-block(1,0)

    hi there,

    first of all, let me just thank anyone who has taken the time to read this
    post ... and also i apologise for being naivety, i'm just crossing over to
    linux from unix :>

    needless to say, i'm kinda at the end of my tether trying to figure out what
    the heck is going on ... so let me explain my problem

    what i'm trying to do is run montavista linux on an embedded PmPPC7448
    PowerPC-Based
    processor pmc module ... the board is diskless, a compressed kernel image
    and filesystem
    image is resident in flash ... i want to boot the kernel (ok) and mount the
    fs as a ramdisk from
    sdram (this is my problem!)

    my linux kernel is 2.6.10 and the artesyn board has the following
    configuration,

    CPU: MPC7448 v2.0 @ 999.999 MHz
    Board: PM/PPC-7448
    BusHz: 133333333
    I2C: ready
    DRAM: DDR SDRAM in slot 0 ECC 1024 MB
    FLASH: [64MB@e8000000] 64 MB

    my embedded physical memory map is as follows,

    SDRAM - 0000,0000 to 3fff,ffff
    FLASH - e800,0000 to ec00,0000

    the bootloader is the board manufacturers version of u-boot with slimmed
    down functionality

    the FLASH memory is partitioned as follows,

    e800,0000 - e810,0000 bootloader image
    e810,0000 - e828,0000 compressed linux kernel image
    e828.0000 - ea08,0000 compressed filesystem image

    the filesystem image (ext2) was prepared with the uboot "mkimage" tool in
    order to
    incorporate the appropriate header data for u-boot to interpret the image as
    a (gzip) compressed ramdisk

    i've provided a script of my kernel boot below, and as you will see, the
    kernel fails to mount the root fs. ramdisk support is built into the kernel
    and i use the uboot command "bootm " to boot

    it seems to me that the ramdisk driver goes start, creates 16 devices
    (/dev/ram0 to /dev/ram15 i guess) but it fails to mount the ramdisk. its
    almost as if the kernel has not associated the passed to uboot
    with the /dev/ram ... ?

    i can also see that uboot has loaded the ramdisk and relocated it at the top
    of sdram, but can the kernel address this ?? from the script it logs that
    the total memory is 768MB and not 1024MB (1GB) ... do i need to use the
    kernel prompt argument mem= ?

    are there any kernal build CONFIG_ issues that i need to address?
    the kernel is statically linked with NO modules

    i'm confused as to how the initrd is associated with the /dev/ram device ...
    how does the bootloader pass the address of the ramdisk to the kernel?

    do i need a separate initrd image in the linux /boot directory? and compile
    this into the kernel? hmmmm

    what am i doing wrong? the target platform is diskless, so i need the kernel
    to boot from flash with a root fs also located in flash.
    i've successfully booted over nfs, but now i've hit a brick wall (ugh)

    if anybody can help me then please, please please do!!

    many thanks,
    -bill

    *****************************
    here is the boot script
    *****************************

    U-Boot 0.4.0 (Jul 14 2005 - 16:09:18)1.0

    CPU: MPC7448 v2.0 @ 999.999 MHz
    Board: PM/PPC-7448
    BusHz: 133333333
    I2C: ready
    DRAM: DDR SDRAM in slot 0 ECC (Clearing..) 1024 MB
    FLASH: [64MB@e8000000] 64 MB
    PCI: Bus Host

    Waiting For EREADY ('q' to exit w/o enum).
    00 02 10b5 9656 0680 ff

    Diags Mem: PASSED
    Diags I2C: PASSED
    Diags Flash: PASSED

    Ser#: 1020
    Mon: Resides 0x40000000 - 0x3ff359c0
    BtDev: Soldered Flash
    DCach: on (WriteThrough)
    ICach: on
    L2Che: on (WriteThrough)
    Net: portdbg, porta, portb
    Hit any key to stop autoboot: 0

    PM/PPC-7448(1.0)=>printenv
    baudrate=9600
    cachemode=write
    clearmem=on
    dcache=on
    ecc=on
    enumerate=on
    eready=on
    icache=on
    l2cache=on
    model=PM/PPC-7448
    powerondiags=on
    eth_portb=auto
    eth_frontpanel=auto
    console=frontpanel
    ecc_1bit_report=off
    serial#=1020
    netmask=255.255.255.0
    serverip=192.168.1.114
    gatewayip=192.168.1.1
    bootdelay=2
    tftpport=69
    loadaddr=0x400000
    rootpath=/opt/montavista/pro/devkit/ppc/74xx/target
    bootfile=uImage.quad0
    hostname=pico-ppc3
    ipaddr=192.168.1.103
    ethport=porta
    eth_porta=100t_full
    nfs_bootargs=setenv bootargs console=ttyMM0,9600 root=/dev/nfs rw
    nfsroot=$(rootpath) ip=$(ipaddr):$(serverip)::$(netmask):$(hostname):ff
    devfs=mount
    nfs_bootcmd=dhcp ; run nfs_bootargs ; bootm
    bootcmd=run nfs_bootcmd
    ffs_bootcmd=run ffs_bootargs ; bootm e8100000 e8280000
    ffs_bootargs=setenv bootargs console=ttyMM0,9600 ramdisk_size=7167
    root=/dev/ram0 rw rootfstype=ext2 panic=10 initrd=e8280000,6ffc00
    stdin=serial
    stdout=serial
    stderr=serial
    bootargs=console=ttyMM0,9600 ramdisk_size=7167 root=/dev/ram0 rw
    rootfstype=ext2 panic=10 initrd=e8280000,6ffc00

    Environment size: 1043/1492 bytes

    PM/PPC-7448(1.0)=>run ffs_bootcmd
    ## Booting image at e8100000 ...
    Image Name: Linux-2.6.10_dev-pmppc7448-mod
    Created: 2006-03-21 11:23:51 UTC
    Image Type: PowerPC Linux Kernel Image (gzip compressed)
    Data Size: 1123720 Bytes = 1.1 MB
    Load Address: 00000000
    Entry Point: 00000000
    Verifying Checksum ... OK
    Uncompressing Kernel Image ... OK
    ## Loading RAMDisk Image at e8280000 ...
    Image Name: ram disk
    Created: 2006-03-21 10:53:06 UTC
    Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
    Data Size: 2398340 Bytes = 2.3 MB
    Load Address: e8280000
    Entry Point: e8280000
    Verifying Checksum ... OK
    Loading Ramdisk to 3fd2b000, end 3ff74884 ... OK
    Total memory = 768MB; using 2048kB for hash table (at c0400000)
    Linux version 2.6.10_dev-pmppc7448-mod (nkw@tobermoray) (gcc version 3.4.3
    (MontaVista 3.4.3-25.0.70.0501961 2005-12-18)) #65 Tue Mar 21 11:23:48 GMT
    2006
    Calling the enumerate pci bus Code
    PCI Autoconfig: Found Bus 0, Device 2, Function 0
    PCI Autoconfig: BAR 0x10, Mem size=0x200, address=0x9ffffe00
    PCI Autoconfig: BAR 0x14, I/O, size=0x100, address=0x3ffff00
    PCI Autoconfig: BAR 0x18, Mem size=0x400000, address=0x9f800000
    PCI Autoconfig: BAR 0x1c, Mem size=0x400000, address=0x9f400000
    Artesyn Communication Products, LLC - PmPPC7447
    Configured for Quad Slot 0
    Built 1 zonelists
    Kernel command line: console=ttyMM0,9600 ramdisk_size=7167 root=/dev/ram0 rw
    rootfstype=ext2 panic=10 initrd=e8280000,6ffc00
    PID hash table entries: 4096 (order: 12, 65536 bytes)
    time_init: decrementer frequency = 33.333333 MHz
    Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
    Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
    Memory: 774400k available (1796k kernel code, 544k data, 116k init, 0k
    highmem)
    Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
    spawn_desched_task(00000000)
    desched cpu_callback 3/00000000
    ksoftirqd started up.
    desched cpu_callback 2/00000000
    desched thread 0 started up.
    NET: Registered protocol family 16
    PCI: Probing PCI hardware
    Thermal assist unit not available
    JFFS version 1.0, (C) 1999, 2000 Axis Communications AB
    JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
    Generic RTC Driver v1.07
    Serial: MPSC driver $Revision: 1.00 $
    ttyMM0 at MMIO 0xf1062000 (irq = 36) is a MPSC
    ttyMM1 at MMIO 0xf1068000 (irq = 38) is a MPSC
    io scheduler noop registered
    io scheduler anticipatory registered
    io scheduler deadline registered
    io scheduler cfq registered
    RAMDISK driver initialized: 16 RAM disks of 7167K size 1024 blocksize
    loop: loaded (max 8 devices)
    pcnet32.c:v1.30i 06.28.2004 tsbogend@alpha.franken.de
    MV-643xx 10/100/1000 Ethernet Driver
    eth0: port 0 with MAC address 00:80:f9:81:00:14
    eth0: RX NAPI Enabled
    eth1: port 1 with MAC address 00:80:f9:82:00:14
    eth1: RX NAPI Enabled
    eth2: port 2 with MAC address 00:80:f9:83:00:14
    eth2: RX NAPI Enabled
    elevator: using anticipatory as default io scheduler
    physmap flash device: 4000000 at e8000000
    phys_mapped_flash: Found 2 x16 devices at 0x0 in 32-bit bank
    Intel/Sharp Extended Query Table at 0x0031
    Using buffer write method
    cfi_cmdset_0001: Erase suspend on write enabled
    cmdlinepart partition parsing not available
    RedBoot partition parsing not available
    Using physmap partition definition
    Creating 6 MTD partitions on "phys_mapped_flash":
    0x00000000-0x00100000 : "Monitor"
    0x00100000-0x00280000 : "Primary Kernel"
    0x00280000-0x02080000 : "Primary Filesystem"
    0x02080000-0x02200000 : "Secondary Kernel"
    0x02200000-0x04000000 : "Secondary Filesystem"
    0x00100000-0x04000000 : "User FLASH"
    NET: Registered protocol family 2
    IP: routing cache hash table of 8192 buckets, 64Kbytes
    TCP: Hash tables configured (established 262144 bind 65536)
    NET: Registered protocol family 1
    NET: Registered protocol family 17
    Kernel panic - not syncing: VFS: Unable to mount root fs on
    unknown-block(1,0)
    <0>Rebooting in 10 seconds..

    rhubarb!!






  2. Re: HELP! VFS: Unable to mount root fs on unknown-block(1,0)

    On Thu, 23 Mar 2006 09:00:15 -0000, "Bill Little" wrote:
    . . .
    > it seems to me that the ramdisk driver goes start, creates 16 devices
    > (/dev/ram0 to /dev/ram15 i guess) but it fails to mount the ramdisk. its
    > almost as if the kernel has not associated the passed to uboot
    > with the /dev/ram ... ?
    >
    > i can also see that uboot has loaded the ramdisk and relocated it at the top
    > of sdram, but can the kernel address this ?? from the script it logs that
    > the total memory is 768MB and not 1024MB (1GB) ... do i need to use the
    > kernel prompt argument mem= ?
    >
    > are there any kernal build CONFIG_ issues that i need to address?
    > the kernel is statically linked with NO modules
    >
    > i'm confused as to how the initrd is associated with the /dev/ram device ...
    > how does the bootloader pass the address of the ramdisk to the kernel?

    . . .

    I think one problem at least is with your kernel command line; I think
    you need a "root=" setting along the lines of "/dev/mtdX".

    The ramdisks you set up are (I believe) not related to your mounting of
    an initrd as your root filesystem.

    We went through this for the first time a couple of months ago and had
    similar difficulties. To start with I'd recommend the following refer-
    ences that we found helpful:
    -
    "Embedded Linux - Managing Flash Memory"; is a much better MTD FAQ than
    the official one
    -
    "Linux MTD, JFFS HOWTO"
    - "Find your
    Root File System with MTD" (written for uClinux, but generally not
    uClinux-specific)
    And also the BELS book (Building Embedded Linux Systems).

    HTH. Tom
    --
    /"\ ASCII Ribbon Campaign |
    \ / | Email to user 'CTZ001'
    X Against HTML | at 'email.mot.com'
    / \ in e-mail & news |




  3. Re: HELP! VFS: Unable to mount root fs on unknown-block(1,0)


    "T Ziomek" wrote in message
    news:1104_1143142907@news.mot.com...
    > On Thu, 23 Mar 2006 09:00:15 -0000, "Bill Little"

    wrote:
    > . . .
    > > it seems to me that the ramdisk driver goes start, creates 16 devices
    > > (/dev/ram0 to /dev/ram15 i guess) but it fails to mount the ramdisk. its
    > > almost as if the kernel has not associated the passed to uboot
    > > with the /dev/ram ... ?
    > >
    > > i can also see that uboot has loaded the ramdisk and relocated it at the

    top
    > > of sdram, but can the kernel address this ?? from the script it logs

    that
    > > the total memory is 768MB and not 1024MB (1GB) ... do i need to use the
    > > kernel prompt argument mem= ?
    > >
    > > are there any kernal build CONFIG_ issues that i need to address?
    > > the kernel is statically linked with NO modules
    > >
    > > i'm confused as to how the initrd is associated with the /dev/ram device

    ....
    > > how does the bootloader pass the address of the ramdisk to the kernel?

    > . . .
    >
    > I think one problem at least is with your kernel command line; I think
    > you need a "root=" setting along the lines of "/dev/mtdX".
    >
    > The ramdisks you set up are (I believe) not related to your mounting of
    > an initrd as your root filesystem.
    >
    > We went through this for the first time a couple of months ago and had
    > similar difficulties. To start with I'd recommend the following refer-
    > ences that we found helpful:
    > -
    > "Embedded Linux - Managing Flash Memory"; is a much better MTD FAQ than
    > the official one
    > -
    > "Linux MTD, JFFS HOWTO"
    > - "Find your
    > Root File System with MTD" (written for uClinux, but generally not
    > uClinux-specific)
    > And also the BELS book (Building Embedded Linux Systems).
    >
    > HTH. Tom
    > --
    > /"\ ASCII Ribbon Campaign |
    > \ / | Email to user 'CTZ001'
    > X Against HTML | at 'email.mot.com'
    > / \ in e-mail & news |
    >
    >
    >


    nice one tom!

    i'll check out those references ... i'm learning as i'm going, so your help
    is very much appreciated

    as it turned out we needed a patch to the monta vista kernel tsk! tsk!

    it failed to set the "initrd_start" and "initrd_end" kernel variables ...
    these are set from register values (r4 and r5) passed to the kernel from the
    boot loader. its the boot loader that takes the compressed ramdisk image,
    strips the uboot header and relocates it at the top of the sdram ... of
    course the kernel needs to know the image start/finish address before it can
    even attempt to load it

    cheers again tom
    -bill



+ Reply to Thread