CN119376800B

CN119376800B - A multi-firmware loading optimization method and corresponding embedded system

Info

Publication number: CN119376800B
Application number: CN202411290007.1A
Authority: CN
Inventors: 丁钊; 李立; 杨磊
Original assignee: Zhaoxun Hengda Technology Co ltd
Current assignee: Zhaoxun Hengda Technology Co ltd
Priority date: 2024-09-14
Filing date: 2024-09-14
Publication date: 2025-08-26
Anticipated expiration: 2044-09-14
Also published as: CN119376800A

Abstract

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

Description

Multi-firmware loading optimization method and corresponding embedded system

Technical Field

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

Background

In embedded systems, firmware loading is a critical step in the secure, reliable transition of an electronic device from a powered-off state to an operational state. This process first involves initiating initialization of a medium, such as a 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 securely read, the embedded system loads it into memory, such as RAM (random access memory) or SRAM (static random access memory), and configures the operating mode and register settings of the CPU in preparation for executing the firmware code. The main responsibility of the firmware is to initialize the system hardware and to load or boot an operating system or other high-level software as needed.

With the increasing complexity of firmware functions, the demand for memory space is increasing, which presents challenges to the SRAM capacity inside the SoC (Syst em on Chip, system on a chip). SRAM capacities typically range from 32KB to 256KB, which has made it difficult to meet the increasing storage requirements. In addition, due to compatibility, hardware and process limitations, the SoC cannot cure the code initializing the DDR memory, which results in that the conventional ROM ends its life cycle after loading the boot program (bootloader), thereby limiting the size of the boot program. Accordingly, firmware loading techniques need to accommodate these limitations, ensuring that embedded systems can efficiently initialize and load the necessary firmware components.

In the Chinese patent of the invention with the patent number ZL 201910567474.7, a method and a device for effectively improving the loading speed of the solid state disk firmware are disclosed. The method realizes the efficient flow from the power-on of the chip to the final system firmware carrying to the destination address through the hierarchical processing bootstrap. The method comprises the specific steps of running an internally solidified BootROM (start-up read-only memory) after a chip is electrified, loading boot programs with different poles from Nor flash, initializing a peripheral module, initializing NAND FLASH, loading firmware, and finally carrying out exception handling. Through the hierarchical and staged loading mechanism, the overall loading speed of the SSD system firmware is remarkably improved, and the effectiveness and advantages of the multi-stage firmware loading technology in practical application are demonstrated.

Disclosure of Invention

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

The invention aims to provide an embedded system adopting the multi-firmware loading optimization method.

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

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

s1, when the SoC is powered on, the ROM is used for initialization, and hardware configuration and safety setting are carried out by utilizing the authority of Monit or modes;

S2, the ROM reads the boot program of the first stage from the starting medium and designates a starting mode which needs to be operated;

s3, before executing the bootstrap program, the ROM stores key registers and values of the key registers;

S4, after the ROM loads the bootstrap program of the first stage, setting the key register and the value of the key register, and writing the value of the key register into a preset memory address by utilizing a register window to prepare for executing the bootstrap program of the first stage;

s5, the ROM jumps to a boot program of the first stage by using a mov pc lr instruction and starts execution, and the independence of states in different CPU modes is ensured by using the characteristic of a backup register;

s6, before the boot program in the first stage is executed, switching to the SVC mode of the firmware is carried out, and execution is started on a preset address;

s7, returning to a CPU mode and a safe state where the ROM is by utilizing an SMC instruction after the execution of the boot program in the first stage is completed;

and S8, after the ROM successfully loads and verifies the boot program of the second stage, continuously executing or reloading the boot program according to the CPU mode and the safety state.

Wherein preferably the embedded system employs an ARMv 7-series processor architecture.

Wherein preferably, 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.

Wherein preferably in said step S2 the ROM checks and configures the embedded system control registers, program status registers, before preparing to run the boot program of the first stage.

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

Preferably, in the step S5, before the CPU mode is switched, the state of the key register is saved in the SRAM and backed up in a software manner.

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

