Reproduce

This section describes how to download, configure, build and execute the solutions in this repository.

Note

You can copy all command examples on this page from the HTML document format by clicking the copy button. In the PDF document format, be aware that special characters are added when lines get wrapped.

Build host environment setup

Please see Build Host Environment for details on how to set up the build host environment.

Download

Note

Performing the builds and FVP execution in a tmux session is mandatory for Arm Automotive Solutions because the runfvp tool that invokes the FVP expects the presence of a tmux session to attach its spawned tmux windows for console access to the processing elements.

Refer to Tmux Documentation for more information on the usage of tmux. It is recommended to change the default history-limit by adding set-option -g history-limit 3000 to ~/.tmux.conf before starting tmux.

Start a new tmux session, via:

tmux new-session -s arm-auto-solutions

To reconnect to an existing tmux session:

tmux attach -t arm-auto-solutions

Download the Arm Automotive Solutions repository using Git and checkout a release, via:

mkdir -p ~/arm-auto-solutions
cd ~/arm-auto-solutions
git clone https://git.gitlab.arm.com/automotive-and-industrial/arm-auto-solutions/sw-ref-stack.git --branch v2.0

Reproducing the use cases

General

Kas build

Note

This documentation does not cover network configuration settings, more information can be found at Set Up Yocto Source Download and Proxy

Run the following to open the configuration menu:

kas menu sw-ref-stack/Kconfig

To build and run any image for an Arm FVP the user has to accept its EULA by selecting the corresponding configuration option in the build setup and pressing spacebar.

The default number of Primary Compute CPUs is 4. The user can change this by selecting a value between 1 and 4 from the Number of Primary Compute CPUs option.

Arm Auto Solutions Build Configuration Menu

To start the build, press the right arrow key, select the Build option and press enter. Subsequent builds with the same configuration can be started by running:

kas build

Note

Typically, the build process should complete without any interruptions. However, if it is manually interrupted (e.g., by pressing Ctrl-c) or due to network/resource failures, errors may occur when rerunning the build, such as:

NOTE: Reconnecting to bitbake server...
NOTE: No reply from server in 30s (for command <command> at 10:11:08.527092)

This happens because some processes might still be running in the background. To resolve this, you can manually terminate them using: killall -e Cooker

Check for lock files and ensure there are no leftover lock files from the previous build. You can locate and remove them with: find . -name "bitbake.lock" -exec rm -f {} \;

If the above steps don’t resolve the issue, a system reboot might help clear any lingering problems.

FVP

Note

FVPs, and Fast Models in general, are functionally accurate, meaning that they fully execute all instructions correctly, however they are not cycle accurate. The main goal of the Reference Software Stack is to prove functionality only, and should not be used for performance analysis.

The runfvp tool that invokes the FVP creates one tmux terminal window per processing element. The default window displayed will be that of the Primary Compute terminal, titled terminal_ns_uart0. You may press Ctrl-b w to see the list of tmux windows and use arrow keys to navigate through the windows and press Enter to select any processing element terminal.

The following table lists the different tmux panes and their purpose:

tmux pane name

Purpose

python3

FVP terminal

terminal_uart

RSE terminal

terminal_uart_si_cluster0

SI Cluster0 terminal

terminal_sec_uart

AP Secure world terminal

terminal_ns_uart0

AP Non-secure world terminal
Run the FVP

Note

During boot and runtime the user shall never issue more than two Ctrl-c, since it might corrupt the images and prevent successful reboot of the CSS-Aspen FVP. In this eventuality, it can be re-generated by issuing kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy"

To start the FVP and run the software reference stack:

kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"

Ensure that the tmux window titled terminal_ns_uart0 is selected. If not, press Ctrl-b w from the tmux session, navigate to the tmux window titled terminal_ns_uart0 followed by pressing the Enter key.

Wait for the system to boot and for the Linux prompt to appear.

The Reference Software Stack running on the Primary Compute can be logged into as the root user without a password in the Linux terminal.

Shut down the FVP

To shut down the FVP and terminate the emulation, select the terminal titled python3 where the runfvp was launched by pressing Ctrl-b 0 and press Ctrl-c to stop the FVP process.

Note

In some cases, pressing Ctrl-c while the system is writing back to the flash might corrupt the images, resulting in an error during boot. If this happens, rebuilding the images with the following command will resolve the issue: kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy"

PSA APIs Tests in Primary Compute

The demo can only be run on the Baremetal Architecture.

See Primary Compute Secure Services for more information on this application. This demo is included as part of the Arm Automotive Solutions Demo.

Baremetal architecture

Build

Note

If the Arm Automotive Solutions Demo for the Baremetal Architecture is the most recent build, there is no need to rebuild. For a first-time build, follow the instructions below.

To configure and build a Baremetal Architecture image see Kas build.

Run the FVP

Note

If the FVP has already been launched with the specified build configuration and is connected to the Primary Compute terminal (running Linux), there is no need to stop and relaunch. For first-time launch, follow the instructions to start the FVP and connect it to the Primary Compute terminal.

To start the FVP and connect to the Primary Compute terminal:

kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"

Wait for the system to boot and for the Linux prompt to appear.

The Reference Software Stack running on the Primary Compute can be logged into as root user without a password in the Linux terminal. Run the below command to ensure that all the expected services have been initialized:

systemctl is-system-running --wait

Wait for it to return. The expected terminal output is running.

Run the demo

The demo consists of simple tests run from the Linux terminal.

See Primary Compute Secure Services for more information on this application.

  1. Run the PSA Crypto API tests from the Primary Compute terminal using the following command:

    psa-crypto-api-test

    A message similar to the following will appear when the tests have completed:

    ************ Crypto Suite Report **********
