Rick,

On Wednesday 08 August 2007 15:05, Rick Bronson wrote:
>   If yaffsVersion is never set to 2 (ie. always set to 1),
> does that mean that a partition that was written with ancient
> yaffs1 code on a 2.4 kernel will be able to be read/written
> using modern yaffs2 code and a 2.6.22 kernel with a 512/16
> part?

The yaffsVersion variable, displayed as isYaffs2 in /proc/yaffs, 
shows which yaffs methods are being used. So called Yaffs1 
methods are used when the underlying device is a small-page 
(512) NAND chip. Yaffs2 methods are used when the underlying 
device is large-page (2k).  Yaffs operates differently on these 
two types of NAND.

The "yaffs2" codebase at cvs.aleph1.co.uk:/home/aleph1/cvs 
supports both page sizes, both sets of methods.  When it runs 
with a small-page device, it runs much like the original "yaffs" 
codebase.

The format or layout of the tags and MTD's ECC is really a 
separate issue. There are various formats depending mainly on 
the MTD vintage and configuration choices.

With 2.4 MTD, and 2.6 pre 2.6.17, Yaffs may influence the layout 
using the nand_oobinfo struct in yaffs_mtdif.c.  But with newer 
kernels (post 2.6.17) MTD defines the layout using 
nand_ecclayout in nand_base.c, or the platform NAND mapping 
driver, and Yaffs just goes along with the MTD's 'autoplace' 
policy.

Compatibility: If you build the "yaffs2" codebase for a post 
2.6.17 kernel with CONFIG_YAFFS_9BYTE_TAGS set, and you are 
using a small-page NAND chip, the layout can be made compatible 
with an older scheme, but you have to have MTD's nand_ecclayout 
defined appropriately -- use the older implementation as a 
reference to derive the tags/ECC byte ordering that is/was used, 
then define a compatible nand_ecclayout 'autoplace' policy for 
use on the post 2.6.17 platform.

[We need a Yaffs FAQ, don't we]

-imcd