The Arm Total Compute Platform utilizes U-Boot as the bootloader for the non-secure world. U-Boot is responsible for loading the Linux kernel, device tree, and root filesystem, providing the necessary foundation for the operating system to initialize, which allows the Total Compute Platform to seamlessly boot into Linux.

This guide describes:

• How to setting up the u-boot debug connection
• How to loading the u-boot debug symbol file
• How to starting the u-boot debug

This guide assumes that you already set up the debugging environment as described in the Guide to Set Up Debugging Environment for Total Compute Software Stack.

The guidance given in this guide is based on the Total Compute TC23.1 code.
Note: Future code updates might introduce changes, so the guidance might not apply to all cases.

Setting up u-boot debugging connection

The Guide to Set Up Debugging Environment for Total Compute Software Stack describes how to set up the Total Compute debugging environment in Arm DS.

There are some considerations to be aware of when setting up the u-boot debugging environment.

Select ARM_Cortex-A520x2 SMP Cluster 0 as your target as follows, when debugging the u-boot.

Loading the u-boot debugging symbol file

U-Boot is compiled as position-independent code and is loaded to a specified location by TF-A's BL2. This location is determined by the following code in both TF-A and U-Boot:

src/trusted-firmware-a/include/plat/arm/css/common/css_def.h:

#define PLAT_ARM_NS_IMAGE_BASE            U(0xE0000000) 

src/u-boot/configs/total_compute_defconfig:

CONFIG_TEXT_BASE=0xe0000000

During U-Boot's initialization phase, it relocates itself to a different address. You can refer to the following code:

src/u-boot/arch/arm/lib/relocate_64.S:

In the Debugger tab of the TF-A debug configuration, include corresponding commands in Execute Debugger Commands to add symbol tables, as shown in the following figure. Each time the debugging connection starts, these commands are automatically executed to load the symbol table files.



Since different firmwares run at different exception levels, you need to specify different addresses for each ELF file. For example:

add-symbol-file /workspace/arm/tc23.1/output/tc3/buildroot/fvp/tmp_build/tfa/build/tc/debug/bl1/bl1.elf EL3:0
add-symbol-file /workspace/arm/tc23.1/output/tc3/buildroot/fvp/tmp_build/tfa/build/tc/debug/bl2/bl2.elf EL1S:0
add-symbol-file /workspace/arm/tc23.1/output/tc3/buildroot/fvp/tmp_build/tfa/build/tc/debug/bl31/bl31.elf EL3:0

You can also add other commands here, such as setting breakpoints:

break bl1_main
break bl31_main
break EL3:0x04

The commands will automatically execute after the connect to the target like below: 

Starting the TF-A debugging

When connecting the TF-A debug connection, you will find the all cores are power down and the continue button is grey



To make the Application Processor core power on,  you need create a SCP debug connection according to Guide to Debug RSS Firmware Booting on Total Compute Platform, and then connect the SCP target as below: 



You can set any breakpoints at the TF-A connection and then click the continue button at the SCP connection. The application processor core 0 will be powered up by the SCP as below: 




The application processor will stop at the breakpoint and you can use the continue button to continue debug the TF-A: