In ancient Egypt, a properly placed curse was considered sufficient to protect the mortal remains of pharaohs from unwanted tampering. Today, we shall study the modern equivalent of such curses on the example of NOR Flash.
Introduction ------------ NOR Flash can be used in applications where its content changes never or almost never (e.g., for boot ROMs), where it changes infrequently (e.g., to store an operating system kernel), or where changes are somewhat frequent (e.g., for a file system). In M1, all three usage patterns exist. NOR chips implement mechanisms to prevent accidental changes. These mechanisms have different characteristics that make them more or less suitable for a given usage scenario. Before we go into details, let's first look at how a CPU (or FPGA) communicates with the NOR. The bus interface of parallel NOR is similar to that of static RAM (SRAM). In both cases, memory locations are read by sending the respective address on the address lines and setting a read enable signal, after which the memory chip outputs the desired value on the data lines. (There are a few more control signals, but let's keep things simple for now.) SRAM and NOR differ in the way their content is changed. While writing to SRAM is similar to reading from it, NOR implements a command interface instead. Commands are sequences of addresses and data words that instruct the NOR to perform a number of operations, including locking and unlocking blocks, and writing to memory cells. For example, to write new data to a cell of the NOR used in M1, one would first write the command code 0xd0 to the desired address and, in a second write cycle and to the same address, the data word. After that, one could read back a status word and finally send another command (0xff) to return the NOR to normal read operation. Protection ---------- To prevent NOR content from unintended changes, a variety of protection mechanisms have been devised. They are controlled by hardware, software, or a mixture of both. The general concept is that a locking mechanism, when activated, prevents write and erase operations on either the entire device or on selected blocks. NOR memory is normally divided into blocks. When erasing NOR content, all memory cells in a block are erased in the same operation. Similarly, locking often has block granularity. In the case of the 256 Mbit (32 MB) NOR used in M1, each block has a size of 128 kBytes. Below is a description of mechanisms found in various families of parallel NOR Flash chips (currently) made by Micron [1]. Device write protect (hardware) - - - - - - - - - - - - - - - - Hardware-based NOR protection can be as simple as a write-protect pin that, when driven low, disallows all changes to the NOR. A variant of hardware-based write protection is protection of the boot loader. In this case, the write-protect pin only restricts writes to selected blocks but does not affect the rest of the NOR. Which blocks are considered boot loader blocks depends on the chip. Some chips protect blocks at the bottom, others blocks at the top, and still others protect blocks at the bottom and at the top. Block locking (software) - - - - - - - - - - - - Software-based NOR protection comes in two forms: volatile locking where locking returns to a hardwired state when the NOR chip resets or is power-cycled, and persistent locking where locking is retained across resets. In both cases, locking is applied on a per block basis, with one lock bit for each block. Volatile locks are basically RAM cells that can be set or cleared individually and as often as necessary. Setting and clearing is done through the command interface. Persistent locks are NOR cells that can be erased and programmed. Each block has a lock bit that can be individually set. All the lock bits are erased together, i.e., there is no way to selectively unlock a single block without also unlocking all the others with the same operation. Since persistent lock bits are NOR cells, they are subject to wear. Some chips also have a lock bit that prevents changes to the persistent locks. This bit is implemented as a "trapdoor": it is cleared on reset and software - through the command interface - can only set it. (Except, of course, if the hardware is designed such that software can command a selective reset of the NOR chip.) Block locking (mixed) - - - - - - - - - - - A variation of software-based block locking is the so-called "lock-down" mechanism. This is also a "trapdoor", allowing changes after a reset, and letting software only set the lock but not remove it. Lock-down is controlled through an input pin. If the pin is low, lock-down behaves as described above. If the pin is high, lock-down has no effect until the pin is driven low. Password protection - - - - - - - - - - Some NOR chip also implement password protection, for example to protect the volatile bit locking the persistent locks. Some chips also implement password protection mechanisms that are not publicly documented. Protection against accidental changes - - - - - - - - - - - - - - - - - - - A software or hardware error or an invalid operating condition at power up or power down may generate write accesses that happen to correspond to a command sequence that changes the NOR. Besides implementing mechanisms to ignore commands received while power is unstable, some chips also try to reduce the probability of an accidently generated sequence matching a valid command by extending the length of command sequences. This is done by introducing so-called "unlock" commands (not to be confused with unlocking a block) that must precede each write or erase command. No rule without exception: there is also an "unlock bypass" command that enters a state where this unlock command prefix is omitted. Unlock bypass can also be commanded by driving a hardware pin to a high "programming" voltage. Examples of protection mechanisms found in Micron chips ------------------------------------------------------- The following table shows the locking mechanisms found in several families of NOR chips available from Micron. The Common Flash Interface (CFI) [9] is a mechanism for retrieving meta-data from the Flash chip. Among other things, it contains a code identifying the set of command codes the chip implements. M1 uses the first chip in the table, the JS28F256J3F105A. Numonyx 256 Mbit parallel NOR Flash [1]: Family Example Data sheet CFI 13h Locking ------- --------------- ----------- ------- ------------------------------- J3 JS28F256J3F105A [2] 12/2008 0x0001 WP, PBL/GU, uPW M29EW JS28F256M29EWHA [3] 4/2011 0x0002 WPB, PBL/GU+SLL, SLu, PW, WU+UB P30 JS28F256P30BFA [4] 7/2011 0x0001 WP, SLp+SLD, uPW P33 JS28F256P33BFA [5] 8/2011 0x0001 same as P30 M29DW M29DW256G70NF6E [6] 4/2011 0x0002 same as M29EW (with SLp opt ?) M29 M29W256GH70N6E [7] 2/2011 0x0002 same as M29EW (with SLp opt ?) G18 PC28F256G18AE [8] 8/2011 0x0200 WP, SLp+SLD CFI ID codes (according to [10]): 0x0001 Intel/Sharp Extended Command Set 0x0002 AMD/Fujitsu Standard Command Set 0x0200 Intel Performance Code Command Locking mechanism: Hardware: WP = global Write Protect pin WPB = Write Protect pin for Boot block Persistent (survives reset/loss of power): PBL = Persistent Block Lock GU = Global Unlock (or persistent block locks) SLL = Soft Lock of persistent Locks (one-way, cleared by device reset) Volatile (returns to default state on reset): SLp = Soft Lock, locked after reset SLu = Soft Lock, unlocked after reset SLD = Soft Lock-Down (one-way, cleared by device reset) Password: uPW = PassWord (undocumented) PW = PassWord (documented) Extra-long write/erase command sequence: WU = Write Unlock (unlock command required before each write/erase) UB = Unlock Bypass (set unlock state for multiple write/erase) Rate of change -------------- Hardware-based protection mechanisms are usually intended for long-term stable configurations and then have a very simple external circuit, e.g., with the respective control pin tied to a power rail either directly or through a resistor, maybe combined with a jumper. Software-based persistent mechanisms are suitable for more frequent changes but care must be taken to avoid excessive wear not only of the NOR cells storing data but also of the NOR cells containing the lock bits. Given that persistent lock bits cannot be erased individually, an update process that unlocks-modifies-locks N separate blocks would produce one erase cycle for each data block but N erase cycles for the lock bits. If changes are frequent and happen on a per-block basis, soft locks have the benefit of being fast and free from wear. Lock-down combined with a suitable boot loader can also offer protection against accidental changes that use code paths that include unlocking, and also against malicious code. [1] http://www.micron.com/partscatalog.html?categoryPath=products/parametric/nor_flash/parallel_nor_flash [2] http://www.micron.com/get-document/?documentId=6062&file=319942_J3_65_256M_MLC_DS.pdf [3] http://www.micron.com/get-document/?documentId=6070&file=Numonyx_Axcell_M29EW_3V_1Gb.pdf [4] http://www.micron.com/get-document/?documentId=6963&file=320002_P30-65nm_Discrete_DS.pdf [5] http://www.micron.com/get-document/?documentId=6964&file=320003_P33-65nm_Discrete_DS.pdf [6] http://www.micron.com/get-document/?documentId=6083&file=M29DW256G.pdf [7] http://www.micron.com/get-document/?documentId=6093&file=M29W256G.pdf [8] http://www.micron.com/get-document/?documentId=6702&file=128_256_512_1Gb_65nm_g18.pdf [9] http://www.jedec.org/sites/default/files/docs/JESD68-01.pdf [10] http://www.jedec.org/standards-documents/docs/jep-137b [9] and [10] require registration. The form will accept junk, including an invalid e-mail address - and then log you in. - Werner _______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkymist@Freenode
