Optimizing e.MMC Memory on Intel®

(Altera®) SoC FPGA Platforms

Justin Hunter, Application Engineer Micron Technology

Embedded Business Unit

1

2

Objective

• Managed NAND devices, like e.MMC, provide not only industry standard features and characteristics but also detailed proprietary features

• Though designed to be as drop-in ready as possible, many advantages are often under-utilized

• With a little investment in software design, improvements can be made to:

- optimize data throughput

- improve data reliability

- increase life span

• This presentation will cover a few best practice methods on how to enable these capabilities of the e.MMC memory on the Intel® (Altera®) SoC FPGA platforms

3

Agenda

• Arria® 10 SoC FPGA System and e.MMC Overview

• Wrestling with e.MMC in a System

• Rules of Thumb

• Improvement Techniques

• Summary

4

e.MMC in Arria® 10 SoC FPGA Hard Processor System (HPS) Block

Diagram

• e.MMC is used for:

- Unified storage for boot, OS, FPGA configuration and other data

- Lower cost/bit storage

- ease of development converting SD Card usage robust e.MMC

• e.MMC is useful in various industrial, automotive and consumer applications

Image Source: Arria 10 Hard Processor System Technical Reference Manual

5

Architecture and Interface of e.MMC

• Embedded Managed NAND system:

- Controller

Core Regulator

Internal error correction code (ECC) engine

NAND Block management

- NAND stack

• Interface with host (Logical Block Address) :

- CMD: bidirectional channel for device initialization and command transfers

- DAT [7:0]: bidirectional I/O data signals

1-bit: dat[0]

4-bit: dat[3:0]

8-bit: dat [7:0]

- CLK: timing signal

