XIP – eXecute In Place Jiyong Park

2 Contents Flash Memory How to Use Flash Memory Flash Translation Layers (Traditional) JFFS JFFS2 eXecute In Place Future

3 Flash Memory Non-volatile Memory mask ROM – non-programmable PROM– once programmable, non-erasable EPROM – erasable (ultraviolet) EEPROM – erasable (electrically) Flash Memory 1984, Toshiba, originated from Flash EEPROM In system programmablity

4 Flash Memory - Characteristics Array of blocks (few KB) 0  1 (erase): by block unit 1  0 (program): by bit unit Power: Low Read: Flash 10~50mA, DRAM 100~150mA Standby: Flash 10~50uA, DRAM 100~200mA Speed: Slow Read: Flash 70ns~25us, DRAM few ns Write: Very slow. (us ~ sec)

5 Flash Memory – NOR type Interface Similar to SRAM Lineary accessable No H/W is needed to be attached on memory interface Block size: Typically 128KB Limited lifetime: 100,000 erase cycle Manufactures: Intel, AMD, Sharp, Fujitsu Package: single chip

6 Flash Memory – NAND type Interface 8Bit I/O (shared address & data line) Not linearly accessable Special H/W needed to be attached on memory interface … than NOR type Cheaper, lower tolerance Smaller erase blocks (8KB) Bigger size (NOR: Mb, NAND: Gb) Slower read speed (NOR: ns, NAND: us) Manufacture: Samsung, Toshiba Package: card type

7 Flash Memory - Problems Cannot read while write(erase/program) Limited erase cycle Long erase/program time Slower than RAM Narrower bus witdh than RAM More expensive than RAM

How to Use Flash Memory

9 Flash Translation Layers Traditional answer Emulate a standard block device (IDE HDD) Use a normal file system on top of that Not Good FTL is itself a pseudo-file system Not efficient No wear levelling (FAT is updated frequently) Licensed

10 Flash Translation Layers Flash Memory Flash Translation Layer Block Device Driver IDE hard disk EXT2, FAT, …

11 JFFS Journalling Flash File System Log-structured Operates directly on flash memory Built-in wear levelling Axis Communications AB, 1999, Sweden Redhat, JFFS2 (with compression, hardlink, …) GPL’d, Ported to Linux 2.4 Flash Memory MTD Layer (Memory Technology Layer) JFFS(2)

12 eXecute In Place Flash Memory code data copied RAM CPU code data CPU XIP

13 Should We Use XIP ? Benefits RAM usage reduced Copying overhead eleminated Power saving Drawback Flash is more expensive (smaller RAM vs larger Flash) Cannot use compression Flash is slower Writing with compression is faster RAM is more flexible (e.g. discarding file buffers) Power not saved much Page-aligned: space waste While writing, all page mapping should be invalidated

14 How to Use XIP Read-only XIP On separate file-system Based on ROMFS MTD Layer (Memory Technology Layer) JFFS(2)XIP filesystem Flash Memory

15 Still Problems Read while write While writing, read operation returns status info (‘write done’ or ‘write in progress’) RWW-enabled flash Independent zones Software approach RAM based interrupt handler suspend flash operation + interrupt service + resume

16 IDLE read + address / data Erase write + erase + block read / status Program read / status write + program + address + data

17 Still Problems With MMU Program don’t need to be position independent code data Flash Memory RAM Page Table code data x NOR TypeNAND Type CPU page fault handler

18 Still Problems Without MMU Program should be relocatable In case of multi-section is used, section base should be written in code Writing is prohibited Solution: using software interrupt inter-section reference instruction followed by software interrupt instruction interrupt handler routine examines inter-section reference instruction, then jump to or return data Drawback: slow

19 Current and Future Linux Redhat, no plan to support r/w XIP XIP is considered as bad technology Windows CE Support XIP using MMU Intel’s Persistent Storage Manager (iPSM): software XIP Future XIP without MMU ?