SOC Firmware Patching via Non-Volatile Memory Tables
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing System on a Chip (SOC) designs face challenges in modifying firmware code after the boot ROM has been burned, making it difficult to correct bugs, add functionality, or update the code without performing a complete re-tapeout, which is costly and complex.
Innovation Solution
The SOC is configured to include a patch table data structure in non-volatile memory, allowing for patching of firmware code by writing patch code for functional blocks. Upon startup, the processor consults the patch table to determine if a functional block has been patched and executes the corresponding patch code instead of or in addition to the original functional block code.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If firmware code is burned into boot ROM, then reliability and integrity of firmware is improved, but adaptability and ease of modification deteriorates
Solution Approach 1:
The patent segments the firmware into two parts: immutable core firmware burned into boot ROM and modifiable patch code stored in RAM. The boot ROM contains the original firmware that maintains reliability, while RAM stores patch code that can be modified without re-tapeout. The system selectively executes either original or patched code based on patch presence, resolving the contradiction between integrity and modifiability.
Solution Approach 2:
The patent introduces an intermediary mechanism - a patch management system that mediates between the immutable boot ROM firmware and the modifiable patch code in RAM. This intermediary layer allows the system to load, validate, and execute patch code conditionally, enabling firmware modification while preserving the integrity of the original boot ROM firmware.
2Manufacturing precision
If complete re-tapeout is performed to modify firmware, then manufacturing precision is maintained, but productivity and time consumption deteriorates
Solution Approach 1:
The patent performs preliminary actions by pre-burning only the critical core firmware into boot ROM during manufacturing, while allocating RAM space for future patch code. This preliminary setup enables rapid updates without requiring complete re-tapeout, as patches can be loaded into RAM and executed immediately, dramatically improving update productivity while maintaining quality control on the immutable portion.
Solution Approach 2:
The patent introduces dynamics to the traditionally static firmware by making part of the firmware (patch code in RAM) dynamic and changeable after manufacturing. The system can dynamically load, validate, and execute patch code without re-tapeout, transforming the firmware from a fixed to a flexible state, thereby improving update speed and productivity.
3Ease of operation
If function table is used for patching, then ease of operation is improved, but device complexity increases
Solution Approach 1:
The patent extracts the complex function table concept and replaces it with a simpler patch presence detection mechanism. Instead of maintaining a comprehensive function table that maps every function to its patched version, the system simply checks for the presence of patch code in RAM and executes it if found. This extraction of the essential function (patch execution) while removing the complex structure (function table) reduces device complexity while maintaining ease of operation.
Data Source
AI summary
Various examples are directed to a System on a Chip (SOC) and methods of operating the same. The SOC may access firmware code from a boot Read-Only Memory (ROM) of the SOC. The firmware code may comprise a plurality of functional blocks. The SOC may determine that firmware patching is active for the SOC and access patch data from a non-volatile memory of the SOC. The SOC may determine that a first functional block of the firmware code has been patched and access first patch code from the patch data. The first patch code may be associated with the first functional block. The SOC may execute the first patch code.


