You are currently reviewing an older revision of this page.

Guide to Debug SCP Firmware Booting on Total Compute Platform

The System Control Processor (SCP) is a dedicated processor that is used to abstract power and system management tasks away from Application Processors (APs). The SCP Firmware provides a software reference implementation for the SCP on the Arm Total Compute Platform.

The primary services of the SCP firmware include:

  • Power control
    Using the Power Policy Unit (PPU), it manages power domain modes in accordance with the constraints of System Control and Management Interface (SCMI) commands that request changes in core, cluster, device, and SoC power states.
  • Performance management
    Responds to SCMI commands, and manages clock and voltage supplies.
  • Initialization and system boot
    The SCP is responsible for configuring the system to allow the Application processor to boot.
  • System events
    Respond to system events, such as GIC wake requests, local timer events, always-on domain wake requests, debug power requests, and watchdog expiration.

On the Total Compute platform, the SCP firmware consists of ROM firmware (SCP BL1) and RAM firmware (SCP BL2). The SCP BL1 firmware is responsible for configuring the entire system and subsequently powering up the main CPU core of the AP. The SCP BL2 firmware serves as the runtime firmware for the SCP, implementing the main features and functionalities of the SCP.

This guide describes:

  • How the SCP firmware is loaded and booted
  • How the SCP powers up the primary AP core and the secondary AP core

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 TC2-2023.10.04 code.
Note: Future code updates might introduce changes, so the guidance might not apply to all cases.

This guide includes the following sections:

  • Set up SCP Debug Environment
  • Introduction to SCP firmware
  • Build SCP firmware
  • Interaction between RSS and SCP
  • Interaction between AP and SCP
  • Power up the Secondary CPU of AP

Set up SCP Debug Environment

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 Total Compute debugging environment.

Step 1: Select Cortex-M3 as your target as follows, when debugging the SCP.

Step 2: Enable debug symbol table file, based on the firmware image you want to debug

By default, however, the SCP firmware is compiled without debug symbol tables. Therefore, the following modifications are necessary to enable the debug symbol tables:

build-scripts:

diff --git a/config/common.config b/config/common.config
index a99008c..032e3ea 100644
--- a/config/common.config
+++ b/config/common.config
@@ -23,9 +23,9 @@ CMAKE=${TOOLS_DIR}/cmake-3.22.4-linux-x86_64/bin/cmake
 SCP_OUTDIR=$OUTPUT_DIR/tmp_build/scp/
 SCP_SRC=$SRC_DIR/SCP-firmware
 SCP_LOG_LEVEL="INFO"
-SCP_BUILD_RELEASE=1
+SCP_BUILD_RELEASE=0
 SCP_COMPILER=$ARM_BARE_METAL/arm-none-eabi
-SCP_BUILD_MODE="release"
+SCP_BUILD_MODE="debug"
 SCP_PLATFORM_VARIANT_STD=0
 SCP_PLATFORM_VARIANT_EXPERIMENT=1
 SCP_PLATFORM_VARIANT_MPMM=2


