A multi-firmware loading optimization method and corresponding embedded system

Abstract

The present invention discloses a multi-firmware loading optimization method and a corresponding embedded system. In this method, different CPU modes are utilized to implement phased loading, effectively resolving the SRAM capacity limitation issue and improving the security and functionality of the embedded system. During the startup process, complex firmware components can be loaded into DDR memory on demand, breaking through the limitations of SRAM. Furthermore, this method reduces the required SRAM capacity, lowering the manufacturing cost and area of ​​the chip, while increasing the functionality and flexibility of the bootloader and improving the stability and reliability of the embedded system. The present invention is particularly suitable for applications requiring high security and reliability, such as automotive electronics, industrial control, and high-end consumer electronics.

Description

Technical Field

[0001] The present invention relates to a multi-firmware loading optimization method and also to an embedded system adopting the multi-firmware loading optimization method, belonging to the technical field of data processing. Background Art

[0002] In embedded systems, firmware loading is a critical step in ensuring that electronic devices transition safely and reliably from a shutdown state to an operational state. This process begins with initializing the boot media, such as a hard drive, solid-state drive, or flash memory. The embedded system reads and verifies the firmware binary data stored on these media, ensuring data integrity and security through error detection and correction mechanisms. Once the firmware data has been securely read, the embedded system loads it into memory, such as RAM (random access memory) or SRAM (static random access memory), and configures the CPU's operating mode and register settings in preparation for executing the firmware code. The firmware's primary responsibilities are to initialize the system hardware and, as needed, load or start the operating system or other advanced software.

[0003] As firmware functionality becomes increasingly complex, the demand for storage space continues to increase, posing a challenge to the SRAM capacity within SoCs (System-on-Chip). SRAM capacities typically range from 32KB to 256KB, making it difficult to meet growing storage demands. Furthermore, due to compatibility, hardware, and process limitations, SoCs cannot harden the code that initializes DDR memory. Consequently, traditional ROMs expire after loading the bootloader, further limiting the size of the bootloader. Therefore, firmware loading technology needs to adapt to these limitations to ensure that embedded systems can efficiently initialize and load the necessary firmware components.

[0004] In the Chinese invention patent with patent number ZL 201910567474.7, a method and device for effectively improving the loading speed of solid-state drive firmware are disclosed. This method realizes an efficient process from chip power-on to the final system firmware being moved to the destination address by hierarchical processing of the boot program. The specific steps include: running the internally solidified BootROM (boot read-only memory) after the chip is powered on, loading boot programs of different polarities from Nor flash and initializing peripheral modules, initializing Nand flash and loading firmware, and finally performing exception handling. Through this hierarchical and staged loading mechanism, the overall loading speed of the SSD system firmware is significantly improved, demonstrating the effectiveness and advantages of multi-stage firmware loading technology in practical applications. Summary of the Invention

[0005] The primary technical problem to be solved by the present invention is to provide a multi-firmware loading optimization method.

[0006] Another technical problem to be solved by the present invention is to provide an embedded system using the multi-firmware loading optimization method.

[0007] In order to achieve the above object, the present invention adopts the following technical methods:

[0008] According to a first aspect of an embodiment of the present invention, a multi-firmware loading optimization method is provided, which is applicable to an embedded system and includes the following steps:

[0009] S1: When the SoC is powered on, it performs initialization through the ROM and uses the permissions of the Monitor mode to perform hardware configuration and security settings;

[0010] S2: The ROM reads the first-stage boot program from the boot medium and specifies the boot mode it needs to run. When generating the boot program, the boot mode of the boot program is written to the specified location using the matching image creation tool.

[0011] S3: ROM saves key registers and their values ​​before executing the bootloader;

[0012] S4: After the ROM loads the first-stage boot program, it sets the key registers and the key register values, and uses the register window to write the key register values ​​to the predetermined memory address, in preparation for executing the first-stage boot program;