Up to 52MHz (SDR/DDR, HS200 (SDR/DDR)

Additional Data Strobe (DS) for HS400

Embedded MMC System Host

Interface

NAND

Stack

CMD

DAT [0-7]

CLK

DS (HS400)

RST_n

e.MMC Controller

Core Regulator (3.3V)

e.MMC Registers

OCR

CID CSD

RCA DSR

eCSD

NAND Interface

ECC Block

Management

Vccq (1.8, 3V)

Vcc (3V)

- e.MMC Power supply

Vcc: NAND core and I/O power supply

Vccq: Embedded controller core & e.MMC power supply

Vss, Vssq: Common ground

Vddi: Coupling for core regulator

6

Challenges of e.MMC Behavior

• What do we want from an e.MMC?

- Faster throughput (“Performance”)

- Better data reliability (“Data Retention”)

- Longer life (“Endurance”)

• How can we get more out of the e.MMC?

- Supplier improvements

Time consuming

Requalification complications

- Employ simple software techniques

Typically faster results

Especially helpful during early design process

Better allowance of forward-compatibility

7

Rules of Thumb for e.MMC

• Managed NAND is a system—it is NOT the same as discrete NAND

- Strive to keep it orderly!

• Sequential writes are best

- Faster throughput

- Less “defragmentation” maintenance

• File systems are frustrating

- File systems can complicate e.MMC functions and increase wear on the NAND

• Avoid unnecessary data removal

- Logical erase procedures amplify actual erase cycles

• Between data retention and endurance, err on the side of data retention

- Intact read-only data is better than no data

8

Software Block Diagram with e.MMC

User Application

System Call Interface

Generic Block Layer

I/O Scheduler

e.MMC Block Driver

Host e.MMC

• User Application

- Improvement limited to user applications

• File System

- Many file systems have configuration options

• Driver

- Often open source and good for enabling or improving e.MMC features

• Hardware

- Can be changed but high investment in time and money

VFS

File System Mapping Layer

buffer & page cache

NTFS EXT etc.

9

Utilize Register Settings

• Aligning system behavior to many register setting values results in increased performance, lower write amplification (longer life), and even some data retention improvement

• Some useful values:

- Optimal Write/Read Sizes – Performance

Good for data transfer “chunk” size and file system block size (typically 4KB – 32KB)

- NAND page access size (“ACC size”) – Performance, Endurance, Data Retention

Good for data file/packet size (typically 32KB – 512KB)

- High Capacity Write Protect/Erase – Performance, Endurance, Data Retention

Best size for file system partitions and boot code size (512KB – 16MB)

- Life estimate and EOL – Endurance, Performance

• Timing parameters may be equally valuable (especially u-boot)

Rules 1, 2, 3, & 4

10

eMMC

File System Data & Partition Alignment Illustration

• Simplified management assuming a convenient register size of 10 LBA

- Misaligned data and file system partitions result in extra performance overhead and wear on NAND

- Aligned data chunks and partition sizes reduce management requirements by the controller, increasing data throughput and reducing NAND program cycles

NAND Area 1 NAND Area 2 NAND Area 3 NAND Area 4 NAND Area 5

P03 LBA 16 - 26

P04 LBA 27 -49

P01 LBA 0 - 6

P02 LBA 7 - 15

write LBA 7 - 15 write LBA 17 - 25 write LBA 29 - 44

P01 LBA 0 - 9

P02 LBA 10 - 19

P03 LBA 20 - 29

P04 LBA 30 - 49

write LBA 10-19 write LBA 20-29 write LBA 30-49

11

Example: Optimal Data Transfer Size

• An EXT4 file system example:

- The mkfs "-b [size]" option forces the file system to use a certain block size

- The eCSD minimum value for “optimal write/read” is 4KB

Best practice would be to use e.MMC register settings to determine the best block size

“Multiblock allocation” option may have more alignment implications

• In addition to software partition alignment, file system should have proper alignment with a convenient block size during the formatting procedure

12

• Carefully consider data removal mechanisms

- File system (and OS) data removal functions may be convenient for system maintenance but can significantly—and often unnecessarily—increase NAND block erase counts affecting life span

- Operational nomenclature differences between host and e.MMC may result in decreased performance and endurance

For example: file system “trim” may actually result in e.MMC “secure trims”

• Enable a manual e.MMC background operations (BKOPS) regimen

- Maintains optimal performance

- Refreshes weak data

- Reduction in data removal needs

- Interruptible and resumeable Performance: Random 4KB; After BKOPS_STATUS = 1

No BKOPS Within 10K writes Within 1K writes

Host Manual Preventative Maintenance Rules 3, 4, & 5

13

Removing Data with Software Tools

Linux* “fstrim” runs a file system trim in all the card mapped area

- Some file systems do not distinguish between unmapped and unassigned resulting in excessive erases

- Actual execution depends on system settings, kernels, etc.

“Trim” may not always be “trim”

rah@:mmc-utils# mmc sanitize /dev/mmcblk0 rah@:mmc-utils# dmesg [ 907.259829] mmc0: mmc_can_sanitize - SANITIZE is supported = 1 [ 907.259833] mmc0: ioctl_do_sanitize - SANITIZE IN PROGRESS... [ 907.259835] mmc0: starting CMD6 arg 03a50101 flags 0000049d [ 907.259844] sdhci [sdhci_calc_timeout()]: mmc0: Too large timeout 0xf requested for CMD6! [ 907.259862] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001 [ 909.950959] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00108000 [ 909.950964] mmc0: Got data interrupt 0x00100000 even though no data operation was in progress.

rah@:mmc-utils$ sudo fstrim /dev/mmcblk0 rah@:mmc-utils$ dmesg [621296.738364] mmc0: starting CMD35 arg 00000800 flags 00000095 [621296.738384] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001 [621296.738392] mmc0: req done (CMD35): 0: 00000900 00000000 00000000 00000000 [621296.738399] mmc0: starting CMD36 arg 00000fff flags 00000095 [621296.738415] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001 [621296.738422] mmc0: req done (CMD36): 0: 00000900 00000000 00000000 00000000 [621296.738426] mmc0: starting CMD38 arg 00000001 flags 0000049d [621296.738440] sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001 …

• Besides built-in commands, add-on software tools are available like mmc-utils (left)

• Some vendors may have their own add-on proprietary tools for vendor specific functions

14

Example: Host Manual Background Operation

Operating System example (Linux* 3.16):

Software add-on example:

• Manual BKOPS can be implemented with simple code additions or using some add-on code packages

- Enable OS to start BKOPS when status is 1 or 2 instead of 3 (critical)

- When usage model is known, occasional and regular instances of manual execution can be determined with little impact on life span

- Some e.MMC may have additional user-friendly “automatic refresh” functions

# ./xxxxxxx -h Usage: ./xxxxxxx [debug][options]... [device file]... … -b --bkops Print BKOPS info -n --enable_bkops Enable BKOPS -s --start_bkops Start BKOPS …

Function Code pointer

Starting BKOPS mmc_start_bkops

Stopping BKOPS mmc_stop_bkops

High Priority Interrupt (HPI) mmc_interrupt_hpi

15

Health Monitoring

• Health status data provides information on remaining life expectancy

- Standard JEDEC* health monitoring useful and applicable to all e.MMC

Reported via several dedicated Extended CSD register values

- Vendor specific health reports can provide considerably more detail

May use additional dedicated Extended CSD or specialized write and read commands

- Incorporate specialized monitoring into design as early as possible

• Vendor specific reports may provide much more detail

- Depending on detail of vendor health reporting, data may be useful not only for lifespan estimations but also for optimizing user operations upstream

- Vendors often “upstream” application of these features to be incorporated into new kernel versions or add-on kernel patches

Add-on software packets may also be available from some vendors

Rules 4 & 5

16

Vendor Specific Health Monitoring

Software Tool

• Package or patch added to existing code

JEDEC* std CMDs

• Upstream enablement

Extended CSD

• Register methods largely in place

Health Report Method Advantages Required Information from Vendor

Extended CSD Register Values

Simple, uniform, relatively familiar output Some code adjustment to read new indexes High risk of device migration inconsistency Limited available reporting detail

Standard JEDEC Commands High “Upstream” inclusion Large potential for detailed reporting

Enablement confirmation from Vendor Detail of report can be cumbersome

Software add-ons Simple implementation (“turn-key”) Large potential for detailed reporting Easily updateable with new features

Software & enablement confirmation from Vendor

# ./xxxxxxx –[arg] Total spare block count: 310 Used spare blocks[%]: 0.00 Total initial bad block count: 0 Total later bad block count : 0 MLC area erase count Min/Max/Ave: 5 100 30 SLC area erase count Min/Max/Ave: 30 200 80

Register Name eCSD Slice

Vendor Health Report [301:270]

Vendor Specific Fields [127:64]

CMD Register Name

55 Indicates next command is application specific

56 General purpose single block data write/read from non-user area

17

Summary and Next Steps

• Always keep rules of thumb in mind

• Some simple, low-effort software adaptations can yield quick results

- Use register settings in software to streamline managed NAND behavior

- Implement manual Background Operations and execute periodically for preventative maintenance

- Value to health monitoring is immeasurable: especially vendor proprietary functions

• Software improvements “upstream” are always in the works

- Friendly suppliers may be able to help with code review or “upstream” actions

Proprietary vendor commands, software tools, etc.

- Don’t wait for systemic overhauls to save a few paddle strokes!

18

Additional Sources of Information

A PDF of this presentation is available is available from our Technical Session Catalog: www.intel.com/idfsessionsSF.

Demos in the ISDF Exhibit Hall – Micron Booth, Table #9

More web based info: e.MMC Software Documentation, e.MMC Technical Notes