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.