From: Wolfgang Denk <hidden> Date: 2005-10-10 23:46:36
In message [off-list ref] you wrote:
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()
Are you sure that your flash device name in Linux is just "0" ? Which
board is this?
And I tried different bootargs
bootargs=console=ttyCPM0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2
...
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.
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: wd@denx.de
Technology is dominated by those who manage what they do not under-
stand.
===> 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?
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?
Are you sure that your flash device name in Linux is just "0" ?
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)
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
From: Robin Gilks <hidden> Date: 2005-10-11 01:47:19
Dmytro Bablinyuk wrote:
quoted
Are you sure that your flash device name in Linux is just "0" ?
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 : robin.gilks@tait.co.nz
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.
=======================================================================
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()
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.
From: Robin Gilks <hidden> Date: 2005-10-11 03:24:37
Dmytro Bablinyuk wrote:
quoted
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()
Thank you Robin,
Yes, I have 'working' jffs2.img (original from board).
I checked for spaces - it looks ok. It has 'physically_mapped_flash'.
[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 : robin.gilks@tait.co.nz
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.
=======================================================================
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()
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
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
Dmytro Bablinyuk wrote:
quoted
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()
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
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded