Subject: Re: RFC: Flash memory device API
To: Jared D. McNeill <email@example.com>
From: David Laight <firstname.lastname@example.org>
Date: 09/05/2006 07:57:37
On Mon, Sep 04, 2006 at 10:40:25PM -0400, Allen Briggs wrote:
> There are devices out there with non-uniform erase block sizes.
> These are often called "boot flashes" and have the first or last
> erase block sub-divided up into smaller blocks. Do you plan to
> deal with those at all?
It would be very useful to be able to exclude some of the flash sectors
(typically the 'boot block' ones) from use by the normal 'block' device
and flash adaptation layer for file-systems.
As well as the low level boot code, I've used the initial sectors to
save system environment data. Using the format:
The end is indicated by len=0xff (ie the rest of the sector).
Items are deleted by overwriting the 'type' (and maybe data) with 0x00.
New items (or re-written values) are added at the end.
The sector erase is only needed infrequently.
> Another, perhaps interesting, thing to consider is devices that
> are set up in parallel. For example, two 16-bit devices on a
> single 32-bit bus where bits 0-15 select one device and bits 16-31
> select the other.
> For a flash filesystem, I think you'll want a way to read/write
> byte- or maybe word-size elements--taking advantage of the fact
> that on NOR flash at least, you can rewrite a word as long as
> you're just clearing bits. That can be useful.
I always did that for a 'sector' write - compare old and new data first.
Any flash filesystem needs to make use of that fact to avoid erase cycles.
David Laight: email@example.com