Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system
These tools perform a complete analysis of the eMMC device application accesses, in terms of addresses accessed, frequency and access methods.
The end goal is to calculate the Write Amplification Factor (WAFor WA) seen by the eMMC (or by any other managed-NAND block device). WAF is defined as the ratio of physical data written onto the NAND and the data written by the host.
When the host writes logical sectors of the eMMC, the internal eMMC controller erases and re-programs physical pages of the NAND device. This could cause a management overhead. Large sequential writes aligned to physical page boundaries typically result in minimal overhead and optimal NAND write activity (WAF=~1). Small chunks of random writes could result in a higher overhead (WAF>>1).
This becomes important when considering the life of the raw-NAND memory inside the eMMC, which has a finite number of Program/Erase cycles. See the example below:
To estimate the WAF for any particular eMMC device, and hence its expected lifetime on your application, you can capture the log file of the activity.
* For each eMMC operation, <code>ftrace</code> saves roughly 876 bytes of log information.
|}
==== Appendix 1: source code example ====
<syntaxhighlight lang="C">
</syntaxhighlight>
===Device's built-in advanced functionalities==Power failures=TBD =Power failures=
Even though modern file systems are usually tolerant w.r.t. power failures (*), in general, sudden power cuts should be avoided. The system should always be turned off cleanly. As this is not always possible, several techniques can be put in place to mitigate the effects of a power failure. For instance, see [[Carrier_board_design_guidelines_(SOM)#Sudden_power_off_management|this section of the carrier board design guidelines]].
* [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writebuffer UBIFS write-buffer].
== Example: embedded Linux system equipped with SanDisk SDINBDG4-8G-XI1 eMMC and ext4 file system ==TBD = Memory health monitoring ==
Although implementing a mechanism for monitoring the health of flash memories is not required strictly speaking, it is recommended. Think about it as a sort of life insurance to cope with unpredictable events that might occur during the life of the product. As a result of a on-the-field software upgrade, for example, new features could be added leading to an increase of data rate written onto the flash memories. Consequently, the lifetime expectancy calculated when the product was designed is not valid anymore. In such a case, a properly designed monitoring system would alert the personnel devoted to the maintenance who could take measures before it is too late (see for instance the case of eMMC's used in [https://electrek.co/2020/11/09/tesla-emmc-failure-touchscreen-offers-extended-warranty/ Tesla cars]). The following section details an example of such a system.
</syntaxhighlight>
== Example: embedded Linux system equipped with SanDisk SDINBDG4-8G-XI1 eMMC and ext4 file system ==TBD References = References =
* Western Digital Corporation, ''[https://link.westerndigital.com/content/dam/customer-portal/en_us/external/public/cps/p/White_Paper_Design_Considerations_v1.0.pdf Design Considerations for Embedded Products]'', 2018
* Western Digital Corporartion, ''[https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/white-paper/white-paper-automotive-workload-analysis.pdf Automotive Workload Analysis]'', September 2021