[0013] S5: The ROM uses the mov pc lr instruction to jump to the first-stage bootloader and start executing it, and uses the backup register feature to ensure the independence of the state in different CPU modes;

[0014] S6: Before executing the first stage boot program, switch to the SVC mode of the firmware and start execution at the preset address;

[0015] S7: After the first stage boot program is executed, the SMC instruction is used to return to the CPU mode and security state where the ROM is located;

[0016] S8: After the ROM successfully loads and verifies the second-stage bootloader, it continues execution or reloads the bootloader based on the CPU mode and security state.

[0017] Preferably, the embedded system adopts the ARMv7 series processor architecture.

[0018] Preferably, in step S1, the boot program is executed in the secure world by utilizing the security extension feature of the ARMv7 series processor architecture.

[0019] Preferably, in step S2, before preparing to run the first stage boot program, the ROM checks and configures the embedded system control register and the program status register.

[0020] Preferably, in step S3, the key registers include but are not limited to a program status register, an embedded system control register, a control register, a program counter, a stack pointer and a link register.

[0021] Preferably, in step S5, before switching the CPU mode, the state of the key registers is saved in SRAM and backed up in a software manner.

[0022] Preferably, in step S6, after the ROM completes preparation for the first-stage boot program, it sets the program counter and the link register to point to the preset address.

[0023] Preferably, in step S8, after the ROM successfully loads the second-stage boot program, it verifies whether the CPU mode and security status of the second-stage boot program are consistent with the ROM settings; if they are consistent, the startup process guided by the second-stage boot program continues to be executed, otherwise steps S4 to S7 are repeated and the second-stage boot program is reloaded.

[0024] According to a second aspect of an embodiment of the present invention, an embedded system is provided, comprising a SoC, a ROM, and an SRAM, wherein the SoC is coupled to the ROM and the SRAM to implement the above-mentioned multi-firmware loading optimization method.

[0025] Compared with the prior art, the multi-firmware loading optimization method provided by the embodiment of the present invention effectively solves the problem of SRAM capacity limitation by innovatively utilizing different CPU modes to achieve phased loading, while significantly improving the security and functionality of the embedded system. This method allows the embedded system to load complex firmware components into a larger capacity DDR memory on demand during the startup process, no longer limited by the storage space of SRAM. In addition, this method reduces the manufacturing cost and area of ​​the chip by reducing the required SRAM capacity, while increasing the functionality and flexibility of the boot program, improving the stability and reliability of the embedded system, ensuring the implementation of complex functions, and providing strong support for protecting the data security of legitimate users. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 A simplified flowchart of the multi-firmware loading optimization method provided by an embodiment of the present invention;

[0027] Figure 2 A detailed flowchart of the multi-firmware loading optimization method provided by an embodiment of the present invention;

[0028] Figure 3 A schematic diagram of an embedded system using the multi-firmware loading optimization method provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0029] The technical content of the present invention is described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] In the traditional embedded system startup process, ROM (read-only memory) is responsible for storing and executing the initial startup code. After loading the boot program (bootloader), the ROM's task is usually completed. The embodiment of the present invention draws on the model of the operating system (OS) running the application program (APP), wherein the OS does not end its life cycle after the APP runs, but runs simultaneously with the APP. Therefore, the multi-firmware loading optimization method provided by the embodiment of the present invention allows the ROM and the boot program to take over the execution of the CPU in a time-sharing manner, ensuring that at any time, either the ROM or the boot program is executing, rather than both running at the same time. After loading the boot program, the ROM does not end its life cycle immediately, but can continue to execute. This design realizes the time-sharing system control takeover between the ROM and the boot program.

