An introduction to flash memory in Linux

Transcription

1 An introduction to flash memory in Linux Ezequiel Garcia Linux Developer Conference Brazil /34

2 Agenda Flash memory: NAND and NOR Linux MTD subsystem Linux UBI/UBIFS systems 2/34

3 The hardware side 3/34

4 Intro to flash memory Fujio Masuoka, invented NAND and NOR memory circa /34

5 Intro to flash memory 5/34

6 Intro to flash memory 6/34

7 Memory organization Minimum I/O size Erase size usually larger than I/O size 7/34

8 NAND and NOR interface 8/34

9 SPI NOR interface 9/34

10 NAND command example 10/34

11 Constraints of flash memory On NAND devices, there is no byte I/O Erase blocks go bad after X number of erases NAND devices also have factory shipped bad blocks Random bit-flips appear as a result of stress 11/34

12 Constraints of flash memory These constraints mean that... On NAND devices, you can t execute-in-place (without additional hardware) Wear leveling is needed to maximize flash life Bad block management is needed on the kernel Bad block management will be needed on the bootloader too! 12/34

13 The software side 13/34

14 What is our goal? We want simple UNIX file semantics: f d = open ( / foo / s o m e _ f i l e ) ; read ( fd, buf, s i z e ) ; w r i t e ( fd, buf, s i z e ) ; c l o s e ( f d ) ; 14/34

15 The stack 15/34

16 The stack 16/34

17 The MTD Linux subsystem 17/34

18 The MTD subsystem Handles NAND, NOR, SPI NOR and more. Devices can be partitioned, and labeled Each partitioned exposes a char device interface Offers a uniform API for different types of devices MTD offers a mechanism for upper layers to manage the bad block table 18/34

19 The MTD subsystem The userspace API consists in POSIX read/write semantics, plus some ioctls to erase memory, create partitions, get the device geometry, etc. s t r u c t e r a s e _ i n f o _ u s e r e r a s e ; f d = open ( / dev /mtd0 ) ; buf = m a l l o c ( s i z e ) ; read ( fd, buf, s i z e ) ; i o c t l ( fd, MEMERASE, &e r a s e ) ; w r i t e ( fd, buf, s i z e ) ; 19/34

20 The MTD subsystem Kernel API, simplified: l i n u x /mtd/mtd. h : i n t mtd_erase ( s t r u c t mtd_info mtd, s t r u c t e r a s e _ i n f o i n s t r ) ; i n t mtd_read ( s t r u c t mtd_info mtd, l o f f _ t from, s i z e _ t len, s i z e _ t r e t l e n, u_char buf ) ; i n t mtd_write ( s t r u c t mtd_info mtd, l o f f _ t to, s i z e _ t len, s i z e _ t r e t l e n, c o n s t u_char buf ) ; 20/34

21 The MTD subsystem Defining partitions can be done in several ways. For instance, via devicetree: p a r t i t i o n s { c o m p a t i b l e = f i x e d p a r t i t i o n s ; p a r t i t i o 0 { l a b e l = U Boot ; r e g = <0 0 x >; } ; p a r t i t i o { l a b e l = F i l e s y s t e m ; r e g = <0x xce0000 >; } ; } ; Also possible to define via kernel parameters and add/removed via ioctls too. 21/34

22 The MTD subsystem The MTD subsystem is very simple, its goal is to abstract the hardware differences and expose a uniform API to upper layers. It won t do anything smart, in particular: No bad block hiding No wear leveling 22/34

23 The UBI and UBIFS Linux subsystems 23/34

24 UBI Solves almost all the constraints problems! Let s take a look at its features: UBI exposes logical volumes UBI implements wear-leveling on MTD devices Volumes are composed of consecutive logical erase blocks Volumes may be created, removed, or re-sized UBI can also expose a read-only block interface UBI fastmap (experimental) can improve attach time UBI is power-cut tolerant Although the block interface may be used to mount a read-only filesystem. It s not enough for a read-write filesystem. 24/34

25 UBI API i n t u b i _ l e b _ e r a s e ( s t r u c t ubi_volume_desc, i n t lnum ) ; i n t ubi_leb_read ( s t r u c t ubi_volume_desc, i n t lnum, char buf, i n t o f f, i n t len, i n t check ) ; i n t u b i _ l e b _ w r i t e ( s t r u c t ubi_volume_desc, i n t lnum, c o n s t v o i d buf, i n t o f f s e t, i n t l e n ) ; i n t ubi_leb_change ( s t r u c t ubi_volume_desc, i n t lnum, c o n s t v o i d buf, i n t l e n ) ; 25/34

26 UBIFS Journal filesystem for UBI volumes, designed to meet special requirements such as power-cut tolerance. Its features are: scalability fast mount (when UBI fastmap is used) write-back support power-cut tolerance fast I/O on-the-flight compression recoverability integrity See for detailed information about UBIFS implementation and features. 26/34

27 Some examples to put all of these together 27/34

28 UBI and UBIFS examples Let s start by preparing a virtual MTD device, backed by a regular file. The commands will need root permission: $ f a l l o c a t e l 100M a_dummy_file $ l o s e t u p show f a_dummy_file $ modprobe block2mtd block2mtd=/dev / loop0 (Yes, it s a bit hacky, but it does the job pretty well). 28/34

29 UBI and UBIFS examples Taa-daa! $ mtdinfo / dev /mtd0 mtd0 Name : block2mtd : / dev / loop0 Type : ram E r a s e b l o c k s i z e : b y t e s Amount o f e r a s e b l o c k s : 200 Minimum i n p u t / output u n i t s i z e : 1 byte Sub page s i z e : 1 byte C h a r a c t e r d e v i c e major / minor : 9 0:0 Bad b l o c k s a r e a l l o w e d : f a l s e Device i s w r i t a b l e : true 29/34

30 UBI and UBIFS examples Now let s format the MTD as UBI and create a UBI volume. $ u b i f o r m a t / dev /mtd0 $ u b i a t t a c h mtdn 0 $ ubimkvol / dev / u b i 0 s 60MiB N v o l t e s t 30/34

31 UBIFS example Finally, we create an UBIFS image, write it and mount it. $ mkfs. u b i f s r ~/ t e s t r e e m 1 \ e c 200 \ o r o o t f s. u b i f s $ u b i u p d a t e v o l / dev / ubi0_0 r o o t f s. u b i f s $ mount t u b i f s u b i 0 : v o l t e s t /mnt/ 31/34

32 UBI read-only filesystem examples What if we just want a read-only filesystem on top of UBI? f a l l o c a t e l 50M r o o t f s. e x t 4 mkfs. e x t 4 r o o t f s. e x t 4 u b i u p d a t e v o l / dev / ubi0_0 r o o t f s. e x t 4 u b i b l o c k c r e a t e / dev / ubi0_0 mount / dev / ubiblock0_0 /mnt touch /mnt/ some_new_stuff 32/34

33 References Micron NAND Flash 101: An Introduction to NAND Linux MTD documentation An Introduction to SPI-NOR Subsystem the internet 33/34

34 Thanks for attending! Q & A ezequiel@collabora.com 34/34