Michael: Updated the Flash driver page

2009-07-29T20:14:46Z

Updated the Flash driver page

Michael: Created a stub for new Flash driver page

2009-07-29T18:53:22Z

Created a stub for new Flash driver page

Michael: moved Flash driver to Talk:Flash driver/Original: Archived original flash driver page

2009-07-29T18:39:48Z

moved Flash driver to Talk:Flash driver/Original: Archived original flash driver page

New page

#REDIRECT [[Talk:Flash driver/Original]]

@@ Line 3: / Line 3: @@
 == High level API ==
-Like other drivers in Embedded Xinu, the Flash driver provides user level calls to <code>open()</code>, <code>close()</code>, <code>read()</code>, <code>write()</code>, <code>control()</code>, and <code>seek()</code>.
+Like other drivers in Embedded Xinu, the Flash driver provides user level calls to <code>open()</code>, <code>close()</code>, <code>read()</code>, <code>write()</code>, and <code>control()</code>.  In order to begin using a device the user must <code>open()</code> it, this initializes the logical layer and sets up structures for use.  The complimentary <code>close()</code> function will clear those structures and write any cached data to the underlying Flash hardware.
 === <code>read()</code> and <code>write()</code> ===
-Both <code>read()</code> and <code>write()</code> take three parameters (<code>device_id</code>, <code>buffer</code>, and <code>block_number</code>).  This is unlike other device calls where the final parameter is the size of the buffer.
+The Flash device takes three slightly different parameters for <code>read()</code> and <code>write()</code> when compared to other devices in Embedded Xinu.  Normal devices will take the device identifier, a buffer, and the size of the buffer.  Since the Flash device uses fixed size logical blocks, it is assumed that the buffer will be the size of a single logical block.  Therefore, the Flash driver API for <code>read()</code> and <code>write()</code> is:
 == Logical Layer ==
-Maps the high level 512 byte block size to the underlying erase block size and location for reading and writing.  Loads an entire erase block into RAM and marks it as dirty if modified.
+Normal block-oriented devices present a consistent view of data storage with each block being a small fixed size ranging from 512 bytes to 4,096 bytes.  Flash memory does not act like normal block-oriented devices though.  The underlying hardware is separated into erase block regions of which there can be four.  Each erase block region can hold a number of erase blocks of a fixed size.  These fixed sizes can be any size that is a power of two.  For example, on the [[WRT54GL]] platform, Flash is separated into two erase block regions, one with 8 - 8 KB erase blocks and the other with 63 - 64 KB erase blocks.
 == Physical Layer ==
-Handles interfacing with the underlying hardware by erasing the erase blocks when needed.
+Once the logical to erase block mapping has occurred, the logical layer can pass the erase block stored in RAM to the physical layer to perform the low level hardware operations.  At this layer, the software only deals in erase block units and uses manufacturer specific code.  Currently, Embedded Xinu fully supports the Intel Standard Command Set (SCS) and the AMD/Samsung SCS is a work in progress.
-=== Intel ===
+Largely, the routines to handle the hardware follow similar concepts.  When a non-read request is made to the physical layer the software steps through a series of operations to change an erase block from read-mode to program or erase mode.  When this happens, the software is able to safely modify the data.
-Provides an interface for working with the Intel Standard Command Set.
+An interesting property of Flash memory is that certain devices allow program and erase operations to be suspended, so it may be possible to spin the physical layer off as a separate pre-emptible process.  Unfortunately, while the Intel SCS supports suspend/resume operations the AMD/Samsung SCS does not, so this would lead to compatibility issues if implemented.
-=== AMD/Samsung ===
+== NVRAM ==
-Provides an interface for working with the AMD/Samsung Standard Command Set.
+[[Flash memory#NVRAM|NVRAM settings]] are stored in Flash memory and take advantage of both the logical and physical layers of the Flash driver.  When NVRAM is first initialized, the Flash driver determines what logical block the settings begin in and then begins reading and storing the settings into RAM.  Each tuple is indexed into a hash table and allocated a piece of memory to store the data in.  When a setting is changed, the original value is released from memory and the new value is added.  If a value is requested, the driver will simply find the storage location and return the pointer to the data.
-Since [[Flash memory#NVRAM|NVRAM]] settings are part of Flash memory, the code to modify them is closely related to the Flash driver.
+When the updated settings are committed to Flash, the NVRAM driver will discover the logical block to erase block mapping, create a complete erase block with the new settings, cause a write in the physical layer, and finally force a synchronization to commit the settings to Flash.

← Older revision		Revision as of 18:53, 29 July 2009
Line 1:		Line 1:
−	~~#REDIRECT~~ [[~~Talk:~~Flash driver/~~Original~~]]	+	[[Embedded Xinu]] uses a multi-layered approach to dealing with [[Flash memory]]. This allows the presentation of a simple and consistent interface to user programs, while handling the more complicated hardware interface underneath.
		+
		+	== High level API ==
		+
		+	Like other drivers in Embedded Xinu, the Flash driver provides user level calls to <code>open()</code>, <code>close()</code>, <code>read()</code>, <code>write()</code>, <code>control()</code>, and <code>seek()</code>.
		+
		+	=== <code>read()</code> and <code>write()</code> ===
		+
		+	Both <code>read()</code> and <code>write()</code> take three parameters (<code>device_id</code>, <code>buffer</code>, and <code>block_number</code>). This is unlike other device calls where the final parameter is the size of the buffer.
		+
		+	== Logical Layer ==
		+
		+	Maps the high level 512 byte block size to the underlying erase block size and location for reading and writing. Loads an entire erase block into RAM and marks it as dirty if modified.
		+
		+	== Physical Layer ==
		+
		+	Handles interfacing with the underlying hardware by erasing the erase blocks when needed.
		+
		+	=== Intel ===
		+
		+	Provides an interface for working with the Intel Standard Command Set.
		+
		+	=== AMD/Samsung ===
		+
		+	Provides an interface for working with the AMD/Samsung Standard Command Set.
		+
		+	== NVRAM ==
		+
		+	Since [[Flash memory#NVRAM\|NVRAM]] settings are part of Flash memory, the code to modify them is closely related to the Flash driver.

Flash driver - Revision history

Michael: Updated the Flash driver page

Michael: Created a stub for new Flash driver page

Michael: moved Flash driver to Talk:Flash driver/Original: Archived original flash driver page