Preferably, in the step S8, after the ROM successfully loads the second-stage boot program, it is verified whether the CPU mode and the security state of the second-stage boot program are consistent with the settings of the ROM, if so, the boot process of the second-stage boot program is continuously executed, otherwise, the steps S4 to S7 are repeatedly executed and the second-stage boot program is reloaded.

According to a second aspect of the embodiment of the present invention, there is provided an embedded system, including SoC, ROM, SRAM, wherein the SoC is coupled to the ROM and the SRAM, for implementing the above-mentioned multi-firmware load optimization method.

Compared with the prior art, the multi-firmware loading optimization method provided by the embodiment of the invention realizes staged loading by innovatively utilizing different CPU modes, effectively solves the problem of SRAM capacity limitation, and simultaneously remarkably improves the safety and the functionality of an embedded system. The method allows the embedded system to load complex firmware components to the DDR memory with larger capacity according to the need in the starting process, and is not limited by the storage space of the SRAM. In addition, the method reduces the necessary SRAM capacity, reduces the manufacturing cost and the area of the chip, increases the functionality and the flexibility of the bootstrap program, improves the stability and the reliability of the embedded system, ensures the realization of complex functions, and provides powerful support for protecting the data security of legal users.

Drawings

FIG. 1 is a flow chart diagram of a multi-firmware load optimization method provided by an embodiment of the invention;

FIG. 2 is a detailed flowchart of a multi-firmware load optimization method according to an embodiment of the present invention;

Fig. 3 is a schematic diagram of an embedded system adopting the multi-firmware loading optimization method according to an embodiment of the present invention.

Detailed Description

The technical contents of the present invention will be described in detail with reference to the accompanying drawings and specific examples.

In the conventional embedded system boot process, the ROM (read only memory) is responsible for storing and executing the initial boot code, and after loading the boot loader, the ROM task is usually completed. The embodiment of the invention refers to a mode of Operating System (OS) to run application program (APP), wherein the OS does not end the life cycle of the APP after the APP is run, but runs simultaneously with the APP. Therefore, the multi-firmware loading optimization method provided by the embodiment of the invention allows the ROM and the boot program to take over the execution of the CPU in a time-sharing manner, so that the ROM or the boot program can be executed at any moment, and the ROM or the boot program can not run simultaneously. The ROM does not end its life cycle immediately after the boot program is loaded, but can continue to execute. This design enables time-sharing system control authority take over between the ROM and the boot program.

