Re: [Yaffs] yaffsVersion meaning

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