Erwin, Thank you. I knew I was missing something simple. Your suggestion fixed the problem. Now on to the next issue...
Thanks, - Steve On Tue, Dec 11, 2012 at 12:27 AM, Erwin Authried <ea...@softsys.co.at> wrote: > you should specify rootfstype=romfs on the kernel commandline. > > -Erwin > > Am Monday, den 10.12.2012, 21:08 -0800 schrieb Steve deRosier: >> Everything is going fine (I can boot, the system is all good, I can >> even see MTD partitions I've setup), until I enable jffs2 support. >> Then on boot, it seems to want to scan my root file system and treat >> it like jffs2, and I get: >> >> uclinux[mtd]: RAM probe address=0x2ae368 size=0x178000 >> uclinux[mtd]: set ROMfs to be root filesystem >> Creating 1 MTD partitions on "RAM": >> 0x000000000000-0x000000178000 : "ROMfs" >> Flash external probe(0xffc00000,4194304,2): 400000 at ffc00000 >> External_Flash: Found 1 x16 devices at 0x0 in 16-bit bank. >> Manufacturer ID 0x000001 Chip ID 0x0022f9 >> Amd/Fujitsu Extended Query Table at 0x0040 >> Amd/Fujitsu Extended Query version 1.1. >> number of CFI chips: 1 >> Creating 4 MTD partitions on "External_Flash": >> 0x000000000000-0x000000004000 : "simpleboot" >> 0x000000004000-0x000000006000 : "ubootenv" >> 0x000000006000-0x000000040000 : "uboot" >> mtd: partition "uboot" doesn't start on an erase block boundary -- >> force read-only >> 0x000000040000-0x000000400000 : "image" >> Flash external probe(0xff400000,4194304,2): 400000 at ff400000 >> External_Flash2: Found 1 x16 devices at 0x0 in 16-bit bank. >> Manufacturer ID 0x000001 Chip ID 0x0022f9 >> Amd/Fujitsu Extended Query Table at 0x0040 >> Amd/Fujitsu Extended Query version 1.1. >> number of CFI chips: 1 >> Creating 1 MTD partitions on "External_Flash2": >> 0x000000000000-0x000000400000 : "rootfs" >> ... >> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: >> 0x2d72 instead >> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004: >> 0x3166 instead >> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008: >> 0x0017 instead >> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000000c: >> 0xad0c instead >> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: >> 0x524f instead >> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000014: >> 0x6973 instead >> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000002c: >> 0xd1ff instead >> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000030: >> 0x2e00 instead >> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000004c: >> 0xd1d1 instead >> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000050: >> 0x2e2e instead >> Further such events for this erase block will not be printed >> JFFS2: Erase block at 0x00000000 is not formatted. It will be erased >> .... >> >> I'm using "uClinux RAM/ROM filesystem is located at ebss >> (MTD_UCLINUX_EBSS)", with a ROMfs. It looks like jffs2's trying to >> scan my mtd0 device, even though that's a just fine mounted ROMfs >> that's loaded in RAM. AFAIK, I haven't done anything to tell the >> system to mount mtd0 as jffs2. >> >> Is there any way to tell jffs2 to not scan things I'm not specifically >> telling it are jffs2? I'm working on a legacy system with mixed >> filesystem types, with one of the flash partitions having a jffs2 and >> the other 3 partitions set up differently. And that's not to mention >> the "fake" MTD partition that the MTD_UCLINUX_EBSS configuration >> creates. >> >> Thanks in advance, >> - Steve >> _______________________________________________ >> uClinux-dev mailing list >> uClinux-dev@uclinux.org >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by uclinux-dev@uclinux.org >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev > > -- > Dipl.-Ing. Erwin Authried > Softwareentwicklung und Systemdesign > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
