` to validate networking between the Primary Compute and
the three Safety Island clusters.
Baremetal Architecture
----------------------
Build
^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To build a Baremetal Architecture image:
1. Select ``Safety Island Communication Demo (using HIPC)`` from the
``Use-Case`` menu.
2. Select ``Baremetal`` from the ``Reference Software Stack Architecture``
menu.
3. Select ``Build``.
Automated Validation
^^^^^^^^^^^^^^^^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To run the validation tests:
1. Select ``Safety Island Communication Demo (using HIPC)`` as ``Use-Case``.
2. Select ``Baremetal`` from the ``Reference Software Stack Architecture``
menu.
3. Select ``Run Automated Validation`` from the ``Runtime Validation Setup``
menu.
4. Select ``Build``.
The complete test suite takes around 45 minutes to complete. See
:ref:`validation_hipc_demo` for more details.
The following messages are expected in the output to validate this Use-Case:
.. code-block:: text
RESULTS - test_30_hipc.HIPCTestBase.test_hipc_cluster0: PASSED (223.04s)
RESULTS - test_30_hipc.HIPCTestBase.test_hipc_cluster1: PASSED (351.62s)
RESULTS - test_30_hipc.HIPCTestBase.test_hipc_cluster2: PASSED (426.17s)
RESULTS - test_30_hipc.HIPCTestBase.test_hipc_cluster_cl0_cl1: PASSED (100.46s)
RESULTS - test_30_hipc.HIPCTestBase.test_hipc_cluster_cl0_cl2: PASSED (120.00s)
RESULTS - test_30_hipc.HIPCTestBase.test_hipc_cluster_cl1_cl2: PASSED (161.80s)
RESULTS - test_30_hipc.HIPCTestBase.test_ping_cl0_cl1: PASSED (37.34s)
RESULTS - test_30_hipc.HIPCTestBase.test_ping_cl0_cl2: PASSED (36.80s)
RESULTS - test_30_hipc.HIPCTestBase.test_ping_cl1_cl2: PASSED (37.10s)
RESULTS - test_30_hipc.HIPCTestBase.test_ping_cluster0: PASSED (102.31s)
RESULTS - test_30_hipc.HIPCTestBase.test_ping_cluster1: PASSED (95.50s)
RESULTS - test_30_hipc.HIPCTestBase.test_ping_cluster2: PASSED (92.91s)
RESULTS - test_30_ptp.PTPTest.test_ptp_linux_services: PASSED (4.56s)
RESULTS - test_30_ptp.PTPTest.test_ptp_si_clients: PASSED (34.73s)
.. note::
There is a rare known failure where a timeout might occur during test execution.
Refer to :ref:`releasenotes_knownissues` for possible workarounds.
Virtualization Architecture
---------------------------
Build
^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To build a Virtualization Architecture image:
1. Select ``Safety Island Communication Demo (using HIPC)`` as ``Use-Case``.
2. Select ``Virtualization`` from the ``Reference Software Stack Architecture``
menu.
3. Select ``Build``.
Automated Validation
^^^^^^^^^^^^^^^^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To run the validation tests:
1. Select ``Safety Island Communication Demo (using HIPC)`` as ``Use-Case``.
2. Select ``Virtualization`` from the
``Reference Software Stack Architecture`` menu.
3. Select ``Run Automated Validation`` from the ``Runtime Validation Setup``
menu.
4. Select ``Build``.
The complete test suite takes around 90 minutes to complete. See
:ref:`validation_hipc_demo` for more details.
The following messages are expected in the output to validate this Use-Case:
.. code-block:: text
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_hipc_cluster0: PASSED (311.77s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_hipc_cluster1: PASSED (389.55s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_hipc_cluster2: PASSED (413.83s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_hipc_cluster_cl0_cl1: PASSED (114.97s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_hipc_cluster_cl0_cl2: PASSED (138.32s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_hipc_cluster_cl1_cl2: PASSED (182.33s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_ping_cl0_cl1: PASSED (60.64s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_ping_cl0_cl2: PASSED (61.63s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_ping_cl1_cl2: PASSED (61.06s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_ping_cluster0: PASSED (153.76s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_ping_cluster1: PASSED (154.39s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU1.test_ping_cluster2: PASSED (153.34s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU2.test_hipc_cluster1: PASSED (365.17s)
RESULTS - test_30_hipc_virtualization.HIPCTestDomU2.test_ping_cluster1: PASSED (152.43s)
RESULTS - test_30_ptp_virtualization.PTPTestDom0.test_ptp_linux_services: PASSED (7.17s)
RESULTS - test_30_ptp_virtualization.PTPTestDom0.test_ptp_si_clients: PASSED (50.57s)
RESULTS - test_30_ptp_virtualization.PTPTestDomU1.test_ptp_domu_client: PASSED (47.37s)
RESULTS - test_30_ptp_virtualization.PTPTestDomU1.test_ptp_linux_services: PASSED (7.17s)
RESULTS - test_30_ptp_virtualization.PTPTestDomU2.test_ptp_domu_client: PASSED (50.57s)
RESULTS - test_30_ptp_virtualization.PTPTestDomU2.test_ptp_linux_services: PASSED (47.37s)
.. note::
There is a rare known failure where a timeout might occur during test execution.
Refer to :ref:`releasenotes_knownissues` for possible workarounds.
.. _user_guide_reproduce_parsec_tls:
Parsec-enabled TLS Demo
=======================
The demo can be run on the Baremetal Architecture. It consists of a TLS server
and a TLS client application.
Refer to :ref:`design_applications_parsec_enabled_tls` for more information on
this application. This demo is included as part of the
``Safety Island Actuation Demo``.
Baremetal Architecture
----------------------
Build
^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To build a Baremetal Architecture image:
1. Select ``Safety Island Actuation Demo`` from the ``Use-Case`` menu.
2. Select ``Baremetal`` from the ``Reference Software Stack Architecture`` menu.
3. Select ``Build``.
Run the FVP
^^^^^^^^^^^
To start the FVP and connect to the Primary Compute terminal (running Linux):
.. code-block:: text
kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"
The user should 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 guarantee 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 a TLS server and a TLS client application.
Refer to :ref:`design_applications_parsec_enabled_tls` for more information on
this application.
1. Run ``ssl_server`` from the Primary Compute terminal in the background and
press the ``Enter`` key to continue:
.. code-block:: text
ssl_server &
A message similar to the following should appear:
.. code-block:: text
. Seeding the random number generator... ok
. Loading the server cert. and key... ok
. Bind on https://localhost:4433/ ... ok
. Setting up the SSL data.... ok
. Waiting for a remote connection ...
The TLS client application can take an optional parameter as the TLS server
IP address.
The default value of the parameter is ``localhost``.
2. Run ``ssl_client1`` from the Primary Compute terminal in a container:
.. code-block:: text
docker run --rm -v /run/parsec/parsec.sock:/run/parsec/parsec.sock -v /usr/bin/ssl_client1:/usr/bin/ssl_client1 --network host docker.io/library/ubuntu:22.04 ssl_client1
After a few seconds, a message similar to the following should appear:
.. code-block:: text
Trying to pull docker.io/library/ubuntu:22.04...
Getting image source signatures
Copying blob a186900671ab done |
Copying config 981912c48e done |
Writing manifest to image destination
. Seeding the random number generator... ok
. Loading the CA root certificate ... ok (0 skipped)
. Connecting to tcp/localhost/4433... ok
. Performing the SSL/TLS handshake... ok
. Setting up the SSL/TLS structure... ok
. Performing the SSL/TLS handshake... ok
< Read from client: 18 bytes read
GET / HTTP/1.0
> Write to client: 156 bytes written
HTTP/1.0 200 OK
Content-Type: text/html
Mbed TLS Test Server
Successful connection using: TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256
ok
. Verifying peer X.509 certificate... ok
> Write to server: . Closing the connection... ok
18 bytes written
GET / HTTP/1.0
< Read from server: . Waiting for a remote connection ... 156 bytes read
HTTP/1.0 200 OK
Content-Type: text/html
Mbed TLS Test Server
Successful connection using: TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256
3. Stop the TLS server and synchronize the container image to the
persistent storage:
.. code-block:: text
pkill ssl_server
sync
4. 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 indicate the shutdown process is complete.
.. code-block:: text
[ OK ] Finished System Power Off.
[ OK ] Reached target System Power Off.
reboot: Power down
Automated Validation
^^^^^^^^^^^^^^^^^^^^
For more details about the validation of Parsec demo, refer to
:ref:`validation_parsec_enabled_tls_demo`.
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To run the validation tests:
1. Select ``Safety Island Actuation Demo`` as ``Use-Case``.
2. Select ``Baremetal`` from the ``Reference Software Stack Architecture``
menu.
3. Select ``Run Automated Validation`` from the ``Runtime Validation Setup``
menu.
4. Select ``Build``.
The complete test suite takes around 45 minutes to complete. See
:ref:`validation_parsec_enabled_tls_demo` for more details.
The following messages are expected in the output to validate this Use-Case:
.. code-block:: text
RESULTS - test_40_parsec.ParsecTest.test_parsec_demo: PASSED (479.25s)
.. note::
There is a rare known failure where a timeout might occur during test execution.
Refer to :ref:`releasenotes_knownissues` for possible workarounds.
.. _user_guide_reproduce_pc_psa_ps_crypto_api_test:
Primary Compute PSA Secure Storage and Crypto APIs Architecture Test Suite
==========================================================================
The demo can be run on the Baremetal Architecture.
Refer to :ref:`design_primary_compute_secure_services` for more information on
this application. This demo is included as part of the ``Critical Application
Monitoring Demo``.
Baremetal Architecture
----------------------
Build
^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To build a Baremetal Architecture image:
1. Select ``Critical Application Monitoring Demo`` from the ``Use-Case`` menu.
2. Select ``Baremetal`` from the ``Reference Stack Architecture`` menu.
3. Select ``Build``.
Run the FVP
^^^^^^^^^^^
To start the FVP and connect to the Primary Compute terminal (running Linux):
.. code-block:: text
kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"
The user should 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 guarantee 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.
Refer to :ref:`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 should appear once the tests have
completed:
.. code-block:: text
************ Crypto Suite Report **********
TOTAL TESTS : 59
TOTAL PASSED : 59
TOTAL SIM ERROR : 0
TOTAL FAILED : 0
TOTAL SKIPPED : 0
******************************************
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 should appear once 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 should appear once 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. 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 indicate the shutdown process is complete.
.. code-block:: text
[ OK ] Finished System Power Off.
[ OK ] Reached target System Power Off.
reboot: Power down
Automated Validation
^^^^^^^^^^^^^^^^^^^^
For more details about the validation of PSA Architecture Test Suite, refer to
:ref:`validation_trusted_services_tests`.
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To run the validation tests:
1. Select ``Critical Application Monitoring Demo`` as ``Use-Case``.
2. Select ``Baremetal`` from the ``Reference Stack Architecture`` menu.
3. Select ``Run Automated Validation`` from the ``Runtime Validation Setup``
menu.
4. Select ``Build``.
The complete test suite takes around 40 minutes to complete. See
:ref:`validation_trusted_services_tests` for more details.
The following messages are expected in the output to validate this Use-Case:
.. code-block:: text
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_03_psa_crypto_api_test: PASSED (298.70s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_04_psa_its_api_test: PASSED (17.47s)
RESULTS - test_50_trusted_services.ArmAutoSolutionsTrustedServices.test_05_psa_ps_api_test: PASSED (68.88s)
.. note::
There is a rare known failure where a timeout might occur during test execution.
Refer to :ref:`releasenotes_knownissues` for possible workarounds.
.. _user_guide_reproduce_si_psa_ps_api_test:
Safety Island PSA Secure Storage APIs Architecture Test Suite
=============================================================
The demo can be run on the Baremetal Architecture.
See :ref:`design_applications_psa_arch_tests` for further details.
Baremetal Architecture
----------------------
Build
^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To build a Baremetal Architecture image:
1. Select ``Safety Island PSA Secure Storage APIs Architecture Test Suite``
from the ``Use-Case`` menu.
2. Select ``Build``.
Run the FVP
^^^^^^^^^^^
To start the FVP:
.. code-block:: text
kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"
The Safety Island Cluster 2 terminal running the ``PSA Secure Storage APIs
Architecture Test Suite`` is available via the tmux window titled
``terminal_uart_si_cluster2``.
The Safety Island Cluster 2 tmux window can be accessed by typing ``Ctrl-b w``,
using the arrow keys to select ``terminal_uart_si_cluster2`` then pressing the
``Enter`` key.
Run the Demo
^^^^^^^^^^^^
The tests will automatically run. A log similar to the following should be
visible; it is normal for some tests to be skipped but there should be no
failed tests:
.. code-block:: text
***** PSA Architecture Test Suite - Version 1.4 *****
Running.. Storage Suite
******************************************
TEST: 401 | DESCRIPTION: UID not found check | UT: STORAGE
[Info] Executing tests from non-secure
[Info] Executing ITS Tests
[Check 1] Call get API for UID 6 which is not set
[Check 2] Call get_info API for UID 6 which is not set
[Check 3] Call remove API for UID 6 which is not set
[Check 4] Call get API for UID 6 which is removed
[Check 5] Call get_info API for UID 6 which is removed
[Check 6] Call remove API for UID 6 which is removed
Set storage for UID 6
[Check 7] Call get API for different UID 5
[Check 8] Call get_info API for different UID 5
[Check 9] Call remove API for different UID 5
[Info] Executing PS Tests
[Check 1] Call get API for UID 6 which is not set
[Check 2] Call get_info API for UID 6 which is not set
[Check 3] Call remove API for UID 6 which is not set
[Check 4] Call get API for UID 6 which is removed
[Check 5] Call get_info API for UID 6 which is removed
[Check 6] Call remove API for UID 6 which is removed
Set storage for UID 6
[Check 7] Call get API for different UID 5
[Check 8] Call get_info API for different UID 5
[Check 9] Call remove API for different UID 5
TEST RESULT: PASSED
******************************************
************ Storage Suite Report **********
TOTAL TESTS : 17
TOTAL PASSED : 11
TOTAL SIM ERROR : 0
TOTAL FAILED : 0
TOTAL SKIPPED : 6
******************************************
.. note::
This use-case does not require waiting for the Primary Compute to boot.
To shut down the FVP and terminate the emulation, select the terminal titled as
``python3`` where the ``runfvp`` was launched by pressing ``Ctrl-b 0`` and press
``Ctrl-c`` to stop the FVP process.
Automated Validation
^^^^^^^^^^^^^^^^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To run the validation tests:
1. Select ``Safety Island PSA Secure Storage APIs Architecture Test Suite``
from the ``Use-Case`` menu.
2. Select ``Run Automated Validation`` from the ``Runtime Validation Setup``
menu.
3. Select ``Build``.
The complete test suite takes around 15 minutes to complete. See
:ref:`validation_si_psa_arch_tests` for more details.
The following message is expected in the output to validate this Use-Case:
.. code-block:: text
RESULTS - test_10_si_psa_arch_tests.SIPSAArchTests.test_psa_si_cluster2: PASSED (0.00s)
.. note::
There is a rare known failure where a timeout might occur during test execution.
Refer to :ref:`releasenotes_knownissues` for possible workarounds.
.. _user_guide_reproduce_si_psa_crypto_api_test:
Safety Island PSA Crypto APIs Architecture Test Suite
=====================================================
The demo can be run on the Baremetal Architecture.
See :ref:`design_applications_psa_arch_tests` for further details.
Baremetal Architecture
----------------------
Build
^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To build a Baremetal Architecture image:
1. Select ``Safety Island PSA Crypto APIs Architecture Test Suite``
from the ``Use-Case`` menu.
2. Select ``Build``.
Run the FVP
^^^^^^^^^^^
To start the FVP:
.. code-block:: text
kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"
The ``PSA Crypto APIs Architecture Test Suite`` is deployed on all the 3 Safety
Island (SI) Clusters. The test results can be seen on the following tmux
windows:
* ``terminal_uart_si_cluster0``
* ``terminal_uart_si_cluster1``
* ``terminal_uart_si_cluster2``
The user can navigate through the windows mentioned above by pressing
``Ctrl-b w`` and arrow keys followed by the ``Enter`` key.
Run the tests
^^^^^^^^^^^^^
The tests will automatically run after the FVP is started. The complete test
suite takes around 5 minutes to complete.
When the tests finish, a log similar to the following should be visible.
Normally no failure should be seen::
************ Crypto Suite Report **********
TOTAL TESTS : 61
TOTAL PASSED : 61
TOTAL SIM ERROR : 0
TOTAL FAILED : 0
TOTAL SKIPPED : 0
******************************************
.. note::
This use-case does not require waiting for the Primary Compute to boot.
To shut down the FVP and terminate the emulation, select the terminal titled as
``python3`` where the ``runfvp`` was launched by pressing ``Ctrl-b 0`` and press
``Ctrl-c`` to stop the FVP process.
Automated Validation
^^^^^^^^^^^^^^^^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To run the validation tests:
1. Select ``Safety Island PSA Crypto APIs Architecture Test Suite`` from the
``Use-Case`` menu.
2. Select ``Run Automated Validation`` from the ``Runtime Validation Setup``
menu.
3. Select ``Build``.
The complete test suite takes around 35 minutes to complete. See
:ref:`validation_si_psa_arch_tests` for more details.
The following messages are expected in the output to validate this Use-Case:
.. code-block:: text
RESULTS - test_10_si_psa_arch_tests.SIPSAArchTests.test_psa_si_cluster0: PASSED (0.01s)
RESULTS - test_10_si_psa_arch_tests.SIPSAArchTests.test_psa_si_cluster1: PASSED (0.01s)
RESULTS - test_10_si_psa_arch_tests.SIPSAArchTests.test_psa_si_cluster2: PASSED (0.01s)
.. note::
There is a rare known failure where a timeout might occur during test execution.
:ref:`releasenotes_knownissues` for possible workarounds.
.. _user_guide_reproduce_fault_management:
Fault Management Demo
=====================
The demo uses the Safety Island Cluster 1 console and it can be run on the
Baremetal Architecture of the Safety Island Actuation Demo.
Refer to :ref:`design_applications_fault_mgmt` for further details.
Baremetal Architecture
----------------------
Build
^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To build the Baremetal Architecture image:
1. Select ``Safety Island Actuation Demo`` from the ``Use-Case`` menu.
2. Select ``Baremetal`` from the ``Reference Software Stack Architecture`` menu.
3. Select ``Build``.
Run the FVP
^^^^^^^^^^^
To start the FVP:
.. code-block:: text
kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"
The Fault Management subsystem is deployed on Safety Island Cluster 1 so the
instructions below should be executed on its terminal.
The Safety Island Cluster 1 tmux window can be accessed by typing ``Ctrl-b w``,
using the arrow keys to select ``terminal_uart_si_cluster1`` then pressing the
``Enter`` key.
Run the Demo
^^^^^^^^^^^^
The instructions below demonstrate injecting faults into both the System FMU
and GIC-720AE FMU and how this affects the SSU safety state.
1. Start by enumerating the configured fault device tree:
.. code-block:: text
fault tree
The output shows the root fault device ``fmu@2a510000`` (the System FMU),
after which are the attached safety state device ``ssu@2a500000``, the
fault device ``fmu@2a570000`` (the Primary Compute GIC-720AE FMU) and the
fault device ``fmu@2a530000`` (the Safety Island GIC-720AE FMU):
.. code-block:: text
Root 0: fmu@2a510000
Safety: ssu@2a500000
Slot 0: fmu@2a570000
Slot 1: fmu@2a530000
2. After booting, query the initial state of the SSU:
.. code-block:: text
fault safety_status ssu@2a500000
The initial state is TEST:
.. code-block:: text
Status: TEST (0x0)
3. It is expected that a Fault Management deployment would perform a self-test
after boot then signal its outcome to the SSU. For demonstration purposes,
simulate a successful self-test completion by issuing the
``compl_ok`` signal to the SSU:
.. code-block:: text
fault safety_control ssu@2a500000 compl_ok
The system is now ``SAFE`` for operation:
.. code-block:: text
Signal: compl_ok (0x0)
State: SAFE (0x3)
4. Simulate an internal *Lockstep error* (``0x4``) in the System FMU:
.. code-block:: text
fault inject fmu@2a510000 0x4
Three events are logged:
* The subsystem reports that it received the fault and that it was
non-critical (all System FMU internal faults are non-critical).
* The safety component reports that this caused the SSU to enter the
``ERRN`` state.
* The storage component reports that the total historical fault count for
this fault on this device is now ``1``.
.. code-block:: text
Injecting fault 0x4 to device fmu@2a510000
[00:04:49.110,000] fault_mgmt: Fault received (non-critical): 0x4 on fmu@2a510000
[00:04:49.110,000] fault_mgmt_safety: Safety status: ERRN (0x5) on ssu@2a500000
[00:04:49.160,000] fault_mgmt_protected_storage: Fault count for 0x4 on fmu@2a510000: 1
5. The SSU will remain in the ``ERRN`` state until signaled (unless a critical
fault occurs). Send a ``compl_ok`` signal again to recover from this fault:
.. code-block:: text
fault safety_control ssu@2a500000 compl_ok
The SSU is now in the ``SAFE`` state again:
.. code-block:: text
Signal: compl_ok (0x0)
State: SAFE (0x3)
6. Next, inject an *SPI collator external error* (``0x20000a00``) into the
GIC-720AE FMU:
.. code-block:: text
fault inject fmu@2a570000 0x20000a00
This results in a similar output to above, except that the received fault
was critical and the safety status is now ``ERRC``. (GIC-720AE FMU faults
are critical by default, but this can be changed from the shell using the
``fault set_critical`` sub-command).
.. code-block:: text
Injecting fault 0x20000a00 to device fmu@2a570000
[00:09:13.210,000] fault_mgmt: Fault received (critical): 0x20000a00 on fmu@2a570000
[00:09:13.210,000] fault_mgmt_safety: Safety status: ERRC (0x6) on ssu@2a500000
[00:09:13.270,000] fault_mgmt_protected_storage: Fault count for 0x20000a00 on fmu@2a570000: 1
7. The number of occurrences of each fault is tracked per device by the
storage component. Inject another *Lockstep error* into the System FMU:
.. code-block:: text
fault inject fmu@2a510000 0x4
The fault count is now ``2``. Note that the safety status is still
``ERRC``.
.. code-block:: text
Injecting fault 0x4 to device fmu@2a510000
[00:14:02.800,000] fault_mgmt: Fault received (non-critical): 0x4 on fmu@2a510000
[00:14:02.800,000] fault_mgmt_safety: Safety status: ERRC (0x6) on ssu@2a500000
[00:14:02.860,000] fault_mgmt_protected_storage: Fault count for 0x4 on fmu@2a510000: 2
The full list of stored faults can also be queried:
.. code-block:: text
fault list
This shows all the faults injected into both FMUs above:
.. code-block:: text
Fault history:
Fault received (non-critical): 0x4 on fmu@2a510000 : count 2
Fault received (critical): 0x20000a00 on fmu@2a570000 : count 1
8. The ``ERRC`` represents a critical system failure and cannot be recovered
by the software - confirm this by trying to issue ``compl_ok`` again:
.. code-block:: text
fault safety_control ssu@2a500000 compl_ok
The SSU status is still ``ERRC``:
.. code-block:: text
Signal: compl_ok (0x0)
State: ERRC (0x6)
The state can now only be affected through a full system reset (e.g. by
stopping and starting the FVP), after which the state will be ``TEST``
once again.
.. note::
This use-case does not require waiting for the Primary Compute to boot.
9. To shut down the FVP and terminate the emulation, select the terminal titled
as ``python3`` where the ``runfvp`` was launched by pressing ``Ctrl-b 0``
and press ``Ctrl-c`` to stop the FVP process.
See the :ref:`design_applications_fault_mgmt_shell_reference` for more details
about these and other Fault Management shell sub-commands.
Automated Validation
^^^^^^^^^^^^^^^^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To run the validation tests:
1. Select ``Safety Island Actuation Demo`` as ``Use-Case``.
2. Select ``Baremetal`` from the ``Reference Software Stack Architecture``
menu.
3. Select ``Run Automated Validation`` from the ``Runtime Validation Setup``
menu.
4. Select ``Build``.
The complete test suite takes around 45 minutes to complete. See
:ref:`validation_fault_management` for more details.
The following messages are expected in the output to validate this Use-Case:
.. code-block:: text
RESULTS - test_10_fault_mgmt.FaultMgmtSSUTest.test_gic_fmu_ssu_compl_ok: PASSED (96.24s)
RESULTS - test_10_fault_mgmt.FaultMgmtSSUTest.test_ssu_ce_not_ok: PASSED (38.18s)
RESULTS - test_10_fault_mgmt.FaultMgmtSSUTest.test_ssu_nce_ok: PASSED (29.24s)
RESULTS - test_10_fault_mgmt.FaultMgmtTest.test_fmu_fault_clear: PASSED (11.24s)
RESULTS - test_10_fault_mgmt.FaultMgmtTest.test_fmu_fault_count: PASSED (6.04s)
RESULTS - test_10_fault_mgmt.FaultMgmtTest.test_fmu_fault_list: PASSED (36.22s)
RESULTS - test_10_fault_mgmt.FaultMgmtTest.test_fmu_fault_summary: PASSED (22.64s)
RESULTS - test_10_fault_mgmt.FaultMgmtTest.test_gic_fmu_inject: PASSED (18.69s)
RESULTS - test_10_fault_mgmt.FaultMgmtTest.test_system_fmu_internal_inject: PASSED (8.77s)
RESULTS - test_10_fault_mgmt.FaultMgmtTest.test_system_fmu_internal_set_enabled: PASSED (11.09s)
RESULTS - test_10_fault_mgmt.FaultMgmtTest.test_tree: PASSED (0.71s)
.. note::
There is a rare known failure where a timeout might occur during test execution.
Refer to :ref:`releasenotes_knownissues` for possible workarounds.
.. _user_guide_reproduce_arm_systemready_ir_validation:
Arm SystemReady IR Validation
=============================
Arm SystemReady IR Firmware Build
---------------------------------
The Arm SystemReady IR Firmware Build option just builds the
Arm SystemReady IR-aligned firmware.
Refer to :ref:`design_systemready_ir` for more details.
.. image:: ../images/build_config_sr_ir.*
:align: center
:alt: Arm Auto Solutions Build Configuration Menu - Arm SystemReady IR Firmware Build
|
Build
^^^^^
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To build the Arm SystemReady IR-aligned firmware image:
1. Select ``Arm SystemReady IR Firmware Build`` under
``Arm SystemReady IR Validation`` from the ``Use-Case`` menu.
2. Select ``Build``.
The firmware images listed below can be found in the directory
``build/tmp_systemready-glibc/deploy/images/fvp-rd-kronos/``.
* ``ap-flash-image.img``
* ``encrypted_cm_provisioning_bundle_0.bin``
* ``encrypted_dm_provisioning_bundle.bin``
* ``rse-flash-image.img``
* ``rse-nvm-image.img``
* ``rse-rom-image.img``
.. _user_guide_reproduce_sr_ir_acs:
Arm SystemReady IR Architecture Compliance Suite (ACS) Tests
------------------------------------------------------------
The ACS for the Arm SystemReady IR certification is delivered through a
live OS image, which enables the basic automation to run the tests.
The system will boot with the ACS live OS image and the ACS tests will run
automatically after the system boots. See :ref:`systemready_ir_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 IR ACS tests:
1. Select ``Arm SystemReady IR Architecture Compliance Suite (ACS) Tests`` under
``Arm SystemReady IR Validation`` from the ``Use-Case`` menu.
2. Select ``Build``.
A similar output to the following is printed out:
.. code-block:: text
NOTE: recipe arm-systemready-ir-acs-2.1.0-r0: task do_testimage: Started
Creating terminal default on terminal_ns_uart0
Creating terminal tf-a on terminal_sec_uart
Creating terminal scp on terminal_uart_scp
Creating terminal rse on terminal_rse_uart
Creating terminal safety_island_c0 on terminal_uart_si_cluster0
Creating terminal safety_island_c1 on terminal_uart_si_cluster1
Creating terminal safety_island_c2 on terminal_uart_si_cluster2
ACS SIE + bbr/bsa running
Test Group (VariableAttributes): PASSED
Test Group (VariableUpdates): FAILED
Test Group (AuthVar_Conf): FAILED
Test Group (AuthVar_Func): FAILED
Test Group (BBSRVariableSizeTest_func): FAILED
Test Group (ImageLoading): FAILED
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
Test Group (RestoreTPL_Func): PASSED
Test Group (SetTimer_Conf): PASSED
Test Group (SetTimer_Func): PASSED
Test Group (SignalEvent_Func): PASSED
Test Group (WaitForEvent_Conf): PASSED
Test Group (WaitForEvent_Func): PASSED
Test Group (AllocatePages_Conf): PASSED
Test Group (AllocatePages_Func): PASSED
Test Group (AllocatePool_Conf): PASSED
Test Group (AllocatePool_Func): PASSED
Test Group (FreePages_Conf): PASSED
Test Group (FreePages_Func): PASSED
Test Group (GetMemoryMap_Conf): PASSED
Test Group (GetMemoryMap_Func): PASSED
...
...
Capsule update test succeeded
Transitioned to off
RESULTS:
RESULTS - arm_systemready_ir_acs.SystemReadyACSTest.test_acs: PASSED (17074.54s)
RESULTS - arm_systemready_ir_acs_capsule_update.SystemReadyACSCapsuleUpdateTest.test_capsule_update: PASSED (229.49s)
RESULTS - arm_systemready_ir_acs_shutdown.SystemReadyACSShutdownTest.test_shutdown: PASSED (15.17s)
SUMMARY:
arm-systemready-ir-acs () - Ran 3 tests in 17327.711s
arm-systemready-ir-acs - OK - All required tests passed (successes=3, skipped=0, failures=0, errors=0)
As seen in the above logs, some Test Groups are expected to fail. The following
messages are expected to validate this Use-Case:
.. code-block:: text
RESULTS - arm_systemready_ir_acs.SystemReadyACSTest.test_acs: PASSED (17074.54s)
RESULTS - arm_systemready_ir_acs_capsule_update.SystemReadyACSCapsuleUpdateTest.test_capsule_update: PASSED (229.49s)
RESULTS - arm_systemready_ir_acs_shutdown.SystemReadyACSShutdownTest.test_shutdown: PASSED (15.17s)
.. 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-kronos -C deploy"
kas shell -c "bitbake arm-systemready-ir-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-ir-acs -C unpack"
.. note::
There is a rare known failure where a timeout might occur during test execution.
Refer to :ref:`releasenotes_knownissues` for possible workarounds.
Refer to :ref:`systemready_ir_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_ir_linux:
Linux Distribution Installation (Debian, openSUSE and Fedora)
=============================================================
The Arm SystemReady IR-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:`systemready_ir_acs_tests` runs the SIE tests, which enrolls 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-kronos -C deploy"
Refer to :ref:`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 or confirmations,
entering the user and password, etc.
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.
Refer to :ref:`systemready_ir_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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not supported in the current release.
Distro Manual Installation
^^^^^^^^^^^^^^^^^^^^^^^^^^
To install Debian, you can refer to 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-kronos -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 ``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.*
: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
install process begins when you see the following:
.. image:: ../images/sr-ir-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-ir-linux-distro-debian-install-grub-1.*
:align: center
:alt: Grub Installation Prompt - Debian Linux Distro Installation
|
There will be 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-ir-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-ir-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-ir-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-ir-linux-distro-debian-install-grub-5.*
:align: center
:alt: Debian Installer Main Menu - 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 indicates 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 (:repo:`yocto/kas/\
patches/meta-arm-systemready/\
0001-arm-systemready-linux-distros-Implement-unattended-o.patch`)
Distro Installation
~~~~~~~~~~~~~~~~~~~
The firmware flash images need to be recreated with the following command:
.. code-block:: text
kas shell -c "bitbake firmware-fvp-rd-kronos -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 ``openSUSE 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_opensuse_unattended.*
:align: center
:alt: Arm Auto Solutions Build Configuration Menu - openSUSE Linux Distro Installation
|
A similar output to the following indicates when the installation is finished, which will take
around 12 hours:
.. 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 off
RESULTS:
RESULTS - arm_systemready_opensuse_unattended.SystemReadyOpenSUSEUnattendedTest.test_opensuse_unattended: PASSED (24367.99s)
SUMMARY:
arm-systemready-linux-distros-opensuse () - Ran 1 test in 24367.997s
* 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 openSUSE.
Distro Manual Installation
^^^^^^^^^^^^^^^^^^^^^^^^^^
To install openSUSE, you can refer to 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-kronos -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 ``openSUSE Linux Distro Installation`` under
``Linux Distribution Installation (Debian, openSUSE and Fedora)`` from the
``Use-Case`` menu.
2. Unselect ``Run Unattended Installation`` under
``Distros Unattended Installation Setup`` menu.
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-ir-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-ir-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-ir-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
Once 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 indicates 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/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-kronos -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 ``Fedora 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_fedora_unattended.*
:align: center
:alt: Arm Auto Solutions Build Configuration Menu - Fedora Linux Distro Installation
|
A similar output to the following indicates when the installation is finished, which will take
around 12 hours:
.. code-block:: text
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 off
RESULTS:
RESULTS - arm_systemready_fedora_unattended.SystemReadyFedoraUnattendedTest.test_fedora_unattended: PASSED (38743.47s)
SUMMARY:
arm-systemready-linux-distros-fedora () - Ran 1 test in 38743.478s
* 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 Fedora.
Distro Manual Installation
^^^^^^^^^^^^^^^^^^^^^^^^^^
To install Fedora, you can refer to 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-kronos -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 ``Fedora Linux Distro Installation`` under
``Linux Distribution Installation (Debian, openSUSE and Fedora)``
from the ``Use-Case`` menu.
2. Unselect ``Run Unattended Installation`` under
``Distros Unattended Installation Setup`` menu.
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
install process begins when you see the following:
.. image:: ../images/sr-ir-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. Once 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 indicates 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 should now 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.
Once you see the message ``Installation complete. Press ENTER to quit:``,
you need to 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 indicates the shutdown process is complete.
.. code-block:: text
reboot: Power down
Subsequently running the FVP will boot into Fedora.
.. _user_guide_reproduce_secure_firmware_update:
Secure Firmware Update
======================
The firmware update is on-disk to meet Arm SystemReady IR requirements.
Baremetal Architecture
----------------------
Build
^^^^^
The firmware update capsule for testing will be generated together with
the image for the software stack when building. The firmware capsule is placed
on a removable storage device (in the case of Arm FVPs, an MMC card
implementation).
Run this step to ensure the creation of the initial firmware flash images:
.. code-block:: text
kas shell -c "bitbake firmware-fvp-rd-kronos -C deploy"
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To build a Baremetal Architecture image:
1. Select ``Critical Application Monitoring Demo`` from the ``Use-Case`` menu.
2. Select ``Baremetal`` from the ``Reference Software Stack Architecture`` menu.
3. Select ``Build``.
Run the FVP
^^^^^^^^^^^
To start the FVP and connect to the Primary Compute terminal (running Linux):
.. code-block:: text
kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"
Note that the main tmux windows involved in the Secure Firmware Update are
``terminal_ns_uart0`` and ``terminal_rse_uart``. For ease of navigation, it is
recommended to join these in a single window with two panes.
Follow the steps below to achieve the same:
1. 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.
2. Press ``Ctrl-b :`` and then type ``join-pane -s :terminal_rse_uart -h``
followed by pressing the ``Enter`` key to join the RSE terminal window to
the Primary Compute terminal window.
Refer to the following image of the tmux panes rearrangement. Panes can
be navigated using ``Ctrl-b`` followed by the arrow keys.
.. image:: ../images/secure_firmware_update_baremetal_fvp.*
:align: center
:alt: Arm Auto Solutions Secure Firmware Update Baremetal FVP Windows
|
The user should 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. Run the below
command to guarantee 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
^^^^^^^^^^^^
1. To start the Secure Firmware Update, run the following commands to create
the UpdateCapsule directory and copy the update capsule into it, followed by
a reboot.
.. code-block:: text
mount /dev/vda1 /boot
mount /dev/mmcblk0p1 /mnt
mkdir -p /boot/EFI/UpdateCapsule
cp -f /mnt/fw.cap /boot/EFI/UpdateCapsule
reboot
The system will begin the firmware update automatically. The following logs
indicate that the upgrade process has started and is in progress.
In ``terminal_ns_uart0``:
.. code-block:: text
FF-A driver 1.0
FF-A framework 1.0
FF-A versions are compatible
EFI: MM partition ID 0x8003
EFI: FVP: Capsule shared buffer at 0x81000000 , size 8192 pages
In ``terminal_rse_uart``:
.. code-block:: text
[INF]:[FWU]: get_fwu_agent_state: enter, boot_index = 0
[INF]:[FWU]: get_fwu_agent_state: enter, boot_index = 0
[INF]:[FWU]: FMP image update: image id = 1
[INF]:[FWU]: FMP image update: status = 0, version=7, last_attempt_version=0.
[INF]: [FWU]: Host acknowledged.
[INF]:[FWU]: pack_image_info:207 ImageInfo size = 105, ImageName size = 14, ImageVersionName size = 14
[INF]: [FWU]: Getting image info succeeded.
[INF]:[FWU]: get_fwu_agent_state: enter, boot_index = 0
[INF]:[FWU]: uefi_capsule_retrieve_images: enter, capsule ptr = 0x0x65000000
[INF]:[FWU]: uefi_capsule_retrieve_images: capsule size = 18284656, image count = 1
[INF]:[FWU]: uefi_capsule_retrieve_images: image 0, version = 3
[INF]:[FWU]: uefi_capsule_retrieve_images: image 0 at 0x65000070, size=18284560
[INF]:[FWU]: flash_rss_capsule: enter: image = 0x65000070, size = 16187408, version = 3
[INF]:[FWU]: erase_bank: erasing sectors = 4080, from offset = 16748544
[INF]:[FWU]: flash_rss_capsule: writing capsule to the flash at offset = 16748544...
.. note::
This step will take about 10 minutes.
2. The system will reset after a successful firmware update and boot with the
updated firmware. This can be confirmed by checking the terminal logs; if
there are lines in the log like below, then the upgrade was successful and
the system has successfully rebooted with the updated firmware.
In ``terminal_rse_uart``:
.. code-block:: text
[INF]: [FWU]: Flashing the image succeeded.
[INF]: [FWU]: Performing system reset...
...
...
[INF]:[FWU]: get_fwu_agent_state: enter, boot_index = 1
.. note::
The following error messages will appear in the logs:
.. code-block:: text
[ERR]:[FWU]: flash_rss_capsule: version error
...
[ERR]:[FWU]: flash_fip_capsule: version error
...
...
[ERR]: [FWU]: Flashing the image Failed.
These errors are expected. As long as you scroll upwards and see
the aforementioned lines then the update was successful.
3. The system will eventually boot into Linux using the upgraded firmware.
4. To shut down the FVP and terminate the emulation automatically, follow the
below steps:
* Issue the following command on the Primary Compute terminal.
.. code-block:: text
shutdown now
The below messages indicate the shutdown process is complete.
.. code-block:: text
[ OK ] Finished System Power Off.
[ OK ] Reached target System Power Off.
reboot: Power down
* Close the tmux pane started for the build host machine by pressing
``Ctrl-d``.
Automated Validation
^^^^^^^^^^^^^^^^^^^^
Run this step to ensure the creation of the initial firmware flash images:
.. code-block:: text
kas shell -c "bitbake firmware-fvp-rd-kronos -C deploy"
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To run the validation tests:
1. Select ``Critical Application Monitoring Demo`` as ``Use-Case``.
2. Select ``Baremetal`` from the ``Reference Software Stack Architecture``
menu.
3. Select ``Run Automated Validation`` from the ``Runtime Validation Setup``
menu.
4. Select ``Build``.
The following messages are expected in the output to validate this Use-Case:
.. code-block:: text
RESULTS - test_00_fwu.SecureFirmwareUpdateTest.test_securefirmwareupdate: PASSED (414.85s)
.. note::
There is a rare known failure where a timeout might occur during test execution.
Refer to :ref:`releasenotes_knownissues` for possible workarounds.
See :ref:`validation_secure_firmware_update` for more details.
Virtualization Architecture
---------------------------
Build
^^^^^
The firmware update capsule for testing will be generated together with
the image for the software stack when building. The firmware capsule is placed
on a removable storage device (in the case of Arm FVPs, an MMC card
implementation).
Run this step to ensure the creation of the initial firmware flash images:
.. code-block:: text
kas shell -c "bitbake firmware-fvp-rd-kronos -C deploy"
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To build a Virtualization Architecture image:
1. Select ``Critical Application Monitoring Demo`` from the ``Use-Case`` menu.
2. Select ``Virtualization`` from the ``Reference Software Stack Architecture``
menu.
3. Select ``Build``.
Run the FVP
^^^^^^^^^^^
To start the FVP and connect to the Primary Compute terminal (running Linux):
.. code-block:: text
kas shell -c "../layers/meta-arm/scripts/runfvp -t tmux --verbose"
Note that the main tmux windows involved in the Secure Firmware Update are
``terminal_ns_uart0`` and ``terminal_rse_uart``. For ease of navigation, it is
recommended to join these in a single window with two panes.
Follow the steps below to achieve the same:
1. 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.
2. Press ``Ctrl-b :`` and then type ``join-pane -s :terminal_rse_uart -h``
followed by pressing the ``Enter`` key to join the RSE terminal window to
the Primary Compute terminal window.
Refer to the following image of the tmux panes rearrangement. Panes can
be navigated using ``Ctrl-b`` followed by the arrow keys.
.. image:: ../images/secure_firmware_update_virtualization_fvp.*
:align: center
:alt: Arm Auto Solutions Secure Firmware Update Virtualization FVP Windows
|
The user should 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. Run the below
command to guarantee 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
^^^^^^^^^^^^
1. To start the Secure Firmware Update, run the following commands to create
the UpdateCapsule directory and copy the update capsule into it, followed by
a reboot.
.. code-block:: text
mount /dev/vda1 /boot
mount /dev/mmcblk0p1 /mnt
mkdir -p /boot/EFI/UpdateCapsule
cp -f /mnt/fw.cap /boot/EFI/UpdateCapsule
reboot
The system will begin the firmware update automatically. The following logs
indicate that the upgrade process has started and is in progress.
In ``terminal_ns_uart0``:
.. code-block:: text
FF-A driver 1.0
FF-A framework 1.0
FF-A versions are compatible
EFI: MM partition ID 0x8003
EFI: FVP: Capsule shared buffer at 0x81000000 , size 8192 pages
In ``terminal_rse_uart``:
.. code-block:: text
[INF]:[FWU]: get_fwu_agent_state: enter, boot_index = 0
[INF]:[FWU]: get_fwu_agent_state: enter, boot_index = 0
[INF]:[FWU]: FMP image update: image id = 1
[INF]:[FWU]: FMP image update: status = 0, version=0, last_attempt_version=0.
[INF]: [FWU]: Host acknowledged.
[INF]:[FWU]: pack_image_info:207 ImageInfo size = 105, ImageName size = 14, ImageVersionName size = 14
[INF]: [FWU]: Getting image info succeeded.
[INF]:[FWU]: get_fwu_agent_state: enter, boot_index = 0
[INF]:[FWU]: uefi_capsule_retrieve_images: enter, capsule ptr = 0x0x65000000
[INF]:[FWU]: uefi_capsule_retrieve_images: capsule size = 18219116, image count = 1
[INF]:[FWU]: uefi_capsule_retrieve_images: image 0, version = 3
[INF]:[FWU]: uefi_capsule_retrieve_images: image 0 at 0x6500006c, size=18219024
[INF]:[FWU]: flash_rss_capsule: enter: image = 0x6500006c, size = 16121872, version = 3
[INF]:[FWU]: erase_bank: erasing sectors = 4080, from offset = 16748544
[INF]:[FWU]: flash_rss_capsule: writing capsule to the flash at offset = 16748544...
.. note::
This step will take about 10 minutes.
2. The system will reset after a successful firmware update and boot with the
updated firmware. This can be confirmed by checking the terminal logs; if
there are lines in the log like below, then the upgrade was successful and
the system has successfully rebooted with the updated firmware.
In ``terminal_rse_uart``:
.. code-block:: text
[INF]: [FWU]: Flashing the image succeeded.
[INF]: [FWU]: Performing system reset...
...
...
[INF]:[FWU]: get_fwu_agent_state: enter, boot_index = 1
.. note::
The following error messages will appear in the logs:
.. code-block:: text
[ERR]:[FWU]: flash_rss_capsule: version error
...
[ERR]:[FWU]: flash_fip_capsule: version error
...
...
[ERR]: [FWU]: Flashing the image Failed.
These errors are expected. As long as you scroll upwards and see
the aforementioned lines then the update was successful.
3. The system will eventually boot into Linux using the upgraded firmware.
4. To shut down the FVP and terminate the emulation automatically, follow the
below steps:
* Issue the following command on the Primary Compute terminal.
.. code-block:: text
shutdown now
The below messages indicate the shutdown process is complete.
.. code-block:: text
[ OK ] Finished System Power Off.
[ OK ] Reached target System Power Off.
reboot: Power down
* Close the tmux pane started for the build host machine by pressing
``Ctrl-d``.
Automated Validation
^^^^^^^^^^^^^^^^^^^^
Run this step to ensure the creation of the initial firmware flash images:
.. code-block:: text
kas shell -c "bitbake firmware-fvp-rd-kronos -C deploy"
To run the configuration menu:
.. code-block:: text
kas menu sw-ref-stack/Kconfig
To run the validation tests:
1. Select ``Critical Application Monitoring Demo`` as ``Use-Case``.
2. Select ``Virtualization`` from the ``Reference Software Stack Architecture``
menu.
3. Select ``Run Automated Validation`` from the ``Runtime Validation Setup``
menu.
4. Select ``Build``.
The following messages are expected in the output to validate this Use-Case:
.. code-block:: text
RESULTS - test_00_fwu.SecureFirmwareUpdateTest.test_securefirmwareupdate: PASSED (414.85s)
.. note::
There is a rare known failure where a timeout might occur during test execution.
Refer to :ref:`releasenotes_knownissues` for possible workarounds.
See :ref:`validation_secure_firmware_update` for more details.