Safety Boot

Introduction

Safety boot refers to a controlled startup mechanism that ensures the system begins execution from a known-good and verified state.

The Safety Island (SI) is intended to host real-time and safety-critical applications. Functional safety standards such as ISO 26262 mandate verifying that such a system is in a known and defined state before it is used.

Typical verification examples include:

  • LBIST: Logic circuitry built-in self-tests

  • MBIST: Memory built-in self-tests

  • Image-integrity: Detects corrupted boot image due to random failure in the loading process.

Safety Island Boot Architecture

The Safety Island enables secure boot execution through the Runtime Security Engine (RSE).

Two boot modes are supported for the Safety Island:

  • RSE-oriented boot

    RSE executes the complete Safety Island boot sequence.

  • ROM-based boot

    RSE initiates the boot process, after which cluster element CL0 executes the boot sequence using a ROM.

In both boot modes, RSE is responsible for starting the boot process.

Aspen supports RSE-oriented boot.

RSE Safety Considerations

The RSE is not safety-qualified and may exhibit random, systematic or latent hardware failures.

To mitigate some of the failures, the following safety operations are performed during the boot process of SI:

  • Register configuration checks

  • ATU configuration verification

  • Image integrity verification

Scope and Limitations

This design provides reference guidance for implementing Safety Island safety boot mechanisms.

This design does not include formal safety qualification or certification.

Design

LBIST

Logic Built-In Self-Test (LBIST) is a Design-for-Testability (DFT) technique that enables an integrated circuit (IC) to autonomously test its own digital logic without relying on external test equipment. LBIST is widely used in safety-critical systems such as automotive, aerospace, and industrial applications, where periodic self-testing is mandatory to ensure system reliability and functional safety (for example, compliance with ISO 26262).

The Safety Island (SI) provides an interface to a Test Controller responsible for executing the LBIST procedure. The Test Controller initiates and manages LBIST operations to verify the integrity of the Safety Island digital logic.

The test is executed by RSE BL2 before SI CL0 and SI CL1 images are loaded.

Note

The Aspen FVP platform does not implement or integrate a Test Controller.

As a result:

LBIST is not functionally executed on the Aspen FVP. A dummy implementation is provided to maintain software compatibility and interface completeness. The dummy implementation does not perform any actual logic testing and always reports an LBIST execution with the following message in RSE console:

BL2: SI LBIST happens here

MBIST

Memory Built-In Self-Test (MBIST) is a hardware-based self-test mechanism used to verify the integrity of embedded memory blocks during system startup or periodically during runtime.

MBIST is commonly applied to on-chip memories, including:

  • Static Random-Access Memories (SRAMs)

  • Tightly Coupled Memories (TCMs)

  • Cache memories

By exercising predefined test patterns and algorithms, MBIST helps detect stuck-at faults, coupling faults, and address decoder faults, thereby improving system reliability and safety.

The test is executed by RSE BL2 before SI CL0 and SI CL1 images are loaded.

Note

Currently, the Aspen FVP platform does not implement or integrate MBIST controller.

As a result:

MBIST is not functionally executed on the Aspen FVP. A dummy implementation is provided to maintain software compatibility and interface completeness. The dummy implementation does not perform any actual testing of memories and always reports an MBIST execution with the following message in RSE console:

BL2: SI MBIST happens here

Image Integrity

Verifying image integrity after the image has been loaded into RAM is an essential safety measure during boot. Although the image may have been generated correctly and transferred by the Runtime Security Engine (RSE), faults can still be introduced while the image is being copied into memory. For example, transient or random hardware failures on the transfer path or memory interface since RSE is Quality Managed.

Performing an integrity check at this stage helps detect such corruption before execution begins. In other words, the check confirms that the image present in RAM is identical to the image that was intended to be loaded. This provides a mitigation against random hardware failures during the loading operation and prevents the Safety Island from booting from a corrupted software image.

Build-Time Process

  • Calculate the checksum during the post-build stage.

  • Append the calculated checksum to the end of the compiled image binary.

  • This is done using a post-build script within SCP firmware (SI CL0) and Zephyr (SI CL1).

Boot-Time Process

  • After RSE loads the image to RAM and early boot stage of CL0 and CL1 begins.

  • Calculate the software CRC32 of the binary loaded in RAM.

  • Compare the calculated CRC32 with the CRC appended at build/compile time.

  • Halt the boot if the comparison fails.

Because the .data section is part of the RAM image covered by the integrity check, CRC verification must complete before software execution modifies any memory location within that section.

ATU configuration verification

The Safety Island (SI) verifies that the access required for Address Translation Unit (ATU) configuration has been correctly performed in the Root of Security Enclave (RSE). This is a mitigation against any systematic failure in RSE.

  • If an access failure is detected during ATU verification:

    • The boot process is halted immediately.

    • No further execution is allowed to ensure safety.

SCR configuration verification

The Safety Island (SI) verifies that the System Control Register (SCR) configuration matches the expected register values defined for the safety boot sequence. The SCR summary can be found here: System control register.

  • If the configuration does not match the expected value:

    • The boot process is halted immediately.

    • No further execution is allowed to ensure safety.

This verification ensures that the system control settings are in a known and safe state before continuing the boot process.