On Thursday 15 September 2011 00:04:26 Sebastian Huber wrote:
> 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.

AFAIK in NAND flash there are no software errors to abort an erase. Because 
NOR flash takes ~1sec to erase, it has the ability to do erase suspend under 
software control. NAND does not.

>
> > 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?

They depend on flash properties to an extent.

Since flash can only change 1 bits to zero, the order of markers for the 
states unmarked>erase started>erase completed must follow the sequence in 
which bits can be changed from 1s to 0s.

0xFF -> 0xF6 -> 0xF0 works

Something like:
0xFF->0xF2->0xF1 would not

>
> 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.
Correct.

The operation of setting the premarker changes the value from 0xFF to 0xF6. ie 
this is changing bits 3 and 0 to zero.

If power fails when only 1 bit is changed (ie. value is 0xF7 or 0xFE) then we 
still want to treat it as if the pre-marker was set.

I doubt this can actually happen in the real world, but the NOR layer 
(yaffs_norif1.c) is tested against a test harness which simulates single bits 
changing and can simulate a power failure part way through a programming or 
erase operation).

>
> 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;
>

With the values used that would work too.

-- Charles