TOTAL TESTS     : 47
TOTAL PASSED    : 46
TOTAL SIM ERROR : 0
TOTAL FAILED    : 0
TOTAL SKIPPED   : 1
******************************************

  2. Run the PSA Protected Storage API tests from the Primary Compute terminal using the following command:

    psa-ps-api-test

    A message similar to the following will appear when the tests have completed:

    ************ Storage Suite Report **********
TOTAL TESTS     : 17
TOTAL PASSED    : 11
TOTAL SIM ERROR : 0
TOTAL FAILED    : 0
TOTAL SKIPPED   : 6
******************************************

  3. Run the PSA Internal Trusted Storage API tests from the Primary Compute terminal using the following command:

    psa-its-api-test

    A message similar to the following will appear when the tests have completed:

    ************ Storage Suite Report **********
TOTAL TESTS     : 10
TOTAL PASSED    : 10
TOTAL SIM ERROR : 0
TOTAL FAILED    : 0
TOTAL SKIPPED   : 0
******************************************

  4. Run the PSA Initial Attestation API tests from the Primary Compute terminal using the following command:

    psa-iat-api-test

    A message similar to the following will appear when the tests have completed:

    ************ Attestation Suite Report **********
TOTAL TESTS     : 1
TOTAL PASSED    : 1
TOTAL SIM ERROR : 0
TOTAL FAILED    : 0
TOTAL SKIPPED   : 0
******************************************

    Note

    There is no need to shut down and relaunch the FVP before demonstrating another use case on the Arm Automotive Solutions Demo build (Baremetal Architecture).

  5. To shut down the FVP and terminate the emulation automatically, issue the following command on the Primary Compute terminal:

    shutdown now

    The below messages show that the shutdown process is complete:

    [  OK  ] Finished System Power Off.
[  OK  ] Reached target System Power Off.
reboot: Power down

See Automated validation for more details on how to trigger the automated validation.

Integration Test Using Debugger CLI

SCP-firmware provides a built-in debugger CLI that can be used to run integration tests on the Safety Island firmware. This is especially useful for validating fault-handling logic and verifying module-specific behavior in isolation.

Debugger CLI Access

To enter the debugger CLI while the system is running on the Safety Island:

  • Press Ctrl-e in the terminal_uart_si_cluster0 tmux window.

Once inside the CLI prompt, integration tests can be triggered using test commands defined in SCP-firmware.

Running SSU Integration Test

To trigger the SSU integration test:

  1. Enter the debugger CLI using Ctrl-e.

  2. At the > prompt, run the following command:

    test ssu

  3. Exit the CLI using Ctrl-d. This resumes normal firmware execution.

  4. The test suite will run automatically.

Test output will be displayed in the same terminal_uart_si_cluster0 UART console window. A successful test will print output similar to:

[CLI_DEBUGGER_MODULE] Entering CLI
> test ssu
>
[CLI_DEBUGGER_MODULE] Exiting CLI
[   15.046229] [INTEGRATION_TEST] Start: ssu
[   15.046236] [SSU] Setting SSU FSM to: SAFE (0x0)
[   15.046243] [SSU] SSU FSM status: SAFE (0x2)
[   15.046251] [SSU] Setting SSU FSM to: ERRN (0x1)
[   15.046259] [SSU] SSU FSM status: ERRN (0x4)
[   15.046266] [SSU] Setting SSU FSM to: SAFE (0x0)
[   15.046274] [SSU] SSU FSM status: SAFE (0x2)
[   15.046280] [SSU] Setting SSU FSM to: ERRC (0x2)
[   15.046288] [SSU] SSU FSM status: ERRC (0x8)
[   15.046296] [SSU] Setting SSU FSM to: SAFE (0x0)
[   15.046303] [SSU] SSU FSM status: ERRC (0x8)
/usr/src/debug/scp-firmware/2.14.0/module/integration_test/src/mod_integration_test.c:122:test_ssu_sys_api:PASS
/usr/src/debug/scp-firmware/2.14.0/module/integration_test/src/mod_integration_test.c:122:test_error_control_api:PASS

-----------------------
2 Tests 0 Failures 0 Ignored
OK
[   15.046341] [INTEGRATION_TEST] End: ssu

Note

  • The SSU test case must be run before any other test case, which may interfere with the SSU state.

  • After running the test case, the FVP must be rebooting before running again in order to reset the SSU state.

Running FMU Integration Test

To trigger the FMU integration test:

  1. Enter the debugger CLI using Ctrl-e.

  2. At the > prompt, run the following command:

    test fmu

  3. Exit the CLI using Ctrl-d. This resumes normal firmware execution.

  4. The test suite will automatically run once the event loop resumes.

Test output will be displayed in the same terminal_uart_si_cluster0 UART console window. A successful test will print output similar to:

[CLI_DEBUGGER_MODULE] Entering CLI
> test fmu
>
[CLI_DEBUGGER_MODULE] Exiting CLI
[  17.606923] [INTEGRATION_TEST] Start: fmu
[  17.606930] [FMU] Critical fault received: Device: 0x0, Node 0x0, SM 0x10
[  17.606942] [FMU] Non-critical fault received: Device: 0x0, Node 0x1, SM 0x1
[  17.606953] [FMU] Non-critical fault received: Device: 0x1, Node 0x0, SM 0x1
/usr/src/debug/scp-firmware/2.14.0/module/integration_test/src/
mod_integration_test.c:122:test_inject:PASS
[  17.606977] [FMU] Critical fault received: Device: 0x0, Node 0x0, SM 0x10
/usr/src/debug/scp-firmware/2.14.0/module/integration_test/src/
mod_integration_test.c:122:test_set_enabled:PASS
[  17.607001] [FMU] Non-critical fault received: Device: 0x0, Node 0x1, SM 0x1
[  17.607014] [FMU] Non-critical fault received: Device: 0x0, Node 0x1, SM 0x1
[  17.607026] [FMU] Critical fault received: Device: 0x0, Node 0x1, SM 0x10
/usr/src/debug/scp-firmware/2.14.0/module/integration_test/src/
mod_integration_test.c:122:test_upgrade:PASS
--------------------
3 Tests 0 Failures 0 Ignored
OK
[  17.607056] [INTEGRATION_TEST] End: fmu

