Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.
To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.
The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.
Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.
These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)
The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.
This work was funded by the Champaign-Urbana Community Wireless Network
Project.
e8ac1cad77