Specifically, after the boot program has completed its initialization task and completed execution, it does not give control to the operating system, but returns to the ROM. In this way, the ROM can continue to perform other preset tasks or load the boot program of the next stage according to the requirement of the embedded system. The ROM does not directly give control to the operating system after loading and executing a boot program, but continues to remain active. Thus, once the boot program has completed its initialization task, it may choose to return to ROM instead of ending its lifecycle. At this time, the ROM may continue to perform other preset tasks, or load and start the boot program of the next stage according to the start requirement of the embedded system. The process utilizes different running modes of the CPU, ensures that the ROM can maintain the life cycle of the boot program even after the execution of the X (X is a positive integer and the same as the next boot program is finished, and continues the management of control rights and the loading of the subsequent boot program, thereby realizing a flexible and dynamic system starting and updating flow.

The multi-firmware loading optimization method provided by the embodiment of the invention can effectively utilize the DDR memory with large capacity to overcome the problem of the limitation of the SRAM capacity in the prior art, and simultaneously provides greater starting flexibility and functionality. In this process, the first boot program has the responsibility of initializing the DDR memory, after completion, giving control back to the ROM, which is responsible for loading the subsequent boot program into the DDR memory with more space. Because the capacity of the DDR memory is far beyond that of the SRAM, the subsequent boot program is not limited by the size of the SRAM, so that the functionality and flexibility of the boot program are enhanced, the capacity of the SRAM is allowed to be reduced, and only enough space is reserved for storing firmware for initializing the DDR memory, so that the area and cost of a chip are effectively reduced. In addition, the multi-stage loading process of ROM management allows each stage of boot program to focus on specific initialization tasks, e.g., the first boot program is responsible for basic hardware setup, while the subsequent boot program can handle more complex configuration tasks, such as network setup or security function initialization, ensuring the efficiency and stability of system startup. On the other hand, the method also enhances the robustness and reliability of the embedded system. If an error is encountered while executing a certain boot program, the ROM may intervene and take measures, such as reloading the boot program or switching to a standby boot image, thereby ensuring that the system is able to boot stably. This error resilience is critical to ensure the stability of the system in the face of various anomalies.

The following takes an ARMv7 series processor architecture (see, for details, the official reference manual "ARM Architecture Reference Manual ARMv-a and ARMv 7-Redition" issued by the ARM company) as an example, and the specific implementation steps of the multi-firmware loading optimization method provided by the embodiment of the present invention are described in detail with reference to fig. 1 and 2:

s1, initializing the SoC through the ROM when the SoC is powered on, and carrying out hardware configuration and safety setting by utilizing the high authority of a Monitor mode.

When the SoC supporting the Secure Ext ension (secure extension) ARMv7 serial processor architecture is powered on, the embedded system will start the ROM that is cured in the chip. The ROM is used to store boot code as a non-volatile memory that ensures that the embedded system can resume and begin performing the necessary initialization steps even after a power failure.

In the ARMv7 series processor architecture, the SoC operates in Monitor mode by default after power-on, which is the mode with the highest CPU authority level 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 setup adjustments. This mode has complete control over system resources, ensuring that the necessary hardware detection and configuration is enabled at start-up. Monit or mode also has the ability to switch to other modes of the ARM processor and different levels of authority, such as user mode or system mode. This flexibility enables the SoC to dynamically adjust the operating state and permissions of the CPU to perform specific tasks or load subsequent boot code, such as Bootloader, according to different phases and requirements during the boot process. The design not only improves the safety of the system, but also enhances the adaptability to different starting scenes.

Secure Ext ension as an important feature of the ARMv 7-series processor architecture, security of the embedded system is enhanced by distinguishing Secure World (Secure World) from normal World (Non-Secure World). In the secure world, code in Monit or mode can access all resources without limit, while code in the ordinary world is restricted, protecting sensitive operations and data from unauthorized access and potential malicious attacks.

In the Secure Boot (Secure Boot) process, the SoC in Monit or mode first completes hardware initialization, then loads and executes the Boot. The boot program continues to perform further initialization of the embedded system, 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 full running state, and ensures that only authenticated and authorized code is executed, thereby maintaining the integrity and security of the entire embedded system.

S2, the ROM reads a bootstrap program (bootloader 1) of the first stage from the starting medium. In the process of generating bootloader 1, designating the starting mode which needs to be operated, and writing the starting mode of the bootstrap program to the designated position by using a matched mirror image making tool.

ROM plays a critical role in the start-up process of the SoC. Once the embedded system is powered up, the boot code in the ROM is first executed, the primary task of which is to initialize the boot media. These media include eMMC (embedded multimedia card), SD (secure digital card), NAND (a nonvolatile memory technology), etc., which are devices for storing an operating system, application data, and a boot program in an embedded system.

After the initialization of the boot media is completed, the ROM will then read the first phase boot program, bootloader 1, from these media. bootloader 1 is a key component in the starting process of the embedded system, and is responsible for loading and initializing an operating system. In the process of generating bootloader 1, a developer specifies the startup mode that the developer needs to run, and uses a matched mirror image making tool to write the information into the specified position of the bootloader 1 mirror image. This step ensures that bootloader 1 can run in the correct processor mode to match the hardware architecture and security requirements of the embedded system.

Wherein, after generating a binary (bin) file of a boot program during the startup of an embedded system, a special image generation tool is required to create a specific image format. The tool combines information required for starting key ARM mode setting, loading address, execution address and the like with the bin file of the bootstrap program, and encapsulates the information into a complete mirror image file. When the ROM loads the image file, the ROM analyzes information such as ARM mode (the starting mode in the starting process, the user mode and other working modes after the starting process is finished) and loading address, so that the boot program can be started in correct configuration and executed on a preset memory address. This process is a key step to ensure safe, reliable start-up of the embedded system, allowing the ROM to properly initialize hardware and configure the system environment according to preset parameters.

It should be noted that before the ROM is ready to run bootloader 1, it will perform a series of checking and setting operations to ensure that the embedded system can switch correctly to the required ARM mode and security state. This step is critical because it ensures that the boot program can run in a defined, secure execution environment.

Specifically, the ROM checks and configures the CPU's core registers, including embedded system control registers (Sys tem Control Register, abbreviated SCR). The ns bit (unsafe bit) in the SCR is a critical bit field that is used to control whether the CPU is in a safe state. If this bit is set it will instruct the CPU to operate in non-secure mode, and if cleared, the CPU is in secure mode.

In addition to SCR registers, ROM also configures program status registers (Saved Program Status Regist er, abbreviated SPSR). SPSR is used to save certain state information of the CPU, such as modes, interrupt enable states, etc., so that these states can be restored when needed. Proper setting of the SPSR ensures that the CPU can switch to the proper ARM mode and secure state when bootloader 1 is executed, allowing the boot program to run at the proper level of authority.

By these settings, the ROM ensures that bootloader 1 can be booted in a predefined, secure execution environment, which is critical to protecting the boot process of the embedded system from unauthorized access or potential attacks. Once these registers are properly configured, the ROM will jump to the entry point of bootloader 1, begin executing the code of the boot program, and continue the boot sequence of the embedded system.

And S3, before the boot program is executed, the ROM stores key registers and necessary data of the ARM core.

In the ARMv7 family of processor architectures, ROM performs a critical operation, namely saving the critical registers and necessary data of the ARM core, prior to execution of the boot program. These registers include, but are not limited to, program status registers (SPSR), embedded System Control Registers (SCR), control registers (CTLR), program Counters (PC), stack Pointers (SP) and Link Registers (LR), and general purpose registers R0 through R14.

The preservation of these critical registers is critical because they contain the current state of the processor and context information. For example, SPSR is typically used to save current program states, including processor mode, interrupt enable state, etc., SCR contains important information to control CPU security state and exception level, while PC, SP, and LR indicate current program execution location, top of stack, and subroutine return address, respectively.

By saving the values of these critical registers, the ROM can be restored to a saved state when needed, ensuring that the processor can continue to operate from an interrupt or exception safely back to the correct execution point. This mechanism is critical to the stability and reliability of the embedded system, especially when dealing with complex startup procedures or making embedded system calls.

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

S4, after the ROM loads the bootstrap program (bootloader 1) of the first stage, setting key registers and necessary data of the ARM Core.

In the SoC of the ARMv7 serial processor architecture, the ROM, after loading bootloader 1, performs a fine operation of setting the critical registers and necessary data of the ARM Core. This includes setting the values of program status register (SPSR), embedded System Control Register (SCR), control register (CTLR), program Counter (PC), stack Pointer (SP), link Register (LR), and general purpose registers R0 through R14 to the locations specified by the LR return address.

The purpose of this step is to be able to accurately restore to the previous state after bootloader 1 is executed. By writing the values of these critical registers to predetermined memory addresses, the ROM ensures that after bootloader 1 is executed, subsequent boot flow can continue by seamlessly returning to the appropriate location in the ROM via these saved state information.

In addition, this arrangement also embodies an important feature of the ARM architecture, namely a register window (Regist er Banking, specifically a set of repeated register sets, each mode having its own copy of registers when the processor switches from one mode to another, it transparently switches to the corresponding mode register set, protecting the context and data of each mode) in different CPU modes, the same register names may point to different physical registers. Thus, by writing register values into memory, ROM is able to maintain continuity and consistency of these key values as it switches between different modes.

Finally, when bootloader 1 completes its task and returns to ROM via SMC (Secure monitor call, security monitoring call) instructions or other mechanisms, ROM can resume to the correct ARM mode and secure state using the previously saved register state, continuing to execute the startup sequence of the embedded system. This ensures the smoothness of the overall start-up process and the stability of the embedded system.

S5, the ROM jumps to bootloader 1 for execution by using the mov pc lr instruction, and ensures the independence of states in different CPU modes by utilizing the characteristic of a backup register, so that the respective register values and state information are maintained when the execution environment is switched.

In the SoC of the ARMv 7-series processor architecture, after the ROM completes the preparation work of bootloader 1, the mov pc lr instruction is used to realize the address execution to jump to bootloader 1. The mov PC LR instruction is a basic instruction in the ARM instruction set to move the value in the Link Register (LR) into the Program Counter (PC) to change the execution flow of the CPU to the new location pointed to by the LR. Before this, LR has been set to the entry address pointing to bootloader 1, and the status register and the like are also configured appropriately.

After executing the mov pc lr instruction, the ARM core will use state information such as the CPU mode, security state (s ecure s tate), stack (s stack) and the like set previously. This state information ensures that when control passes to bootloader 1, it can run in a predefined, correct execution environment. At the same time, the registers and stack information utilized by the ROM are saved to Static Random Access Memory (SRAM) so that the state of ROM execution can be restored when needed.

The backup register (banked regist er) nature of the CPU modes supported by the ARMv 7-series processor architecture allows for a common name but physically independent register set to exist for different CPU modes. This means that when switching from one CPU mode to another, the corresponding register values will remain in the registers of the respective modes without interfering with each other. For example, when switching from Monit or mode of ROM operation (Monit or mode) to another mode of firmware operation, each mode has its own set of registers, thereby ensuring that the execution state of ROM and the execution state of firmware do not conflict with each other.

In one embodiment of the invention, the ROM also provides a software backup method to cope with the need for CPU mode switching in the case of limited memory resources. Before switching the CPU mode, the state of the key register can be saved in the SRAM and backed up in a software mode. This approach requires an extra SRAM space, about 300 bytes, for storing these backed up register states. Once the original execution environment needs to be returned, the backup register states can be recovered from the SRAM, so that the continuity and stability of the embedded system are ensured.

S6, before executing the bootstrap program (bootloader 1) of the first stage, the ARM core switches the SVC mode to the firmware and starts to execute at a preset address.

Before executing bootloader 1, the ARM core switches to SVC (Supervisory call) mode of firmware, and starts executing at preset address (starting address of bootloader 1 in memory). This mode switch is a function supported by the ARMv 7-series processor architecture that allows software to change the operating mode of the processor by setting specific registers.

In the ARMv7 family of processor architectures, SVC mode is a privileged mode commonly used to handle embedded system calls of operating systems. 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 boot program needs to perform hardware initialization and configuration.

To achieve this mode switching, a plurality of registers including a program status register (SPSR), a Link Register (LR), and the like need to be provided. 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 if necessary. When the ROM completes the preparation for bootloader 1, it sets a Program Counter (PC) and a Link Register (LR) to the above-mentioned preset address.

By setting the LR register, the embedded system defines the address that should be returned after the code in SVC mode is executed. The SPSR stores program state information in the current mode, including a processor mode, an interrupt enable state, etc., so that the SVC mode can be restored to a correct state after the execution is completed.

And S7, after the execution of the boot program in the first stage is finished, returning to a CPU mode and a safe state where the ROM is by utilizing an SMC instruction, and ensuring that the control right of the embedded system is returned to the starting code of the embedded system.

When bootloader 1 completes its execution, it returns to the CPU mode and secure state where ROM is located using SMC instructions. SMC instructions are a special instruction introduced in the ARMv7 family of processor architectures to switch between secure and non-secure world, or from application mode to Monitor mode. In this case, the SMC instruction is used to securely return from bootloader 1 to ROM, ensuring that control of the embedded system is passed back to the boot code of the embedded system.

In order to process the SMC instructions, an assembly function must be implemented in the ROM code that defines how the embedded system should respond when triggered by the SMC instructions. The secure extension of ARMv7 supports SMC instructions that, when executed, the ARMv7 core hardware will jump to execution at a pre-set SMC exception entry, allowing the embedded system to handle security related operations or to perform mode switching.

Before bootloader 1 executes an SMC instruction, it needs to specify the address where the next boot program to be loaded in ROM is stored on Flash (Flash) by setting the SMC parameter. Since ROM typically loads Bootloader 1 from a fixed flash address, for subsequent bootloaders, they may be stored at different addresses of the flash, depending on the application scenario. bootloader 1, by setting these parameters, provides the ROM with the exact location of the next boot program, ensuring that the embedded system can continue to load and initialize in a predetermined boot 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.

And S8, after the ROM of the embedded system successfully loads the second-stage bootstrap program, verifying whether the CPU mode and the security state of the second-stage bootstrap program are consistent with the setting of the ROM, if so, continuing to execute the boot process of the second-stage bootstrap program, otherwise, repeatedly executing the steps S4-S7 by the ROM and reloading the second-stage bootstrap program.

Specifically, after the ROM successfully reads the second stage boot program (bootloader 2) from the specified flash address, the embedded system checks whether the CPU mode and security state of bootloader2 match the settings of the ROM. If bootloader2 is configured with the same CPU mode and security state as ROM, then after bootloader2 is executed, ROM lifecycle will end, embedded system will enter boot flow guided by bootloader2 completely, and continue subsequent operating system loading or other initialization tasks.

However, if the CPU mode and security state of bootloader2 are inconsistent with those set by the ROM, the embedded system will not continue to execute bootloader2, but will repeat S4-S7 before. This means that the ROM will reload bootloader2, check again and set the correct CPU mode and security status, and then try again to execute bootloader2. This process ensures that the embedded system remains in the correct execution environment and security level at each mode switch.

It should be noted that if any error occurs in this process, for example, the SMC parameter set by Bootloader2 is incorrect, or the ROM is incorrect when attempting to read the flash memory, or the Bootloader image content read from the flash memory is incorrect, the embedded system will not continue to execute Bootloader2. Instead, the ROM will initiate an error recovery procedure, jumping to a download mode. In this download mode, the embedded system may attempt to reload Bootloader from an external source or perform other recovery operations to ensure the stability and security of the embedded system. The design provides an error handling mechanism with good robustness for the embedded system, and ensures that proper measures can be taken for recovery when problems are encountered.

On the basis of the multi-firmware loading optimization method, the embodiment of the invention further provides an embedded system adopting the multi-firmware loading optimization method. As shown in fig. 3, the embedded system includes at least a SoC, a ROM, and an SRAM, wherein the SoC is coupled with the ROM and the SRAM.

In one embodiment of the present invention, after the embedded system is powered on, the Monitor mode is first entered, and the boot code in the ROM is executed. The ROM initializes necessary hardware devices including a memory controller, a clock system, and the like. The ROM reads the first phase boot program from Flash or other boot media and checks its security and integrity. Depending on the instruction of the boot program, the ROM may switch CPU mode or secure state and then jump to the execution address of the boot program.

The boot loader 1 in the first stage is responsible for initializing critical hardware such as DDR memory and preparing the embedded system to enter a higher level boot stage. After execution, bootloader 1 returns to ROM via SMC instructions or other mechanisms and specifies the storage address of the second stage boot program.

The ROM loads the second stage boot program (bootloader 2) according to the specified address, which can be responsible for finer hardware configuration and system detection. It should be noted that in the embodiment of the present invention, there may be more stages of bootstrap programs, for example bootloader3, bootloader4, bootloader5.

If an error is encountered during the loading or execution of the boot program, such as a failure to read or verify, the embedded system will enter an error recovery procedure. Specific actions may include re-downloading the boot program from a network or other external medium, or switching to a standby system image.

After a series of bootstraps, the operating system kernel and necessary system services are finally loaded. The operating system takes over control rights to complete the rest of system initialization, including loading of device drivers and starting of network services.

In a preferred embodiment of the invention, the embedded system may take advantage of the Secure Ext ension (secure extension) feature of the ARMv7 family of processor architecture to ensure that critical boot code is executed in the secure world. And meanwhile, the SMC instruction is used for switching between a safe state and a non-safe state, so that the safety of the embedded system and the integrity of data are protected.

By the multi-firmware loading optimization method, the embedded system can realize a quick, safe and flexible starting process and has strong error recovery capability. The design is particularly suitable for application scenes with extremely high requirements on safety and reliability, such as automotive electronics, industrial control and high-end consumer electronics.

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

1. And the expansion capacity is realized by utilizing different running modes of the CPU, so that different firmware components are allowed to be loaded in stages in the starting process of the embedded system, the limit of the SRAM capacity is broken through, and a storage medium with larger capacity, such as a DDR memory, can be used by the ROM.

2. The method improves the functionality and the flexibility, allows the boot program to return to the ROM after the execution is finished, and loads the subsequent boot program according to the requirement, so that the time-sharing take-over mechanism not only improves the functionality of the system, but also increases the flexibility of the system.

3. The cost and the chip area are reduced, and the capacity of the SRAM is reduced, so that only enough space is reserved for storing necessary firmware, thereby reducing the area and the manufacturing cost of the chip.

4. The method supports complex functions, the bootstrap program is not limited by the size of the SRAM any more, more complex functions can be designed, and the processing capacity and the application range of the embedded system are enhanced.

5. The system stability is improved, namely, potential errors in the starting process of the embedded system are reduced and the overall stability and reliability are improved through staged loading and accurate control of firmware execution.

It should be noted that the above embodiments are merely examples. The technical schemes of the embodiments can be combined, and all the technical schemes are within the protection scope of the invention.

In addition, the terms "first," "second," are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature. In the description of the present invention, the meaning of "a plurality" is two or more, unless explicitly defined otherwise.

The multi-firmware loading optimization method and the corresponding embedded system provided by the invention are described in detail. Any obvious modifications to the present invention, without departing from the spirit thereof, would constitute an infringement of the patent rights of the invention and would take on corresponding legal liabilities.

Claims

1. The multi-firmware loading optimization method is suitable for an embedded system and is characterized by comprising the following steps of:

S1, when the SoC is powered on, the ROM is used for initialization, and hardware configuration and safety setting are carried out by utilizing the authority of a Monitor mode;

2. The multi-firmware load optimization method of claim 1, wherein:

The embedded system adopts an ARMv7 series processor architecture.

3. The multi-firmware load optimization method of claim 2, wherein:

In step S1, a boot program is executed in the secure world using the secure extension feature of the ARMv7 processor architecture.

4. The multi-firmware load optimization method of claim 2, wherein:

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

5. The multi-firmware load optimization method of claim 2, wherein:

In step S3, the key registers include, but are not limited to, program status registers, embedded system control registers, program counters, stack pointers, and link registers.

6. The multi-firmware load optimization method of claim 2, wherein:

in the step S5, before switching the CPU mode, the state of the key register is saved in the SRAM and backed up in a software manner.

7. The multi-firmware load optimization method of claim 2, wherein:

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

8. The multi-firmware load optimization method of claim 2, wherein:

In the step S8, after the ROM successfully loads the second-stage boot program, verifying whether the CPU mode and the security state of the second-stage boot program are consistent with the setting of the ROM, if so, continuing to execute the boot process of the second-stage boot program, otherwise, repeatedly executing the steps S4-S7 and reloading the second-stage boot program.

9. An embedded system comprising SoC, ROM, SRAM, wherein the SoC is coupled to the ROM and the SRAM, for implementing the multi-firmware load optimization method of any one of claims 1-8.