Note

After running the test case once, the FVP must be rebooted before running again to reset the FMU state.

Platform Fault Detection Interface

The Software Reference Stack currently supports the Platform Fault Detection Interface (PFDI) Specification, which is used to detect hardware faults by registering appropriate firmware test libraries.

For more technical information on PFDI’s architecture and design, see Platform Fault Detection Interface (PFDI).

Arm Software Test Libraries (STL) can be integrated as the real PFDI firmware test backend. To enable STL support and obtain access, please contact Arm or visit Arm Software Test Libraries

Run the configuration menu:

kas menu sw-ref-stack/Kconfig

  1. Select Use Case > Arm Automotive Solutions Demo.

  2. Select Build.

After the build process is complete, to start the FVP and run the software reference stack:

kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"

Ensure that the tmux window titled terminal_ns_uart0 is selected. If not, press Ctrl-b w from the tmux session, navigate to the tmux window titled terminal_ns_uart0 followed by pressing the Enter key.

Wait for the system to boot and for the Linux prompt to appear.

The Reference Software Stack running on the Primary Compute can be logged into as root user without a password in the Linux terminal.

A systemd service which runs the PFDI in the background is started automatically.

Run the following command to check the status of the PFDI service:

systemctl status pfdi-app.service

The output should be similar to

* pfdi-app.service - Platform Fault Detection Application
    Loaded: loaded (/usr/lib/systemd/system/pfdi-app.service; enabled; preset: enabled)
    Active: active (running) since Mon 2025-06-02 08:37:36 UTC; 3min 18s ago
