I Seem to Have Built a Bad Kernel

[debio]

Well, I tried building 2.6.30.4 of the mainline kernel today, using the kirkwood_defconfig, and now I'm getting this when I reboot:

Code:

List of all partitions:
1f00            1024 mtdblock0 (driver?)
1f01            4096 mtdblock1 (driver?)
1f02          519168 mtdblock2 (driver?)
No filesystem could mount root, tried:  ext3 ext2 cramfs vfat msdos
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1)
[<c002a810>] (unwind_backtrace+0x0/0xdc) from [<c0309a90>] (panic+0x48/0x12c)
[<c0309a90>] (panic+0x48/0x12c) from [<c0008f30>] (mount_block_root+0x1d4/0x21c)
[<c0008f30>] (mount_block_root+0x1d4/0x21c) from [<c000919c>] (prepare_namespace+0x120/0x180)
[<c000919c>] (prepare_namespace+0x120/0x180) from [<c00085ac>] (kernel_init+0xbc/0xec)
[<c00085ac>] (kernel_init+0xbc/0xec) from [<c0039694>] (do_exit+0x0/0x6e0)
[<c0039694>] (do_exit+0x0/0x6e0) from [<df82a300>] (0xdf82a300)
eth0: link up, 1000 Mb/s, full duplex, flow control disabled

I assumed that the defconfig would have jffs2 support, but apparantly this isn't the case. Do I have to get uBoot to boot from TFTP now if I want to get it running again? Where can I find a good kernel uImage to start from?

[cbxbiker61]

Try adding "rootfs=jffs2" to your bootargs.

[debio]

That didn't do the trick.
Reading the above log, it seems like the root partition in the flash is now /dev/mtdblock2, but it was originally /dev/mtdblock1, but changing that doesn't make a difference either. I can see JFFS2 loading from the kernel boot log, so I'm not sure what's causing the issues.
My bootargs in U-Boot is currently "console=ttyS0,115200 mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/mtdblock2 rw ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none rootfs=jffs2"
I haven't modified the flash partition sizes, so that part should still be correct.
The boot fails, ending in these lines:

Code:

Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "<NULL>" 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)
[<c002a810>] (unwind_backtrace+0x0/0xdc) from [<c0309a90>] (panic+0x48/0x12c)
[<c0309a90>] (panic+0x48/0x12c) from [<c0008f30>] (mount_block_root+0x1d4/0x21c)
[<c0008f30>] (mount_block_root+0x1d4/0x21c) from [<c000919c>] (prepare_namespace+0x120/0x180)
[<c000919c>] (prepare_namespace+0x120/0x180) from [<c00085ac>] (kernel_init+0xbc/0xec)
[<c00085ac>] (kernel_init+0xbc/0xec) from [<c0039694>] (do_exit+0x0/0x6e0)
[<c0039694>] (do_exit+0x0/0x6e0) from [<df82a300>] (0xdf82a300)

Here's where it scans the flash:

Code:

NAND device: Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 554 at 0x000004540000
Bad eraseblock 895 at 0x000006fe0000
Bad eraseblock 1038 at 0x0000081c0000
Bad eraseblock 1202 at 0x000009640000
Bad eraseblock 1739 at 0x00000d960000
Bad eraseblock 1856 at 0x00000e800000
Bad eraseblock 1908 at 0x00000ee80000
Bad eraseblock 3012 at 0x000017880000
Bad eraseblock 3225 at 0x000019320000
Bad eraseblock 3238 at 0x0000194c0000
Bad eraseblock 3243 at 0x000019560000
Bad eraseblock 3311 at 0x000019de0000
Bad eraseblock 3317 at 0x000019ea0000
Bad eraseblock 3529 at 0x00001b920000
Bad eraseblock 3576 at 0x00001bf00000
Creating 3 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000020000000 : "root"

Here's the line where the JFFS2 system initializes:

Code:

JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.

I guess the first thing I should ask is whether there's a patch that fixes this behavior because this image is the 2.6.30.4 kernel compiled from the kirkwood_defconfig with no patches and no modifications to the config.
The second thing I should ask is whether this is worth diagnosing because I can just get a premade image elsewhere. If I've configured something wrong though, it could be a good learning experience.

[cbxbiker61]

You might want to use the patches/config file for 2.6.30.4 available from the link under this topic.

http://plugcomputer.org/plugforum/index.php?topic=549

[debio]

I saw that, and the config that's labeled for 2.6.30.4 is actually from 2.6.30.3, but I guess there were no changes in options that affected it. I generated a patch from the kirkwood_defconfig to that config, and I'll be looking through it tomorrow to see what significant changes are in there.
I'll probably wind up just using the uImage from that link or the one from the recovery/install system, but it'll be interesting to see what's different.

EDIT:
Here's what the problem was:

Code:

####### change bootargs, replace nand_mtd with orion_nand and add rootfstype=jffs2
# setenv bootargs rootfstype=jffs2 console=ttyS0,115200 mtdparts=orion_nand:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/mtdblock1 rw ip=192.168.1.9:192.168.1.4:192.168.1.4:255.255.255.0:DB88FXX81:eth0:none
# saveenv

After doing that, my kernel boots.

[restamp]

@anyone: Out of curiosity:  What is the signficance of "nand_mtd" vs. "orion_nand"?  What do they mean, and how are they used by the kernel?

[debio]

I'm guessing the kernel module for our NAND changed, probably because in Marvell's original kernel tree, they patched the nand_mtd driver to work with a slightly different NAND setup. When it was merged into the full kernel, it was probably separated into a different driver.

That's just my guess though.