On Wed, 2005-06-22 at 10:47 +1200, Charles Manning wrote:
> On Wednesday 22 June 2005 07:25, Peter Barada wrote:
> > I have a NOR implementation of YAFFS, and I've been pounding my head
> > with mkyaffsimage.c trying to get an image that can be built on a linux
> > box and used on a ColdFire mcf5475 based embedded Linux board using
> > kernel 2.4.26.
> >
> > To do this, I've set up the MTD access such that the spare abuts its
> > corresponding data chunk which all seems to work(this is that I make
> > sure that a data chunk and spare are in the same block). What I
> > stumbled across is that YAFFS refuses to use the first flash block(which
> > in my case is 64K in size) by setting dev->startBlock = 1 in
> > yaffs_internal_read_super. This causes it to behave bizarrely when I
> > first burned the image created by mkyaffsimage into the flash starting
> > at block zero.
> >
> > If I change dev->startBlock to zero, then yaffs_GutsInitialize() fails
> > due to checks for a non-zero startBlock. If I change those checks to
> > allow a zero startBlock, things look like they work fine, including the
> > image that mkyaffsimage created(after I modified write_chunk to place
> > the data and spares in the appropriate offsets).
> >
> > Am I setting myself up for a bunch of problems by changing the
> > startBlock to zero?
>
> Not using chunk zero is a historical accident, of sorts. On NAND, chunk zero
> is guaranteed good while others might not. On many systems, the first n
> chunks hold boot image etc. Sometimes chunk zero is used to store bad block
> tables etc.
>
> I needed a value for "invalid chunk" and "invalid block" and, because of the
> above, and because zero is easy to use, I chose zero. In hindsight, it might
> have been better to use -1/0xffffffffff.
>
> Most NAND folk don't hurt to much if a single block has to be lost (since
> NAND typically has many blocks), but it can be nasty for NOR folk with few
> blocks.
Yeah, that's my problem. It wastes a serious percentage of space...
> All is not lost though, there is a way to use that block zero, and it is
> pretty straight forward. You just need to tell YAFFS some lies!
>
> All yaffs flash calls go through a few access functions.
> All you need to do is to do a mapping in these functions so that yaffs block
> 1 = physical block 0.
>
> eg.
> int (*writeChunkToNAND)(struct yaffs_DeviceStruct *dev,int chunkInNAND, const
> __u8 *data, yaffs_Spare *spare)
> {
> chunkInNAND -= dev->nChunksPerBlock;
>
> ..... // rest of stuff
> }
>
> int (*eraseBlockInNAND)(struct yaffs_DeviceStruct *dev,int blockInNAND)
> {
> blockInNAND--;
> ...// rest of stuff
> }
>
> Now you must need to keep the illusion going by setting up the device start
> and end blocks accordingly. If you have, say, 32 physical blocks numbered
> from 0 to 31, then just set up startBlock=1 and endBlock =32;
>
> There is no chunk or block info imprinted in the actual YAFFS data, so no
> changes are needed to mkyaffsimage etc to make this work.
Ugh, that sounds like a *total* hack. Is there anything wrong with
allowing dev->startBlock to be zero instead of 1?
I *could* do the remap in the access functions, but it *assumes some
magical offset that requires a comment of:
/* This is a total hack since YAFFS refuses to use block zero */
Is there anything *actually* wrong with using block zero? If what you
say is true for NAND, then you don't even bother using the one
guaranteed good block in the device...
> -- Charles
>
>
>
>
--
Peter Barada <
Peter.B@LogicPD.com>
(text/plain)