Invocation: 21933cd70c0346e19f6e0564270c1b20
    Process: 280 ExecStartPre=/usr/sbin/modprobe pfdi_misc (code=exited, status=0/SUCCESS)
    Process: 286 ExecStartPre=/usr/bin/sh -c until [ -e /dev/cpu ]; do sleep 0.5; done (code=exited, status=0/SUCCESS)
  Main PID: 289 (pfdi-sample-app)
      Tasks: 5 (limit: 2265)
    Memory: 980K (peak: 1.4M)
        CPU: 4.119s
    CGroup: /system.slice/pfdi-app.service
            `-289 /usr/bin/pfdi-sample-app -i -c /etc/pfdi/pfdi_test_config_0.pack

Jun 02 08:37:36 fvp-rd-aspen systemd[1]: Starting Platform Fault Detection Application...
Jun 02 08:37:36 fvp-rd-aspen systemd[1]: Started Platform Fault Detection Application.
Jun 02 08:37:36 fvp-rd-aspen pfdi-sample-app[289]: [2025-06-02 08:37:36][info][pid:289][tid:289] libPFDI version: 1.0
Jun 02 08:37:36 fvp-rd-aspen pfdi-sample-app[289]: [2025-06-02 08:37:36][info][pid:289][tid:289] Stub firmware detected - No real diagnostics will be executed
Jun 02 08:37:36 fvp-rd-aspen pfdi-sample-app[289]: [2025-06-02 08:37:36][info][pid:289][tid:289] Firmware reports 41 available diagnostic tests
Jun 02 08:37:36 fvp-rd-aspen pfdi-sample-app[289]: [2025-06-02 08:37:36][info][pid:289][tid:289] Loading config V1.0: running 4 tasks every 60 ms

The PFDI CLI provides a command-line interface for interacting with the Platform Fault Detection Interface. The tool supports several operations:

  1. Display the user space PFDI library version

Use the following command:

pfdi-cli --info

Expected output:

libPFDI version: 1.0

  1. Display the firmware PFDI library version

Use the following command:

pfdi-cli --pfdi_info <core_id>

  • <core_id>: Core number to retrieve the version for

Example:

pfdi-cli --pfdi_info 0

Expected output:

Stub firmware detected - No real diagnostics will be executed

  1. Display the number of available PFDI tests

Use the following command:

pfdi-cli --count <core_id>

  • <core_id>: Core number to retrieve the number of tests for

Example:

pfdi-cli --count 0

Expected output:

CPU0: Firmware reports 41 available diagnostic tests

  1. Retrieve Out-of-Reset (OoR) PFDI tests results

Query the OoR tests results for a specific core:

pfdi-cli --result <core_id>

  • <core_id>: Core number to retrieve results for

Example:

pfdi-cli --result 0

Expected output:

CPU0: Out of Reset (OoR) test OK

  1. This command simulates a platform fault by injecting an error into the firmware for a specific function on a target core. The injected error is returned on the next call to the specified function. Note that:

  • No actual hardware error occurs, this is purely a simulation.

  • The forced error is automatically cleared after it is reported once by the targeted function.

  • All function and error ID combinations are permitted, including injecting an error into the force error function itself.

pfdi-cli --force_error <core_id> <function_id> <error_id>

  • <core_id>: Target core number

  • <function_id>: PFDI function index to inject the error into

  • <error_id>: Error ID to be injected

Example 1:

pfdi-cli --force_error 1 COUNT INVALID_PARAMETERS

Expected output:

CPU1: injected force error to FID=3 with error id =-3

Triggering the simulated error:

pfdi-cli --count 1

Expected output:

CPU1: fetching pfdi firmware test count failed: Invalid argument (errno=22)

Example 2:

pfdi-cli --force_error 2 RUN ERROR

Expected output:

CPU2: injected force error to FID=4 with error id =-5

To confirm that the background PFDI sample application detects and logs the error, inspect the system journal:

journalctl -u pfdi-app.service

You should see a log similar to:

Jun 03 11:00:01 fvp-rd-aspen pfdi-sample-app[275]: [2025-06-03 11:00:01][error][pid:275][tid:281] CPU2: PFDI Online (OnL) test failed: Input/output error (errno=5)

Refer README.md, libpfdi/README.md and pfdi-demo/README.md for further details on the PFDI project, the PFDI library, and the application.

Automated validation

Run the following to open the configuration menu:

kas menu sw-ref-stack/Kconfig
Arm Auto Solutions Run Automated Validation Menu

To start Automated Validation, select Run Automated Validation option from Runtime Validation Setup, select the Build option and press enter.

RESULTS:
RESULTS - ping.PingTest.test_ping: PASSED (0.01s)
RESULTS - ssh.SSHTest.test_ssh: PASSED (167.44s)
RESULTS - test_10_linuxboot.LinuxBootTest.test_linux_boot: PASSED (0.00s)
RESULTS - test_10_linuxlogin.LinuxLoginTest.test_linux_login: PASSED (13.63s)
RESULTS - test_10_pfdi.PFDITest.test_init_systemd_service: PASSED (10.27s)
RESULTS - test_10_pfdi.PFDITest.test_pfdi_app: PASSED (22.47s)
RESULTS - test_10_pfdi.PFDITest.test_pfdi_cli: PASSED (1.22s)
RESULTS - test_10_pfdi.PFDITest.test_pfdi_cli_force_error: PASSED (0.67s)
RESULTS - test_20_fvp_devices.ArmAutoSolutionsFvpDevicesTest.test_cpu_hotplug: PASSED (158.15s)
RESULTS - test_20_fvp_devices.ArmAutoSolutionsFvpDevicesTest.test_networking: PASSED (25.11s)
RESULTS - test_20_fvp_devices.ArmAutoSolutionsFvpDevicesTest.test_rtc: PASSED (13.95s)
RESULTS - test_20_fvp_devices.ArmAutoSolutionsFvpDevicesTest.test_virtiorng: PASSED (13.95s)
RESULTS - test_20_fvp_devices.ArmAutoSolutionsFvpDevicesTest.test_watchdog: PASSED (9.30s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_03_psa_crypto_api_test: PASSED (13.79s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_04_psa_its_api_test: PASSED (6.61s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_05_psa_ps_api_test: PASSED (11.85s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_06_psa_iat_api_test: PASSED (8.39s)
RESULTS - test_99_linuxshutdown.LinuxShutdownTest.test_linux_shutdown: PASSED (110.82s)
RESULTS - test_00_rse.RseTest.test_measured_boot: PASSED (2.10s)
RESULTS - test_00_rse.RseTest.test_normal_boot: PASSED (5.50s)
RESULTS - test_00_rse.RseTest.test_scmi_poweroff: PASSED (169.13s)
RESULTS - test_00_rse.RseTest.test_scmi_reboot: PASSED (329.42s)
RESULTS - test_00_secure_partition.OpteeTest.test_optee_normal: PASSED (7.90s)
RESULTS - test_10_safetydiagnostics_ssu_fmu.SafetyDiagnosticsTestSSUFMU.test_safety_island_fmu: PASSED (0.27s)
RESULTS - test_10_safetydiagnostics_ssu_fmu.SafetyDiagnosticsTestSSUFMU.test_safety_island_ssu: PASSED (0.15s)
RESULTS - test_99_uefi_secure_boot.UEFI_Secure_Boot_Test.test_unsigned_kernel_image: PASSED (5.03s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_00_ts_demo: SKIPPED (0.00s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_02_ts_uefi_test: SKIPPED (0.00s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_07_spmc_test: SKIPPED (0.00s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_09_ts_service_grp_check: SKIPPED (0.00s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_10_fwu_service_tests: SKIPPED (0.00s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_11_ps_service_tests: SKIPPED (0.00s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_12_its_service_tests: SKIPPED (0.00s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_14_attestation_service_tests: SKIPPED (0.00s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_15_crypto_service_tests: SKIPPED (0.00s)
SUMMARY:
baremetal-image () - Ran 35 tests in 1107.153s
baremetal-image - OK - All required tests passed (successes=26, skipped=9, failures=0, errors=0)
NOTE: Tasks Summary: Attempted 5592 tasks of which 0 didn't need to be rerun and all succeeded.

RAS error processing validation

Error injection plays an important role in the Reliability, Availability, and Serviceability (RAS) feature. It is the act of intentionally simulating errors in a system, which can be used to check whether the system can properly detect, report, and recover from them.

The Software Reference Stack currently supports the error injection on Cortex-A720AE CPU cores and verification of the processing of the simulated error.

For more information on the RAS design, see Reliability, Availability, and Serviceability. See Primary Compute CPUs RAS tests for further details on the validation.

To run the configuration menu:

kas menu sw-ref-stack/Kconfig

To build the CPU cores RAS validation image:

  1. Select Use Case > Primary Compute CPUs RAS Validation

  2. Select Build.

Arm Auto Solutions Build Configuration Menu - Primary Compute CPUs RAS Validation

After the build process is complete, to start the FVP and run the test:

kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"

The output from the tmux window titled terminal_ns_uart0 should be similar to:

> Executing 'AP CPU RAS Test CE'
INFO:    ErrStatus = 0x0
INFO:    Corrected ErrStatus by FFH = 0x12
  TEST COMPLETE                                                 Passed

> Executing 'AP CPU RAS Test DE'
INFO:    ErrStatus = 0x12
INFO:    Deferred ErrStatus by FFH = 0x12
  TEST COMPLETE                                                 Passed

******************************* Summary *******************************
> Test suite 'RDAspen Tests'
                                                                Passed
=================================
Tests Skipped : 0
Tests Passed  : 2
Tests Failed  : 0
Tests Crashed : 0
Total tests   : 2
=================================
NOTICE:  Exiting tests.

The output from the tmux window titled terminal_sec_uart indicates the error processing on the Primary Compute. It should be similar to:

VERBOSE: CPU RAS: Interrupt Received ID: 0x11
VERBOSE: CPU RAS: Error Status value : 0x4e000012
VERBOSE: CPU RAS: Doorbell rung from SI0 0x2
VERBOSE: CPU RAS: Error Status Clear Value  : 0x4e000012
VERBOSE: CPU RAS: Interrupt Received ID: 0x11
VERBOSE: CPU RAS: Error Status value : 0x4e000012
VERBOSE: CPU RAS: Doorbell rung from SI0 0x2
VERBOSE: CPU RAS: Error Status Clear Value  : 0x12
VERBOSE: CPU RAS: Interrupt Received ID: 0x11
VERBOSE: CPU RAS: Error Status value : 0x40800012
VERBOSE: CPU RAS: Doorbell rung from SI0 0x2
VERBOSE: CPU RAS: Error Status Clear Value  : 0x12

The output from the tmux window titled terminal_uart_si_cluster0 indicates the error processing on the Safety Island. It should be similar to:

[    2.173821] [AP_RAS_CPU_INT] AP Door Bell, Error Record cleared by AP
[    2.173831] [AP_RAS_CPU_INT] fwk_int number = 324
[    2.173838] [AP_RAS_CPU_INT] ERXSTATUS = 0x4e000012
[    2.173845] [AP_RAS_CPU_INT] ERXMISC0 = 0x0
[    2.173852] [AP_RAS_CPU_INT] Fault Type = Correctable Error
[    2.173949] [AP_RAS_CPU_INT] AP Door Bell, Error Record cleared by AP
[    2.173959] [AP_RAS_CPU_INT] fwk_int number = 324
[    2.173966] [AP_RAS_CPU_INT] ERXSTATUS = 0x12
[    2.173974] [AP_RAS_CPU_INT] ERXMISC0 = 0x0
[    2.173979] [AP_RAS_CPU_INT] Fault Type = Correctable Error
[    2.174222] [AP_RAS_CPU_INT] AP Door Bell, Error Record cleared by AP
[    2.174232] [AP_RAS_CPU_INT] fwk_int number = 324
[    2.174239] [AP_RAS_CPU_INT] ERXSTATUS = 0x12
[    2.174246] [AP_RAS_CPU_INT] ERXMISC0 = 0x0
[    2.174252] [AP_RAS_CPU_INT] Fault Type = Deferred Error
[    2.174261] [SSU] Setting SSU FSM to: ERRN (0x1)
[    2.174269] [SSU] SSU FSM status: ERRN (0x4)
[    2.174275] [AP_RAS_CPU_INT] SSU State Changed to 0x4

  • Terminate the FVP

    To close the FVP and terminate the emulation switch back to [0] 0:bash window in the tmux session by navigating using Ctrl-b + 0, and then terminating the FVP via Ctrl-c.

Arm SystemReady Devicetree validation

Arm SystemReady Devicetree firmware build

The Arm SystemReady Devicetree Firmware Build option just builds the Arm SystemReady Devicetree-aligned firmware.

See Arm SystemReady Devicetree for more details.

Arm Auto Solutions Build Configuration Menu - Arm SystemReady Devicetree Firmware Build

Build

To run the configuration menu:

kas menu sw-ref-stack/Kconfig

To build the Arm SystemReady Devicetree-aligned firmware image:

  1. Select Use Case > Arm SystemReady Devicetree Firmware Build.

  2. Select Build.

The firmware images listed below can be found in the directory build/tmp_systemready/deploy/images/fvp-rd-aspen/:

  • ap-flash-image.img

  • combined_provisioning_message.bin

  • rse-flash-image.img

  • rse-otp-image.img

  • rse-rom-image.img

Arm SystemReady Devicetree Architecture Compliance Suite (ACS) tests

The ACS for the Arm SystemReady Devicetree certification is delivered through a live OS image, which enables the basic automation to run the tests.

The system boots with the ACS live OS image and the ACS tests run automatically after the system boots. See Arm SystemReady Devicetree ACS tests for more details.

Build and automated validation

To run the configuration menu:

kas menu sw-ref-stack/Kconfig

To build and run the Arm SystemReady Devicetree ACS tests:

  1. Select Use Case > Arm SystemReady Devicetree Validation > Arm SystemReady Devicetree Architecture Compliance Suite (ACS) Tests.

  2. Select Build.

A similar output to the following is printed out:

NOTE: Executing Tasks
Creating terminal default on terminal_ns_uart0
Creating terminal tf-a on terminal_sec_uart
Creating terminal rse on terminal_uart
Creating terminal safety_island_c0 on terminal_uart_si_cluster0
Transitioned to on
Test Group (PlatformSpecificElements): FAILED
Test Group (RequiredElements): FAILED
Test Group (CheckEvent_Conf): PASSED
Test Group (CheckEvent_Func): PASSED
Test Group (CloseEvent_Func): PASSED
Test Group (CreateEventEx_Conf): PASSED
Test Group (CreateEventEx_Func): PASSED
Test Group (CreateEvent_Conf): PASSED
Test Group (CreateEvent_Func): PASSED
Test Group (RaiseTPL_Func): PASSED
...
...
ACS BBSR running
Test Group (VariableAttributes): FAILED
Test Group (VariableUpdates): FAILED
...
Test Group (virtio_blk virtio1): vda
Test Group (virtio_blk virtio2): vdb
Test Group (virtio_blk virtio3): vdc
Test Group (virtio_blk virtio4): vdd
Linux tests complete
Transitioned to OEFVPTargetState.OFF
RESULTS:
RESULTS - arm_systemready_devicetree_acs.SystemReadyACSTest.test_acs: PASSED (9258.72s)
SUMMARY:
arm-systemready-devicetree-acs () - Ran 1 test in 9258.723s
arm-systemready-devicetree-acs - OK - All required tests passed (successes=1, skipped=0, failures=0, errors=0)
ACS test suite results are consistent with baseline.

As seen in the above logs, some Test Groups are expected to fail. The following message is expected to validate this use case:

RESULTS - arm_systemready_devicetree_acs.SystemReadyACSTest.test_acs: PASSED (7626.94s)

Note

Running the ACS tests more than once will have them resume from where they last stopped. Additionally, consecutive runs are not supported by the ACS logs; it will result in a failure after the end of the tests. To run the ACS tests again, use the following to refresh the firmware images in flash and re-start the entire ACS test suite properly:

kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy"
kas shell -c "bitbake arm-systemready-devicetree-acs -C unpack"

Note

The ACS tests take hours to complete. The actual time taken will vary depending on the performance of the build host. The default timeout setting for the tests is 12 hours for an x86_64 host or 24 hours for an aarch64 host. If a timeout failure occurs, increase the timeout setting and re-run the tests with the following command on the build host terminal. The example command below changes the timeout setting to 16 hours:

TEST_OVERALL_TIMEOUT="\${@16*60*60}" kas shell -c "bitbake arm-systemready-devicetree-acs -C unpack"

Note

There is a rare known failure where a timeout might occur during test execution.

See Arm SystemReady Devicetree ACS tests for an explanation on how the ACS tests are set up and how they work in the Reference Software Stack.

Linux distribution installation (Debian, openSUSE and Fedora)

The Arm SystemReady Devicetree-aligned firmware must boot at least three unmodified generic UEFI distribution images from an ISO image.

This Software Stack currently supports three Linux distributions: Debian Stable, openSUSE Leap and Fedora Server.

Note

Arm SystemReady Devicetree ACS tests runs the Base Boot Security Requirements (BBSR) tests, which enroll the authenticated variables for UEFI Secure Boot, so running the Linux distros installation after running the ACS tests will result in a failure. The firmware flash images need to be recreated with the following command:

kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy"

See UEFI Secure Boot for more information.

Note

The manual installation of a Linux distribution requires some manual interaction, for example, some necessary selections, confirmations or entering the user and password.

The whole installation process takes a long time (possibly up to 10 hours, or even longer).

We suggest that when running the Linux distribution installations the FVP is the only running process as it will consume large amounts of RAM that can make the system unstable.

See Linux Distributions Installation Tests for an explanation on how the Linux distros installation is set up and how they work in the Reference Software Stack.

Debian

Distro unattended installation

In this test we have modified the installation ISO image to add the preconfiguration file preseed.cfg inside it. This required editing the grub.cfg file inside the ISO image to select starting the unattended installation from the preconfiguration file. (meta-arm-systemready/recipes-test/arm-systemready-linux-distros/files/unattended-boot-conf/Debian/preseed.cfg)

Distro installation

The firmware flash images need to be recreated with the following command:

kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy"

To run the configuration menu:

kas menu sw-ref-stack/Kconfig

To build the Arm SystemReady Devicetree Linux distros installation tests:

  1. Select Debian Linux Distro Installation under Linux Distribution Installation (Debian, openSUSE and Fedora) from the Use-Case menu.

  2. Select Build.

Arm Auto Solutions Build Configuration Menu - Debian Linux Distro Installation

A similar output to the following indicates when the installation is finished, which will take around 3 hours:

Transitioned to on
Installation status: Scanning installation media...
Installation status: Detecting network hardware...
Installation status: Installing the base system...
Installation status: Installing GRUB...
Installation status: Finishing the installation...
Installation status: Debian installation finished successfully.
Transitioned to OEFVPTargetState.OFF
RESULTS:
RESULTS - arm_systemready_debian_unattended.SystemReadyDebianUnattendedTest.test_debian_unattended: PASSED (7843.92s)
SUMMARY:
arm-systemready-linux-distros-debian () - Ran 1 test in 7843.924s

  • Log in

    After the installation is finished, run the following command to log into the Linux shell:

    kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"

    Log into the Linux shell with the user created during the installation using the username user and the password unsafe.

  • Terminate the FVP

    To shut down the FVP and terminate the emulation automatically, run the following command.

    sudo shutdown now

    The below message indicates the shutdown process is complete.

    reboot: Power down

    Subsequently running the FVP will boot into Debian.

Distro manual installation

To install Debian, see the Debian GNU/Linux Installation Guide.

Distro installation media preparation

The firmware flash images need to be recreated with the following command:

kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy"

To run the configuration menu:

kas menu sw-ref-stack/Kconfig

To build the Arm SystemReady Devicetree Linux distros installation tests:

  1. Select Use Case > Linux Distribution Installation (Debian, openSUSE and Fedora) > Debian Linux Distro Installation.

  2. Select Build.

Arm Auto Solutions Build Configuration Menu - Debian Linux Distro Installation

Distro installation

Run the following command to start the installation:

kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"

The whole process of installing Debian will probably take about 5 hours. The installation process begins when you see the following:

Grub Install Options Menu - Debian Linux Distro Installation

Select Install to start the installation process.

The following is the problem that has been encountered during the Debian installation process and how to solve it:

  • Install the GRUB boot loader

    When the installation reaches the Install the GRUB boot loader phase, choose Yes.

    Grub Installation Prompt - Debian Linux Distro Installation

Expect an error Unable to install GRUB in dummy. This is because on an EBBR platform, UEFI SetVariable() is not required at runtime (however, it is required at boot time).

Grub Installation Failure Prompt - Debian Linux Distro Installation

One workaround we have is to “execute a shell” when the GRUB install phase throws the above error. To execute a shell, press Ctrl-a n to switch the debug shell, and run the following commands:

chroot /target
update-grub
cp -v /boot/efi/EFI/debian/grubaa64.efi /boot/efi/EFI/BOOT/bootaa64.efi

A snapshot is as below:

Grub Workaround Console Output - Debian Linux Distro Installation

After doing the above GRUB workaround, press Ctrl-a p to go back to the installer again. Select Continue on the GRUB failure screen.

Second Grub Installation Failure Prompt - Debian Linux Distro Installation

Select Continue without boot loader in the Debian installer main menu and continue.

Debian Installer Main Menu - Debian Linux Distro Installation

Select Yes in the Update NVRAM variables to boot automatically into Debian and continue.

Install the GRUB boot loader - Debian Linux Distro Installation

  • Log in

    When the installation reaches the final Finishing the installation phase, you will need to wait some time to finish the remaining tasks, and then it will automatically reboot into the installed OS. You can log into the Linux shell with the user created during installation.

  • Terminate the FVP

    To shut down the FVP and terminate the emulation automatically, log into the Linux shell as the root user then run the following command:

    shutdown now

    The below message shows that the shutdown process is complete:

    reboot: Power down

    Subsequently running the FVP will boot into Debian.

openSUSE

Distro unattended installation

In this test we have modified the installation ISO image to add the automatic installation file inside it. This required adding the autoinst.xml file inside the ISO image to locate the installation configuration file (meta-arm-systemready/recipes-test/arm-systemready-linux-distros/files/unattended-boot-conf/openSUSE/autoinst.xml).

Distro installation

The firmware flash images need to be recreated with the following command:

kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy"

To run the configuration menu:

kas menu sw-ref-stack/Kconfig

To build the Arm SystemReady IR Linux distros installation tests:

  1. Select Use Case > Linux Distribution Installation (Debian, openSUSE and Fedora) > openSUSE Linux Distro Installation.

  2. Select Build.

Arm Auto Solutions Build Configuration Menu - openSUSE Linux Distro Installation

This installation will take around 7 hours to complete. A similar output to the following shows when the installation is finished:

Transitioned to on
Installation status: Loading the kernel, initrd and basic drivers...
Installation status: Starting hardware detection...
Installation status: Loading Installation System...
Installation status: Performing Installation...
Installation status: Finishing Configuration...
Installation status: openSUSE installation finished successfully.
Transitioned to OEFVPTargetState.OFF
RESULTS:
RESULTS - arm_systemready_opensuse_unattended.SystemReadyOpenSUSEUnattendedTest.test_opensuse_unattended: PASSED (25285.12s)
SUMMARY:
arm-systemready-linux-distros-opensuse () - Ran 1 test in 25285.117s

  • Log in

After the installation is finished, run the following command to log into the Linux shell:

kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"

Log into the Linux shell with the user created during the installation using the username user and the password unsafe.

  • Terminate the FVP

    To shut down the FVP and terminate the emulation automatically, run the following command:

    sudo shutdown now

    The below message shows that the shutdown process is complete:

    reboot: Power down

    Subsequently running the FVP will boot into openSUSE.

Distro manual installation

To install openSUSE, see the openSUSE Installation Guide.

Distro installation media preparation

The firmware flash images need to be recreated with the following command:

kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy"

To run the configuration menu:

kas menu sw-ref-stack/Kconfig

To build the Arm SystemReady IR Linux distros installation tests:

  1. Select Use Case > Linux Distribution Installation (Debian, openSUSE and Fedora) > openSUSE Linux Distro Installation.

  2. Unselect Distros Unattended Installation Setup > Run Unattended Installation.

  3. Select Build.

Arm Auto Solutions Build Configuration Menu - openSUSE Linux Distro Installation

Run the following command to start the installation:

kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"

The whole process of installing openSUSE will take several hours. The install process begins when you see the following:

Leap Install Options Menu - openSUSE Linux Distro Installation

Select No when you get to the Online Repositories screen.

Online Repositories Options Menu - openSUSE Linux Distro Installation

Select Installation to start the installation process.

  • System Role

    When you get to the System Role screen, select Server, then select Next to continue with the installation.

    System Role Selection Menu - openSUSE Linux Distro Installation

    Tip

    Use Tab to cycle through options on screens during installation.

  • Installation process

    When you have selected Install on the Confirm Installation screen, the installation will proceed and it will take several hours. The steps of the installation process are:

    • Installing Packages...

    • Save configuration

    • Save installation settings

    • Install boot manager

    • Prepare system for initial boot

    • Then the system will reboot automatically in 10s, you can select OK to reboot immediately.

  • Log in

    After the reboot process, log into the Linux shell with the user created during installation.

  • Terminate the FVP

    To shut down the FVP and terminate the emulation automatically, run the following command:

    sudo shutdown now

    The below message shows that the shutdown process is complete:

    reboot: Power down

    Subsequently running the FVP will boot into openSUSE.

Fedora

Distro unattended installation

In this test we have modified the installation ISO image to add the kickstart configuration file inside it. This required editing the grub.cfg file inside the ISO image to locate the kickstart configuration file (meta-arm-systemready/recipes-test/arm-systemready-linux-distros/files/unattended-boot-conf/Fedora/ks.cfg).

Distro installation

The firmware flash images need to be recreated with the following command:

kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy"

To run the configuration menu:

kas menu sw-ref-stack/Kconfig

To build the Arm SystemReady IR Linux distros installation tests:

  1. Select Use Case > Linux Distribution Installation (Debian, openSUSE and Fedora) > Fedora Linux Distro Installation.

  2. Select Build.

Arm Auto Solutions Build Configuration Menu - Fedora Linux Distro Installation

This installation will take around 18 hours to complete. A similar output to the following shows when the installation is finished:

Transitioned to on
Transitioned to on
Installation status: Loading the installer, kernel and initrd...
Installation status: Setting up the installation environment...
Installation status: Installing the software packages...
Installation status: Fedora installation finished successfully.
Transitioned to OEFVPTargetState.OFF
RESULTS:
RESULTS - arm_systemready_fedora_unattended.SystemReadyFedoraUnattendedTest.test_fedora_unattended: PASSED (61939.30s)
SUMMARY:
arm-systemready-linux-distros-fedora () - Ran 1 test in 61939.303s

  • Log in

    After the installation is finished, run the following command to log into the Linux shell:

    kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"

    Log into the Linux shell with the user created during the installation using the username user and the password unsafe.

  • Terminate the FVP

    To shut down the FVP and terminate the emulation automatically, run the following command:

    sudo shutdown now

    The below message shows that the shutdown process is complete:

    reboot: Power down

    Subsequently running the FVP will boot into Fedora.

Distro manual installation

To install Fedora, see the Fedora Installation Guide.

Distro installation media preparation

The firmware flash images need to be recreated with the following command:

kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy"

To run the configuration menu:

kas menu sw-ref-stack/Kconfig

To build the Arm SystemReady IR Linux distros installation tests:

  1. Select Use Case > Linux Distribution Installation (Debian, openSUSE and Fedora) > Fedora Linux Distro Installation.

  2. Unselect Distros Unattended Installation Setup > Run Unattended Installation.

  3. Select Build.

Arm Auto Solutions Build Configuration Menu - Fedora Linux Distro Installation

Distro installation

Run the following command to start the installation:

kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"

The whole process of installing Fedora will probably take about 24 hours. The installation process begins when you see the following:

Grub Install Options Menu - Fedora Linux Distro Installation

Select Install Fedora 39 to start the installation process.

Here are some tips for installing Fedora:

  1. It will take a few minutes for GRUB to load the installer, kernel and initrd.

  2. When the installer has started, enter 2 to choose Use text mode.

    Starting installer, one moment...
anaconda 39.32.6-2.fc39 for Fedora 39 started.
 * installation log files are stored in /tmp during the installation
 * shell is available on TTY2 and in second TMUX pane (Ctrl-b, then press 2)
 * when reporting a bug add logs from /tmp as separate text/plain attachments

X or window manager startup failed, falling back to text mode.
================================================================================
================================================================================
X was unable to start on your machine. Would you like to start VNC to connect to
this computer from another computer and perform a graphical installation or
continue with a text mode installation?

1) Start VNC
2) Use text mode

Please make a selection from the above ['c' to continue, 'h' to help, 'q' to
quit, 'r' to refresh]: 2

  3. When reaching the installation menu, you will see several items marked as ! which shows that the item needs to be configured before proceeding.

    ================================================================================
================================================================================
Installation

1) [x] Language settings                 2) [x] Time settings
       (English (United States))                (America/Chicago timezone)
3) [!] Installation source               4) [!] Software selection
       (Setting up installation                 (Processing...)
       source...)
5) [!] Installation Destination          6) [x] Network configuration
       (Processing...)                          (Connected: eth0)
7) [!] Root password                     8) [!] User creation
       (Root account is disabled)               (No user will be created)

Please make a selection from the above ['b' to begin installation, 'h' to help,
'q' to quit, 'r' to refresh]:

    For 3) [!] Installation source, enter 3, then 1 to select CD/DVD.

    ================================================================================
================================================================================
Installation source

Choose an installation source type.
1) CD/DVD
2) local ISO file
3) Network

Please make a selection from the above ['c' to continue, 'h' to help, 'q' to
quit, 'r' to refresh]: 1

    For 4) [!] Software selection, enter 4, then c to continue.

    For 5) [!] Installation Destination, enter 5, then c to select the default options.

    For 6) [!] Network configuration, it will automatically change to x.

    For 7) [!] Root password, follow the prompts to enter the password and confirm.

    After entering root password, 8) [ ] User creation becomes optional and can be skipped.

    The final configuration will appear as follows:

    ================================================================================
================================================================================
Installation

1) [x] Language settings                 2) [x] Time settings
       (English (United States))                (America/Chicago timezone)
3) [x] Installation source               4) [x] Software selection
       (Local media)                            (Fedora Server Edition)
5) [x] Installation Destination          6) [x] Network configuration
       (Automatic partitioning                  (Connected: eth0)
       selected)
7) [x] Root password                     8) [ ] User creation
       (Root password is set)                   (No user will be created)

Please make a selection from the above ['b' to begin installation, 'h' to help,
'q' to quit, 'r' to refresh]:

    Now enter b to start the installation.

  4. The installer is expected to stay at Configuring kernel-core.aarch64 for several hours. The installer will then verify the installed packages and continue to install the boot loader.

  5. The following error is expected while installing the boot loader. Ignore the error by responding yes and continue.

    Installing boot loader
================================================================================
================================================================================
Question

The following error occurred while installing the boot loader. The system will
not be bootable. Would you like to ignore this and continue with installation?

Failed to set new efi boot target. This is most likely a kernel or firmware bug.

Please respond 'yes' or 'no': yes

[anaconda]1:main* 2:shell  3:log  4:storage-log >Switch tab: Alt+Tab | Help: F1

  • Log in

    When the installation reaches the final Finishing the installation phase, you will need to wait some time to finish the remaining tasks. When you see the message Installation complete. Press ENTER to quit:, press enter to reboot into the installed OS. You can log into the Linux shell with the user created during installation.

  • Terminate the FVP

    To shut down the FVP and terminate the emulation automatically, log into the Linux shell as the root user then run the following command:

    shutdown now

    The below message shows that the shutdown process is complete:

    reboot: Power down

    Subsequently running the FVP will boot into Fedora.