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

[David Gay]

On 7/26/06, Philip Levis <pal at cs.stanford.edu> wrote:
> 2. These storage abstractions are not the lowest common denominator
> when it
> comes to an interface for flash.
> The most direct, abstract interfaces to any flash chip are:
>    * read(addr, *buf, len);
>    * write(addr, *buf, len);
>    * erase(eraseUnitIndex);
>    * crc(addr, len);
>    * flush();

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