JFFS2 and INFTL compatibility

JFFS2 and INFTL compatibility

[Braden Simpson]

[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]

Hi all,

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 2.6.12.6 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
partition?

Regards,

Braden Simpson

Re: JFFS2 and INFTL compatibility

[Dan Brown]

Braden Simpson wrote:
> What do I need to do to stop the INFTL driver from corrupting the JFFS2
> partition?

Here's the deal.  Basically, the INFTL driver was written assuming it's 
the only driver using the device.  However, I believe you can work 
around this.

When the INFTL driver is loaded (or when your kernel boots, if it's 
compiled in), it searches through each MTD device.  It rejects anything 
that isn't a DiskOnChip.  For each DiskOnChip, it scans for the *first* 
BDTL partition, and mounts it as an INFTL volume.  It can't distinguish 
between a corrupted INFTL volume and something that isn't INFTL at all 
(such as JFFS2).

So, make sure your INFTL partition is FIRST, then your jffs2.  If this 
was already the case for you, I'll have to give this some more thought.

The relevant code is find_boot_record() in inftlmount.c.

You mentioned that you had to patch fill_autooob_layout().  If you think 
this is relevant to other users, please consider posting your changes 
and the reason for them on this list.

Good luck!

	-Dan

JFFS2 and INFTL compatibility

[Braden Simpson]

Hi all,

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

The kernel is based on 2.6.12.6 with the latest MTD updates and a patch I had
to make to the fill_autooob_layout function to get it to work.

Regards,

Braden Simpson