JFFS2 and INFTL compatibility
braden.simpson at gmail.com
Mon Feb 6 23:09:27 EST 2006
[Apologies for the partial post sent earlier but somehow I managed to press a
magic key combination for Gmail and it decided to send the message for me]
I am having mixed success in using both JFFS2 and INFTL on different partitions
of a Diskonchip 2000 TSOP and was wondering if I was missing something that
should have been obvious.
The intention is to have the main application residing on a seldom-modified EXT2
over INFTL partition and the logs and such on a power-failure resistant JFFS2
partition. The system currently boots the kernel from the Diskonchip using the
Docboot bootloader and loads the root filesystem into a RAMDisk.
Formatting and mounting the EXT2 partition works just fine but I cannot get the
JFFS2 partition to survive a reboot without being 'fixed' by the INFTL driver on
kernel startup. The kernel messages on startup are:
INFTL : corrupt block 8147 in chain 8147, chain length 0, erase mark 0xffff?
INFTL : formatting chain at block 8147
INFTL : formatting block 8147
If I use nanddump to view the OOB I can see that the OOB data for the fifth
512-byte page (after offset 0x05F0) in every 16KiB block is set to:
FF FF FF FF FF FF FF FF 00 00 00 00 69 3C 69 3C
All the rest of the pages and OOB data look to be blank.
This is in contrast to the contents of the OOB after using "flash_eraseall -j"
where the OOB data for the first 512-byte page (after offset 0x01F0) is set to:
FF FF FF FF FF FF FF FF 85 19 03 20 08 00 00 00
Again all the rest of the pages and OOB data look to be blank.
The kernel is based on 126.96.36.199 with the latest MTD updates and a small
change I had to make to the fill_autooob_layout function to get it to work.
This is an embedded PC/104 platform so all the MTD code used is compiled
into the kernel. The root filesystem was generated using Buildroot.
What do I need to do to stop the INFTL driver from corrupting the JFFS2
More information about the linux-mtd