Re: [Yaffs] Can yaffs2 move a file around in NAND because of…

On Wed, 2010-06-30 at 09:57 +0100, Brian Robertson wrote:

> We have started using yaffs2 with NAND flash and we are writing a linux
> main image into NAND and boot from this OK.
>
> We use a series of pointer length pairs which we extract from yaffs2 for
> this booting. We call this a scatterList and save this scatterList
> elsewhere in NOR flash (not controlled by yaffs2). This booting works
> fine and we can power cycle OK as many times as we like.

This adds a level of complexity and makes the invalid assumption that
once data is written into NAND it will never move.


> The issue comes after we boot when we try to write any file:
> cat /dev/urandom > <any_file>
> What seems to happen after this write of a file is that the scatterList
> of the original Linux mainImage has changed. The MD5sum of the original
> mainImage is still the same, it is just where it is stored that is
> changed.
> My questions are:
>
> Can yaffs2 move a file around (i.e. can this happen)?

Yes.

> What conditions will trigger a file to be moved elsewhere in NAND?

A few - there are probably more:

1) If CONFIG_YAFFS_DISABLE_BLOCK_REFRESHING is *NOT* defined, then YAFFS
will eventually copy every chunk referenced in NAND to another chunk in
different blocks to refresh the charge in each NAND cell.

2) If a soft-ECC error is detected while reading a chunk in the block
that hold the kernel image (think read disturb) then YAFFS will copy out
the data into a different block and erase the original block.

3) If the block was not full, and chunks were added that are
subsequently deleted then yaffs will eventually garbage collect the
block.


> Is there anything that we can do to stop a file being moved i.e. to lock
> the file down?

Not without code modifications that potentially cripple the benefits of YAFFS.

>
> We do not try to write to the original mainImage file so in theory this
> should stay undisturbed. Also there is plenty of room on the NAND flash
> so there should be no need to shuffle the file around e.g. because of a
> garbage collector / space reallocator.
>

Seriously, why complicate your system by forcing a correspondence
between your NOR "scatterlist" and the NAND layout? The direct YAFFS
interface is more than adequate to read the kernel image out of NAND,
and abstracts the location of the data which allows YAFFS to do a lot of
good things w/o your bootloader having to know about it. Otherwise
you'll have to dig into YAFFS to make the modifications to lock down
data in NAND and then maintain them yourself. This is most likely more
trouble than its worth.

One other possible solution is to make a partition that holds nothing
but the kernel image, then your "scatterlist" would have a higher chance
of working, but eventually on a read soft-ECC error it will break.