[0031] Specifically, after the boot program completes its initialization tasks and execution, it does not hand over control to the operating system, but returns it to the ROM. This allows the ROM to continue to perform other preset tasks or, based on the needs of the embedded system, load the next stage of the boot program. After loading and executing a boot program, the ROM does not directly hand over control to the operating system, but remains active. In this way, once the boot program completes its initialization tasks, it can choose to return to the ROM instead of ending its life cycle. At this point, the ROM can continue to perform other preset tasks or, based on the startup requirements of the embedded system, load and start the next stage of the boot program. This process utilizes the different operating modes of the CPU to ensure that even after the Xth (X is a positive integer, the same below) boot program has been executed, the ROM can still maintain its life cycle, continue to manage control and load subsequent boot programs, thereby realizing a flexible and dynamic system startup and update process.

[0032] The multi-firmware loading optimization method provided by the embodiments of the present invention effectively utilizes large-capacity DDR memory to overcome the SRAM capacity limitations of the prior art, while also providing greater boot flexibility and functionality. During this process, the first bootloader is responsible for initializing the DDR memory and, upon completion, returns control to the ROM. The ROM is then responsible for loading subsequent bootloaders into the larger DDR memory. Because the capacity of DDR memory far exceeds that of SRAM, subsequent bootloaders are no longer limited by the size of SRAM. This not only enhances the functionality and flexibility of the bootloader but also allows for a reduction in SRAM capacity, requiring only enough space to store the firmware that initializes the DDR memory, effectively reducing chip area and cost. Furthermore, the ROM-managed multi-stage loading process allows each bootloader to focus on specific initialization tasks. For example, the first bootloader is responsible for basic hardware setup, while subsequent bootloaders can handle more complex configuration tasks such as network setup or security feature initialization, ensuring efficient and stable system startup. Furthermore, the above method enhances the robustness and reliability of embedded systems. If an error occurs while executing a bootloader, the ROM can intervene and take action, such as reloading the bootloader or switching to a backup boot image, to ensure a stable system startup. This error recovery capability is crucial to ensuring the stability of the system in the face of various abnormal situations.

[0033] Below, taking the ARMv7 series processor architecture (see the official reference manual "ARM Architecture Reference Manual ARMv7-A and ARMv7-Redition" released by ARM for details) as an example, combined with Figure 1 and Figure 2 The specific implementation steps of the multi-firmware loading optimization method provided by the embodiment of the present invention are described in detail:

[0034] S1: The SoC performs initialization through ROM when powered on, and uses the high privileges of Monitor mode to perform hardware configuration and security settings.

[0035] When a Secure Extension-supported ARMv7 processor architecture SoC is powered on, the embedded system boots from the embedded ROM. ROM, a non-volatile memory used to store boot code, ensures the embedded system can recover and begin executing necessary initialization steps even after a power outage.

[0036] In the ARMv7 series processor architecture, the SoC runs in Monitor mode by default after power-on, which is the mode with the highest CPU privilege level in the ARM processor. Monitor mode allows the SoC to execute all privileged instructions, covering critical tasks such as hardware initialization, memory configuration, and security settings adjustment. This mode has full control over system resources, ensuring that necessary hardware detection and configuration can be performed at startup. Monitor mode also has the ability to switch to other modes and different privilege levels of the ARM processor, such as user mode or system mode. This flexibility enables the SoC to dynamically adjust the CPU's working state and permissions according to different stages and requirements of the startup process to perform specific tasks or load subsequent startup code, such as the Bootloader. This design not only improves the security of the system, but also enhances its adaptability to different startup scenarios.

[0037] Secure Extension, a key feature of the ARMv7 processor architecture, enhances embedded system security by distinguishing between the Secure World and the Non-secure World. In the Secure World, code in Monitor mode has unrestricted access to all resources, while code in the Non-secure World is subject to restrictions, protecting sensitive operations and data from unauthorized access and potential malicious attacks.

[0038] During a secure boot process, the SoC in Monitor mode first completes hardware initialization, then loads and executes the bootloader. The bootloader then performs further embedded system initialization, such as loading the operating system kernel. This consistent process ensures that the embedded system can safely and reliably transition from a shutdown state to a fully operational state, and ensures that only authenticated and authorized code is executed, thus maintaining the integrity and security of the entire embedded system.

