boot-time partitions and bootargs for 2.6.14

I have 2.6.14 kernel and the following partitions (defined in U-Boot 1.1.4) mtdparts=0:1024k(Linux),4096k(root),2048k(Unused),512k(U-Boot),512()

And I tried different bootargs bootargs=console=ttyCPM0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2

And I tried
bootargs console=ttyCPM0,115200 root=31:01 rw rootfstype=jffs2

I still have

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1)

I tried different minor numbers but result the same. Does anybody know what type of root param I should use for 2.6.14 - mtdblock1 or 31:01? Can anybody suggest me what I missed? One of the reasons I see that I may have a corrupted root.

Thank you

Dimitry

Are you sure that your flash device name in Linux is just "0" ? Which board is this?

...

The kernel boot messages contain a section about MTD partitions found, something like this:

...
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 4 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 4 TX channels, 2 RX channels
eth0: emac0, MAC 00:50:c2:1e:af:fe
eth0: found Generic MII PHY (0x00)
eth1: emac1, MAC 00:50:c2:1e:af:fd
eth1: found Generic MII PHY (0x01)
PPChameleon: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
PPChameleon: Swapping erase regions for broken CFI table. number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
===> Creating 3 MTD partitions on "PPChameleon":
===> 0x00000000-0x00180000 : "linux"
===> 0x00180000-0x003c0000 : "user"
===> 0x003c0000-0x00400000 : "u-boot"

	...

Can you see these messages on your system? Is the flash name really "0"? Are the partitions correct?

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected]
Technology is dominated by those who manage what they do  not  under-
stand.

Yes, these partitions are correct (well, I think)
Bank # 1: Sharp 28F016SC (16 Mbit, 32 x 64K)
Size: 8 MB in 32 Sectors
Sector Start Addresses:

    FF800000      FF840000      FF880000      FF8C0000      FF900000
    FF940000      FF980000      FF9C0000      FFA00000      FFA40000
    FFA80000      FFAC0000      FFB00000      FFB40000      FFB80000
    FFBC0000      FFC00000      FFC40000      FFC80000      FFCC0000
    FFD00000      FFD40000      FFD80000      FFDC0000      FFE00000
    FFE40000      FFE80000      FFEC0000      FFF00000 (RO) FFF40000 (RO)
    FFF80000      FFFC0000

FF800000 - FF8C0000 - Linux (4 sect, 1024k)
FF900000 - FFCC0000 - Root (16 sect, 4096k)
FFD00000 - FFEC0000 - Unused (8 sect, 2048k)
FFF00000 - FFF40000 - U-boot (2 sect, 512k)
FFF80000 - FFFC0000 - Rest (2 sect, 512k)

