This section describes how to download, configure, build and execute the
the supported use cases.
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.
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-ghistory-limit3000 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.1
This section explains different supported use cases and how to reproduce them.
Note that the software can be built for two different platform configurations -
CFG1 and CFG2. See
Configurations
for more information.
The Safety Island Cluster 1 (SI CL1) is present only in the FVP CFG2 variant.
The tmux window for SI CL1 terminal_uart_si_cluster1 only appears when
the CFG2 variant is selected during the build configuration.
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 16 from the
NumberofPrimaryComputeCPUs option. And also the default Platform variant
is RD-AspenCFG1. The user can change this to RD-AspenCFG2 by selecting the
PlatformVariant option.
Fig. 3 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-eCooker
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"-execrm-f{}\;
If the above steps don’t resolve the issue, a system reboot might help clear
any lingering problems.
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-bw 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:
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
kasshell-c"bitbakefirmware-fvp-rd-aspen-Cdeploy"
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:
kasshell-c"bitbakefirmware-fvp-rd-aspen-Cdeploy"
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-bw 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.
To shut down the FVP and terminate the emulation, select the terminal titled
python3 where the runfvp was launched by pressing Ctrl-bw and press
Ctrl-c to stop the FVP process.
In general, it is not necessary to rebuild the Arm Automotive Solutions Demo
for each use case, and it is not required to shut down and relaunch the FVP for
every use case.
See the following instructions for building images for both Baremetal and
Virtualization architectures.
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.
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 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 : 60
TOTAL PASSED : 57
TOTAL SIM ERROR : 0
TOTAL FAILED : 0
TOTAL SKIPPED : 3
******************************************
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
******************************************
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
******************************************
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).
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
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.
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. The PFDI TF-A runner
is implemented based on the Beta version of this specification.
Software Reference Stack uses dummy PFDI firmware unless the Arm Software
Test Libraries (STL) are used. This 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
Select PlatformVariant > RD-AspenCFG1 or RD-AspenCFG2
Select UseCase > ArmAutomotiveSolutionsDemo.
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-bw 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:
Display the user space PFDI library version
Use the following command:
pfdi-cli --info
Expected output:
libPFDI version: 1.0
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
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
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
Show usage of pfdi-cli command including function types and error types:
pfdi-cli
Expected output:
Usage: pfdi-cli [options] -e, --force_error <cpu> <func> <err> Inject error
-p, --pfdi_info <cpu> Show PFDI firmware version
-i, --info Show user lib version
-c, --count <cpu> Show PFDI firmware count
-r, --result <cpu> Show OOR result
Functions: INFO,COUNT,RUN,OOR_RESULT,FW_CHECK,FORCE_ERROR
Errors: COUNT_ZERO,UNKNOWN,NOT_RUN,ERROR,FAULT_FOUND,INVALID_PARAMETERS,NOT_SUPPORTED,SUCCESS
The pfdi-cli--force_error 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.
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.
Select PlatformVariant > RD-AspenCFG1 or RD-AspenCFG2
Select UseCase > PrimaryComputeCPUsRASValidation
Select Build.
Fig. 4 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:
Running test suite 'RDAspen Tests'
Description: RDAspen platform test code
> Executing 'AP CPU Check ERXCTLR state'
TEST COMPLETE Passed
> Executing 'AP CPU RAS Test CE'
INFO: ErrStatus = 0x0
INFO: Corrected ErrStatus by FFH = 0x0
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 : 3
Tests Failed : 0
Tests Crashed : 0
Total tests : 3
=================================
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 : 0x46000012
VERBOSE: CPU RAS: SI Acknowledges doorbell
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
VERBOSE: CPU RAS: SI Acknowledges doorbell
The output from the tmux window titled terminal_uart_si_cluster0 indicates
the error processing on the Safety Island. It should be similar to:
To close the FVP and terminate the emulation switch back to [0]0:bash
window in the tmux session by navigating to the FVP window using Ctrl-b+w,
and then terminating the FVP via Ctrl-c.
This demo uses a large random data file which increases the time required in
HTTPS session and amplifies the timing effects of the Arm Cryptographic
Extension.
Use the following command to connect the server and download the data file.
OpenSSL involves the Arm Cryptographic Extension for the ciphering algorithm.
time echo -e \
"GET / HTTP/1.1\r\nHost: localhost\r\nConnection: close\r\n\r\n" \
| openssl s_client -connect localhost:4433 -cipher AES256-GCM-SHA384 \
-servername localhost -quiet > /dev/null
Connecting to ::1
depth=0 C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
verify error:num=18:self-signed certificate
verify return:1
depth=0 C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
verify return:1
GET / HTTP/1.1
Host: localhost
Connection: close
real 0m22.478s
user 0m4.325s
sys 0m5.504s
Client side without extension enabled
Use the following command to connect the server and download the data file.
OpenSSL will not involve the Arm Cryptographic Extension for the ciphering
algorithm. OPENSSL_armcap=0x0 disables the usage of Arm Cryptographic
Extension.
Available power profiles:
- Parking
- City
- Highway
To select one of the above profiles, use the -s or --select option.
Set the Parking profile. Run ./mbpp.sh-sParking. This will change
scaling governors to powersave for 0-3 CPUs and power down the rest of
the CPUs. The following logs will appear.
If the Arm Automotive Solutions Demo for the Virtualization
Architecture is the most recent build, there is no need to rebuild.
For a first-time build, follow the instructions below.
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 below.
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, then run:
xl list
Expected output:
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 1 r----- 87.1
domu1 1 1024 2 r----- 66.6
domu2 2 1024 1 r----- 41.1
The following log entries are expected:
(XEN) d1v0 Unhandled SMC/HVC: 0x8600ff01
(XEN) d1v0: vGICD: RAZ on reserved register offset 0x00000c
(XEN) d1v0: vGICR: SGI: unhandled word write 0x000000ffffffff to ICACTIVER0
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"
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.
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:
Fig. 8 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 InstalltheGRUBbootloader phase,
choose Yes.
Fig. 9 Grub Installation Prompt - Debian Linux Distro Installation
Select Yes in the UpdateNVRAMvariablestobootautomaticallyintoDebian
and continue.
Fig. 10 Install the GRUB boot loader - Debian Linux Distro Installation
Expect an error UnabletoinstallGRUBindummy. This is because
on an EBBR platform, UEFI SetVariable() is not required at
runtime (however, it is required at boot time).
One workaround we have is to “execute a shell” when the GRUB install phase
throws the above error. To execute a shell, press Ctrl-an to switch the
debug shell, and run the following commands:
After doing the above GRUB workaround, press Ctrl-ap to go back to the
installer again. Select Continue on the GRUB failure screen.
Fig. 13 Second Grub Installation Failure Prompt - Debian Linux Distro Installation
Select Continuewithoutbootloader in the Debianinstallermainmenu
and continue.
Fig. 14 Debian Installer Main Menu - Debian Linux Distro Installation
Log in
When the installation reaches the final Finishingtheinstallation
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.
Fig. 16 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:
Fig. 17 Leap Install Options Menu - openSUSE Linux Distro Installation
Select No when you get to the OnlineRepositories screen.
Fig. 18 Online Repositories Options Menu - openSUSE Linux Distro Installation
Select Installation to start the installation process.
System Role
When you get to the SystemRole screen, select Server, then select
Next to continue with the installation.
Fig. 19 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 ConfirmInstallation screen, the
installation will proceed and it will take several hours. The steps of the
installation process are:
InstallingPackages...
Saveconfiguration
Saveinstallationsettings
Installbootmanager
Preparesystemforinitialboot
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.
Fig. 20 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.
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:
Fig. 22 Grub Install Options Menu - Fedora Linux Distro Installation
Select InstallFedora39 to start the installation process.
Here are some tips for installing Fedora:
It will take a few minutes for GRUB to load the installer, kernel and initrd.
When the installer has started, enter 2 to choose Usetextmode.
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
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)[!]Installationsource, 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)[!]Softwareselection, enter 4, then c to continue.
For 5)[!]InstallationDestination, enter 5, then c to select
the default options.
For 6)[!]Networkconfiguration, it will automatically change to x.
For 7)[!]Rootpassword, follow the prompts to enter the password and
confirm.
After entering root password, 8)[]Usercreation 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.
The installer is expected to stay at Configuringkernel-core.aarch64
for several hours. The installer will then verify the installed packages
and continue to install the boot loader.
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 Finishingtheinstallation
phase, you will need to wait some time to finish the remaining tasks.
When you see the message Installationcomplete.PressENTERtoquit:,
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.
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 compliance 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
ACS tests for more details.
Note
For a full SR compliance report on the Reference Software Stack, the Debian
unattended installation use case must be run before the ACS tests.
You should not delete or modify the build directory between the Debian
unattended installation and the ACS tests, otherwise the results for SR
compliance will be inaccurate. If the Debian unattended installation is run
multiple times, only the results from the most recent installation will be
considered. See
ACS tests for more information.
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)
As seen in the above logs, some Test Groups are expected to fail. The following
message is expected to validate this use case:
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:
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 ACS tests for an explanation on how the
ACS tests are set up and how they work in the Reference Software Stack.
When automated validation runs with RD-Aspen CFG1, all Safety Island Cluster 1
related tests are skipped; as a result, the Baremetal and Virtualization suites
are smaller than in CFG2, which includes those Safety Island Cluster 1 checks.
test_10_safety_island.SafetyIslandTestBase.test_cluster1 will not be executed
in RD-Aspen CFG1 config.
