查看“TF-A - How to debug”的源代码

__TOC__
== Article Purpose ==
本文介绍了如何调试TF-A固件。<br>
调试专门链接到TrustZone环境。
调试TF-A的主要方法有两种，一种是使用代码内部的跟踪，另一种是使用JTAG来访问安全环境。
这里的重点是集成在OpenSTLinux中的解决方案：通过gdb调试（基于ST-Link或JTAG）。

== Debugging ==
=== TF-A Version number ===

调试的起点是确定目标中使用的TF-A版本。 调试和发行版本以以下格式显示在控制台上：<br>
<pre>
NOTICE: BL2: v2.0(debug):<tag>
</pre>
* v2.0是使用的TF-A版本。
* (debug) ：启用构建模式。
* <tag> : 在构建时由'''git describe'''命令生成的Git参考。

=== Debug with traces ===
TF-A allows RELEASE and DEBUG modes to be enabled:
* RELEASE mode builds with default LOG_LEVEL to 20, which only prints ERROR and NOTICE traces 
* DEBUG mode enables the -g build flag (for debug build object), and defaults LOG_LEVEL to 40 
With the debug LOG_LEVEL, you can add console traces such as ERROR, NOTICE, WARNING or INFO. Please refer to '''include/common/debug.h'''.
{{Warning| You cannot build code with LOG_LEVEL set to 50 (the highest level); there are too many traces and TF-A does not fit in the SYSRAM. If required, change some VERBOSE settings to INFO.}}

For both modes, you must ensure that the UART is properly configured:
* BL2: UART traces are enabled by default
* BL32: UART traces are enabled by default<br>

Traces and errors are available on the console defined in the chosen node of the device tree by the stdout-path property:
<pre>
chosen {
        stdout-path = "serial0:115200n8";
};
</pre>

=== Debug with GDB ===
TF-A runs in SYSRAM and is executed in CPU secure state. One can debug TF-A through JTAG using an ST-Link or the JTAG output, depending on the board.

==== Debug boot sequence ====
The BL2 boot stage is only executed during a boot sequence. To break into BL2, connect to the target and break.

Load symbols to the correct offset:
<pre>
(gdb) add-symbol-file <path_to_build_folder>/tf-a-bl2.elf (or bl2.elf) <load_address>
</pre>

BL2 and BL32 load addresses can be found in the generated '''tf-a-stm32mp157c-<board>.map''' file:
<pre>
...
 *fill*         0x000000002ffce000     0x5000 
                0x000000002ffd3000                __BL2_IMAGE_START__ = .  -> BL2 Load address
 *(.bl2_image*)
 .bl2_image     0x000000002ffd3000    0x1166c build/stm32mp1/stm32mp1.o
                0x000000002ffe466c                __BL2_IMAGE_END__ = .
                0x0000000000024b00                . = 0x24b00
 *fill*         0x000000002ffe466c     0x2994 
                0x000000002ffe7000                __BL32_IMAGE_START__ = . -> BL32 Load address
 *(.bl32_image*)
 .bl32_image    0x000000002ffe7000    0x1744c build/stm32mp1/stm32mp1.o
                0x000000002fffe44c                __BL32_IMAGE_END__ = .
                0x000000002fffe44c                __DATA_END__ = .
                0x000000002fffe44c                __TF_END__ = .
...
</pre>
In this example:
* BL2 load address is 0x2ffd3000.
* BL32 load address is 0x2ffe7000.

You can load all your symbols directly:
<pre>
(gdb) add-symbol-file <path_to_build_folder>/tf-a-bl2.elf 0x2ffd3000
(gdb) add-symbol-file <path_to_build_folder>/tf-a-bl32.elf 0x2ffe7000
</pre>

Set your hardware breakpoint and reset:
<pre>
(gdb) hb bl2_early_platform_setup
(gdb) monitor reset halt
</pre>

==== Debugging during runtime execution ====
Once [[U-Boot overview|U-Boot]] or the Linux kernel is running, you cannot access secure memory or regions, but you can break, set a hardware breakpoint into SMC handler (in BL32). [[GDB]] breaks once it has switched into the secure world and reached the break instruction. Once halted in the secure monitor, [[GDB]] can access secure resources as IPs or memory. For example, one can break into kernel:
<pre>
(gdb) hb stm32mp1_svc_smc_handler
(gdb) continue
</pre>

On the first SMC call occurence [[GDB]] breaks the stm32mp1_svc_smc_handler() entry in BL32.

<noinclude>
{{PublicationRequestId | 9776 | 2018-11-22 | PhilipeS}}
[[Category:Trusted Firmware-A (TF-A)]]
[[Category:Tracing tools]]
[[Category:Debugging tools]]
</noinclude>