mmc support in 2.6.37 and 2.6.38

[Nicolas]

I just tried the last kernel (2.6.35.13, 2.6.36.4, 2.6.37.6, 2.6.38.4 and 2.38.5).  The 2.6.37 and 2.6.38 fail to mount the root filesystem from mmcblk0p2 where the 2.6.35 and 2.6.36 succeed.

Is the mmc support deprecated?  I've my /boot on mmcblk0p1 (ext2) and the root on mmcblk0p2 (ext3). I thought it was a common setup.

Regards,
N.

[cbxbiker61]

If you're talking about sheeva.with-linux kernels. ext3 is built in to all of those versions.  I use ext2 on my flash devices, so I'm not sure what your problem is.

[Nicolas]

Sorry, yes I'm speaking of the sheeva.with-linux kernels.

I get the following oops with 2.6.37 and 2.6.38, but not the previous ones:

Code:

VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "mmcblk0p2" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00            1024 mtdblock0  (driver?)
1f01            4096 mtdblock1  (driver?)
1f02          519168 mtdblock2  (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
[<c00355d4>] (unwind_backtrace+0x0/0xe0) from [<c0409378>] (panic+0x58/0x17c)
[<c0409378>] (panic+0x58/0x17c) from [<c0008d98>] (mount_block_root+0x1bc/0x1fc)
[<c0008d98>] (mount_block_root+0x1bc/0x1fc) from [<c0008f70>] (mount_root+0xa0/0xc0)
[<c0008f70>] (mount_root+0xa0/0xc0) from [<c00090f4>] (prepare_namespace+0x164/0x1b8)
[<c00090f4>] (prepare_namespace+0x164/0x1b8) from [<c00089f0>] (kernel_init+0x10c/0x14c)
[<c00089f0>] (kernel_init+0x10c/0x14c) from [<c0031494>] (kernel_thread_exit+0x0/0x8)

I just change a symlink in the /boot partition to switch kernels, so the remaining of the system is identical.

Regards,
N.

[cbxbiker61]

Sorry, yes I'm speaking of the sheeva.with-linux kernels.

I get the following oops with 2.6.37 and 2.6.38, but not the previous ones:

Code:

VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "mmcblk0p2" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00            1024 mtdblock0  (driver?)
1f01            4096 mtdblock1  (driver?)
1f02          519168 mtdblock2  (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
[<c00355d4>] (unwind_backtrace+0x0/0xe0) from [<c0409378>] (panic+0x58/0x17c)
[<c0409378>] (panic+0x58/0x17c) from [<c0008d98>] (mount_block_root+0x1bc/0x1fc)
[<c0008d98>] (mount_block_root+0x1bc/0x1fc) from [<c0008f70>] (mount_root+0xa0/0xc0)
[<c0008f70>] (mount_root+0xa0/0xc0) from [<c00090f4>] (prepare_namespace+0x164/0x1b8)
[<c00090f4>] (prepare_namespace+0x164/0x1b8) from [<c00089f0>] (kernel_init+0x10c/0x14c)
[<c00089f0>] (kernel_init+0x10c/0x14c) from [<c0031494>] (kernel_thread_exit+0x0/0x8)

I just change a symlink in the /boot partition to switch kernels, so the remaining of the system is identical.

Regards,
N.

My head wasn't in the game when I posted the previous reply (I've been up all night).  It'd be good to see your uboot environment.  I'm going to take a look at mine.  Probably a good time to see if the userspace util for listing the uboot env works.

The utils contain sheeva-ubootenv-print.  It looks like they haven't been updated in a long time (but the print did work).

https://sheeva-uboot-tools.googlecode.com/hg/

OK my current bootargs are as follows:
bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0(uBoot),0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) ro root=/dev/mmcblk0p1 ip=192.168.1.9:192.168.1.4:192.168.1.4:255.255.255.0:DB88FXX81:eth0:none

My fstab has the following entry: (don't use the default rootfs / rootfs entry, it's known to cause fsck problems).

/dev/mmcblk0p1 / ext2 rw,noatime 1 1

[Nicolas]

Here is my uboot env from the console. uboot version is Newit one (uboot-sata-090903.bin).

Code:

Marvell>> reset

         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|
 ** MARVELL BOARD: SHEEVA PLUG LE

U-Boot 1.1.4 (Jul 14 2009 - 06:46:57) Marvell version: 3.4.16

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CF120

Soc: 88F6281 A0 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM CS[1] base 0x10000000   size 256MB
DRAM Total size 512MB  16bit width
Flash:  0 kB
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:512 MB

CPU : Marvell Feroceon (Rev 1)

