Changes

Jump to: navigation, search
Device's built-in advanced functionalities
== Embedded Linux systems with eMMC or SD cards ==
Another typical use case refers to eMMC's and SD cards. As explained [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_raw_vs_ftl here], these components are FTL devices, where FTL stands for ''Flash Translation Layer''. This layer ''emulates a block device on top of flash hardware''. Therefore, these storage devices are used in tandem with file systems such as [https://en.wikipedia.org/wiki/Ext4 ext4] and [https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32 FAT32]. Besides a raw NAND flash memory, eMMC's and SD cards integrate a microcontroller implementing the FTL and other important tasks as detailed in the rest of the document. All things considered, eMMC's and SD cards appear therefore to the host as managed-NAND block devices.
 
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 integrates 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), 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].
== Example: embedded Linux system equipped with SanDisk SDINBDG4-8G-XI1 eMMC and <code>ext4</code> file system ==
=== Introduction ===
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]]
cat /sys/kernel/debug/tracing/trace_pipe > /home/root/prove/ftrace.txt
</pre>
 
 
===== Verification =====
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,
=== Device's built-in advanced functionalities ===
As explained in [[#Example: embedded Embedded Linux system equipped systems with an e.MMCeMMC or SD cards|this section]], e.MMC manufacturers usually implement proprietary feature specific registers for monitoring the health of the device. Some of these registers provides a Following is a dump of the standard registers of the targte's e.MMC related to get detailed information about the wear-out status of the device, namely <code>DEVICE_LIFE_TIME_EST_TYP_B</code>, <code>DEVICE_LIFE_TIME_EST_TYP_B</code>, and <code>PRE_EOL_INFO</code>.
TBD
 
It is worth remembering that some providers use the additional proprietary registers to provide information about the amount of data that have been actually written on to the device. If available, this number allows to calculate the WAF as the amount of data written by the applications of the test workload is know as well.
=Power failures=
== Example: embedded Linux system equipped with an e.MMC ==
Regardless of the file system used, e.MMC devices provide some functionalities conceived to monitor their health status while operating. As these functionalities are defined by explained [[https://www.jedec.org/sites/default/files/docs/JESD84#Device's built-B51.pdf JEDEC standardsin advanced functionalities|here]], all the vendors implement them.  In practice, e.MMC's integrates some registers — namely, <code>DEVICE_LIFE_TIME_EST_TYP_B</code>, <code>DEVICE_LIFE_TIME_EST_TYP_B</code>, and <code>PRE_EOL_INFO</code> — providing information about the health status of the device. 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]. Following is exploited to implement a dump of such registers of an emonitoring mechanism.MMC mounted on a [[MITO_8M_SOM|Mito8M SoM]].  TBD InterestinglyFor example, JEDEC standard also defines a set user-space application may poll periodically the status 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 take actions accordingly if the e.MMC manufacturer to get the required tools for accessing such registerswear-out exceeds predefined thresholds.
= References =
4,650
edits

Navigation menu