Bureaucrats, dave_user, Administrators
4,650
edits
Changes
→Example: embedded Linux system equipped with SanDisk SDINBDG4-8G-XI1 eMMC and ext4 file system
<pre class="workstation-terminal">
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
</pre>
The <code>infoBit</code> field can be written as follows:
<pre class="workstation-terminal">
Var.set T32_mmc.infoBit = 0x80000000
</pre>
This allows the user and the tools to distinguish between data written in the Context ID register by the instrumentation code from those written by Linux for task switches. In this case, the range of values must also be reserved so that they are not interpreted as task switch identifiers. The command to do this is shown below:
<pre class="workstation-terminal">
ETM.ReserveContextID 0x80000000--0xffffffff
</pre>
It’s important to note that the Linux kernel must be compiled for debugging (see the Training Linux Debugging manual at [https://www.lauterbach.com/manual.html]). The TRACE32 debugger also offers extensions for many different operating systems, known as an “OS awareness”. These add OS-specific features to the TRACE32 debugger such as the display of OS resources (tasks, queues, semaphores, ...) or support for MMU management in the OS. In TRACE32, the ability to trace tasks and execute code is based on task switch information in the trace flow. The command <code>ETM.ReserveContextID</code> allows simultaneous use of the Linux OS awareness support and the instrumentation for eMMC access analysis.
To reduce the amount of trace information generated by the target and to allow long-term trace via streaming, filters can be applied to isolate just the instrumentation code and its writes to the Context ID register. For example:
<pre class="workstation-terminal">
Break.REset
Break.Set mmc_request_done /Program /TraceON
Break.Set mmc_request_done\94 /Program /TraceOFF
Break.Set mmc_start_request /Program /TraceON
Break.Set mmc_start_request\38 /Program /TraceOFF
</pre>
where the filters marked as /TraceOFF are mapped to program addresses immediately after the instrumentation.
To ensure the task switch data generated by the OS is included in the filtered trace flow, add an additional filter to the __switch_to() function (<code>arch/arm64/kernel/process.c</code>) where it calls the static inline contextidr_thread_switch() function:
<pre class="workstation-terminal">
Break.Set __switch_to+0x74 /Program /TraceON
Break.Set __switch_to+0x80 /Program /TraceOFF
</pre>
The trace flow recorded by TRACE32 can be arranged into a view suitable for exporting by post-processing with the command:
<pre class="workstation-terminal">
Trace.FindAll , Address address.offset(mmc_start_request) OR Address address.offset(mmc_request_done) OR Cycle info OR Cycle task /List run cycle symbol %TimeFixed TIme.Zero data
</pre>
NOTE: ‘OR Cycle task’ is optional.
==== Comparison with the software-based method (<code>ftrace</code>) ====
In Linux, eMMC access log solutions based on purely software methods are already available. The <code>ftrace</code> framework provides this capability, as well as being able to log many other events. The term <code>ftrace</code> stands for “function tracer” and basically allows you to examine and record the execution flow of kernel functions. The dynamic tracing mode of <code>ftrace</code> is implemented through dynamic probes injected into the code, which allow the definition of the code to be traced at runtime. When tracing is enabled, all the collected data is stored by <code>ftrace</code> in a circular memory buffer. In the framework, there is a virtual filesystem called <code>tracefs</code> (usually mounted in <code>/sys/kernel/tracing</code>) which is used to configure <code>ftrace</code> and collect the trace data. All management is done with simple operations on the files in this directory.
Comparative tests performed on the DAVE Embedded Systems “MITO 8M Evaluation Kit” target showed that the <code>ftrace</code> impact compared to the TRACE32-based log solution is considerably higher in several respects. This is understandable, considering that <code>ftrace</code> is a general-purpose trace framework designed to trace many possible events, while the instrumentation required for the TRACE32 log method is specific and limited to the pertinent functions. Moreover, <code>ftrace</code> requires some buffering (ring buffer) and saving data to a target's persistent memory, while the solution based on TRACE32 uses off-chip trace to save the data externally in real-time. The following tables show a comparison between <code>ftrace</code> and the TRACE32 solution.
vmlinux code size
vmlinux data
vmlinux source files
instrumentation code size (*)
instrumentation data size (*)
Clean
12,79MB
10,78MB
4640
TRACE32
12,79MB (+0%)
10,78MB (+0%)
+0 (41 source code lines in mmc driver)
+372 byte
+64 byte
ftrace
14,78MB (+15,6%)
11,77MB (+9%)
+836 (+18%)
+1,99MB
+0,99MB + ??MB ring buffer (**)
==== Conclusion ====
