Dual Firmware Volume Update Mechanism for NVRAM
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Updating firmware components stored on non-volatile random access memory (NVRAM) can be challenging due to block-level erasability, leading to difficulties in managing firmware updates and potential system inoperability if updates are unsuccessful, requiring extensive recovery processes.
Innovation Solution
Implementing a dual firmware volume system where original firmware files are stored in a main volume and updated files in a separate update volume, with globally unique identifiers (GUIDs) allowing for seamless switching between versions, and a launch/blacklist mechanism to ensure only validated updates are executed.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If firmware components are updated by erasing and rewriting sections of NVRAM, then firmware can be updated, but the memory section erased is greater in size than just the firmware components to be updated, complicating the update process
Solution Approach 1:
The patent segments the firmware storage into multiple separate volumes (first firmware volume and second firmware volume) within the NVRAM. This allows individual firmware files to be updated by writing only to the specific volume containing that file, rather than erasing entire memory blocks. The segmentation enables precise targeting of update operations, reducing the scope of erasure and simplifying update orchestration.
Solution Approach 2:
The patent implements preliminary action by maintaining a pending firmware volume that contains updated firmware files before they are activated. The system can prepare updates in advance in the second firmware volume while the first firmware volume remains operational. This allows the system to switch between volumes seamlessly, enabling updates without disrupting system operation and reducing the complexity of coordinated update operations.
2Productivity
If firmware components are deleted and updated versions are written, then firmware can be updated, but if writing fails the system becomes inoperable, requiring extensive recovery processes
Solution Approach 1:
The patent implements beforehand cushioning by maintaining a redundant firmware volume that contains the original, known-good firmware files. When updates are applied to one volume, the other volume serves as a safety buffer. If an update fails or creates an inoperable system, the system can automatically or manually switch to the other volume, preventing complete system failure and eliminating the need for extensive recovery processes involving field technicians.
Solution Approach 2:
The patent introduces an intermediary mechanism in the form of a volume switching system. Instead of directly overwriting firmware files in place, the system uses a second firmware volume as an intermediary storage location for updated files. The system can switch between volumes based on update success, providing a buffer that protects against failed updates and maintains system operability.
3Reliability
If a redundant copy of firmware is maintained for recovery, then system recovery is possible, but additional hardware and complexity are required
Solution Approach 1:
The patent merges the redundant firmware storage requirement with the existing NVRAM structure by organizing it into multiple firmware volumes within a single NVRAM device. Instead of requiring separate physical storage devices for redundancy, the system combines both the original and updated firmware copies within the same physical medium, using logical volume separation. This reduces hardware complexity while maintaining recovery capability.
Data Source
AI summary
Technologies are disclosed herein for updating a firmware file system (FFS) file by preserving the original FFS file in its current firmware volume and then storing an updated version of the original FFS file in a firmware volume for updated FFS files. The updated FFS file may be stored in the firmware volume for updated FFS files referenced to the same FFS file identifier as the original FFS file. During boot-up of a system incorporating the updated firmware, the firmware volume for updated FFS files may be accessed to determine if an updated version of any FFS files are present. If updated FFS files are present, then those updated FFS files may be executed, rather than the original FFS files.