Flash memory framework
jtm at smoothsmoothie.com
Wed Nov 2 22:23:40 UTC 2005
I'm working on porting JFFS2 to RTEMS, and it would be helpful to have
something like Linux's MTD (Memory Technology Device) system. It
provides a device independent interface to flash devices (actually any
memory device, including EEPROM and RAM).
In the RTEMS BSP Development guide, there's a reference to a
"non-volatile memory driver", but I can't find it anywhere in the
source code. The document does say that it is part of only one BSP.
I think it would be useful to have a generic interface to flash
devices in RTEMS. Something that would allow a developer to combine
multiple physical devices, partition them, take care of the erase and
programming algorithms, etc.
Before I really start on this, I'd like to get some feedback so that I
can make it useful to others and hopefully avoid problems I'd run into
I'm only interested in NOR flash, but I'd like something that could
be extended to support NAND flash (and other types of devices) without
changing the interface. I also want to support RAM, mainly for testing.
Since the main goal is to handle flash and other non-volatile memory,
I propose calling it the Non-Volatile Memory system - NVM.
First, some definitions:
An NVM device is the basic unit of operation. It is made up of one
or more physical memory devices.
An NVM device is divided into one or more partitions. The
partition boundaries fall along the physical device(s)'s erase
Each NVM partition can be accessed as a character device. That
means open(), close(), read(), write(), ioctl(), lseek() are
Currently lseek() is not supported for devices in RTEMS, so that
would have to be added somehow. It looks like the required
information is stored in the rtems_libio_t struct - it just needs
to be updated correctly.
It would probably be best to have write() only write, not
erase. Erase would be initiated by an IOCTL on the partition.
I don't know much about block devices in RTEMS, and they aren't
needed for JFFS2, so I'll just say: TBD
This is the API that the character and block drivers
use. Applications that need finer control than those two models
allow would also use this interface.
The data structures include:
nvm_device_info - describes an NVM device
nvm_partition_info - describes an NVM partition
Most functions are passed a pointer to the partition_info struct,
which is the basic unit of operation. Offsets are based on the
start of the partition. The functions are:
nvm_add_device - passed in partly filled in nvm_device_info
nvm_probe_device - tries to find out flash type, programming
information. This doesn't have to be called if the
correct parameters are filled in in nvm_device_info
nvm_create_partitions - used to divide NVM device into
nvm_create_char_devs - creates character device nodes for NVM
nvm_create_block_devs - creates block device nodes for NVM
nvm_write - writes data to flash, optionally verifies it
nvm_read - reads data from flash
nvm_erase - erases a partition
nvm_protect - sets protection bit(s) for partitions
nvm_unprotect - clears protection bit(s) for partitions
I think NAND flash can fit into this model, but I'm not positive. I'd
appreciate feedback from anyone who knows more than I do about it.
More information about the users