[prev in list] [next in list] [prev in thread] [next in thread] 

List:       yaffs
Subject:    Re: [Yaffs] Yaffs Packed Tags and bad block markings
From:       Charles Manning <manningc2 () actrix ! gen ! nz>
Date:       2005-03-29 4:26:42
Message-ID: 20050329042732.E9D6615B79 () desire ! actrix ! co ! nz
[Download RAW message or body]

To give another perspective on this...
The main reason for the change to ExtendedTags in YAFFS2 was to make an 
abstraction between YAFFS data structures and their actual storage in the 
NAND spare area.

This move was driven by:
1) YAFFS1 supports primarily SmartMedia. The yaffs_guts knows about spare 
areas etc and expects a certain spare area layout (though of course this can 
be corrected with some hacking and byte shuffling etc to accomodate hardware 
ECC and different byte ordering).
2) YAFFS1 expects the SmartMedia bad block marking strategy. YAFFS2's 
extended tags pushes the bad block management out of YAFFS and into the mtd. 
This was done to support the various bad block handling strategies that 
various chips use. For example, some chinks use the SmartMedia strategy and 
others need bad block tables for initial bad blocks. These strategies are 
chip specific and do not really belong in YAFFS.

-- Charles


On Thursday 24 March 2005 11:29, Thomas Gleixner wrote:
> On Wed, 2005-03-23 at 23:46 +0100, Thomas Gleixner wrote:
> > On Wed, 2005-03-23 at 16:55 -0500, Lance Ware wrote:
> > > I am using yaffs2 and i am looking at the arrangement of the extended
> > > tags areas.  My question is i have a Samsung chip which uses bad block
> > > markers at the 0 byte of the 64-byte spare area.  But when i pass the
> > > extended tags parameter to my nand_write function, the bad block maker
> > > is overwritten with the tag information.
> >
> > What is your nand_write function ? Userspace application ?
> >
> > >  I was wondering was their a way to change the arrangement of the bad
> > > block marker.
> >
> > No
>
> Oops, I forgot about bad block tables, but there is no necessity to use
> them.
>
> The NAND driver can create bad block table(s) on the first detection of
> the chip. Then the bad block marker position is not longer reserved,
> because the driver scans for bad block tables instead of the oob bits,
> which mark the block bad. This requires to have intact bad block
> information on the first detection.
>
> tglx
>
>
>
> _______________________________________________
> yaffs mailing list
> yaffs@stoneboat.aleph1.co.uk
> http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs


[prev in list] [next in list] [prev in thread] [next in thread]