[0039] S2: The ROM reads the first-stage bootloader (bootloader 1) from the boot medium. During the generation of bootloader 1, the boot mode to be run is specified, and the boot mode of the bootloader is written to the specified location using the accompanying image creation tool.

[0040] ROM plays a crucial role in the SoC boot process. Once the embedded system is powered on, the boot code in ROM is first executed. Its primary task is to initialize the boot media. These media include eMMC (embedded MultiMediaCard), SD (Secure Digital), NAND (a non-volatile storage technology), etc. These are the devices used by embedded systems to store the operating system, application data, and bootloaders.

[0041] After initializing the boot media, the ROM reads the first-stage bootloader, Bootloader 1, from these media. Bootloader 1 is a key component in the embedded system's boot process, responsible for loading and initializing the operating system. When generating Bootloader 1, developers specify the desired boot mode and use the accompanying image creation tool to write this information to a specific location in the Bootloader 1 image. This step ensures that Bootloader 1 runs in the correct processor mode, matching the embedded system's hardware architecture and security requirements.

[0042] Among them, during the startup process of the embedded system, after generating the binary (bin) file of the boot program, a dedicated image generation tool is needed to create a specific image format. This tool combines the key ARM mode settings, load address, execution address and other information required for startup with the boot program bin file itself, and encapsulates it into a complete image file. When the ROM loads this image file, it will parse the ARM mode (boot mode during the startup process, and can be other working modes such as user mode after the startup process) and load address information contained therein to ensure that the boot program can be started with the correct configuration and executed at the predetermined memory address. This process is a key step to ensure the safe and reliable startup of the embedded system, allowing the ROM to correctly initialize the hardware and configure the system environment according to the preset parameters.

[0043] It should be noted that before the ROM is ready to run bootloader 1, it will perform a series of checks and setup operations to ensure that the embedded system can correctly switch to the required ARM mode and security state. This step is crucial because it ensures that the bootloader can run in an established and secure execution environment.

[0044] Specifically, the ROM checks and configures the CPU's core registers, including the embedded System Control Register (SCR). The .ns bit (non-secure bit) in the SCR is a key bit field that controls whether the CPU is in a secure state. If this bit is set, it indicates that the CPU is running in non-secure mode; if it is cleared, the CPU is in secure mode.

[0045] In addition to the SCR register, the ROM also configures the Saved Program Status Register (SPSR). The SPSR is used to save certain CPU status information, such as the mode and interrupt enable status, so that these states can be restored when needed. Correctly setting the SPSR ensures that the CPU can switch to the correct ARM mode and security state when bootloader 1 is executed, allowing the bootloader to run at the appropriate privilege level.

[0046] Through these settings, the ROM ensures that bootloader 1 can be started in a predefined, secure execution environment, which is critical for protecting the embedded system's boot process from unauthorized access or potential attacks. Once these registers are correctly configured, the ROM will jump to the entry point of bootloader 1 and begin executing the bootloader code, continuing the embedded system's boot sequence.

[0047] S3: ROM saves the key registers and necessary data of the ARM core before executing the boot program.

[0048] In the ARMv7 series processor architecture, the ROM performs a critical operation before executing the bootloader: saving the key registers and necessary data of the ARM core. These registers include but are not limited to the Program Status Register (SPSR), the Embedded System Control Register (SCR), the Control Register (CTLR), the Program Counter (PC), the Stack Pointer (SP), the Link Register (LR), and general-purpose registers R0 to R14.

[0049] Saving these key registers is crucial because they contain information about the processor's current state and context. For example, the SPSR typically stores the current program state, including processor mode and interrupt enable status. The SCR contains important information for controlling the CPU's security state and exception levels. The PC, SP, and LR indicate the current program execution location, the top of the stack, and the subroutine return address, respectively.