Streaming disabled
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
Net:   egiga0 [PRIME], egiga1
Hit any key to stop autoboot:  0
Marvell>> printenv
baudrate=115200
loads_echo=0
rootpath=/mnt/ARM_FS/
netmask=255.255.0.0
console=console=ttyS0,115200
CASset=min
MALLOC_len=1
ethprime=egiga0
bootargs_root=root=/dev/mtdblock2 ro
ethmtu=1500
usb0Mode=host
nandEcc=1bit
ethact=egiga0
serverip=10.10.0.2
ipaddr=10.10.0.1
cesvcid=ULULULULULULPPULULULULULDA
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
mvPhoneConfig=mv_phone_config=dev0:fxs,dev1:fxs
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
yuk_ethaddr=00:00:00:EE:51:81
netretry=no
rcvrip=169.254.100.100
loadaddr=0x02000000
autoload=no
ethaddr=00:50:43:01:4C:23
run_diag=no
bootargs=console=ttyS0,115200 mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/mtdblock1 rw ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none
arcNumber=2678
bootargs_console=console=ttyS0,115200
bootargs_mtd=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs
bootargs_mmc=root=/dev/mmcblk0p2
load_mmc=ext2load mmc 0:1 0x00800000 /uImage
bootcmd_mtd=setenv bootargs $(bootargs_console) $(bootargs_mtd); nand read.e 0x800000 0x100000 0x300000; bootm 0x800000
bootcmd_mmc=mmcinit; run load_mmc; setenv bootargs $(bootargs_console) $(bootargs_mmc); bootm 0x00800000
bootargs_usb=root=/dev/sda2 rootdelay=10
bootcmd_usb=setenv bootargs $(bootargs_console) $(bootargs_usb); usb start; ext2load usb 0:1 0x00800000 /uImage; bootm 0x00800000
bootcmd=run bootcmd_usb; run bootcmd_mmc;run bootcmd_mtd
stdin=serial
stdout=serial
stderr=serial
mainlineLinux=yes
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
netbsd_en=no
vxworks_en=no
bootdelay=3
disaMvPnp=no
enaAutoRecovery=yes

Environment size: 1883/131068 bytes

And Here is the fstab.

Code:

# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/mmcblk0p2 during installation
UUID=2d32987a-81f5-4d9b-9e84-0585ffce1645 /               ext3    errors=remount-ro 0       1
# /boot was on /dev/mmcblk0p1 during installation
UUID=18da8739-d1c8-4b88-b60e-c25a58d9d4b0 /boot           ext2    defaults        0       2
# swap was on /dev/mmcblk0p5 during installation
UUID=c5c9015d-6d3b-42e8-bcfd-f382a19012e8 none            swap    sw              0       0
/dev/sda1       /media/usb0     auto    rw,user,noauto  0       0

Regards,
N.

[cbxbiker61]

Try to mount it without using the UUID approach and see if it works.

Failing that...I'd suggest you mount it EXT2 - that works for sure.

Personally I'm convinced that EXT2 is better on flash devices anyway since it creates less wear and tear on the flash.

[marcus]

Is this a different problem to the eSATA / mmc issue that I brought up a while back?

[birdman]

VFS: Cannot open root device "mmcblk0p2" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available partitions:

That's not an fstab issue - it's a boot option issue (cat /proc/cmdline to see what you are using).

There was a change in this area recently (indeed - it was in 2.6.37)

commit b5af921ec02333e943efb59aca4f56b78fc0e100
Author: Will Drewry <wad@chromium.org>
Date:   Tue Aug 31 15:47:07 2010 -0500

    init: add support for root devices specified by partition UUID
   
    This is the third patch in a series which adds support for
    storing partition metadata, optionally, off of the hd_struct.
   
    One major use for that data is being able to resolve partition
    by other identities than just the index on a block device.  Device
    enumeration varies by platform and there's a benefit to being able
    to use something like EFI GPT's GUIDs to determine the correct
    block device and partition to mount as the root.
   
    This change adds that support to root= by adding support for
    the following syntax:
   
      root=PARTUUID=hex-uuid
   
    Signed-off-by: Will Drewry <wad@chromium.org>
    Signed-off-by: Jens Axboe <jaxboe@fusionio.com>

but before that it wouldn't have worked either, unless you were using an initrd image.

[birdman]

That's not an fstab issue - it's a oot option issue (cat /proc/cmdline to see what you are using).

Ah - you already have - your problem is something else.  I got carried away with the UUID usage.
FWIW, my /etc/fstab contains:

Code:

/dev/mmcblk0p1  /boot   ext2    relatime 1 1

and I end up with

Code:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p1           99649      9436     85068  10% /boot

and I'm using 2.6.38.5.  I've had no problem with any 2.6.37* or 2.6.38* kernel (since if I did I wouldn't have been able to change it easily)

[spinifex]

http://www.plugcomputer.org/plugforum/index.php?topic=5815.msg18801#msg18801

I understand the problem, because I have it too. Allow me to try again to state the problem:

The SDHC slot seems only to be detected by the kernel if it has card inserted at boot time.

I recall having a similar issue with an Acer ZG5 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/271019)

I am not sure what to do next.

[birdman]

I understand the problem, because I have it too. Allow me to try again to state the problem:

The SDHC slot seems only to be detected by the kernel if it has card inserted at boot time.

That would be a different problem then.  The OP had the root file-system on an SD card, so would (presumably) have had an SD card inserted at boot time.

[spinifex]

Yes.  I have no troubles booting from SD or using an SD that is inserted prior to boot.
I have noticed that once I remove it I cant use the SD slot anymore.

[spinifex]

# hdparm -z /dev/sdb

Makes the SD work again.  Am I wrong in guessing that the problem is that the detection code in mvsdio does not get called?

[birdman]

I have a vague memory of reading somewhere that inserting an SD card (or CF, or XD) into a USB adaptor doesn't produce any resulting signal, so it can only be detected by continually polling them.
On a desktop system this would be done by hal(?), which probably isn't running on the Plug.
So, if the adaptor behaves like USB this could be the problem.

[spinifex]

The Debian solution appears to be "udisk". However udisk causes udev tasks to loop (50% cpu). Still investigating ...