On Wednesday 22 June 2005 15:09, Coywolf Qi Hunt wrote:
> On 6/22/05, Charles Manning <manningc2@actrix.gen.nz> wrote:
> <snip>
>
> > There is nothing technically wrong with using block zero from a
> > memory/NAND perspective.  At the end of the day, file system integrity is
> > governed by the performance of the worst block and not the best block.
> > Block zero is only guaranteed good at the time of shipping and can go bad
> > with time.  Also, many/most systems use block zero for some other purpose
> > (eg. boot data or bad block marker). Thus, relying on chunk zero being
> > good is pointless.
>
> Is it that the code in the block 0 can be executed in place for
> booting?  We may consider supporting partitions.


Some device (eg. Samsung) support loading from block zero.
>
> As to bad block marker issue, using a fixed block for that purpose is
> against wear leveling and not reliable.  Bad block information always
> can be gathered through oob area.

This is not always true.  Some devices have fixed bytes in the OOB area for 
marking the bad blocks. This is what YAFFS1 expects.

Some devices, particularly some of the newer 2k page devices, have different 
bad block marking strategies. In some of these, any non-FF blocks should be 
considered bad. For these you need to build some sort of bad block table and 
keep that somewhere.  Some people choose to use block zero for this purpose, 
because it is guaranteed good and therefore an easy place to store the table.


In general, it would be better for YAFFS to allow block zero to be usable by 
YAFFS.  At the time the YAFFS code was written, I made the decision not to 
use block zero and these points were merely what I considered as part of the 
rationale behind skipping block zero. To work around this is not very 
difficult outside of YAFFS. I will likely, at some time, integrate the 
workaround into YAFFS so that this all happens transparently inside YAFFS and 
thus make everybody happy.

-- CHarles