[0050] By saving the values ​​of these key registers, the ROM can restore them to the saved state when needed, ensuring that the processor can safely return to the correct execution point after an interrupt or exception. This mechanism is crucial for the stability and reliability of embedded systems, especially when dealing with complex startup processes or making embedded system calls.

[0051] Finally, this register save and restore mechanism also provides the foundation for multitasking and operating system context switching. In modern operating systems, when a task or process needs to be suspended or switched, its state is saved so that execution can be resumed accurately. This mechanism, implemented in ROM, provides flexible context management and efficient resource scheduling capabilities for embedded systems.

[0052] S4: After the ROM loads the first-stage bootloader (bootloader 1), it sets the key registers and necessary data of the ARM Core.

[0053] In SoCs based on the ARMv7 series processor architecture, after loading bootloader 1, the ROM performs a delicate operation: setting up the key registers and necessary data of the ARM Core. This includes setting the values ​​of the Program Status Register (SPSR), the Embedded System Control Register (SCR), the Control Register (CTLR), the Program Counter (PC), the Stack Pointer (SP), the Link Register (LR), and general registers R0 to R14 to the location specified by the LR return address.

[0054] The purpose of this step is to accurately restore the previous state after executing bootloader 1. By writing the values ​​of these key registers to a predetermined memory address, the ROM ensures that when bootloader 1 completes, it can seamlessly return to the appropriate location in the ROM using this saved state information to continue the subsequent boot process.

[0055] In addition, this setting also reflects an important feature of the ARM architecture: register windowing (Regist erBanking, specifically refers to a set of repeated registers. Each mode has its own copy of the registers. When the processor switches from one mode to another, it transparently switches to the register set of the corresponding mode, thereby protecting the context and data of each mode). In different CPU modes, the same register name may point to different physical registers. Therefore, by writing register values ​​to memory, ROM can maintain the continuity and consistency of these key values ​​when switching between different modes.

[0056] Finally, when bootloader 1 completes its task and returns to ROM through an SMC (Secure Monitor Call) instruction or other mechanism, ROM can use the previously saved register state to restore to the correct ARM mode and security state and continue executing the embedded system's boot sequence. This ensures the smoothness of the entire boot process and the stability of the embedded system.

[0057] S5: ROM jumps to bootloader 1 execution by using the mov pc lr instruction and uses the backup register feature to ensure the independence of the states in different CPU modes, thereby maintaining the respective register values ​​and state information when switching the execution environment.

[0058] In SoCs based on the ARMv7 processor architecture, after the ROM completes bootloader 1 preparations, it uses the mov pc lr instruction to jump to the address of bootloader 1. The mov pc lr instruction, a fundamental instruction in the ARM instruction set, moves the value in the link register (LR) to the program counter (PC), thereby changing the CPU's execution flow to the new location pointed to by the LR. Prior to this, the LR has already been set to point to the entry address of bootloader 1, and the status register and other functions have been appropriately configured.

[0059] After executing the mov pc lr instruction, the ARM core adopts the previously set state information, including the CPU mode, secure state, and stack. This state information ensures that when control is transferred to Bootloader 1, it will operate in a predefined and correct execution environment. At the same time, the registers and stack information used by the ROM are saved to static random access memory (SRAM) so that the ROM execution state can be restored when needed.

[0060] The banked register feature of the CPU modes supported by the ARMv7 family of processors allows for physically separate sets of registers with the same name to exist in different CPU modes. This means that when switching from one CPU mode to another, the corresponding register values ​​remain in the registers of each mode without interfering with each other. For example, when switching from a Monitor mode running in ROM to a mode running in firmware, each mode has its own set of registers, ensuring that the execution states of the ROM and firmware do not conflict with each other.

