SOC Firmware Patching via Non-Volatile Memory Tables

Resolve Bottlenecks,
Find Innovative Solutions
Generate 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

VSEngineering 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

Engineering Contradiction:
Improvefirmware integrityVSAvoidfirmware modifiability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

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.

Inventive Principle:
Principle #1Segmentation

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.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Manufacturing precision

If complete re-tapeout is performed to modify firmware, then manufacturing precision is maintained, but productivity and time consumption deteriorates

Engineering Contradiction:
Improvefirmware qualityVSAvoidupdate speed
Core Design Contradiction:
Manufacturing precisionVSProductivity

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.

Inventive Principle:
Principle #10Preliminary action

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.

Inventive Principle:
Principle #15Dynamics

3Ease of operation

If function table is used for patching, then ease of operation is improved, but device complexity increases

Engineering Contradiction:
Improvepatch managementVSAvoidfunction table structure
Core Design Contradiction:
Ease of operationVSDevice complexity

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.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS12265624B2Code patching for system on a chip
Publication Date: 2025.04.01 ANALOG DEVICES INT UNLTD CO
  • US12265624B2 patent drawing
  • US12265624B2 patent drawing
  • US12265624B2 patent drawing

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.