On 09/08/2011 11:42 PM, Charles Manning wrote:
[...]
> YAFFS is designed for NAND flash. NAND typically erases in a few milliseconds.
> There is typically sufficient power rail capacitance to sustain the flash
> chip during the erasure.
Thus if I use YAFFS with a NAND flash, then I have to ensure that an erase
operation completes even in case of a power down or fatal software errors.
>
> Where YAFFS is used on NOR then an erasure marker strategy is suggested. There
> is an implementation of this in yaffs_norif1.c
Thanks for the hint. This is a good example. What is the reason for the
#define YNOR_PREMARKER (0xF6)
#define YNOR_POSTMARKER (0xF0)
values? Are they somewhat random or do they exploit some physical properties
of the NOR flash?
Lets have a look at the following check:
/* If the page status is YNOR_POSTMARKER then it was written
properly
* so change that to 0xFF so that the rest of yaffs is happy.
*/
if(spare->page_status == YNOR_POSTMARKER)
spare->page_status = 0xFF;
else if(spare->page_status != 0xff &&
(spare->page_status | YNOR_PREMARKER) != 0xff)
spare->page_status = YNOR_PREMARKER;
The first part is clear to me, but I don't understand the second part. It was
added later with the following commit message:
"Extra page status checking to combat power loss causing only one bit to change"
Since the one bit count is used to determine if a chunk was deleted, I suppose
that this was added to cope with 0xf7 or 0xfe instead of 0xf6.
What is the reason for the "(spare->page_status | YNOR_PREMARKER) != 0xff"? Is
this wrong:
if(spare->page_status == YNOR_POSTMARKER)
spare->page_status = 0xFF;
else if(spare->page_status != 0xff)
spare->page_status = YNOR_PREMARKER;
?
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.