optimizing e.mmc memory on intel (altera ) soc …...• this presentation will cover a few best...
TRANSCRIPT
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