Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Example: embedded Linux system equipped with SanDisk SDINBDG4-8G-XI1 eMMC and ext4 file system
== Example: embedded Linux system equipped with SanDisk SDINBDG4-8G-XI1 eMMC and <code>ext4</code> file system ==
[[File:Lauterbach-eMMC-schema.png|thumb|481x481px]]
=== 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.
* Exploiting the storage device's built-in advanced functionalities.
These approaches are illustrated in more detail in the rest of the section with the help of actual test results. ==== Testbed ====These tests were run on the [[MITO_8M_SOM/MITO_8M_Evaluation_Kit|Evaluation Kit]] of the [[MITO_8M_SOM|Mito8M SoM]] featuring a SanDisk SDINBDG4-8G-XI1 eMMC operated with an <code>ext4</code> file system.TBD
===Logging the accesses===
A classic software-based recording method (log) of these accesses requires the implementation of additional code that captures information and saves it securely. The information can be saved on another permanent storage device, for example, an external USB drive. This software method is intrusive and in addition to the overhead of monitoring the eMMC access, additional overhead is added in order to save the data.
Besides a traditional software-based approach, this example shows also a different method of capturing and saving such information through the use of a hardware-based trace tool. This can be done with minimal intrusion on the software and, in some cases, almost zero. This tool captures the program and data trace transmitted by the cores of a system-on-chip (SoC) through a dedicated trace port and records it to its own dedicated memory. To do that, advanced hardware functionalities of modern SoC's are exploited.
====Arm CoreSight™====
Many embedded microprocessors and microcontrollers are able to trace information related to the program execution flow. This allows the sequence of instructions executed by the program to be reconstructed and examined in great detail. In some configurations it is also possible to record the data related to the read and/or write cycles performed by the program.
[https://developer.arm.com/ip-products/system-ip/coresight-debug-and-trace CoreSight]™ is the name of the on-chip debug and trace technology provided by Arm®. CoreSight™ is not intended as a default logic block but, like a construction kit, it provides many different components. This allows the SoC designer to define the debug and trace resources that they want to provide. Program flow (and sometimes data flow) information is output through a resource called ETM (Embedded Trace Macrocell). The ETM trace information flow can be stored internally (on-chip trace) or can be exported outside of the SoC (off-chip trace). Arm® provides several ways for exporting a trace flow: through a parallel trace port (TPIU, Trace Port Interface Unit), or serial trace port (HSSTP, High-Speed Serial Trace Port) or through a PCIe interface.
When data trace is not available, Arm® provides the Context ID register. This is often used by an Operating System (OS) to indicate that a task switch has occurred. This is done by code in the OS kernel writing the task identifier to this register. In a multicore Arm®/Cortex® SoC, each core implements this register.
==== Lauterbach TRACE32 development tools ====
Lauterbach's TRACE32 development tools enable hardware-based debug and trace of a wide range of embedded microprocessors and microcontrollers and support debug technologies such as JTAG or SWD, as well as trace technologies such as NEXUS or ETM.
The TRACE32 tools support all Arm® CoreSight™ configurations. A TRACE32 development tool for debug and trace is typically comprised of these units:
* a universal PowerDebug module connected to the host computer via USB3 or Ethernet;
* a debugger (debug cable) for the specific architecture of the microprocessor or microcontroller under debug;
* for the off-chip trace, a universal PowerTrace II or PowerTrace III module providing 4GB or 8GB memory, complemented by a parallel or serial pre-processor to access the trace data;
* or a dedicated PowerTrace Serial module for serial or PCIe trace data.
==== TRACE32-based eMMC access log solution ====
In all operating systems or device drivers that manage an eMMC memory device, some functions are provided for device access which incorporate the eMMC JEDEC standard commands. Long-term monitoring of the execution of these commands and their parameters is the best way to collect the data necessary for the access analysis. After accessing the eMMC device, a function or a code point is usually available where the eMMC command is completed. Monitoring this code point allows the detection of additional information, such as the execution time of the command.
The TRACE32 trace tool can sample the code points where eMMC accesses start and finish. By adding a tiny amount of instrumentation to your source code, you can also trace device access data. In cases where data trace is not available, the instrumentation code writes the access data to the ContextID register, allowing both types of system to be adapted to use this technique.
The following data is traced in the TRACE32-based log solution:
* at the beginning of eMMC access: eMMC device id, command executed and related flags, access address, number of accessed memory blocks and their size;
* at the end of the eMMC access: eMMC device id, command executed, result code and other return codes;
* access duration.
A possible example of access monitoring is shown below, as it appears in the trace views available in TRACE32:
2| ptrace \\vmlinux\core_core\mmc_start_request 24.228827980s
2| info 24.228828005s 31636D6D
2| info 24.228828030s 00000019
2| info 24.228828055s 01620910
2| info 24.228828080s 000000B5
2| info 24.228828105s 00000200
2| info 24.228828130s 00000010
0| ptrace \\vmlinux\core_core\mmc_request_done 24.231239610s
0| info 24.231241385s 31636D6D
0| info 24.231241410s 00000019
0| info 24.231241435s 00000000
0| info 24.231308085s 00000900
0| info 24.231308210s 00000000
This is, typically, a few trace records for each eMMC access. Stress tests have verified that logging an eMMC access (functions mmc_start_request() and mmc_request_done() with related data) requires about 416 trace records in the PowerTrace memory and these accesses occur on average every 4 mSec.
==== Implementation example for Linux OS ====
