MMU-Less Executable Files for External-Memory Asset Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing MMU-less devices face challenges in efficiently installing and executing programs, particularly ELF files, due to limitations in memory space, processing power, and the need for extensive firmware-side processing, which affects usability and customizability.
Innovation Solution
Implementing a loader component that performs relocation of executable sections in RAM, utilizing an API table with sorted hash values to efficiently load and execute programs, including ELF files, while optimizing memory usage and reducing processing overhead.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If an ELF parser is implemented in the embedded installer, then the device can install ELF files, but more processing power is required which increases firmware size and memory usage
Solution Approach 1:
The patent extracts the ELF parsing and installation logic from the firmware into a separate executable file format. The firmware contains only minimal installation capabilities, while the ELF file itself carries the installation instructions and relocation data, eliminating the need for a complex ELF parser in the firmware.
Solution Approach 2:
The patent introduces an intermediate executable file format that serves as a bridge between the ELF source code and the final installed program. This intermediate format contains pre-calculated relocation data that simplifies the installation process, acting as a mediator that reduces the processing burden on the firmware.
2Adaptability or versatility
If position-independent code (PIC) is used with global offset table updates, then applications can be installed separately, but the embedded installer must update the global offset table which increases processing overhead
Solution Approach 1:
The patent performs preliminary actions by pre-calculating and embedding all relocation data directly into the executable file during the compilation stage. The global offset table and all address relocations are pre-computed, so the embedded installer only needs to copy preprocessed data without performing complex updates during installation.
Solution Approach 2:
The patent uses a copying strategy where the pre-processed executable code with embedded relocation data is directly copied from the ELF file to the target memory location. This eliminates the need for complex runtime code generation or multiple pass processing, reducing installation time significantly.
3Adaptability or versatility
If relocatable code is used with memory location translation, then applications can be relocated to different addresses, but the embedded installer must translate all memory locations which increases firmware processing requirements
Solution Approach 1:
The patent extracts the complex memory location translation logic from the firmware and moves it to the compilation stage. The executable file contains a relocation section with pre-calculated address mappings, so the firmware only needs to perform simple data copying and pointer updates based on pre-computed relocation information.
Solution Approach 2:
All memory location translations are performed preliminarily during the compilation and linking stages. The linker generates a relocation section containing all necessary address adjustments, so the embedded installer does not need to perform complex translation operations at installation time.
Data Source
Figure 1A~1B
Figure 2
Figure 3
AI summary
An executable file for a MMU-less device with an application program interface (API), where the executable file includes a program, and the program includes an at least one executable section subject to loading into a RAM of the MMU-less device and, in a same or another allocatable section, at least one bit, corresponding to an API invocation and requiring a relocation. The executable file includes an asset section storing content for at least one asset file for the program, where the program is configured to access, after the relocation, the at least one asset file from an external memory.