Multi-firmware loading optimization method and corresponding embedded system

Abstract

The invention discloses a multi-firmware loading optimization method and a corresponding embedded system. In the method, staged loading is realized by utilizing different CPU modes, so that the problem of capacity limitation of the SRAM is effectively solved, and the safety and functionality of the embedded system are improved. In the starting process, complex firmware components are allowed to be loaded to a DDR memory according to needs, and limitation of an SRAM is broken through. In addition, according to the method, the necessary SRAM capacity is reduced, the manufacturing cost and the area of a chip are reduced, meanwhile, the functionality and the flexibility of a bootstrap program are improved, and the stability and the reliability of an embedded system are improved. The method is particularly suitable for application scenes with high requirements on safety and reliability, such as automotive electronics, industrial control and high-end consumer electronics.

Description

Technical Field

[0001] The 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 the safe and reliable transition of electronic devices from the shutdown state to the running state. This process first includes the initialization of the boot media, such as hard disk, solid-state drive, or flash memory. The embedded system reads and verifies the firmware binary data stored on these media, ensuring the integrity and security of the data through error detection and correction mechanisms. Once the firmware data is safely 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 main responsibilities of the firmware are to initialize the system hardware and load or start the operating system or other advanced software as required.

[0003] As firmware functions become increasingly complex, the demand for storage space continues to increase, which poses a challenge to the SRAM capacity inside the SoC (System on Chip). The SRAM capacity is usually between 32KB and 256KB, which is difficult to meet the growing storage demand. In addition, due to compatibility, hardware and process limitations, SoC cannot solidify the code to initialize DDR memory, resulting in the end of the life cycle of traditional ROM after loading the bootloader, which in turn limits 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 poles from the Nor flash and initializing the peripheral modules, initializing the Nand flash and loading the 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 adopting 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: 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 necessary data before executing the boot program;

[0012] S4: After the ROM loads the first-stage boot program, it sets key registers and necessary data to prepare for executing the first-stage boot program;

[0013] S5: ROM uses the mov pc lr instruction to jump to the first-stage boot program and start execution, and uses the backup register feature to ensure the independence of the states in different CPU modes;

[0014] S6: After 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 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;

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

[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 S4, the value of the key register is written into a predetermined memory address using a register window.

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

[0023] Preferably, in step S6, after the ROM completes the preparation of the first-stage boot program, the program counter and the link register are set to point to the preset address.

[0024] 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.

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

[0026] 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 realize staged loading, while significantly improving the security and functionality of the embedded system. The method allows the embedded system to load complex firmware components to a larger capacity DDR memory on demand during the startup process, and is no longer limited by the storage space of SRAM. In addition, the 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 realization of complex functions, and providing strong support for protecting the data security of legitimate users. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0029] 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

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

[0031] In the traditional embedded system startup process, ROM (read-only memory) is responsible for storing and executing the initial startup code. After loading the bootloader, the ROM's task is usually completed. The embodiment of the present invention draws on the mode of the operating system (OS) running the application program (APP), in which 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 bootloader to take over the execution of the CPU in a time-sharing manner, ensuring that at any time, either the ROM or the bootloader is executing, rather than both running at the same time. After loading the bootloader, 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 bootloader.

[0032] Specifically, after the boot program completes its initialization task and execution, it does not hand over control to the operating system, but returns it to the ROM. In this way, the ROM can continue to perform other preset tasks, or load the next stage of the boot program according to the needs of the embedded system. After loading and executing a boot program, the ROM does not directly hand over control to the operating system, but continues to remain active. In this way, once the boot program completes its initialization task, 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 load and start the next stage of the boot program according to the startup requirements of the embedded system. 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 is 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.

