The Linux kernel within the Arm Total Compute platform includes subsystem-specific features that showcase the platform's capabilities. However, because Linux operates at different exception levels and addresses, debugging it with Arm DS can be challenging.

This guide describes the following tasks:

• How to set up the Linux Kernel debug connection.
• How to disable the Linux Kernel Address Space Layout Randomization.
• How to load the Linux Kernel debug symbol file.
• How to start the Linux Kernel 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.

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

How to set up Linux Kernel 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 the Arm DS.

There are some considerations to be aware of when setting up the Linux Kernel debugging environment.

When debugging the Linux Kernel, select ARM_Cortex-A520x4 SMP Cluster 0 as your target as shown in the following figure:

How to disable the Linux Kernel Address Space Layout Randomization

Kernel Address-space layout randomization (KASLR) is a well-known technique to make exploits harder by placing various objects at random, rather than fixed, addresses. To make debugging the code more convenient, we hope to keep the address of the code fixed every time it runs, so that the symbol table can be easily loaded during debugging. To achieve this, there are two methods to disable KASLR.

1. To disable it during compilation, you can modify the boot arguments. This can be done by editing the file build-scripts/files/u-boot/tc2/fvp.cfg, as shown follows:

diff --git a/files/u-boot/tc2/fvp.cfg b/files/u-boot/tc2/fvp.cfg
index 91b9e54..8e86577 100644
--- a/files/u-boot/tc2/fvp.cfg
+++ b/files/u-boot/tc2/fvp.cfg
@@ -1,5 +1,5 @@
 CONFIG_TARGET_TOTAL_COMPUTE_FVP=y
-CONFIG_BOOTARGS="console=ttyAMA0 debug user_debug=31 earlycon=pl011,0x2A400000 loglevel=9 androidboot.hardware=total_compute androidboot.boot_devices=1c050000.mmci ip=dhcp androidboot.selinux=permissive allow_mismatched_32bit_el0 systemd.log_level=info"
+CONFIG_BOOTARGS="console=ttyAMA0 debug user_debug=31 earlycon=pl011,0x2A400000 loglevel=9 androidboot.hardware=total_compute androidboot.boot_devices=1c050000.mmci ip=dhcp androidboot.selinux=permissive allow_mismatched_32bit_el0 systemd.log_level=info kaslr.disabled=1"
 CONFIG_BOOTDELAY=1

2. At runtime, you can change the boot arguments in the U-Boot command line, as shown follows:

Hit any key to stop autoboot:  0
TOTAL_COMPUTE# setenv bootargs  ${bootargs} kaslr.disabled=1
TOTAL_COMPUTE#

How to load the Linux Kernel debug symbol file

From version 5.11 of Linux kernel,  If the kernel is booted at EL2, it always start with a nVHE init, drop to EL1 to initialise the the kernel.Then upgrade the kernel EL to EL2 if VHE capable, as shown follows:

Depending on the different debugging requirements, it may be necessary to focus on multiple stages of the code during the debugging process. To effectively debug these stages, it is essential to add the corresponding symbol tables for each stage.

1. Load the debug symbol for the booting process at EL2 with MMU disabled

First, you need to find the kernel load address. On the Arm Total Compute platform, the Linux kernel is loaded by U-Boot. You can find the address where the kernel is loaded by checking the U-Boot logs. Refer to the following log as an example:

2. Load the debug symbol for the booting process at EL1 with MMU disabled and MMU enabled with ID mapping 

3. Load the debug symbol for EL1 with MMU enabled

4. Load the debug symbol for EL2 with MMU enabled 

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

Different firmwares run at different exception levels, so you must 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, such as setting breakpoints:

break bl1_main
break bl31_main
break EL3:0x04

The commands will automatically execute after connecting to the target as follows: 

How to start the TF-A debugging

When connecting the TF-A debug connection, you find that all cores are powered down and the Continue button is grey as follows:



To power up the Application Processor core, you must create an SCP debug connection according to the Guide to Debug RSS Firmware Booting on Total Compute Platform, and connect the SCP target as follows: 



You can set any breakpoints at the TF-A connection and click the Continue button at the SCP connection. The Application Processor core 0 is powered up by the SCP as follows: 




The Application Processor stops at the breakpoint and you can use the Continue button to continue debug the TF-A as follows: