SoC Multi-Boot Fallback via Iterative Filename Search
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional booting of a system-on-chip (SoC) using a file-based device like an SD card is time-consuming and inefficient, requiring manual replacement and renaming of boot image files, and lacks the ability to dynamically switch between boot images or handle invalid primary images.
Innovation Solution
A multi-boot or fallback boot method where the SoC initiates boot from nonvolatile memory, incrementally searches for valid boot image files by converting register values to filenames, allowing dynamic selection and fallback to alternative images without the need for power-on-reset.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If manual replacement and renaming of boot image files is used, then the SoC can boot from updated boot images, but the process is time-consuming and inefficient
Solution Approach 1:
Multiple boot image files are pre-stored on the boot device with specific naming conventions (BOOT.BIN, BOOT1.BIN, BOOT2.BIN, etc.). The system automatically searches through these pre-prepared images in sequence, eliminating the need for manual file replacement and renaming operations during boot updates.
Solution Approach 2:
The boot system automatically searches for valid boot images using a predefined naming pattern and sequentially tries different filenames (BOOT.BIN, then BOOT1.BIN, then BOOT2.BIN, etc.) without requiring user intervention. The system self-manages the boot image selection process, replacing manual file management operations with automated filename iteration.
2Adaptability or versatility
If manual replacement of boot image files is used, then updated boot images can be deployed, but the process requires user intervention and is cumbersome
Solution Approach 1:
The system automatically performs boot image selection by iterating through predefined filenames (BOOT.BIN, BOOT1.BIN, BOOT2.BIN, etc.) without requiring user intervention for file replacement or renaming. The automated search and selection process eliminates cumbersome manual operations while maintaining the ability to deploy updated boot images.
Solution Approach 2:
Boot image files are pre-stored with a systematic naming convention that enables automated identification and selection. This preliminary organization of boot images allows the system to automatically find and load the correct image without requiring user intervention during the boot process.
3Reliability
If the primary boot image is invalid or corrupted, then the system needs fallback capability, but conventional methods lack automatic fallback mechanisms
Solution Approach 1:
Multiple backup boot image files (BOOT1.BIN, BOOT2.BIN, etc.) are pre-stored on the boot device as fallback options. If the primary boot image (BOOT.BIN) is invalid or corrupted, the system automatically tries the next available image in sequence, providing redundancy and ensuring system reliability without requiring complex error handling mechanisms.
Solution Approach 2:
The system automatically detects when a boot image is invalid and self-corrects by proceeding to the next filename in the sequence (from BOOT.BIN to BOOT1.BIN to BOOT2.BIN, etc.). This automated fallback mechanism eliminates the need for manual intervention or complex error handling while improving boot reliability.
Data Source
AI summary
A method includes initiating a boot of a system-on-chip coupled to a boot device. The boot is initiated from boot code stored in nonvolatile memory responsive to a power-on-reset. Under control of the boot code: a first register value is loaded into a register; a name string from the boot code is accessed; the first register value is obtained from the register; and the first register value and name string are converted to a first string value, which is provided as a first filename. The boot device is searched for a boot image file with the first filename. If the first filename is not found in the boot device, the first register value is incremented to provide a second register value. The obtaining, converting, and searching are repeated using a second filename generated using the second register value, and a valid filename for the boot image file is iteratively generated.