[0061] In one embodiment of the present invention, the ROM also provides a software backup method to address the need for CPU mode switching when memory resources are limited. Before switching the CPU mode, the state of key registers can be saved to SRAM and backed up in software. This method requires additional SRAM space, approximately 300 bytes, to store these backup register states. Once it is necessary to return to the original execution environment, these backup register states can be restored from SRAM, ensuring the continuity and stability of the embedded system.

[0062] S6: Before executing the first stage bootloader (bootloader 1), the ARM core switches to the firmware SVC mode and starts execution at the preset address.

[0063] Before executing bootloader 1, the ARM core switches to the firmware's SVC (Supervisor Call) mode and begins execution at a preset address (the starting address of bootloader 1 in memory). This mode switch is a feature supported by the ARMv7 series processor architecture, which allows software to change the processor's operating mode by setting specific registers.

[0064] In the ARMv7 series processor architecture, SVC mode is a privileged mode, typically used to handle embedded system calls from the operating system. When the ARM core switches to SVC mode, it will be able to access more privileged instructions and embedded system resources, which is necessary for executing bootloader 1 because the bootloader needs to initialize and configure the hardware.

[0065] To implement this mode switch, several registers must be set, including the Program Status Register (SPSR) and the Link Register (LR). These registers ensure that after switching to SVC mode, the embedded system remembers the current execution state and can return to the previous state or perform other operations when necessary. When the ROM completes preparations for bootloader 1, it sets the Program Counter (PC) and Link Register (LR) to point to the preset addresses mentioned above.

[0066] By setting the LR register, the embedded system defines the address to which it should return after executing the code in SVC mode. The SPSR stores the program status information in the current mode, including the processor mode and interrupt enable status, so that it can be restored to the correct state after the SVC mode execution is completed.

[0067] S7: After the first stage of the boot program is executed, the SMC instruction is used to return to the CPU mode and security state where the ROM is located, ensuring that the control of the embedded system is returned to the startup code of the embedded system.

[0068] When bootloader 1 completes execution, it uses the SMC instruction to return to the CPU mode and secure state where the ROM resides. The SMC instruction, introduced in the ARMv7 series processor architecture, is used to switch between the secure and non-secure worlds, or from application mode to monitor mode. In this case, the SMC instruction is used to securely return from bootloader 1 to the ROM, ensuring that control of the embedded system is returned to the embedded system's startup code.

[0069] To handle the SMC instruction, an assembly function must be implemented in the ROM code. This function defines how the embedded system should respond when the SMC instruction is triggered. The ARMv7 security extension supports the SMC instruction. When this instruction is executed, the ARMv7 core hardware will jump to the pre-defined SMC exception entry point, allowing the embedded system to handle security-related operations or perform mode switching.

[0070] Before bootloader 1 executes the SMC instruction, it needs to specify the address of the next bootloader to be loaded by the ROM stored in the flash memory by setting SMC parameters. Since the ROM usually loads bootloader 1 from a fixed flash memory address, subsequent bootloaders may be stored at different addresses in the flash memory depending on the application scenario. By setting these parameters, bootloader 1 provides the ROM with the exact location of the next bootloader, ensuring that the embedded system can continue to load and initialize according to the predetermined startup sequence. This mechanism provides a flexible way to manage the multi-stage firmware loading process while also maintaining the security and controllability of the embedded system.

[0071] S8: After the embedded system's ROM successfully loads the second-stage boot program, it verifies whether the CPU mode and security status of the second-stage boot program are consistent with the ROM settings; if they are consistent, the startup process of the second-stage boot program continues, otherwise the ROM will repeat steps S4 to S7 and reload the second-stage boot program.

[0072] Specifically, after the ROM successfully reads the second-stage bootloader (bootloader2) from the specified flash address, the embedded system checks whether the CPU mode and security state of bootloader2 match the ROM settings. If bootloader2 is configured with the same CPU mode and security state as the ROM, then after bootloader2 is executed, the ROM lifecycle will end, and the embedded system will fully enter the startup process guided by bootloader2, continuing with subsequent operating system loading or other initialization tasks.

