CRAMFS on MTD/NAND Issue

CRAMFS on MTD/NAND Issue

[Srinivasu.Vaduguri]

Hi all,

I am trying to mount CRAMFS using MTD driver on a NAND flash. 
If there is a BAD block in the CRAMFS area of the NAND flash then i get the following error during mount. 

Error -3 while decompressing!
802c3674(666163445)->83d7d000(4096)

Then the applications on the mounted cramfs are not running properly.

any suggestions are appreciated..

thanx in advance,

regards,
Srini

Re: CRAMFS on MTD/NAND Issue

[Russ Dill]

On Wed, 2003-01-08 at 05:40, Srinivasu.Vaduguri@nokia.com wrote:
> Hi all,
> 
> I am trying to mount CRAMFS using MTD driver on a NAND flash. 
> If there is a BAD block in the CRAMFS area of the NAND flash then i get the following error during mount. 
> 
> Error -3 while decompressing!
> 802c3674(666163445)->83d7d000(4096)
> 
> Then the applications on the mounted cramfs are not running properly.

NAND *will* have bad blocks, cramfs does not handle bad blocks. There
isn't an elegant solution for this right now, but here are some options:

cramfs on top of nftl: This works resonably well, but seems like
overkill to me, and it puts you in questionable legal status if you
aren't using an m-systems product afaik (this is what I use)

yaffs: desgined for NAND, but has no compression

jffs2: The NAND code is pretty new, and the journalling is probably
overkill for your application, but it will work, and should be able to
adapt to bad blocks.

roll your own: Please, make a static compressed filesystem (like cramfs)
that incorporates extra blocks, so that when the checksum is bad while
initially writing the filesystem, or reading the file system (in the
case where ecc can save the data), it rewrites this block to a free
sector). It would seem like a simple modification to cramfs to me.

Re: CRAMFS on MTD/NAND Issue

[Thomas Gleixner]

On Wednesday 08 January 2003 20:42, Russ Dill wrote:
> NAND *will* have bad blocks, cramfs does not handle bad blocks. There
> isn't an elegant solution for this right now, but here are some options:
> yaffs: desgined for NAND, but has no compression
Solid, but no compression

> jffs2: The NAND code is pretty new, and the journalling is probably
> overkill for your application, but it will work, and should be able to
> adapt to bad blocks.
The code is pretty new in comparison to Makefile V1.0, but it's used in 
production system and can be considered "stable". 
It's really a realiable rootfs.

> roll your own: Please, make a static compressed filesystem (like cramfs)
> that incorporates extra blocks, so that when the checksum is bad while
> initially writing the filesystem, or reading the file system (in the
> case where ecc can save the data), it rewrites this block to a free
> sector). It would seem like a simple modification to cramfs to me.
Don't reinvent the wheel! :)
-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: CRAMFS on MTD/NAND Issue

[Henrik Nordstrom]

On Wed, 8 Jan 2003, Thomas Gleixner wrote:

> > roll your own: Please, make a static compressed filesystem (like cramfs)
> > that incorporates extra blocks, so that when the checksum is bad while
> > initially writing the filesystem, or reading the file system (in the
> > case where ecc can save the data), it rewrites this block to a free
> > sector). It would seem like a simple modification to cramfs to me.
> Don't reinvent the wheel! :)

Having a image based filesystem which cannot be written to has it's 
beauty..

Regards
Henrik

Re: CRAMFS on MTD/NAND Issue

[Thomas Gleixner]

On Wednesday 08 January 2003 21:51, Henrik Nordstrom wrote:
> On Wed, 8 Jan 2003, Thomas Gleixner wrote:
> > > roll your own: Please, make a static compressed filesystem (like
> > > cramfs) that incorporates extra blocks, so that when the checksum is
> > > bad while initially writing the filesystem, or reading the file system
> > > (in the case where ecc can save the data), it rewrites this block to a
> > > free sector). It would seem like a simple modification to cramfs to me.
> >
> > Don't reinvent the wheel! :)
>
> Having a image based filesystem which cannot be written to has it's
> beauty..
Mount your rootfs _readonly_ and you have the _same_ including bad block 
handling.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: CRAMFS on MTD/NAND Issue

[Henrik Nordstrom]

On Wed, 8 Jan 2003, Thomas Gleixner wrote:

> Mount your rootfs _readonly_ and you have the _same_ including bad block 
> handling.

If a flag could be added to a jffs2 image denying it to be mounted 
read-write then yes..

With (c)ramfs I know the files in the image is not modified unless someone 
has done a direct block access on the underlying device.

Regards
Henrik

Re: CRAMFS on MTD/NAND Issue

[Russ Dill]

On Wed, 2003-01-08 at 18:08, Henrik Nordstrom wrote:
> On Wed, 8 Jan 2003, Thomas Gleixner wrote:
> 
> > Mount your rootfs _readonly_ and you have the _same_ including bad block 
> > handling.
> 
> If a flag could be added to a jffs2 image denying it to be mounted 
> read-write then yes..
> 

I might reiterate that the end goal of cramfs is efficency, and decent
speed. The end goal of jffs2 is quite different (although it still
strives for those things). iirc, cramfs images usually end up being 5%
to 10% smaller than jffs2 images, they boot a lot faster, the code is a
lot smaller (especially helpfull if you want fs support in your
bootloader)

-- 
Russ Dill <Russ.Dill@asu.edu>

Re: CRAMFS on MTD/NAND Issue

[Henrik Nordstrom]

On 8 Jan 2003, Russ Dill wrote:

> roll your own: Please, make a static compressed filesystem (like cramfs)
> that incorporates extra blocks, so that when the checksum is bad while
> initially writing the filesystem, or reading the file system (in the
> case where ecc can save the data), it rewrites this block to a free
> sector). It would seem like a simple modification to cramfs to me.

It would indeed be quite simple to adopt cramfs to bad blocks as long as
the superblock can be read. You only need to make a list of bad blocks,
and then teach mkcramfs about this, avoiding allocating the bad areas when
making the filesystem layout.

For generic bad-block management it would probably be more beneficial to
all to add a simple (and free from the (N)FTL patent issue) translation
layer capable of dealing with bad blocks and/or ECC I think.

Regards
Henrik

Re: CRAMFS on MTD/NAND Issue

[Russ Dill]

On Wed, 2003-01-08 at 13:33, Henrik Nordstrom wrote:
> On 8 Jan 2003, Russ Dill wrote:
> 
> > roll your own: Please, make a static compressed filesystem (like cramfs)
> > that incorporates extra blocks, so that when the checksum is bad while
> > initially writing the filesystem, or reading the file system (in the
> > case where ecc can save the data), it rewrites this block to a free
> > sector). It would seem like a simple modification to cramfs to me.
> 
> It would indeed be quite simple to adopt cramfs to bad blocks as long as
> the superblock can be read. You only need to make a list of bad blocks,
> and then teach mkcramfs about this, avoiding allocating the bad areas when
> making the filesystem layout.

afaik***, NAND blocks can go bad after time, so it may not be a one time
thing (especially if you have say, 10k units in the field). If you did
it right, it'd be ok if the sb went bad, just use the oob data to mark
blocks as bad, and to number them (your sb might be block 0x00 (or
0x01), and if it was bad, you'd just rewrite the block later on, with
the same block number. When you boot, just check for the last occurance
of each block. (btw, this isn't reinvented the wheel imho, jffs2 adds a
lot of code in the kernel, and often the bootloader of the board, as
well as not being as efficient space wise as cramfs). Course, most of
the space constraints are moot on NAND