src/SCP-firmware: 
diff --git a/framework/src/fwk_dlist.c b/framework/src/fwk_dlist.c
index 6fcfd08b..fa3b3ac7 100644
--- a/framework/src/fwk_dlist.c
+++ b/framework/src/fwk_dlist.c
@@ -73,10 +73,6 @@ void __fwk_dlist_remove(
     fwk_assert(node->prev != NULL);
     fwk_assert(node->next != NULL);

-    assert(__fwk_slist_contains(
-        (struct fwk_slist *)list,
-        (struct fwk_slist_node *)node));
-
     node->prev->next = node->next;
     node->next->prev = node->prev;

diff --git a/framework/src/fwk_slist.c b/framework/src/fwk_slist.c
index b4f41006..a9d09d57 100644
--- a/framework/src/fwk_slist.c
+++ b/framework/src/fwk_slist.c
@@ -108,8 +108,6 @@ struct fwk_slist_node *__fwk_slist_next(
     fwk_assert(list != NULL);
     fwk_assert(node != NULL);

-    fwk_assert(__fwk_slist_contains(list, node));
-
     return (node->next == (struct fwk_slist_node *)list) ? NULL : node->next;
 }

You must recompile the SCP firmware image.  The commands to recompile the image are different for Android and the Build Root file system:

Android Buildroot 
export PLATFORM=tc2
export TC_GPU=hwr-prebuilt
export TC_TARGET_FLAVOR=fvp
export FILESYSTEM=android-fvp
./build-scripts/build-scp.sh clean
./build-scripts/build-scp.sh build
./build-scripts/build-scp.sh deploy
build-scripts/build-tfa-trusty.sh build 
build-scripts/build-tfa-trusty.sh deploy 
#signed BL1 and SCP_BL1
build-scripts/build-rss.sh deploy 
#update the fip image
build-scripts/build-flash-image.sh deploy

export PLATFORM=tc2
export TC_TARGET_FLAVOR=fvp
export FILESYSTEM=buildroot
./build-scripts/build-scp.sh clean
./build-scripts/build-scp.sh build
./build-scripts/build-scp.sh deploy
build-scripts/build-tfa.sh build 
build-scripts/build-tfa.sh deploy
#signed BL1 and SCP_BL1
build-scripts/build-rss.sh deploy 
#update the fip image
build-scripts/build-flash-image.sh deploy

The symbol table files corresponding to different firmware are as follows:
SCP BL1 Firmware: 

output/buildroot/tmp_build/scp/scp/bin/tc2-bl1.elf

SCP BL2 Firmware: 
output/buildroot/tmp_build/scp/scp/bin/tc2-bl2.elf

Step 3: In the Debugger tab of the SCP 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.

Step 4: Click the Debug button to enter the following debugging interface, and you can start debugging.

Introduction to SCP Firmware

SCP firmware is divided  into three layers, the following figure shows an overview of the components of the SCP firmware:

  • Modules
    A module is a unit of code that performs a well-defined operation, or set of operations. Each module might contain elements, which can contain sub-elements. Modules are initialized and driven by the framework through the implementation of the framework module interface.
  • Frameworks
    The framework layer is primarily responsible for initializing memory and interrupts, and managing the modules. This layer also invokes APIs provided by the modules to finish respective tasks. These APIs are defined by the framework and implemented within the modules.
  • Architecture-dependent code
    This layer contains CPU architecture-specific code, including CPU booting code and interrupt processing. The module layer must leverage the frameworks layer to access its functionalities and cannot directly invoke this layer's functions.

The Cortex Microcontroller Software Interface Standard (CMSIS) provides a standardized interface for system initialization and low-level hardware access. It enables consistent and efficient software development across different Cortex-M processors. CMSIS RTX2 plays a real-time operating system (RTOS) for SCP firmware.

SCP Firmware includes the following firmwares: 

  • SCP BL1 Firmware
    The primary role of SCP BL1 Firmware is to configure the system and power on the primary core of the AP. As described in the Guide to Debug RSS Firmware Booting on Total Compute Platform, the BL1 firmware of SCP is loaded by RSS. After RSS completes loading, it releases the SCP CPU from the wait state.
  • SCP BL2 firmware
    The SCP BL2 firmware serves as the runtime firmware for SCP. It receives SCMI requests from the AP side and performs the corresponding service based on the SCMI request.

Build SCP Firmware

Modules are the building blocks of a product firmware. SCP firmware is composed of several modules, which can be either common modules or modules related to a specific platform.

Modules included in each firmware

To find out the specific modules that form the SCP firmware on Total Compute platform, see the following Makefile code:

SCP BL1 Firmware (product/tc2/scp_romfw/Firmware.cmake):

if(SCP_ENABLE_PLAT_FVP)
    list(APPEND SCP_MODULES "pl011")
    list(APPEND SCP_MODULES "ppu-v1")
    list(APPEND SCP_MODULES "tc2-bl1")
    list(APPEND SCP_MODULES "bootloader")
    list(APPEND SCP_MODULES "system-pll")
    list(APPEND SCP_MODULES "pik-clock")
    list(APPEND SCP_MODULES "css-clock")
    list(APPEND SCP_MODULES "clock")
    list(APPEND SCP_MODULES "gtimer")
    list(APPEND SCP_MODULES "timer")
    list(APPEND SCP_MODULES "cmn-booker")
    list(APPEND SCP_MODULES "sds")
    list(APPEND SCP_MODULES "mhu2")
    list(APPEND SCP_MODULES "transport")
else()
    list(APPEND SCP_MODULES "ppu-v1")
    list(APPEND SCP_MODULES "pl011")
    list(APPEND SCP_MODULES "msys-rom")
    list(APPEND SCP_MODULES "snps-umctl")
    list(APPEND SCP_MODULES "cmn-booker")
    list(APPEND SCP_MODULES "sds")
    list(APPEND SCP_MODULES "bootloader")
    list(APPEND SCP_MODULES "system-pll")
    list(APPEND SCP_MODULES "pik-clock")
    list(APPEND SCP_MODULES "css-clock")
    list(APPEND SCP_MODULES "clock")
    list(APPEND SCP_MODULES "gtimer")
    list(APPEND SCP_MODULES "timer")
endif()


SCP BL2 Firmware (product/tc2/scp_ramfw/Firmware.cmake):
list(APPEND SCP_MODULES "armv7m-mpu")
list(APPEND SCP_MODULES "pl011")
list(APPEND SCP_MODULES "gtimer")
list(APPEND SCP_MODULES "timer")
list(APPEND SCP_MODULES "ppu-v1")
list(APPEND SCP_MODULES "system-power")
list(APPEND SCP_MODULES "mhu2")
list(APPEND SCP_MODULES "transport")
list(APPEND SCP_MODULES "scmi")
list(APPEND SCP_MODULES "sds")
list(APPEND SCP_MODULES "system-pll")
list(APPEND SCP_MODULES "pik-clock")
list(APPEND SCP_MODULES "css-clock")
list(APPEND SCP_MODULES "clock")
list(APPEND SCP_MODULES "power-domain")
list(APPEND SCP_MODULES "scmi-power-domain")
list(APPEND SCP_MODULES "scmi-system-power")
list(APPEND SCP_MODULES "dvfs")
list(APPEND SCP_MODULES "scmi-clock")
list(APPEND SCP_MODULES "scmi-perf")
list(APPEND SCP_MODULES "mock-psu")
list(APPEND SCP_MODULES "psu")
list(APPEND SCP_MODULES "tc2-system")

if(SCP_ENABLE_RESOURCE_PERMISSIONS)
    list(APPEND SCP_MODULES,"resource-perms")
endif()

Location of configuration files

In the SCP, each module does not contain platform-specific information. When compiling modules into firmware, you must provide configuration for each module based on the platform. In the SCP Firmware of the Total Compute platform, you can find the configuration files in the following directories:

SCP BL1 Firmware:

product/tc2/scp_romfw/config_bootloader.c
product/tc2/scp_romfw/config_clock.c
product/tc2/scp_romfw/config_cmn_booker.c
product/tc2/scp_romfw/config_css_clock.c
product/tc2/scp_romfw/config_gtimer.c
product/tc2/scp_romfw/config_mhu2.c
product/tc2/scp_romfw/config_msys_rom.c
product/tc2/scp_romfw/config_pik_clock.c
product/tc2/scp_romfw/config_pl011.c
product/tc2/scp_romfw/config_ppu_v1.c
product/tc2/scp_romfw/config_sds.c
product/tc2/scp_romfw/config_system_pll.c
product/tc2/scp_romfw/config_tc2_bl1.c
product/tc2/scp_romfw/config_timer.c
product/tc2/scp_romfw/config_transport.c
product/tc2/scp_romfw/fmw_memory.h


SCP BL2 Firmware:
product/tc2/scp_ramfw/config_armv7m_mpu.c
product/tc2/scp_ramfw/config_clock.c
product/tc2/scp_ramfw/config_css_clock.c
product/tc2/scp_ramfw/config_dvfs.c
product/tc2/scp_ramfw/config_gtimer.c
product/tc2/scp_ramfw/config_mhu2.c
product/tc2/scp_ramfw/config_mock_psu.c
product/tc2/scp_ramfw/config_mpmm.c
product/tc2/scp_ramfw/config_pik_clock.c
product/tc2/scp_ramfw/config_pl011.c
product/tc2/scp_ramfw/config_power_domain.c
product/tc2/scp_ramfw/config_ppu_v1.c
product/tc2/scp_ramfw/config_psu.c
product/tc2/scp_ramfw/config_reg_sensor.c
product/tc2/scp_ramfw/config_resource_perms.c
product/tc2/scp_ramfw/config_scmi.c
product/tc2/scp_ramfw/config_scmi_clock.c
product/tc2/scp_ramfw/config_scmi_perf.c
product/tc2/scp_ramfw/config_scmi_power_domain.c
product/tc2/scp_ramfw/config_scmi_system_power.c
product/tc2/scp_ramfw/config_sds.c
product/tc2/scp_ramfw/config_sensor.c
product/tc2/scp_ramfw/config_system_pll.c
product/tc2/scp_ramfw/config_system_power.c
product/tc2/scp_ramfw/config_tc2_power_model.c
product/tc2/scp_ramfw/config_thermal_mgmt.c
product/tc2/scp_ramfw/config_timer.c
product/tc2/scp_ramfw/config_traffic_cop.c
product/tc2/scp_ramfw/config_transport.c
product/tc2/scp_ramfw/fmw_memory.h
product/tc2/scp_ramfw/fmw_notification.h

Load and authenticate firmware

Perform the following steps to load and authenticate firmware:

  1. Compile the SCP firmware into a RAW binary file by using the previous code. The final load address of this binary file is determined by the following code:

    SCP BL1 Firmware:

    product/tc2/scp_romfw/fmw_memory.h:
/*
 * ROM memory
 */
#define FMW_MEM0_SIZE SCP_BOOT_ROM_SIZE
#define FMW_MEM0_BASE SCP_BOOT_ROM_BASE


    arch/arm/arm-m/src/arch.ld.S:
mem0 (rwx) : ORIGIN = FMW_MEM0_BASE, LENGTH = FMW_MEM0_SIZE

    SCP BL2 Firmware:

    product/tc2/scp_ramfw/fmw_memory.h:
	/* RAM */
#define FMW_MEM0_BASE SCP_RAM_BASE
#define FMW_MEM0_SIZE SCP_RAM_SIZE


    arch/arm/arm-m/src/arch.ld.S:
mem0 (rwx) : ORIGIN = FMW_MEM0_BASE, LENGTH = FMW_MEM0_SIZE

  2. Add a signature to the RAW binary to enable RSS authentication. As a part of the Root of Trusted, SCP BL1 firmware is loaded and verified by RSS. See the following code for reference:

    build-scripts/build-rss.sh:

        sign_image $RSS_SIGN_AP_BL1_NAME \
        $RSS_SIGN_AP_BL1_LOAD_ADDRESS $RSS_SIGN_AP_BL1_BIN_SIZE
    sign_image $RSS_SIGN_SCP_BL1_NAME \
        $RSS_SIGN_SCP_BL1_LOAD_ADDRESS $RSS_SIGN_SCP_BL1_BIN_SIZE

  3. Package the signed file into an FIP file. See the following code for reference:

    build-scripts/build-flash-image.sh:

        $FIPTOOL update --align 8192 --rss-bl2 $BINDIR/bl2_signed.bin $2
    $FIPTOOL update --align 8192 --rss-scp-bl1 $RSS_BINDIR/signed_$RSS_SIGN_SCP_BL1_NAME $2
    $FIPTOOL update --align 8192 --rss-ap-bl1 $RSS_BINDIR/signed_$RSS_SIGN_AP_BL1_NAME $2

    The SCP BL2 firmware is loaded and authenticated by the BL2 firmware of the AP. Therefore, the firmware is packaged into the FIP image during the compilation of TF-A. See the following code for reference:

    build-scripts/config/tc2.config:

    SCP_BL2="$SCP_OUTDIR/scp/bin/tc2-bl2.bin"

  4. Place the FIP file into two GUID partition table (GPT) partitions, a primary partition, and a backup partition. See the following code for reference:

    build-scripts/build-flash-image.sh:

        # create the GPT layout
    sgdisk $gpt_image \
           --set-alignment 16 \
           --disk-guid $location_uuid \
           \
           --new 1:$start_sector_1:+$num_sectors_fip \
           --change-name 1:FIP_A \
           --typecode 1:$fip_type_uuid \
           --partition-guid 1:$FIP_A_uuid \
           \
           --new 2:$start_sector_2:+$num_sectors_fip \
           --change-name 2:FIP_B \
           --typecode 2:$fip_type_uuid \
           --partition-guid 2:$FIP_B_uuid \
           \
           --new 3:$start_sector_3:+$num_sectors_metadata \
           --change-name 3:FWU-Metadata \
           --typecode 3:$metadata_type_uuid \
           \
           --new 4:$start_sector_4:+$num_sectors_metadata \
           --change-name 4:Bkup-FWU-Metadata \
           --typecode 4:$metadata_type_uuid

    # populate the GPT partitions
    dd if=$fip_bin of=$gpt_image bs=$sector_size seek=$(gdisk -l $gpt_image | grep " FIP_A$" | awk '{print $2}') count=$num_sectors_fip conv=notrunc
    dd if=$fip_bin of=$gpt_image bs=$sector_size seek=$(gdisk -l $gpt_image | grep " FIP_B$" | awk '{print $2}') count=$num_sectors_fip conv=notrunc

  5. Pass the GPT file to the FVP as a parameter. The GPT file serves as a disk file during FVP startup. See the following code for reference:
    -C board.flashloader0.fname=output/buildroot/deploy/tc2//fip_gpt-tc.bin

Interaction between RSS and SCP