System starting method and device suitable for multiple chips, electronic equipment and readable storage medium
By employing a preloader, bootloader, and multiple signature verifications and device tree adaptations within the power transmission system, various chip management challenges were resolved, achieving stability and consistency management of the power transmission system and reducing operation and maintenance costs.
Patent Information
- Application Number
- CN202411628625.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-14
- Publication Date
- 2025-11-25
- Estimated Expiration
- 2044-11-14
Smart Images

Figure CN119576435B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of operating system technology, specifically to a system booting method, apparatus, electronic device, and readable storage medium adapted to various chips. Background Technology
[0002] In modern power transmission systems, real-time monitoring and data acquisition during the transmission process are crucial to ensuring the stability and reliability of power transmission. Transmission data acquisition terminals are essential devices for monitoring the power transmission process. These terminals can monitor parameters such as voltage, current, and temperature of power lines, and promptly obtain relevant data on the operating status of transmission lines, thereby effectively preventing faults and ensuring the safe operation of the power system. To meet the ever-increasing power demand, the number of transmission data acquisition terminals is increasing year by year, thus placing higher demands on the hardware and software systems of these terminals.
[0003] Power transmission data acquisition terminals typically employ a hardware architecture that includes chips. However, due to the large number of terminals, chips from a single brand cannot meet the needs of all devices. This necessitates the use of different types of chips from multiple suppliers. However, chips from different manufacturers vary significantly in terms of bootloaders, drivers, and interface specifications. Consequently, different chips support different operating system platforms, making it difficult for power companies to achieve unified management and maintenance of all power transmission data acquisition terminals. This diverse chip solution leads to system adaptation complexity, increases operation and maintenance costs, and reduces the overall management efficiency of the system.
[0004] Under current technological conditions, different chips often require customized operating systems to adapt to their hardware platforms. The high degree of dependency between each operating system and specific hardware limits the software's versatility and compatibility, forcing power companies to perform separate maintenance and management operations for different hardware platforms when managing terminals. This not only increases the workload of system development and maintenance but also affects the scalability and long-term operational stability of the equipment. Ensuring the security and consistency of the entire power transmission monitoring system in the presence of multiple terminal platforms has also become a significant challenge. Summary of the Invention
[0005] To address the problems in the related technologies, this disclosure provides a system booting method, apparatus, electronic device, and readable storage medium that are compatible with various chips.
[0006] In a first aspect, this disclosure provides a system boot method adapted to multiple chips, including:
[0007] The preloader is started to obtain the bootloader image and device tree information, and the preloader is executed to start the bootloader; the device tree information includes the hardware information of the embedded system, and the hardware information includes the device path and device configuration parameters of the device differences between the various chips.
[0008] The bootloader is executed to verify the signature of the preloader;
[0009] In response to the preloader's signature verification being successful, the kernel OS image of the kernel OS is obtained, and the bootloader is executed to verify the signature of the kernel OS image;
[0010] In response to the bootloader verifying the kernel OS image, the bootloader is executed to start the kernel OS; the device tree includes a watchdog timer, which is used to perform a reset operation on the kernel OS when the kernel OS boot exceeds a preset time;
[0011] The kernel OS is executed to verify the signatures of the bootloader image and the preloader.
[0012] In response to the kernel OS verifying the signatures of the bootloader image and the preloader, the kernel OS performs signature verification on the root file system.
[0013] In response to the successful signature verification of the root file system, the root file system is loaded into memory;
[0014] The bootloader image includes a main bootloader image and a backup bootloader image. The step of executing the preloader to start the bootloader includes:
[0015] Load the bootloader main image into memory and verify the bootloader main image;
[0016] If the bootloader main image verification is successful, continue executing the bootloader main image;
[0017] If the bootloader master image verification fails, the bootloader backup image is loaded into memory and verified.
[0018] If the bootloader backup image is successfully verified, after repairing the bootloader main image based on the bootloader backup image, the bootloader main image will continue to be executed.
[0019] The kernel OS image includes a kernel OS primary partition image and a kernel OS backup partition image. The execution of the bootloader to verify the signature of the kernel OS includes:
[0020] The bootloader loads the kernel OS main partition image into memory and verifies the kernel OS main partition image.
[0021] If the kernel OS main partition image verification is successful, continue with the kernel OS main partition image processing.
[0022] If the kernel OS primary partition image verification fails, the kernel OS backup partition image is loaded into memory and verified.
[0023] If the kernel OS backup partition image is successfully verified, after repairing the kernel OS main partition image based on the kernel OS backup partition image, the kernel OS main partition image will continue to be processed.
[0024] According to embodiments of this disclosure, executing the bootloader to start the kernel OS includes:
[0025] The bootloader transmits the device tree information to the kernel OS;
[0026] The kernel OS main partition image and the device tree information are loaded into memory and the kernel OS main partition image is executed.
[0027] According to an embodiment of this disclosure, after the bootloader main image is successfully verified and execution of the bootloader main image continues, the method further includes:
[0028] The preloader loads the signature verification information of the bootloader master image into a specified memory address and saves it.
[0029] According to embodiments of this disclosure, the step of executing the kernel OS to verify the signatures of the bootloader image and the preloader includes:
[0030] Obtain the signature information of the bootloader image and calculate the first hash value of the signature information of the bootloader image;
[0031] Obtain the specified memory address of the preloader and calculate the second hash value of the signature verification information of the bootloader main image;
[0032] If the first hash value matches the second hash value, the kernel OS verifies the bootloader signature information and the preloader signature; otherwise, it stops loading the root file system and waits for the watchdog timer to reset.
[0033] According to embodiments of this disclosure, the watchdog timer is used to perform a reset operation on the kernel OS when the kernel OS has run for a preset time, including:
[0034] The kernel OS obtains the watchdog timer's feeding interface through the device tree;
[0035] If the initialization of the relevant subsystems of the kernel OS is not completed, the kernel OS will manually feed the watchdog timer at preset time intervals.
[0036] If the relevant subsystems of the kernel OS are initialized, the kernel timer of the kernel OS is used to perform a timed dog-feeding operation; the subsystem includes the kernel timer.
[0037] According to embodiments of this disclosure, loading the root file system into memory in response to successful signature verification of the root file system includes:
[0038] The first file system module in the root file system is read-only mounted into the memory;
[0039] The second file system module in the root file system is stored in a preset directory location. The second file system module consists of configurations and files in the root file system that need to be modified frequently.
[0040] Secondly, this disclosure provides a system boot device adapted to multiple chips, including:
[0041] The first startup module is configured to start a preloader, obtain the bootloader image and device tree information, and execute the preloader to start the bootloader; the device tree information includes the hardware information of the embedded system, and the hardware information includes the device path and device configuration parameters of the device differences between the various chips.
[0042] The first signature verification module is configured to execute the bootloader to verify the signature of the preloader.
[0043] The second signature verification module is configured to, in response to the preloader's signature verification being successful, obtain the kernel OS image of the kernel OS and execute the bootloader to verify the signature of the kernel OS image;
[0044] The second boot module is configured to execute the bootloader to start the kernel OS in response to the bootloader's successful verification of the kernel OS image; the device tree includes a watchdog timer, which is used to perform a reset operation on the kernel OS when the kernel OS boot exceeds a preset time.
[0045] The third signature verification module is configured to execute the kernel OS to verify the signatures of the bootloader image and the preloader.
[0046] The fourth signature verification module is configured to execute the kernel OS to verify the signature of the root file system in response to the kernel OS's successful verification of the bootloader image and the preloader.
[0047] The loading module is configured to load the root file system into memory in response to the root file system's signature verification being successful;
[0048] The bootloader image includes a main bootloader image and a backup bootloader image. The first boot module includes:
[0049] The first verification submodule is configured to load the bootloader main image into memory and verify the bootloader main image.
[0050] The first execution submodule is configured to continue executing the bootloader main image if the bootloader main image verification is successful.
[0051] The second verification submodule is configured to load the bootloader backup image into memory and verify the bootloader backup image if the verification of the bootloader main image fails.
[0052] The second execution submodule is configured to, if the bootloader backup image is successfully verified, continue to execute the bootloader main image after repairing the bootloader main image based on the bootloader backup image;
[0053] The second signature verification module includes:
[0054] The third verification submodule is configured to load the kernel OS main partition image into memory by the bootloader and verify the kernel OS main partition image.
[0055] The third execution submodule is configured to continue executing the kernel OS main partition image if the kernel OS main partition image verification is successful.
[0056] The fourth verification submodule is configured to load the kernel OS backup partition image into memory and verify the kernel OS backup partition image if the verification of the kernel OS main partition image fails.
[0057] The fourth execution submodule is configured to, if the kernel OS backup partition image verification is successful, continue to execute the kernel OS main partition image after repairing the kernel OS main partition image based on the kernel OS backup partition image.
[0058] According to an embodiment of this disclosure, the second startup module includes:
[0059] The delivery submodule is configured to allow the bootloader to pass the device tree information to the kernel OS;
[0060] The first loading submodule is configured to load the kernel OS main partition image and the device tree information into memory and execute the kernel OS main partition image.
[0061] According to embodiments of this disclosure, after the first execution submodule, the apparatus further includes:
[0062] The second loading submodule is configured to load the signature information of the bootloader master image into a specified memory address of the preloader and save it.
[0063] According to embodiments of this disclosure, the third signature verification module includes:
[0064] The first calculation submodule is configured to obtain the signature information of the bootloader image and calculate the first hash value of the signature information of the bootloader image.
[0065] The second calculation submodule is configured to obtain a specified memory address of the preloader and calculate the second hash value of the signature verification information of the bootloader main image;
[0066] The matching submodule is configured such that if the first hash value matches the second hash value, the kernel OS verifies the bootloader signature information and the preloader signature; otherwise, it stops loading the root file system and waits for the watchdog timer to reset.
[0067] According to embodiments of this disclosure, the watchdog timer includes:
[0068] The acquisition submodule is configured so that the kernel OS can obtain the watchdog timer's feed interface through the device tree;
[0069] The manual watchdog timer submodule is configured to manually feed the watchdog timer at preset time intervals if the relevant subsystem initialization of the kernel OS is not completed.
[0070] The timed dog-feeding submodule is configured to perform a timed dog-feeding operation using the kernel timer of the kernel OS once the relevant subsystem of the kernel OS has been initialized; the subsystem includes the kernel timer.
[0071] According to embodiments of this disclosure, the loading module includes:
[0072] The mounting submodule is configured to read-only mount the first file system module in the root file system into the memory;
[0073] The storage submodule is configured to store the second file system module in the root file system according to a preset directory location. The second file system module consists of configurations and files in the root file system that need to be modified frequently.
[0074] Thirdly, embodiments of this disclosure provide an electronic device including a memory and a processor, wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method as described in any of the first aspects.
[0075] Fourthly, this disclosure provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the method described in the first aspect.
[0076] According to the technical solution provided in the embodiments of this disclosure, in order to solve the above-mentioned technical problems, this invention discloses a system boot method adapted to multiple chips, comprising: starting a preloader, obtaining a bootloader image and device tree information, and executing the preloader to start a bootloader; the device tree information includes hardware information of the embedded system, and the hardware information includes device paths and device configuration parameters of the device differences between the multiple chips; executing the bootloader to verify the signature of the preloader; in response to the preloader signature verification being passed, obtaining a kernel OS image of the kernel OS, and executing the bootloader to verify the signature of the kernel OS image; in response to the bootloader... The program verifies the signature of the kernel OS image and executes the bootloader to start the kernel OS. The device tree includes a watchdog timer, which is used to perform a reset operation on the kernel OS when the kernel OS startup exceeds a preset time. The kernel OS verifies the signature of the bootloader image and the preloader. In response to the kernel OS verifying the signature of the bootloader image and the preloader, the kernel OS verifies the signature of the root file system. In response to the root file system verifying the signature, the root file system is loaded into memory. The bootloader image includes a main bootloader image and a bootloader backup. The process of executing the bootloader preloader to start the bootloader image includes: loading the main bootloader image into memory and verifying the main bootloader image; if the main bootloader image verification is successful, continuing to execute the main bootloader image; if the main bootloader image verification fails, loading the backup bootloader image into memory and verifying the backup bootloader image; if the backup bootloader image verification is successful, after repairing the main bootloader image based on the backup bootloader image, continuing to execute the main bootloader image; the kernel OS image includes the kernel OS main partition image. The process of executing the bootloader to verify the kernel OS, along with the kernel OS backup partition image, includes: the bootloader loading the kernel OS main partition image into memory and verifying it; if the kernel OS main partition image verification is successful, continuing to execute the kernel OS main partition image; if the kernel OS main partition image verification fails, loading the kernel OS backup partition image into memory and verifying it; if the kernel OS backup partition image verification is successful, after repairing the kernel OS main partition image based on the kernel OS backup partition image, continuing to execute the kernel OS main partition image.
[0077] According to the technical solution disclosed herein, through multiple forward and reverse measurements between the preloader, bootloader, kernel OS, and root file system, it can be ensured that the bootloader and kernel OS in the embedded system are authorized by the manufacturer and have not been tampered with, forming a closed-loop management of operating system verification and ensuring the integrity and trustworthiness of the software running in the terminal. In addition, by setting up a device tree compatible with the differences in various chips, the bootloader and kernel OS can call the device tree to enable various different chips to call hardware devices, thereby improving the compatibility of the embedded system.
[0078] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description
[0079] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments, taken in conjunction with the accompanying drawings. In the drawings:
[0080] Figure 1 A flowchart illustrating a system startup method adapted to various chips according to embodiments of the present disclosure is shown.
[0081] Figure 2 A flowchart illustrating the preloader signature verification process in a bootloader within a system startup method adapted to various chips according to embodiments of the present disclosure is shown.
[0082] Figure 3 A flowchart illustrating the kernel OS signature verification process in the bootloader of a system boot method adapted to various chips according to embodiments of the present disclosure is shown.
[0083] Figure 4 A structural block diagram of a system startup apparatus adapted to various chips according to embodiments of the present disclosure is shown.
[0084] Figure 5 This diagram illustrates a structural block diagram of the first boot module in a bootloader of a system boot method adapted to various chips according to an embodiment of the present disclosure.
[0085] Figure 6 This diagram illustrates the structure of the second signature verification module in the bootloader of a system boot method adapted to various chips according to an embodiment of the present disclosure.
[0086] Figure 7 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown.
[0087] Figure 8 A schematic diagram of the structure of a computer system suitable for implementing the method according to embodiments of the present disclosure is shown. Detailed Implementation
[0088] In the following, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings to enable those skilled in the art to readily implement them. Furthermore, for clarity, portions unrelated to the description of exemplary embodiments have been omitted from the drawings.
[0089] In this disclosure, it should be understood that terms such as “comprising” or “having” are intended to indicate the presence of features, figures, steps, behaviors, components, parts or combinations thereof disclosed in this specification, and are not intended to exclude the possibility of the presence or addition of one or more other features, figures, steps, behaviors, components, parts or combinations thereof.
[0090] It should also be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.
[0091] In this disclosure, any operation involving the acquisition of user information or user data, or the display of user information or user data to others, is an operation authorized or confirmed by the user, or actively selected by the user.
[0092] In modern power transmission systems, real-time monitoring and data acquisition during the transmission process are crucial to ensuring the stability and reliability of power transmission. Transmission data acquisition terminals are essential devices for monitoring the power transmission process. These terminals can monitor parameters such as voltage, current, and temperature of power lines, and promptly obtain relevant data on the operating status of transmission lines, thereby effectively preventing faults and ensuring the safe operation of the power system. To meet the ever-increasing power demand, the number of transmission data acquisition terminals is increasing year by year, thus placing higher demands on the hardware and software systems of these terminals.
[0093] Power transmission data acquisition terminals typically employ a hardware architecture that includes chips. However, due to the large number of terminals, chips from a single brand cannot meet the needs of all devices. This necessitates the use of different types of chips from multiple suppliers. However, chips from different manufacturers vary significantly in terms of bootloaders, drivers, and interface specifications. Consequently, different chips support different operating system platforms, making it difficult for power companies to achieve unified management and maintenance of all power transmission data acquisition terminals. This diverse chip solution leads to system adaptation complexity, increases operation and maintenance costs, and reduces the overall management efficiency of the system.
[0094] Under current technological conditions, different chips often require customized operating systems to adapt to their hardware platforms. The high degree of dependency between each operating system and specific hardware limits the software's versatility and compatibility, forcing power companies to perform separate maintenance and management operations for different hardware platforms when managing terminals. This not only increases the workload of system development and maintenance but also affects the scalability and long-term operational stability of the equipment. Ensuring the security and consistency of the entire power transmission monitoring system in the presence of multiple terminal platforms has also become a significant challenge.
[0095] To address the aforementioned technical problems, this invention discloses a system boot method adaptable to multiple chips, comprising: starting a preloader, acquiring a bootloader image and device tree information, and executing the preloader to start a bootloader; the device tree information includes hardware information of the embedded system, and the hardware information includes device paths and device configuration parameters for the device differences between the various chips; executing the bootloader to verify the signature of the preloader; in response to the preloader's successful signature verification, acquiring a kernel OS image of the kernel OS, and executing the bootloader to verify the signature of the kernel OS image; in response to the bootloader's verification of the kernel OS image... If the signature is approved, the bootloader is executed to start the kernel OS; the device tree includes a watchdog timer, which is used to perform a reset operation on the kernel OS when the kernel OS startup exceeds a preset time; the kernel OS is executed to verify the signature of the bootloader image and the preloader; in response to the kernel OS verifying the signature of the bootloader image and the preloader, the kernel OS is executed to verify the signature of the root file system; in response to the root file system verifying the signature, the root file system is loaded into memory; wherein, the bootloader image includes a bootloader main image and a bootloader backup image, and the execution of the device tree includes a watchdog timer, which is used to reset the kernel OS when the kernel OS startup exceeds a preset time; the kernel OS is executed to verify the signature of the bootloader image and the preloader; in response to the kernel OS verifying the signature of the root file system, the root file system is loaded into memory; wherein, the bootloader image includes a bootloader main image and a bootloader backup image, and the execution of the device tree includes a watchdog timer, which is used to reset the kernel OS when the kernel OS startup exceeds a preset time; the kernel OS is executed to verify the signature of the bootloader image and the preloader; in response to the kernel OS verifying the signature of the root file system, the kernel OS is executed to verify the signature of the root file system; in response to the root file system ... kernel OS is executed to verify the signature of the root file system; in response to the root file system verifying the signature of the root file system, the kernel OS is executed to verify the signature of the root file system; The preloader starts the bootloader, including: loading the bootloader main image into memory and verifying the bootloader main image; if the bootloader main image verification is successful, continuing to execute the bootloader main image; if the bootloader main image verification fails, loading the bootloader backup image into memory and verifying the bootloader backup image; if the bootloader backup image verification is successful, after repairing the bootloader main image according to the bootloader backup image, continuing to execute the bootloader main image; the kernel OS image includes the kernel OS main partition image and the kernel OS image. The process of executing the bootloader to verify the kernel OS backup partition image includes: the bootloader loading the kernel OS main partition image into memory and verifying the kernel OS main partition image; if the kernel OS main partition image verification is successful, the process of executing the kernel OS main partition image continues; if the kernel OS main partition image verification fails, the kernel OS backup partition image is loaded into memory and verified; if the kernel OS backup partition image verification is successful, after repairing the kernel OS main partition image based on the kernel OS backup partition image, the process of executing the kernel OS main partition image continues.
[0096] According to the technical solution disclosed herein, through multiple forward and reverse measurements between the preloader, bootloader, kernel OS, and root file system, it can be ensured that the bootloader and kernel OS in the embedded system are authorized by the manufacturer and have not been tampered with, forming a closed-loop management of operating system verification and ensuring the integrity and trustworthiness of the software running in the terminal. In addition, by setting up a device tree compatible with the differences in various chips, the bootloader and kernel OS can call the device tree to enable various different chips to call hardware devices, thereby improving the compatibility of the embedded system.
[0097] Figure 1 A flowchart illustrating a system startup method adapted to various chips according to embodiments of the present disclosure is shown. Figure 1 As shown, the system startup method for adapting to multiple chips includes the following steps S101-S107:
[0098] In step S101, the preloader is started to obtain the bootloader image and device tree information, and the preloader is executed to start the bootloader. The device tree information includes the hardware information of the embedded system, and the hardware information includes the device paths and device configuration parameters of the device differences between the various chips. The preloader is an early loading stage program in the embedded system startup process. It runs first when the system is powered on or reset, and is used to prepare the hardware environment for the subsequent bootloader, such as initializing the clock, GPIO, DDR memory, etc. It can also read the bootloader from non-volatile memory into memory and transfer control to the bootloader.
[0099] According to embodiments of this disclosure, a device tree is a data structure used to describe the hardware configuration of an embedded system. Its main purpose is to allow the operating system kernel to operate independently of specific hardware configurations. The device tree includes hardware information of the embedded system, such as device name, device path, and device configuration parameters. Furthermore, the device tree includes device paths and device configuration parameters that differ between various chips, enabling it to adapt to the hardware information access needs of different chips and achieve compatibility of the embedded system.
[0100] Figure 2 This diagram illustrates a flowchart of the preloader signature verification process in a system boot method adapted to various chips according to embodiments of the present disclosure. Figure 2 As shown, the bootloader image includes a main bootloader image and a backup bootloader image. Step S101 includes:
[0101] In step S1011, the bootloader main image is loaded into memory, and the bootloader main image is verified.
[0102] In step S1012, if the bootloader main image verification is successful, the bootloader main image continues to be executed;
[0103] In step S1013, if the bootloader master image verification fails, the bootloader backup image is loaded into memory and the bootloader backup image is verified.
[0104] In step S1014, if the bootloader backup image verification is successful, after repairing the bootloader main image based on the bootloader backup image, the bootloader main image continues to be executed.
[0105] In this embodiment, by setting a main image and a backup image for the bootloader, the backup image can be used to repair the main image and start the bootloader when the main image of the bootloader encounters an error or fails to verify the signature, thereby improving the stability and security of the embedded system.
[0106] In step S102, the bootloader is executed to verify the signature of the preloader. After the bootloader starts, it reverse-verifies the electronic signature of the preloader to ensure that the preloader is trustworthy and has not been tampered with, and at the same time ensures that the subsequently loaded bootloader and kernel OS are trustworthy, thus guaranteeing the security of the embedded system.
[0107] In step S103, in response to the preloader's successful signature verification, the kernel OS image is obtained, and the bootloader is executed to verify the signature of the kernel OS image. After the bootloader starts, it needs to start the kernel OS, import the kernel OS image into memory, and verify the electronic signature of the kernel OS image to ensure that the kernel OS image is authorized and has not been altered.
[0108] Figure 3 This diagram illustrates a flowchart of kernel OS signature verification in a bootloader within a system boot method adapted to various chips according to embodiments of the present disclosure. Figure 3 As shown, step S103 includes:
[0109] In step S1031, the bootloader loads the kernel OS main partition image into memory and verifies the kernel OS main partition image;
[0110] In step S1032, if the kernel OS main partition image verification is successful, the kernel OS main partition image is then executed.
[0111] In step S1033, if the kernel OS main partition image verification fails, the kernel OS backup partition image is loaded into memory and verified.
[0112] In step S1034, if the kernel OS backup partition image verification is successful, after repairing the kernel OS main partition image based on the kernel OS backup partition image, the kernel OS main partition image is then executed.
[0113] By configuring a primary and backup image for the kernel OS, the backup image can be used to repair the primary image and start the bootloader when the primary bootloader image encounters errors or fails signature verification, thus improving the stability and security of the embedded system. Additionally, the kernel OS obtains the device tree from the bootloader and loads the drivers and configuration files for the embedded system's hardware devices using this tree.
[0114] In step S104, in response to the bootloader passing the kernel OS image verification, the bootloader is executed to start the kernel OS; the device tree includes a watchdog timer, which is used to perform a reset operation on the kernel OS when the kernel OS boot exceeds a preset time.
[0115] According to embodiments of this disclosure, the watchdog timer is used to perform a reset operation on the kernel OS when the kernel OS has run for a preset time, including:
[0116] The kernel OS obtains the watchdog timer's feeding interface through the device tree;
[0117] If the initialization of the relevant subsystems of the kernel OS is not completed, the kernel OS will manually feed the watchdog timer at preset time intervals.
[0118] If the relevant subsystems of the kernel OS are initialized, the kernel timer of the kernel OS is used to perform a timed dog-feeding operation; the subsystem includes the kernel timer.
[0119] The watchdog timer is used to restart the kernel OS when it may experience prolonged system freezes or crashes. However, after the device powers on, the kernel OS initialization is incomplete, and not all components are fully loaded, preventing the watchdog timer from performing scheduled feeding operations. This could cause the kernel OS to fail to boot. To prevent this, the kernel OS obtains the watchdog timer's configuration from the device tree and reads the watchdog timer's feeding interface and its corresponding GPIO register address. The kernel OS controls the GPIO register via the GPIO register address, actively toggling the GPIO register and sending feeding commands to the feeding interface to manually feed the watchdog timer. If a feeding operation is not performed within a preset time interval, it indicates that the kernel OS loading process has frozen or crashed, requiring the watchdog timer to be reset. Once the relevant subsystems of the kernel OS are initialized, the kernel OS's feeding timer starts, performing scheduled feeding operations at preset intervals.
[0120] According to embodiments of this disclosure, executing the bootloader to start the kernel OS includes:
[0121] The bootloader transmits the device tree information to the kernel OS;
[0122] The kernel OS main partition image and the device tree information are loaded into memory and the kernel OS main partition image is executed.
[0123] In step S105, the kernel OS performs signature verification on the bootloader image and the preloader.
[0124] According to the embodiments of this disclosure, after the main bootloader image is successfully verified and the main bootloader image continues to be executed, the method further includes: the preloader loading the signature verification information of the main bootloader image into a specified memory address of the preloader and saving it.
[0125] According to embodiments of this disclosure, the step of executing the kernel OS to verify the signatures of the bootloader image and the preloader includes:
[0126] Obtain the signature information of the bootloader image and calculate the first hash value of the signature information of the bootloader image;
[0127] Obtain the specified memory address of the preloader and calculate the second hash value of the signature verification information of the bootloader main image;
[0128] If the first hash value matches the second hash value, the kernel OS verifies the bootloader signature information and the preloader signature; otherwise, it stops loading the root file system and waits for the watchdog timer to reset.
[0129] After the preloader loads the correctly verified bootloader image, it will load the signature information of the bootloader image into a specified memory address for storage. After the kernel OS is loaded, in order to ensure system security, the bootloader needs to be reverse-signed. That is, the first hash value of the current bootloader's signature information is compared with the second hash value of the signature information verified by the preloader when it verified the main bootloader image. If the two match, it means that the bootloader has not been tampered with, thus ensuring the security of the embedded system startup.
[0130] In step S106, in response to the kernel OS verifying the signatures of the bootloader image and the preloader, the kernel OS performs signature verification on the root file system. The root file system is the first file system mounted during kernel startup. After the root file system is mounted, the initialization scripts and services in the specified directories are loaded into memory for execution, ultimately completing the system's boot process.
[0131] In step S107, in response to the root file system's signature verification being successful, the root file system is loaded into memory.
[0132] According to embodiments of this disclosure, loading the root file system into memory in response to successful signature verification of the root file system includes:
[0133] The first file system module in the root file system is read-only mounted into the memory;
[0134] The second file system module in the root file system is stored in a preset directory location. The second file system module consists of configurations and files in the root file system that need to be modified frequently.
[0135] The root file system, as the foundation of an embedded system, is the first file system mounted after the kernel OS boots, and it is crucial to the complete system boot process. Damage to the root file system will prevent the system from booting normally. To effectively protect the root file system and prevent corruption, it needs to be mounted in read-only mode to prevent program modification. However, due to the need for adaptation to various chips, the root file system needs to be modified according to the chip type. Therefore, frequently modified files and configurations are stored as a second file system module in preset directory locations, allowing the root file system to retrieve them from the specified directory locations when needed. Examples include network configurations and basic toolsets.
[0136] Figure 4 A structural block diagram of a system boot device adapted to various chips according to embodiments of the present disclosure is shown. Figure 4 As shown, the system startup device 400 adapted to multiple chips includes a first startup module 410, a first signature verification module 420, a second signature verification module 430, a second startup module 440, a third signature verification module 450, a fourth signature verification module 460, and a loading module 470.
[0137] The first boot module 410 is configured as a boot preloader. It acquires the bootloader image and device tree information, and executes the preloader to start the bootloader. The device tree information includes the hardware information of the embedded system, including device paths and device configuration parameters for the differences between the various chips. The preloader is an early loading stage program in the embedded system boot process. It runs first when the system is powered on or reset, and is used to prepare the hardware environment for the subsequent bootloader. For example, it initializes the clock, GPIO, DDR memory, etc. It can also read the bootloader from non-volatile memory into memory and transfer control to the bootloader.
[0138] According to embodiments of this disclosure, a device tree is a data structure used to describe the hardware configuration of an embedded system. Its main purpose is to allow the operating system kernel to operate independently of specific hardware configurations. The device tree includes hardware information of the embedded system, such as device name, device path, and device configuration parameters. Furthermore, the device tree includes device paths and device configuration parameters that differ between various chips, enabling it to adapt to the hardware information access needs of different chips and achieve compatibility of the embedded system.
[0139] Figure 5 This diagram illustrates a structural block diagram of the first boot module in a bootloader within a system boot method adapted to various chips according to embodiments of the present disclosure. Figure 5 As shown, the bootloader image includes a main bootloader image and a backup bootloader image. The first boot module 410 includes:
[0140] The first verification submodule 411 is configured to load the bootloader main image into memory and verify the bootloader main image.
[0141] The first execution submodule 412 is configured to continue executing the bootloader main image if the bootloader main image verification is successful.
[0142] The second verification submodule 413 is configured to load the bootloader backup image into memory and verify the bootloader backup image if the verification of the bootloader main image fails.
[0143] The second execution submodule 414 is configured to continue executing the bootloader main image after repairing the bootloader main image based on the bootloader backup image if the bootloader backup image verification is successful.
[0144] In this embodiment, by setting a main image and a backup image for the bootloader, the backup image can be used to repair the main image and start the bootloader when the main image of the bootloader encounters an error or fails to verify the signature, thereby improving the stability and security of the embedded system.
[0145] The first signature verification module 420 is configured to execute the bootloader to verify the signature of the preloader. After the bootloader starts, it reverse-verifies the electronic signature of the preloader to ensure that the preloader is trustworthy and has not been tampered with, and at the same time ensures that the subsequently loaded bootloader and kernel OS are trustworthy, thus guaranteeing the security of the embedded system.
[0146] The second signature verification module 430 is configured to, in response to the preloader's successful signature verification, obtain the kernel OS image of the kernel OS and execute the bootloader to verify the signature of the kernel OS image. After the bootloader starts, it needs to start the kernel OS, import the kernel OS image into memory, and verify the electronic signature of the kernel OS image to ensure that the kernel OS image is authorized and has not been altered.
[0147] Figure 6 This diagram illustrates the structure of the second signature verification module 430 in the bootloader of a system boot method adapted to various chips according to an embodiment of the present disclosure. Figure 6 As shown, the second signature verification module 430 includes:
[0148] The third verification submodule 431 is configured to load the kernel OS main partition image into memory and verify the kernel OS main partition image;
[0149] The third execution submodule 432 is configured to continue executing the kernel OS main partition image if the kernel OS main partition image verification is successful.
[0150] The fourth verification submodule 433 is configured to load the kernel OS backup partition image into memory and verify the kernel OS backup partition image if the verification of the kernel OS main partition image fails.
[0151] The fourth execution submodule 434 is configured to continue executing the kernel OS main partition image after repairing the kernel OS main partition image based on the kernel OS backup partition image if the kernel OS backup partition image verification is successful.
[0152] By configuring a primary and backup image for the kernel OS, the backup image can be used to repair the primary image and start the bootloader when the primary bootloader image encounters errors or fails signature verification, thus improving the stability and security of the embedded system. Additionally, the kernel OS obtains the device tree from the bootloader and loads the drivers and configuration files for the embedded system's hardware devices using this tree.
[0153] The second boot module 440 is configured to execute the bootloader to start the kernel OS in response to the bootloader's successful verification of the kernel OS image; the device tree includes a watchdog timer, which is used to perform a reset operation on the kernel OS when the kernel OS boot exceeds a preset time.
[0154] According to an embodiment of this disclosure, the watchdog timer includes:
[0155] The acquisition submodule is configured so that the kernel OS can obtain the watchdog timer's feed interface through the device tree;
[0156] The manual watchdog timer submodule is configured to manually feed the watchdog timer at preset time intervals if the relevant subsystem initialization of the kernel OS is not completed.
[0157] The timed dog-feeding submodule is configured to perform a timed dog-feeding operation using the kernel timer of the kernel OS once the relevant subsystem of the kernel OS has been initialized; the subsystem includes the kernel timer.
[0158] The watchdog timer is used to restart the kernel OS when it may experience prolonged system freezes or crashes. However, after the device powers on, the kernel OS initialization is incomplete, and not all components are fully loaded, preventing the watchdog timer from performing scheduled feeding operations. This could cause the kernel OS to fail to boot. To prevent this, the kernel OS obtains the watchdog timer's configuration from the device tree and reads the watchdog timer's feeding interface and the corresponding GPIO register address. The kernel OS controls the GPIO register via the GPIO register address, actively toggling the GPIO register and sending feeding commands to the feeding interface to manually feed the watchdog timer. If a feeding operation is not performed within a preset time interval, it indicates that the kernel OS loading process has frozen or crashed, requiring the watchdog timer to be reset. Once the relevant subsystems of the kernel OS are initialized, the kernel OS's feeding timer starts, performing scheduled feeding operations at preset intervals.
[0159] According to an embodiment of this disclosure, the second startup module includes:
[0160] The delivery submodule is configured to allow the bootloader to pass the device tree information to the kernel OS;
[0161] The first loading submodule is configured to load the kernel OS main partition image and the device tree information into memory and execute the kernel OS main partition image.
[0162] The third signature verification module 450 is configured to execute the kernel OS to verify the signatures of the bootloader image and the preloader.
[0163] According to an embodiment of this disclosure, after the first execution submodule, the apparatus further includes a second loading submodule, configured such that the preloader loads the signature information of the bootloader master image into a specified memory address of the preloader for storage.
[0164] According to embodiments of this disclosure, the third signature verification module includes:
[0165] The first calculation submodule is configured to obtain the signature information of the bootloader image and calculate the first hash value of the signature information of the bootloader image.
[0166] The second calculation submodule is configured to obtain a specified memory address of the preloader and calculate the second hash value of the signature verification information of the bootloader main image;
[0167] The matching submodule is configured such that if the first hash value matches the second hash value, the kernel OS verifies the bootloader signature information and the preloader signature; otherwise, it stops loading the root file system and waits for the watchdog timer to reset.
[0168] After the preloader loads the correctly verified bootloader image, it will load the signature information of the bootloader image into a specified memory address for storage. After the kernel OS is loaded, in order to ensure system security, the bootloader needs to be reverse-signed. That is, the first hash value of the current bootloader's signature information is compared with the second hash value of the signature information verified by the preloader when it verified the main bootloader image. If the two match, it means that the bootloader has not been tampered with, thus ensuring the security of the embedded system startup.
[0169] The fourth signature verification module 460 is configured to, in response to the kernel OS's successful signature verification of the bootloader image and the preloader, execute the kernel OS to verify the signature of the root file system. The root file system is the first file system mounted during kernel startup. After the root file system is mounted, the initialization scripts and services in the specified directories are loaded into memory for execution, ultimately realizing the complete system startup process.
[0170] Loading module 470 is configured to load the root file system into memory in response to the root file system signature being verified.
[0171] According to embodiments of this disclosure, the loading module includes:
[0172] The mounting submodule is configured to read-only mount the first file system module in the root file system into the memory;
[0173] The storage submodule is configured to store the second file system module in the root file system according to a preset directory location. The second file system module consists of configurations and files in the root file system that need to be modified frequently.
[0174] The root file system, as the foundation of an embedded system, is the first file system mounted after the kernel OS boots, and it is crucial to the complete system boot process. Damage to the root file system will prevent the system from booting normally. To effectively protect the root file system and prevent corruption, it needs to be mounted in read-only mode to prevent program modification. However, due to the need for adaptation to various chips, the root file system needs to be modified according to the chip type. Therefore, frequently modified files and configurations are stored as a second file system module in preset directory locations, allowing the root file system to retrieve them from the specified directory locations when needed. Examples include network configurations and basic toolsets.
[0175] This disclosure also discloses an electronic device, Figure 7 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown.
[0176] like Figure 7 As shown, the electronic device includes a memory and a processor, wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method according to embodiments of the present disclosure.
[0177] A system boot method adaptable to multiple chips, including:
[0178] The preloader is started to obtain the bootloader image and device tree information, and the preloader is executed to start the bootloader; the device tree information includes the hardware information of the embedded system, and the hardware information includes the device path and device configuration parameters of the device differences between the various chips.
[0179] The bootloader is executed to verify the signature of the preloader;
[0180] In response to the preloader's signature verification being successful, the kernel OS image of the kernel OS is obtained, and the bootloader is executed to verify the signature of the kernel OS image;
[0181] In response to the bootloader verifying the kernel OS image, the bootloader is executed to start the kernel OS; the device tree includes a watchdog timer, which is used to perform a reset operation on the kernel OS when the kernel OS boot exceeds a preset time;
[0182] The kernel OS is executed to verify the signatures of the bootloader image and the preloader.
[0183] In response to the kernel OS verifying the signatures of the bootloader image and the preloader, the kernel OS performs signature verification on the root file system.
[0184] In response to the successful signature verification of the root file system, the root file system is loaded into memory;
[0185] The bootloader image includes a main bootloader image and a backup bootloader image. The step of executing the preloader to start the bootloader includes:
[0186] Load the bootloader main image into memory and verify the bootloader main image;
[0187] If the bootloader main image verification is successful, continue executing the bootloader main image;
[0188] If the bootloader master image verification fails, the bootloader backup image is loaded into memory and verified.
[0189] If the bootloader backup image is successfully verified, after repairing the bootloader main image based on the bootloader backup image, the bootloader main image will continue to be executed.
[0190] The kernel OS image includes a kernel OS primary partition image and a kernel OS backup partition image. The execution of the bootloader to verify the signature of the kernel OS includes:
[0191] The bootloader loads the kernel OS main partition image into memory and verifies the kernel OS main partition image.
[0192] If the kernel OS main partition image verification is successful, continue with the kernel OS main partition image processing.
[0193] If the kernel OS primary partition image verification fails, the kernel OS backup partition image is loaded into memory and verified.
[0194] If the kernel OS backup partition image is successfully verified, after repairing the kernel OS main partition image based on the kernel OS backup partition image, the kernel OS main partition image will continue to be processed.
[0195] According to embodiments of this disclosure, executing the bootloader to start the kernel OS includes:
[0196] The bootloader transmits the device tree information to the kernel OS;
[0197] The kernel OS main partition image and the device tree information are loaded into memory and the kernel OS main partition image is executed.
[0198] According to an embodiment of this disclosure, after the bootloader main image is successfully verified and execution of the bootloader main image continues, the method further includes:
[0199] The preloader loads the signature verification information of the bootloader master image into a specified memory address and saves it.
[0200] According to embodiments of this disclosure, the step of executing the kernel OS to verify the signatures of the bootloader image and the preloader includes:
[0201] Obtain the signature information of the bootloader image and calculate the first hash value of the signature information of the bootloader image;
[0202] Obtain the specified memory address of the preloader and calculate the second hash value of the signature verification information of the bootloader main image;
[0203] If the first hash value matches the second hash value, the kernel OS verifies the bootloader signature information and the preloader signature; otherwise, it stops loading the root file system and waits for the watchdog timer to reset.
[0204] According to embodiments of this disclosure, the watchdog timer is used to perform a reset operation on the kernel OS when the kernel OS has run for a preset time, including:
[0205] The kernel OS obtains the watchdog timer's feeding interface through the device tree;
[0206] If the initialization of the relevant subsystems of the kernel OS is not completed, the kernel OS will manually feed the watchdog timer at preset time intervals.
[0207] If the relevant subsystems of the kernel OS are initialized, the kernel timer of the kernel OS is used to perform a timed dog-feeding operation; the subsystem includes the kernel timer.
[0208] According to embodiments of this disclosure, loading the root file system into memory in response to successful signature verification of the root file system includes:
[0209] The first file system module in the root file system is read-only mounted into the memory;
[0210] The second file system module in the root file system is stored in a preset directory location. The second file system module consists of configurations and files in the root file system that need to be modified frequently. Figure 8 A schematic diagram of the structure of a computer system suitable for implementing the method according to embodiments of the present disclosure is shown.
[0211] like Figure 8 As shown, the computer system includes a processing unit that can execute various methods described above based on a program stored in a read-only memory (ROM) or a program loaded from a storage portion into a random access memory (RAM). The RAM also stores various programs and data required for the operation of the computer system. The processing unit, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.
[0212] The following components are connected to the I / O interface: input sections including keyboards, mice, etc.; output sections including cathode ray tubes (CRTs), liquid crystal displays (LCDs), and speakers; storage sections including hard disks, etc.; and communication sections including network interface cards such as LAN cards and modems. The communication section performs communication processes via a network such as the Internet. Drives are also connected to the I / O interface as needed. Removable media, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on the drive as needed so that computer programs read from them can be installed into the storage section as needed. The processing unit can be implemented as a CPU, GPU, TPU, FPGA, NPU, etc.
[0213] In particular, according to embodiments of this disclosure, the methods described above can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program containing program code for performing the methods described above. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium.
[0214] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0215] The units or modules described in the embodiments of this disclosure can be implemented in software or programmable hardware. The described units or modules can also be located in a processor, and the names of these units or modules do not necessarily constitute a limitation on the unit or module itself.
[0216] In another aspect, this disclosure also provides a computer-readable storage medium, which may be a computer-readable storage medium included in the electronic device or computer system described above; or it may be a standalone computer-readable storage medium not assembled into a device. The computer-readable storage medium stores one or more programs, which are used by one or more processors to perform the methods described in this disclosure.
[0217] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features disclosed in this disclosure that have similar functions.
Claims
1. A system boot method adaptable to multiple chips, characterized in that, include: Start the preloader, obtain the bootloader image and device tree information, and execute the preloader to start the bootloader; The device tree information includes the hardware information of the embedded system, and the hardware information includes the device paths and device configuration parameters of the device differences between the various chips. The bootloader is executed to verify the signature of the preloader; In response to the preloader's signature verification being successful, the kernel OS image of the kernel OS is obtained, and the bootloader is executed to verify the signature of the kernel OS image; In response to the bootloader verifying the kernel OS image, the bootloader is executed to start the kernel OS; the device tree includes a watchdog timer, which is used to perform a reset operation on the kernel OS when the kernel OS boot exceeds a preset time; The kernel OS is executed to verify the signatures of the bootloader image and the preloader. In response to the kernel OS verifying the signatures of the bootloader image and the preloader, the kernel OS performs signature verification on the root file system. In response to the successful signature verification of the root file system, the root file system is loaded into memory; The bootloader image includes a main bootloader image and a backup bootloader image. Executing the preloader to start the bootloader includes: Load the bootloader main image into memory and verify the bootloader main image; If the bootloader main image verification is successful, continue executing the bootloader main image; If the bootloader master image verification fails, the bootloader backup image is loaded into memory and verified. If the bootloader backup image is successfully verified, after repairing the bootloader main image based on the bootloader backup image, the bootloader main image will continue to be executed. The kernel OS image includes a kernel OS primary partition image and a kernel OS backup partition image. The step of executing the bootloader to verify the signature of the kernel OS image includes: The bootloader loads the kernel OS main partition image into memory and verifies the kernel OS main partition image. If the kernel OS main partition image verification is successful, continue with the kernel OS main partition image processing. If the kernel OS primary partition image verification fails, the kernel OS backup partition image is loaded into memory and verified. If the kernel OS backup partition image is successfully verified, after repairing the kernel OS main partition image based on the kernel OS backup partition image, the kernel OS main partition image will continue to be processed.
2. The method according to claim 1, characterized in that, The execution of the bootloader to start the kernel OS includes: The bootloader transmits the device tree information to the kernel OS; The kernel OS main partition image and the device tree information are loaded into memory and the kernel OS main partition image is executed.
3. The method according to claim 1, characterized in that, After the bootloader main image is successfully verified and execution of the bootloader main image continues, the method further includes: The preloader loads the signature verification information of the bootloader master image into a specified memory address and saves it.
4. The method according to claim 3, characterized in that, The step of executing the kernel OS to verify the signatures of the bootloader image and the preloader includes: Obtain the signature information of the bootloader image and calculate the first hash value of the signature information of the bootloader image; Obtain the specified memory address of the preloader and calculate the second hash value of the signature verification information of the bootloader main image; If the first hash value matches the second hash value, the kernel OS verifies the bootloader signature information and the preloader signature; otherwise, it stops loading the root file system and waits for the watchdog timer to reset.
5. The method according to claim 1, characterized in that, The watchdog timer is used to perform a reset operation on the kernel OS when the kernel OS has been running for a preset time, including: The kernel OS obtains the watchdog timer's feeding interface through the device tree; If the initialization of the relevant subsystems of the kernel OS is not completed, the kernel OS will manually feed the watchdog timer at preset time intervals. If the relevant subsystems of the kernel OS are initialized, the kernel timer of the kernel OS is used to perform a timed dog-feeding operation; the subsystem includes the kernel timer.
6. The method according to claim 1, characterized in that, The step of loading the root file system into memory in response to successful signature verification of the root file system includes: The first file system module in the root file system is read-only mounted into the memory; The second file system module in the root file system is stored in a preset directory location. The second file system module consists of configurations and files in the root file system that need to be modified frequently.
7. A system boot device adaptable to multiple chips, characterized in that, include: The first startup module is configured to start a preloader, obtain the bootloader image and device tree information, and execute the preloader to start the bootloader. The device tree information includes the hardware information of the embedded system, and the hardware information includes the device paths and device configuration parameters of the device differences between the various chips. The first signature verification module is configured to execute the bootloader to verify the signature of the preloader. The second signature verification module is configured to, in response to the preloader's signature verification being successful, obtain the kernel OS image of the kernel OS, and execute the bootloader to verify the signature of the kernel OS image, wherein the kernel OS image includes a kernel OS main partition image and a kernel OS backup partition image; The second boot module is configured to execute the bootloader to start the kernel OS in response to the bootloader verifying the kernel OS image. The device tree includes a watchdog timer, which is used to perform a reset operation on the kernel OS when the kernel OS boot exceeds a preset time. The third signature verification module is configured to execute the kernel OS to verify the signatures of the bootloader image and the preloader. The fourth signature verification module is configured to execute the kernel OS to verify the signature of the root file system in response to the kernel OS's successful verification of the bootloader image and the preloader. The loading module is configured to load the root file system into memory in response to the root file system's signature verification being successful; The bootloader image includes a main bootloader image and a backup bootloader image. The first boot module includes: The first verification submodule is configured to load the bootloader main image into memory and verify the bootloader main image. The first execution submodule is configured to continue executing the bootloader main image if the bootloader main image verification is successful. The second verification submodule is configured to load the bootloader backup image into memory and verify the bootloader backup image if the verification of the bootloader main image fails. The second execution submodule is configured to, if the bootloader backup image is successfully verified, continue to execute the bootloader main image after repairing the bootloader main image based on the bootloader backup image; The second signature verification module includes: The third verification submodule is configured to load the kernel OS main partition image into memory by the bootloader and verify the kernel OS main partition image. The third execution submodule is configured to continue executing the kernel OS main partition image if the kernel OS main partition image verification is successful. The fourth verification submodule is configured to load the kernel OS backup partition image into memory and verify the kernel OS backup partition image if the verification of the kernel OS main partition image fails. The fourth execution submodule is configured to, if the kernel OS backup partition image verification is successful, continue to execute the kernel OS main partition image after repairing the kernel OS main partition image based on the kernel OS backup partition image.
8. The apparatus according to claim 7, characterized in that, The second startup module includes: The delivery submodule is configured to allow the bootloader to pass the device tree information to the kernel OS; The first loading submodule is configured to load the kernel OS main partition image and the device tree information into memory and execute the kernel OS main partition image.
9. The apparatus according to claim 7, characterized in that, Following the first execution submodule, the device further includes: The second loading submodule is configured to load the signature information of the bootloader master image into a specified memory address of the preloader and save it.
10. The apparatus according to claim 9, characterized in that, The third signature verification module includes: The first calculation submodule is configured to obtain the signature information of the bootloader image and calculate the first hash value of the signature information of the bootloader image. The second calculation submodule is configured to obtain a specified memory address of the preloader and calculate the second hash value of the signature verification information of the bootloader main image; The matching submodule is configured such that if the first hash value matches the second hash value, the kernel OS verifies the bootloader signature information and the preloader signature; otherwise, it stops loading the root file system and waits for the watchdog timer to reset.
11. The apparatus according to claim 7, characterized in that, The watchdog timer includes: The acquisition submodule is configured so that the kernel OS can obtain the watchdog timer's feed interface through the device tree; The manual watchdog timer submodule is configured to manually feed the watchdog timer at preset time intervals if the relevant subsystem initialization of the kernel OS is not completed. The timed dog-feeding submodule is configured to perform a timed dog-feeding operation using the kernel timer of the kernel OS once the relevant subsystem of the kernel OS has been initialized; the subsystem includes the kernel timer.
12. The apparatus according to claim 7, characterized in that, The loading module includes: The mounting submodule is configured to read-only mount the first file system module in the root file system into the memory; The storage submodule is configured to store the second file system module in the root file system according to a preset directory location. The second file system module consists of configurations and files in the root file system that need to be modified frequently.
13. An electronic device, characterized in that, The method includes a memory and a processor; wherein the memory is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor to implement the method according to any one of claims 1-6.
14. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by a processor, the computer instructions implement the method described in any one of claims 1-6.
Citation Information
Patent Citations
Fast and safe starting method, device and equipment based on heterogeneous multi-core system and medium
CN118626155A
Method and system for quickly starting multi-core heterogeneous system
CN118760482A