[0073] However, if the CPU mode and security state set by bootloader2 are inconsistent with those set by the ROM, the embedded system will not continue to execute bootloader2, but will repeat the previous S4-S7. This means that the ROM will reload bootloader2, check and set the correct CPU mode and security state again, and then try to execute bootloader2 again. This process ensures that the embedded system maintains the correct execution environment and security level during each mode switch.

[0074] It's important to note that if any errors occur during this process—for example, incorrect SMC parameters set by bootloader2, an error in the ROM's attempt to read flash memory, or incorrect bootloader image content read from flash memory—the embedded system will not continue executing bootloader2. Instead, the ROM initiates an error recovery process, transitioning to a download mode. In this download mode, the embedded system may attempt to reload the bootloader from an external source or perform other recovery operations to ensure the stability and security of the embedded system. This design provides the embedded system with a robust error handling mechanism, ensuring that appropriate recovery measures can be taken in the event of a problem.

[0075] Based on the above multi-firmware loading optimization method, the embodiment of the present invention further provides an embedded system using the multi-firmware loading optimization method. Figure 3 As shown, the embedded system at least includes a SoC, a ROM and an SRAM, wherein the SoC is coupled to the ROM and the SRAM.

[0076] In one embodiment of the present invention, after powering on, the embedded system first enters Monitor mode and executes the boot code in ROM. The ROM initializes necessary hardware devices, including the memory controller and clock system. The ROM then reads the first-stage boot program from Flash or other boot media and checks its security and integrity. Based on the boot program's instructions, the ROM may switch the CPU mode or security state before jumping to the boot program's execution address.

[0077] The first-stage bootloader (bootloader 1) initializes key hardware such as DDR memory and prepares the embedded system for the next stage of booting. After execution, bootloader 1 returns to the ROM via an SMC instruction or other mechanism and specifies the storage address for the second-stage bootloader.

[0078] The ROM loads the second-stage bootloader (bootloader2) according to the specified address. This bootloader is responsible for more detailed hardware configuration and system testing. It should be noted that in the embodiment of the present invention, there can be more stages of bootloaders, such as bootloader3, bootloader4, bootloader5, etc. Each stage of the bootloader has specific tasks and responsibilities, but the processing method is similar to that of bootloader2.

[0079] If an error occurs while loading or executing the bootloader, such as an inability to read or verification failure, the embedded system will enter an error recovery process. Specific measures may include re-downloading the bootloader from the network or other external media, or switching to an alternative system image.

[0080] After a series of boot processes, the operating system kernel and necessary system services are finally loaded. The operating system takes control and completes the remaining system initialization, including loading device drivers and starting network services.

[0081] In a preferred embodiment of the present invention, an embedded system can utilize the Secure Extensions feature of the ARMv7 series processor architecture to ensure that critical boot code is executed in the secure world. Simultaneously, the SMC instruction is used to switch between secure and non-secure states, protecting the security of the embedded system and the integrity of its data.

[0082] This multi-firmware loading optimization method enables embedded systems to achieve a fast, secure, and flexible boot process while also providing strong error recovery capabilities. This design is particularly suitable for applications requiring extremely high security and reliability, such as automotive electronics, industrial control, and high-end consumer electronics.

[0083] Compared with the prior art, the multi-firmware loading optimization method provided by the embodiment of the present invention has the following key technical effects:

[0084] 1. Expanded storage capacity: By utilizing different CPU operating modes, the embedded system can load different firmware components in stages during the startup process, breaking through the limitations of SRAM capacity and allowing ROM to use larger capacity storage media, such as DDR memory.

[0085] 2. Improve functionality and flexibility: Allow the boot program to return to ROM after execution, and the ROM will then load subsequent boot programs as needed. This time-sharing takeover mechanism not only improves the functionality of the system, but also increases the flexibility of the system.