[0033] The multi-firmware loading optimization method provided by the embodiment of the present invention can effectively utilize the large-capacity DDR memory to overcome the limitation problem of SRAM capacity in the prior art, and at the same time provide greater startup flexibility and functionality. In this process, the responsibility of the first boot program is to initialize the DDR memory, and after completion, the control is returned to the ROM, and the ROM is responsible for loading the subsequent boot program into the DDR memory with a larger space. Since the capacity of the DDR memory far exceeds that of the SRAM, the subsequent boot program is no longer limited by the size of the SRAM, which not only enhances the functionality and flexibility of the boot program, but also allows the capacity of the SRAM to be reduced, and only enough space needs to be reserved to store the firmware that initializes the DDR memory, effectively reducing the area and cost of the chip. In addition, the multi-stage loading process managed by the ROM allows the boot program of each stage to focus on specific initialization tasks. For example, the first boot program is responsible for basic hardware settings, while the subsequent boot programs can handle more complex configuration tasks, such as network settings or security function initialization, ensuring the efficiency and stability of system startup. On the other hand, the above method also enhances the robustness and reliability of the embedded system. If an error is encountered when executing a boot program, the ROM can intervene and take measures, such as reloading the boot program or switching to a backup boot image, thereby ensuring that the system can be stably started. This error recovery capability is crucial to ensuring the stability of the system in the face of various abnormal situations.

[0034] Below, we take the ARMv7 series processor architecture (see the official reference manual "ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition" 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:

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

[0036] When the SoC of the ARMv7 series processor architecture supporting Secure Extension is powered on, the embedded system will start the ROM embedded in the chip. ROM is used to store the boot code. As a non-volatile memory, it ensures that the embedded system can recover and start to execute the necessary initialization steps even after power failure.

[0037] In the ARMv7 series processor architecture, the SoC runs in Monitor mode by default after power-on, which is the highest CPU privilege level mode in the ARM processor. Monitor mode allows the SoC to execute all privileged instructions, covering key 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 in 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.

[0038] As an important feature of the ARMv7 series processor architecture, Secure Extension enhances the security of embedded systems by distinguishing between the secure world and the normal world. In the secure world, the code in Monitor mode can access all resources without restriction, while the code in the normal world is restricted, protecting sensitive operations and data from unauthorized access and potential malicious attacks.

[0039] During the Secure Boot process, the SoC in Monitor mode first completes hardware initialization, then loads and executes the boot program. The boot program continues to perform further initialization of the embedded system, such as loading the operating system kernel. This coherent process ensures that the embedded system can safely and reliably transition from the shutdown state to the fully operational state, and ensures that only verified and authorized code can be executed, thereby maintaining the integrity and security of the entire embedded system.

[0040] S2: ROM reads the first stage boot program (bootloader1) from the boot medium. In the process of generating bootloader1, specify the boot mode it needs to run, and use the matching image creation tool to write the boot mode of the boot program to the specified location.

[0041] ROM plays a vital role in the SoC boot process. Once the embedded system is powered on, the boot code in the ROM is executed first, and its primary task is to initialize the boot media. These media include eMMC (embedded Multimedia Card), SD (Secure Digital Card), NAND (a non-volatile storage technology), etc. They are devices used to store operating systems, application data, and boot programs in embedded systems.

[0042] After completing the initialization of the boot media, the ROM will then read the first-stage boot program, bootloader1, from these media. Bootloader1 is a key component in the embedded system startup process, responsible for loading and initializing the operating system. In the process of generating bootloader1, the developer will specify the boot mode it needs to run, and use the supporting image creation tool to write this information to the specified location of the bootloader1 image. This step ensures that bootloader1 can run in the correct processor mode to match the hardware architecture and security requirements of the embedded system.

[0043] 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, loading address, execution address and other startup information with the bin file of the boot program itself, and encapsulates them 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 ends), loading address and other 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.

[0044] It should be noted that before the ROM is ready to run bootloader1, 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 critical because it ensures that the bootloader can run in an established and secure execution environment.

[0045] Specifically, the ROM checks and configures the core registers of the CPU, including the embedded system control register (System Control Register, referred to as SCR). The .ns bit (non-secure bit) in the SCR is a critical bit field that controls whether the CPU is in a secure state. If this bit is set, it will indicate that the CPU is running in non-secure mode; if it is cleared, the CPU is in secure mode.

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

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

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

[0049] In the ARMv7 series processor architecture, the ROM performs a key operation before executing the boot program: saving the key registers and necessary data of the ARM core. These registers include but are not limited to the program status register (SPSR), embedded system control register (SCR), control register (CTLR), program counter (PC), stack pointer (SP) and link register (LR), as well as general registers R0 to R14.

