Re: keep jffs2 from scanning uClinux ROMFs?

Erwin Authried <[email protected]>
Newsgroups gmane.linux.uclinux.devel
Message-ID <1355214431.2219.163.camel@amd>
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
> [email protected]
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by [email protected]
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev

-- 
Dipl.-Ing. Erwin Authried
Softwareentwicklung und Systemdesign

_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.