Changes

|{{oldid|15868|2.0.1}}

Regardless of the file system used, e.MMC devices provide some functionalities conceived to monitor their health while operating. As these functionalities are defined by [https://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf JEDEC standards], all the vendors implement them. In practice, e.MMC's integrate some registers providing specific information about the health status. These registers can be accessed with the <code>mmc-utils</code>, which are documented [https://www.kernel.org/doc/html/latest/driver-api/mmc/mmc-tools.html here]. Interestingly, JEDEC standard also defines a set of registers (<code>VENDOR_PROPRIETARY_HEALTH_REPORT</code>) that vendors are free to use for providing further, fine-grained information about the device's health status. Engineers and system integrators are supposed to contact the e.MMC manufacturer to get the required tools for accessing such registers.  The sections related to eMMC-based use cases are the result of a joint effort between [https://www.westerndigital.com/ Western Digital] (which purchased [https://en.wikipedia.org/wiki/SanDisk SanDisk] in 2016), [https://www.lauterbach.it Lauterbach Italy], and DAVE Embedded Systems. Parts of such sections are retrieved from the White Paper ''TRACE32 log method for analysing accesses to an eMMC device'' by Lauterbach, which is freely available for download [https://www.lauterbach.com/publications/trace32_log_method_for_analysing_accesses_to_an_emmc_device.pdf here].

===Experimental measurement of '''actual''' written data===

As stated previously, eMMC's and SD cards are block devices. As such, they are operated in tandem with file systems that have been developed for hard disks and solid-state drives. [https://en.wikipedia.org/wiki/Ext4 <code>ext4</code>] is one of them and one of the most popular in the Linux world.  [[File:Lauterbach-eMMC-schema.png|thumb|240px]]

To verify the implementation of the TRACE32-based method, a specific test was run. In essence, the testbed was configured in order to run TRACE32 and <code>ftrace</code> tracing — more details in the following section — simultaneously for analyzing the same workload. The logs produced by the two methods were then compared to ensure they match. To this end,  These logs

[[File:MISC-TN-017-eMMC-chart1.png|center|thumb|600x600px800x800px|e.MMC accesses over time]]

[[File:MISC-TN-017-eMMC-chart3-latency.png|center|thumb|600x600px800x800px|Latency]]

Another extremely useful graphical depiction is the chunk size distribution. For instance, this information is often used to understand how efficient the user application is when it comes to optimize the write operations for maximizing the e.MMC lifetime. The pie on the left refers to the read operations, while the other one refers to the write operations. To interpret the result, one needs to take into account how the workload was implemented. [[File:MISC-TN-017-eMMC-chart2-chunk-size.png|center|thumb|600x600px800x800px|Chunk size distribution]]BasicallyTo interpret the result, one needs to take into account how the workload was implemented. In the example under discussion, it the workload basically makes use of two applications: <code>[https://man7.org/linux/man-pages/man1/dd.1.html dd]</code> and <code>stressapptest</code>. <code>dd</code> was specified to use 4-kByte data chunks (<code>bs=4k</code>). <code>stressapptest</code> uses 512-byte chunks instead because the <code>--write-block-size</code> parameter was not used (for more details please refer to the [https://github.com/stressapptest/stressapptest/blob/e6c56d20c0fd16b07130d6e628d0dd6dcf1fe162/src/worker.cc#L2615 source code]). As a result, one would expect that the majority of accesses are 512 bytes and 4 kByte. The charts clearly show that this is not the case. Most of the accesses are 512kBinstead. This is a blatant example of how the algorithms of the file systems and the kernel block driver optimize can alter the accessesissued at application level for optimization purposes.

Regardless of the file system usedAs explained in [[#Embedded Linux systems with eMMC or SD cards|this section]], e.MMC devices 's provide some specific functionalities conceived to monitor their for device's health status while operatingmonitoring. As In practice, these functionalities are defined by [https:components expose some registers that make health-related information available to the host.  Following is a dump of the such registers regarding the wear-out status of the device, namely <code>DEVICE_LIFE_TIME_EST_TYP_B</code>, <code>DEVICE_LIFE_TIME_EST_TYP_B</www.jedec.orgcode>, and <code>PRE_EOL_INFO</sitescode>: <pre class="board-terminal">root@desk-mx8mp:~# mmc extcsd read /defaultdev/filesmmcblk2 | grep LIFEeMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x01eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x01root@desk-mx8mp:~# mmc extcsd read /docsdev/JESD84-B51.pdf JEDEC standardsmmcblk2 | grep EOLeMMC Pre EOL information [EXT_CSD_PRE_EOL_INFO], all : 0x01</pre>This dump refers to the vendors implement themsame testbed described here.

In practice, e.MMC's integrates some Some manufacturers use additional proprietary registers — namely, <code>DEVICE_LIFE_TIME_EST_TYP_B</code>, <code>DEVICE_LIFE_TIME_EST_TYP_B</code>, and <code>PRE_EOL_INFO</code> — also for providing information about the health status amount of data that have been actually written onto the device. These registers can be accessed with If available, this number allows to calculate the WAF given that the <code>mmc-utils</code>, which are documented [https://www.kernel.org/doc/html/latest/driver-api/mmc/mmc-tools.html here]. Following is a dump amount of such registers data written by the applications of an e.MMC mounted on a [[MITO_8M_SOM|Mito8M SoM]]the test workload is known too.

InterestinglyLast but not least, JEDEC standard it is worth remembering that advanced proprietary off-line tools may also defines a set of registers (<code>VENDOR_PROPRIETARY_HEALTH_REPORT</code>) that vendors are free to use be available for providing furtherhealth monitoring. For instance, fine-grained Western Digital provides such tools for its devices. For more information about the device's health status. Engineers and system integrators are supposed to , please contact the eour [mailto:sales@dave.MMC manufacturer to have more detailseu Sales Department].