[Tinyos-devel] Re: [Tinyos-2.0wg] Meeting: July 26 (content within, please read)

[Chang Li]

>> The most direct, abstract interfaces to any flash chip are:
>>    * read(addr, *buf, len);
>>    * write(addr, *buf, len);
>>    * erase(eraseUnitIndex);
>>    * crc(addr, len);
>>    * flush();
>

The API for all flash memory like this is very important. But these are not 
enough.
One mistake I have made was to think and use flash memory like hard disk.
This might come from the flash vendors who tried to replace HD. Actually 
falsh
memory is much different from hard disk. For example, the write speed is 
much
much slow then HD. One of our program tried to write a database file to 
flash
that caused timing problem for multiple tasks. Remove a file may have 
similar
result. And before you write a cell you need to erase a block at first. A 
write
function for flash memory is not as simple as normal file for hard disk.

However there must exist a common subset API for all flash memory. It is 
good
to present it and a low-level API.

Chang

> I don't have time for an in-depth discussion now, but I will give the
> basic reasons we didn't provide an interface like the one above
>
> - the interface above needs to come with a fairly significant set of
> restrictions on writes to actually be portable, at least if you care
> about wear-levelling issues or NAND flash. Two obvious options:
>     (1) the length must be a multiple of the write unit (1 byte for
> most NOR flashes, 256+ bytes for most NAND flashes)
>     (2) we assume flashes with large write units have a write
> buffers, and require that between calls to flush, multiple writes must
> refer to non-overlapping addresses within a write unit (this can be
> generalised to a known number of buffers)
>
> - the interface above doesn't tell us much about failure modes (we can
> maybe assume that  writes to a write unit fail? what about any
> ordering guarantees in the presence of buffering?) - without this,
> there is no writing of any failure-tolerant storage solution
>
> - you need sync as well as flush
>
> - this doesn't expose useful properties of various flashes,e.g.:
>  - the extra 8 bytes/page of an at45db flash
>  - the ability to bypass the buffers in an at45db flash (for reads only, 
> IIRC)
>  - the ability to rewrite bytes in some NOR flashes, as long as you
> only push 1 bits to 0
>  - bad-block information in a NAND flash
>
> So, two obvious conclusions at least:
> - you need a HAL-like layer below the interface proposed above which
> exposes the interesting behaviours of each chip
> - it's probably possible to provide a "least common denominator"
> interface to flash similar to the one above; but this won't let you
> take full advantage of each chip's capabilities (as an example of
> this, consider the fairly different ways in which LogStorage is
> implemented for the stm25p and the at45db - the problem isn't so much
> normal behaviour but fault-tolerance)
>
> My suggestion would be (and I think this is similar to what Jonathan
> is proposing) to fully specify such a "portable" flash interface, and
> propose it as an additional HIL abstraction for volumes. But making
> that the only HIL, and forcing things like Block/Config/Log on top of
> that seems a mistake to me (especially as I don't think that this HIL
> interface is well enough defined yet).
>
> Note also that there may well be a middle point: common interfaces to
> each kind of flash (e.g., NorFlash and NandFlash interfaces).
>
> Btw, re the at45db BlockStorage comments:
> - The at45db implementation implements the behaviour specified by the HIL.
> - There is no hidden address range unavailable to the application (it
> would be pretty useless if there was).
> - The metadata/crc stored on the first page is in an unused portion of
> that page (the extra 8 bytes).
> - The fact that erasing a BlockStorage only physically erases the
> first page is not a problem, as BlockStorage.erase() does not mean
> "physically erase the volume", it means "logically erase the block".
> Erasing the metadata is sufficient to erase the block.
>
> David Gay
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>