No, I cannot see these messages. Here what I see
...
Kernel command line: console=ttyCPM0,115200 root=31:01 rw rootfstype=jffs2 PID hash table entries: 512 (order: 9, 8192 bytes)
Warning: real time clock seems stuck!
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 62848k available (1568k kernel code, 396k data, 88k init, 0k highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
JFFS2: default compression mode: priority
fuse init (API version 7.2)
Initializing Cryptographic API
Generic RTC Driver v1.07
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a00 (irq = 40) is a CPM UART
ttyCPM1 at MMIO 0xf0011a20 (irq = 41) is a CPM UART
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
...

Kernel panic - not syncing: VFS: Unable to mount root fs on

unknown-block(31,1)
<0>Rebooting in 180 seconds..

I am trying to debug right now using gdb and BDI and I found out that error occurs when I try to

(gdb) c
Continuing.

Breakpoint 1, do_mount (dev_name=0xc03c1000 "/dev/root", dir_name=0xc03c0000 "/root", type_page=0xc03bf000 "jffs2", flags=0x8000, data_page=0x0) at fs/namespace.c:1022

long do_mount(char * dev_name, char * dir_name, char *type_page,
unsigned long flags, void *data_page)

{
	struct nameidata nd;
	int retval = 0;
	int mnt_flags = 0;

	/* Discard magic */
	if ((flags & MS_MGC_MSK) == MS_MGC_VAL)
		flags &= ~MS_MGC_MSK;

	/* Basic sanity checks */

	if (!dir_name || !*dir_name || !memchr(dir_name, 0, PAGE_SIZE))
		return -EINVAL;
	if (dev_name && !memchr(dev_name, 0, PAGE_SIZE))
           return -EINVAL; <---- ERROR
           ^^^^^^^^^^^^^^^^

Do you know what this might be?

I think you are right. I missed the point.

=> flinfo

Bank # 1: Sharp 28F016SC (16 Mbit, 32 x 64K)
Size: 8 MB in 32 Sectors
Sector Start Addresses:

    FF800000      FF840000      FF880000      FF8C0000      FF900000
    FF940000      FF980000      FF9C0000      FFA00000      FFA40000
    FFA80000      FFAC0000      FFB00000      FFB40000      FFB80000
    FFBC0000      FFC00000      FFC40000      FFC80000      FFCC0000
    FFD00000      FFD40000      FFD80000      FFDC0000      FFE00000
    FFE40000      FFE80000      FFEC0000      FFF00000 (RO) FFF40000 (RO)
    FFF80000      FFFC0000

So I have mtdparts=1:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()

But problem remains...

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1)

Are you using physmap as the means of creating the mtd devices? If so there is a bug in many variants of the kernel that defines the map structure as follows:
struct map_info physmap_map = {
.name = "Physically mapped flash",
.size = WINDOW_SIZE,
.buswidth = BUSWIDTH,
.phys = WINDOW_ADDR,
};

Note that the name has embedded spaces - something I've never managed to get U-Boot to pass across on the kernel command line (I'm sure Wolfgang will correct me if I'm wrong here!!). The '1' in your "mtdparts=1:1024k(Linux)" should match the name of this map. In this case the code needs to be changed to NOT have spaces in it (and perhaps a more user friendly name) and the kernel config values for WINDOW_SIZE, BUSWIDTH and WINDOW_ADDR set correctly. That way you'd end up with something like:
struct map_info physmap_map = {
.name = "fred",
.size = WINDOW_SIZE,
.buswidth = BUSWIDTH,
.phys = WINDOW_ADDR,
};
and a command line something like:
mtdparts=fred:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()

I'd also suggest that you mount a known good fs using NFS (if you have ethernet on your target) and then try manually mounting the flash fs - that will check out its structure (endian-ness?) and the jffs2 drivers on your target.

Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : [email protected]
New Zealand


=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================

Thank you Robin,

Yes, I have 'working' jffs2.img (original from board).
I checked for spaces - it looks ok. It has 'physically_mapped_flash'.
What I think is the problem with no discovering the flash - it should call 'add_mtd_partitions' in 'mtdpart.c' after finding the chip but it is not calling it and looks like because it's not finding the flash (8272ADS, Sharp 28F016SC).

I have:
...
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
$Id: ftl.c,v 1.55 2005/01/17 13:47:21 hvr Exp $
physmap flash device: 800000 at ff800000
eth0: FCC ENET Version 0.3, 00:04:9f:91:22:33
...

And probably I should expect something like this:
...
PPChameleon: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
PPChameleon: Swapping erase regions for broken CFI table. number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
===> Creating 3 MTD partitions on "PPChameleon":
===> 0x00000000-0x00180000 : "linux"
===> 0x00180000-0x003c0000 : "user"
===> 0x003c0000-0x00400000 : "u-boot"

I may be missing something, from my understanding it should find the chip before mounting root. And it looks like it couldn't find the chip. Again, I may be wrong and very likely I missed something.

But I will really appreciate if somebody can help me with this.

[snip]

In that case you should have a u-boot line of

mtdparts=physically_mapped_flash:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512() not of
mtdparts=1:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()

The name is significant (I think!!)

Robin Gilks
Senior Design Engineer          Phone: (+64)(3) 357 1569
Tait Electronics                Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : [email protected]
New Zealand


=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================

Yep, I set mtdparts=phys_mapped_flash:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()

I got flash discovery working and I set 'CONFIG_MTD_CMDLINE_PARTS=y' but kernel is not even attempting to parse 'mtdparts'. It's not calling 'parse_cmdline_partitions' function. Even if I got wrong 'mtd-id', it still should attempt to parse 'mtdparts' (well, at least I think so).

Here is output:

Kernel command line: console=ttyCPM0,115200 root=31:01 rw rootfstype=jffs2 PID hash table entries: 512 (order: 9, 8192 bytes)
Warning: real time clock seems stuck!
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 62720k available (1572k kernel code, 408k data, 96k init, 0k highmem) Mount-cache hash table entries: 512
NET: Registered protocol family 16
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
JFFS2: default compression mode: priority
fuse init (API version 7.2)
Initializing Cryptographic API
Generic RTC Driver v1.07
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a00 (irq = 40) is a CPM UART
ttyCPM1 at MMIO 0xf0011a20 (irq = 41) is a CPM UART
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
physmap flash device: 800000 at ff800000
Found: Intel I28F016S3
phys_mapped_flash: Found 4 x8 devices at 0x0 in 32-bit bank RedBoot partition parsing not available
eth0: FCC ENET Version 0.3, 00:04:9f:91:22:33
mii_reg: 600eb881
eth0: Phy @ 0x0, type Davicom DM9161E (0x0181b881)
eth1: FCC ENET Version 0.3, 00:04:9f:51:22:33
mii_reg: 618eb881
eth1: Phy @ 0x3, type Davicom DM9161E (0x0181b881)
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17

Does anybody has any idea of why parsing of 'mtdparts' is not even started?

I have enabled debug macro:

/* debug macro */
#if 1
#define dbg(x) do { printk("DEBUG-CMDLINE-PART: "); printk x; } while(0) #else
#define dbg(x)
#endif

Thank you

You may set it, but do you pass it as part of the boot arguments?

No, you don't. [Do you understand now why complete information is essential? If you had provided the boot log with the first posting we would not have wasted our time looking for the wrong things.]

Make sure to add the mtdparts=... stuff to your bootargs!

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected]
Even if you can deceive people about  a  product  through  misleading
statements, sooner or later the product will speak for itself.
- Hajime Karatsu

Yep, thank you all. Indeed I missed it.
I will be more careful next time.

Thank you again!

Assuming the board is 8272ads, you could try the MTD cvs from infradead.org, I used to add the map for this board - look into drivers/mtd/maps/pq2fads.c

Sincerely,
Vitaly

...

You are 100% correct. When using command line partitioning, the .name entry must not contain spaces (no matter which boot loader you use - this is a problem with the Linux kernel's argument parsing).

Best regards,

Wolfgang Denk

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected]
Quote from a recent meeting:   "We are going to continue having these
meetings everyday until I find out why no work is getting done."

Sorry for 3d email. The failed line I sent was incorrect - the problem is that debugger jumps from line to line on every step. I have added -fno-schedule-insns -fno-schedule-insns2 into kernel Makefile:

CFLAGS          := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                   -fno-strict-aliasing -fno-common \
                   -ffreestanding \
                   -fno-schedule-insns -fno-schedule-insns2

But it still jumping. What options shall I add in order to prevent debugger jumping while debugging kernel? Sorry, for slight off-topic.
Thank you