.. # SPDX-FileCopyrightText: Copyright 2024-2025 Arm Limited and/or its # affiliates # # SPDX-License-Identifier: MIT .. _rd-aspen_user_guide_reproduce: ######### 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 :ref:`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: .. code-block:: text :substitutions: tmux new-session -s arm-auto-solutions To reconnect to an existing tmux session: .. code-block:: text :substitutions: tmux attach -t arm-auto-solutions Download the Arm Automotive Solutions repository using Git and checkout a release, via: .. code-block:: text :substitutions: mkdir -p ~/arm-auto-solutions cd ~/arm-auto-solutions git clone |arm auto solutions remote| --branch |arm auto solutions version| .. _rd-aspen_user_guide_reproduce_use_cases: ************************* Reproducing the use cases ************************* General ======= .. _rd_aspen_kas_build: 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: .. code-block:: text 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. .. image:: ../images/build_config.* :align: center :alt: 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: .. code-block:: text 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: .. code-block:: text NOTE: Reconnecting to bitbake server... NOTE: No reply from server in 30s (for 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: .. list-table:: :widths: 100 100 :header-rows: 1 * - 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: .. code-block:: text 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"`` .. _rd_aspen_user_guide_reproduce_psa_apis_tests_in_pc: PSA APIs Tests in Primary Compute ================================= The demo can only be run on the Baremetal Architecture. See :ref:`rd-aspen_design_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 :ref:`rd_aspen_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: .. code-block:: text 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: .. code-block:: text 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 :ref:`rd-aspen_design_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: .. code-block:: text psa-crypto-api-test A message similar to the following will appear when the tests have completed: .. code-block:: text ************ 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: .. code-block:: text psa-ps-api-test A message similar to the following will appear when the tests have completed: .. code-block:: text ************ 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: .. code-block:: text psa-its-api-test A message similar to the following will appear when the tests have completed: .. code-block:: text ************ 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: .. code-block:: text psa-iat-api-test A message similar to the following will appear when the tests have completed: .. code-block:: text ************ 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: .. code-block:: text shutdown now The below messages show that the shutdown process is complete: .. code-block:: text [ OK ] Finished System Power Off. [ OK ] Reached target System Power Off. reboot: Power down See :ref:`rd_aspen_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: .. code-block:: text [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: .. code-block:: text [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 :link_subs:`rd-aspen:pfdi-spec`, which is used to detect hardware faults by registering appropriate firmware test libraries. For more technical information on PFDI’s architecture and design, see :ref:`aspen_design_platform_fault_detection_interface`. 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 :link_subs:`rd-aspen:arm-stl` Run the configuration menu: .. code-block:: text 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: .. code-block:: text 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: .. code-block:: text systemctl status pfdi-app.service The output should be similar to .. code-block:: text * 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: .. code-block:: console pfdi-cli --info Expected output: .. code-block:: text libPFDI version: 1.0 2. Display the firmware PFDI library version Use the following command: .. code-block:: console pfdi-cli --pfdi_info - ````: Core number to retrieve the version for Example: .. code-block:: console pfdi-cli --pfdi_info 0 Expected output: .. code-block:: text Stub firmware detected - No real diagnostics will be executed 3. Display the number of available PFDI tests Use the following command: .. code-block:: console pfdi-cli --count - ````: Core number to retrieve the number of tests for Example: .. code-block:: console pfdi-cli --count 0 Expected output: .. code-block:: text CPU0: Firmware reports 41 available diagnostic tests 4. Retrieve Out-of-Reset (OoR) PFDI tests results Query the OoR tests results for a specific core: .. code-block:: console pfdi-cli --result - ````: Core number to retrieve results for Example: .. code-block:: console pfdi-cli --result 0 Expected output: .. code-block:: text CPU0: Out of Reset (OoR) test OK 5. 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. .. code-block:: console pfdi-cli --force_error - ````: Target core number - ````: PFDI function index to inject the error into - ````: Error ID to be injected **Example 1:** .. code-block:: console pfdi-cli --force_error 1 COUNT INVALID_PARAMETERS Expected output: .. code-block:: text CPU1: injected force error to FID=3 with error id =-3 Triggering the simulated error: .. code-block:: text pfdi-cli --count 1 Expected output: .. code-block:: text CPU1: fetching pfdi firmware test count failed: Invalid argument (errno=22) **Example 2:** .. code-block:: console pfdi-cli --force_error 2 RUN ERROR Expected output: .. code-block:: text 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: .. code-block:: text journalctl -u pfdi-app.service You should see a log similar to: .. code-block:: text 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 :pfdi-repo:`README.md`, :pfdi-repo:`libpfdi/README.md` and :pfdi-repo:`pfdi-demo/README.md` for further details on the PFDI project, the PFDI library, and the application. .. _rd_aspen_automated_validation: Automated validation ==================== Run the following to open the configuration menu: .. code-block:: text kas menu sw-ref-stack/Kconfig .. image:: ../images/build_config_automated_validation.* :align: center :alt: 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. .. code-block:: text 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 :ref:`rd-aspen_design_ras`. See :ref:`rd-aspen_design_pc_cpus_ras_tests` for further details on the validation. To run the configuration menu: .. code-block:: text 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``. .. image:: ../images/build_config_cpu_ras.* :align: center :alt: 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: .. code-block:: text 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: .. code-block:: text > 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: .. code-block:: text 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: .. code-block:: text [ 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``. .. _rd-aspen_user_guide_reproduce_arm_systemready_devicetree_validation: 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 :ref:`rd-aspen_design_systemready_devicetree` for more details. .. image:: ../images/build_config_sr_devicetree.* :align: center :alt: Arm Auto Solutions Build Configuration Menu - Arm SystemReady Devicetree Firmware Build | Build ^^^^^ To run the configuration menu: .. code-block:: text 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`` .. _rd-aspen_user_guide_reproduce_sr_devicetree_acs: 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 :ref:`rd-aspen_systemready_devicetree_acs_tests` for more details. Build and automated validation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To run the configuration menu: .. code-block:: text 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: .. code-block:: text 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: .. code-block:: text 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: .. code-block:: text 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: .. code-block:: text 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 :ref:`rd-aspen_systemready_devicetree_acs_tests` for an explanation on how the ACS tests are set up and how they work in the Reference Software Stack. .. _user_guide_reproduce_arm_systemready_devicetree_linux: 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:: :ref:`rd-aspen_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: .. code-block:: text kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy" See :ref:`rd-aspen_design_boot_process_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 :ref:`systemready_devicetree_linux_install` 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-repo:`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: .. code-block:: text kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy" To run the configuration menu: .. code-block:: text 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``. .. image:: ../images/build_config_sr_distro_debian_unattended.* :align: center :alt: 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: .. code-block:: text 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: .. code-block:: text 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. .. code-block:: text sudo shutdown now The below message indicates the shutdown process is complete. .. code-block:: text 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: .. code-block:: text kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy" To run the configuration menu: .. code-block:: text 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``. .. image:: ../images/build_config_sr_distro_debian_manual.* :align: center :alt: Arm Auto Solutions Build Configuration Menu - Debian Linux Distro Installation | Distro installation ~~~~~~~~~~~~~~~~~~~ Run the following command to start the installation: .. code-block:: text 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: .. image:: ../images/sr-devicetree-linux-distro-debian-install-grub-0.* :align: center :alt: 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``. .. image:: ../images/sr-devicetree-linux-distro-debian-install-grub-1.* :align: center :alt: 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). .. image:: ../images/sr-devicetree-linux-distro-debian-install-grub-2.* :align: center :alt: 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: .. code-block:: text chroot /target update-grub cp -v /boot/efi/EFI/debian/grubaa64.efi /boot/efi/EFI/BOOT/bootaa64.efi A snapshot is as below: .. image:: ../images/sr-devicetree-linux-distro-debian-install-grub-3.* :align: center :alt: 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. .. image:: ../images/sr-devicetree-linux-distro-debian-install-grub-4.* :align: center :alt: Second Grub Installation Failure Prompt - Debian Linux Distro Installation | Select ``Continue without boot loader`` in the ``Debian installer main menu`` and continue. .. image:: ../images/sr-devicetree-linux-distro-debian-install-grub-5.* :align: center :alt: Debian Installer Main Menu - Debian Linux Distro Installation | Select ``Yes`` in the ``Update NVRAM variables to boot automatically into Debian`` and continue. .. image:: ../images/sr-devicetree-linux-distro-debian-install-grub-6.* :align: center :alt: 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: .. code-block:: text shutdown now The below message shows that the shutdown process is complete: .. code-block:: text 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-repo:`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: .. code-block:: text kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy" To run the configuration menu: .. code-block:: text 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``. .. image:: ../images/build_config_sr_distro_opensuse_unattended.* :align: center :alt: 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: .. code-block:: text 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: .. code-block:: text 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: .. code-block:: text sudo shutdown now The below message shows that the shutdown process is complete: .. code-block:: text 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: .. code-block:: text kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy" To run the configuration menu: .. code-block:: text 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``. .. image:: ../images/build_config_sr_distro_opensuse_manual.* :align: center :alt: Arm Auto Solutions Build Configuration Menu - openSUSE Linux Distro Installation | Run the following command to start the installation: .. code-block:: text 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: .. image:: ../images/sr-devicetree-linux-distro-opensuse-install-installation.* :align: center :alt: Leap Install Options Menu - openSUSE Linux Distro Installation Select ``No`` when you get to the ``Online Repositories`` screen. .. image:: ../images/sr-devicetree-linux-distro-opensuse-install-online-repo.* :align: center :alt: 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. .. image:: ../images/sr-devicetree-linux-distro-opensuse-install-system-role.* :align: center :alt: 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: .. code-block:: text sudo shutdown now The below message shows that the shutdown process is complete: .. code-block:: text 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-repo:`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: .. code-block:: text kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy" To run the configuration menu: .. code-block:: text 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``. .. image:: ../images/build_config_sr_distro_fedora_unattended.* :align: center :alt: 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: .. code-block:: text 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: .. code-block:: text 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: .. code-block:: text sudo shutdown now The below message shows that the shutdown process is complete: .. code-block:: text 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: .. code-block:: text kas shell -c "bitbake firmware-fvp-rd-aspen -C deploy" To run the configuration menu: .. code-block:: text 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``. .. image:: ../images/build_config_sr_distro_fedora_manual.* :align: center :alt: Arm Auto Solutions Build Configuration Menu - Fedora Linux Distro Installation | Distro installation ~~~~~~~~~~~~~~~~~~~ Run the following command to start the installation: .. code-block:: text 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: .. image:: ../images/sr-devicetree-linux-distro-fedora-install-grub.* :align: center :alt: 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``. .. code-block:: console 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. .. code-block:: console ================================================================================ ================================================================================ 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``. .. code-block:: console ================================================================================ ================================================================================ 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: .. code-block:: console ================================================================================ ================================================================================ 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. .. code-block:: console 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: .. code-block:: text shutdown now The below message shows that the shutdown process is complete: .. code-block:: text reboot: Power down Subsequently running the FVP will boot into Fedora.