Flash memory framework

Jay Monkman 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
otherwise.

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
    boundaries.



Character interface:
    Each NVM partition can be accessed as a character device. That
    means open(), close(), read(), write(), ioctl(), lseek() are
    supported.

    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.


Block interface:
    I don't know much about block devices in RTEMS, and they aren't
    needed for JFFS2, so I'll just say: TBD

NVM API:
    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
 	        partitions

	nvm_create_char_devs - creates character device nodes for NVM
        	device.

	nvm_create_block_devs - creates block device nodes for NVM
        	device.

        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.

Comments?



More information about the users mailing list