SRAM Boot Image Storage for Critical Domain Reboot
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing processing systems face challenges in maintaining the operability of critical domains, such as audio co-processors in vehicles, when the non-critical domain loses power, as they rely on CPU initialization and external ROM for bootstrapping.
Innovation Solution
The system employs a static random-access memory (SRAM) to store a boot image independently of the CPU, allowing the critical domain to reboot autonomously. This involves a secure processor loading the boot image into SRAM, locking it to prevent further writes, and using error correction code (ECC) for error detection and correction.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the system uses CPU initialization and external ROM for bootstrapping, then the processing system can be initialized and operated, but the critical domain cannot reboot independently when the non-critical domain loses power
Solution Approach 1:
The system is divided into critical and non-critical domains with independent power supply. The critical domain includes its own dedicated SRAM bank for storing boot images, separate from the CPU and non-critical domain. This segmentation allows the critical domain to reboot independently without relying on the CPU or external ROM, resolving the contradiction between reliability and device complexity.
Solution Approach 2:
A dedicated SRAM bank serves as an intermediary storage mechanism between the external boot sources and the critical domain processor. This intermediary component enables the critical domain to store and execute boot images independently, eliminating the dependency chain that currently requires CPU initialization and external ROM, thus improving reliability while managing complexity.
2Reliability
If the boot image is stored in SRAM without protection, then the critical domain can reboot independently, but the boot image may be corrupted by write access or errors
Solution Approach 1:
The system performs preliminary validation and locking of the boot image in SRAM before the critical domain needs to reboot. The secure processor validates the boot image and sets a read-only attribute, preventing subsequent write access. This preliminary protective action ensures the boot image remains intact for independent reboot operations while maintaining reliability.
Solution Approach 2:
The system implements periodic scrubbing of the SRAM bank containing the boot image. This feedback mechanism periodically checks and corrects any potential corruption in the boot image, ensuring data integrity is maintained over time. The scrubbing process provides continuous monitoring and correction, preventing information loss while preserving the independent reboot capability.
3Loss of information
If the SRAM bank is made read-only to protect the boot image, then the boot image integrity is maintained, but error correction capability is reduced
Solution Approach 1:
The system changes the memory protection parameter by implementing selective read-only attributes on the SRAM bank. The boot image is marked as read-only to prevent accidental modification, while the system maintains separate error correction mechanisms (such as ECC memory or periodic scrubbing) that can still detect and correct errors. This parameter change preserves integrity while maintaining reliability through complementary error correction approaches.
Data Source
AI summary
A processing system stores a boot image for a critical domain of a system-on-a-chip (SOC) at a bank of a static random-access memory (SRAM) that is shared by the critical domain and a non-critical domain and that is powered independently from the non-critical domain. The SOC includes a secure processor that loads the boot image to the bank of the SRAM and then blocks subsequent write access to the bank. Because the critical domain is powered independently from the non-critical domain, the bank of the SRAM retains the boot image without regard to the power state of the non-critical domain. In addition, the critical domain implements a boot process that is decoupled from a CPU at the non-critical domain, ensuring that the critical domain can initiate a re-boot sequence even if the non-critical domain is not powered.