[0050] The preservation of these key registers is crucial because they contain the current state and context information of the processor. For example, SPSR is usually used to save the current program state, including processor mode, interrupt enable status, etc.; SCR contains important information such as controlling the CPU security state and exception level; while PC, SP and LR indicate the current program execution position, stack top and subroutine return address respectively.

[0051] 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 from an interrupt or exception and continue to work. This mechanism is critical to the stability and reliability of embedded systems, especially when dealing with complex startup processes or making embedded system calls.

[0052] Finally, this register save and restore mechanism also provides the basis 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 it can be resumed accurately later. This mechanism implemented in ROM provides flexible context management and efficient resource scheduling capabilities for embedded systems.

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

[0054] In the SoC of the ARMv7 series processor architecture, after loading the bootloader1, the ROM will perform a delicate operation: setting the key registers and necessary data of the ARM Core. This includes setting the values ​​of the program status register (SPSR), embedded system control register (SCR), control register (CTLR), program counter (PC), stack pointer (SP), link register (LR), and general registers R0 to R14 to the location specified by the LR return address.

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

[0056] In addition, this setting also reflects an important feature of the ARM architecture: register window (RegisterBanking, specifically refers to a set of repeated registers. Each mode has its own copy of 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.

[0057] Finally, when bootloader1 completes its task and returns to ROM through SMC (Secure monitor call) instructions or other mechanisms, ROM can use the previously saved register state to restore to the correct ARM mode and security state and continue to execute the boot sequence of the embedded system. This ensures the smoothness of the entire boot process and the stability of the embedded system.

[0058] S5: ROM jumps to bootloader1 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.

[0059] In the SoC of the ARMv7 series processor architecture, after the ROM completes the preparation of bootloader1, it uses the movpc lr instruction to implement the jump to the address execution of bootloader1. The mov pc lr instruction is a basic instruction in the ARM instruction set, which is used to move 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 LR. Before this, LR has been set to point to the entry address of bootloader1, and the status register, etc. have also been appropriately configured.

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

[0061] The banked register feature of the CPU mode supported by the ARMv7 series processor architecture allows different CPU modes to have physically independent register sets with the same name. This means that when switching from one CPU mode to another, the corresponding register values ​​will remain in the registers of each mode without interfering with each other. For example, when switching from the Monitor mode (Monitor mode) running in ROM to another mode running in firmware, each mode has its own set of registers, thus ensuring that the execution state of the ROM and the execution state of the firmware do not conflict with each other.

[0062] In one embodiment of the present invention, the ROM also provides a software backup method to cope with 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, about 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 to ensure the continuity and stability of the embedded system.

[0063] S6: The ARM core executes the first stage bootloader (bootloader1), switches to the firmware SVC mode, and starts execution at the preset address.

[0064] Before executing bootloader1, the ARM core switches to the firmware's SVC (supervisory call) mode and starts execution at a preset address (the starting address of bootloader1 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.

[0065] In the ARMv7 series processor architecture, SVC mode is a privileged mode, usually used to handle embedded system calls of 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 bootloader1 because the bootloader needs to initialize and configure the hardware.

[0066] In order to achieve this mode switch, multiple registers need to be set, including the program status register (SPSR), link register (LR), etc. These registers are set to ensure that after switching to SVC mode, the embedded system can remember the current execution state and return to the original state or perform other operations when necessary. When the ROM completes the preparation of bootloader1, it will set the program counter (PC) and link register (LR) to point to the preset address mentioned above.

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

[0068] 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.

[0069] When bootloader1 is finished executing, it uses the SMC instruction to return to the CPU mode and security state where the ROM is located. The SMC instruction is a special instruction introduced in the ARMv7 series processor architecture, which is used to switch between the secure and non-secure worlds, or switch from application mode to Monitor mode. In this case, the SMC instruction is used to safely return from bootloader1 to ROM, ensuring that the control of the embedded system is returned to the startup code of the embedded system.

[0070] In order 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 security extension of ARMv7 supports the SMC instruction. When the instruction is executed, the ARMv7 core hardware will jump to the pre-set SMC exception entry to execute, allowing the embedded system to handle security-related operations or perform mode switching.

[0071] Before bootloader1 executes the SMC instruction, it needs to specify the address of the next boot program to be loaded by ROM stored in the flash memory by setting the SMC parameters. Since ROM usually loads bootloader1 from a fixed flash address, for subsequent bootloaders, they may be stored at different addresses in the flash memory depending on the application scenario. By setting these parameters, bootloader1 provides ROM with the exact location of the next boot program, 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.

[0072] S8: When 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 will continue to be executed, otherwise the ROM will repeat steps S4 to S7 and reload the second-stage boot program.

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

[0074] However, if the CPU mode and security state of bootloader2 are inconsistent with those set by ROM, the embedded system will not continue to execute bootloader2, but will repeat the previous S4 to S7. This means that 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 can maintain the correct execution environment and security level at each mode switch.

[0075] It should be noted that if any error occurs during this process, such as incorrect SMC parameters set by bootloader2, or an error occurs when the ROM attempts to read the flash memory, or the content of the bootloader image read from the flash memory is incorrect, the embedded system will not continue to execute bootloader2. Instead, the ROM will start an error recovery process and jump to a download mode. In this download mode, the embedded system may try 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 a robust error handling mechanism for the embedded system, ensuring that appropriate measures can be taken to recover when problems occur.

[0076] 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 a SRAM, wherein the SoC is coupled to the ROM and the SRAM.

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

[0078] The first stage bootloader (bootloader1) is responsible for initializing key hardware such as DDR memory and preparing the embedded system to enter a higher level startup phase. After execution, bootloader1 returns to ROM through SMC instructions or other mechanisms and specifies the storage address of the second stage bootloader.

[0079] The ROM loads the second-stage bootloader (bootloader2) according to the specified address, which can be responsible for more detailed hardware configuration and system detection. 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 bootloader2.

[0080] If an error occurs during loading or executing the boot program, such as failure to read or verify, the embedded system will enter an error recovery process. Specific measures may include re-downloading the boot program from the network or other external media, or switching to an alternate system image.

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

[0082] In a preferred embodiment of the present invention, the embedded system can utilize the Secure Extension feature of the ARMv7 series processor architecture to ensure that critical startup code is executed in the secure world. At the same time, the SMC instruction is used to switch between secure and non-secure states to protect the security of the embedded system and the integrity of the data.

[0083] Through this multi-firmware loading optimization method, the embedded system can achieve a fast, safe and flexible startup process, while having strong error recovery capabilities. This design is particularly suitable for application scenarios with extremely high requirements for security and reliability, such as automotive electronics, industrial control and high-end consumer electronics.

[0084] 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:

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

[0086] 2. Improve functionality and flexibility: Allow the boot program to return to ROM after execution, and ROM will 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.

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

[0088] 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 power and application scope of the embedded system.

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

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

[0091] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0092] The above is a detailed description of the multi-firmware loading optimization method and the corresponding embedded system provided by the present invention. For those skilled in the art, any obvious changes made to it without departing from the essence of the present invention will constitute an infringement of the patent right of the present invention and will bear 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: 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 necessary data before executing the boot program; S4: After the ROM loads the first-stage boot program, it sets key registers and necessary data to prepare for executing the first-stage boot program; S5: ROM uses the mov pc lr instruction to jump to the first-stage boot program and start execution, and uses the backup register feature to ensure the independence of the states in different CPU modes; S6: After 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 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; S8: After the ROM successfully loads and verifies the second-stage bootloader, it continues to execute or reloads the bootloader based on the CPU mode and security status.

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

3. The multi-firmware loading optimization method according to claim 2, characterized in that: In the 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, characterized in that: 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, characterized in that: 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, characterized in that: In step S4, the value of the key register is written into a predetermined memory address using a register window.

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

8. The multi-firmware loading optimization method according to claim 2, characterized in that: In step S6, after the ROM completes the preparation work for the first stage boot program, the program counter and the link register are set to point to the preset address.

9. The multi-firmware loading optimization method according to claim 2, characterized in that: 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.

10. An embedded system, comprising SoC, ROM, 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 described in any one of claims 1 to 9.

Images