[0086] 3. Reduce cost and chip area: Since the capacity of SRAM can be reduced, only enough space needs to be reserved to store the necessary firmware, thereby reducing the chip area and manufacturing cost.

[0087] 4. Support complex functions: The boot program is no longer limited by the size of SRAM, and more complex functions can be designed, which enhances the processing capability and application scope of the embedded system.

[0088] 5. Improve system stability: By loading firmware in stages and precisely controlling its execution, potential errors during the startup process of embedded systems are reduced, improving overall stability and reliability.

[0089] It should be noted that the above embodiments are merely examples, and the technical solutions of the various embodiments may be combined, all within the scope of protection of the present invention.

[0090] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature specified as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, "plurality" means two or more, unless otherwise specifically defined.

[0091] The above describes in detail the multi-firmware loading optimization method and corresponding embedded system provided by the present invention. For those skilled in the art, any obvious modification made to the method without departing from the essence of the present invention will constitute an infringement of the patent rights of the present invention and will result in the corresponding legal liability.

Claims

1. A multi-firmware loading optimization method, suitable for embedded systems, characterized in that The following steps are involved: S1: When the SoC is powered on, it performs initialization through the ROM and uses the permissions of the monitor mode to perform hardware configuration and security settings; S2: The ROM reads the first-stage boot program from the boot medium and specifies the boot mode it needs to run. When generating the boot program, the boot mode of the boot program is written to the specified location using the matching image creation tool. S3: ROM saves key registers and their values ​​before executing the bootloader; S4: After the ROM loads the first-stage boot program, it sets the key registers and the key register values, and uses the register window to write the key register values ​​to the predetermined memory address, in preparation for executing the first-stage boot program; S5: The ROM uses the mov pc lr instruction to jump to the first-stage bootloader and start executing it, and uses the backup register feature to ensure the independence of the state in different CPU modes; S6: Before executing the first stage boot program, switch to the SVC mode of the firmware and start execution at the preset address; S7: After the first stage boot program is executed, the SMC instruction is used to return to the CPU mode and security state where the ROM is located; S8: After the ROM successfully loads and verifies the second-stage bootloader, it continues execution or reloads the bootloader based on the CPU mode and security state.

2. The multi-firmware loading optimization method according to claim 1, wherein: The embedded system adopts the ARMv7 series processor architecture.

3. The multi-firmware loading optimization method according to claim 2, wherein: In step S1, the boot program is executed in the secure world by utilizing the security extension feature of the ARMv7 series processor architecture.

4. The multi-firmware loading optimization method according to claim 2, wherein: In step S2, before preparing to run the first stage boot program, the ROM checks and configures the embedded system control register and the program status register.

5. The multi-firmware loading optimization method according to claim 2, wherein: In step S3, the key registers include but are not limited to a program status register, an embedded system control register, a control register, a program counter, a stack pointer, and a link register.

6. The multi-firmware loading optimization method according to claim 2, wherein: In step S5, before switching the CPU mode, the state of the key registers is saved in SRAM and backed up in a software manner.

7. The multi-firmware loading optimization method according to claim 2, wherein: In step S6, after the ROM completes the preparation work for the first stage boot program, it sets the program counter and the link register to point to the preset address.

8. The multi-firmware loading optimization method according to claim 2, wherein: In step S8, after the ROM successfully loads the second-stage boot program, it verifies whether the CPU mode and security status of the second-stage boot program are consistent with the ROM settings; if consistent, the startup process of the second-stage boot program continues to be executed, otherwise steps S4 to S7 are repeated and the second-stage boot program is reloaded.

9. An embedded system, comprising SoC, ROM, and SRAM, characterized in that The SoC is coupled to the ROM and the SRAM, and is used to implement the multi-firmware loading optimization method according to any one of claims 1 to 8.

Images