High-reliability partition loading method of partition embedded operating system
By designing partition image files and image headers in embedded systems, and combining FLASH and RAM verification and error monitoring mechanisms, the problems of insufficient data integrity and security in traditional methods are solved, achieving highly reliable partition loading and improving the stability and security of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- XIAN FLIGHT SELF CONTROL INST OF AVIC
- Filing Date
- 2025-12-27
- Publication Date
- 2026-04-24
AI Technical Summary
Traditional embedded system partition loading methods neglect data integrity and security during the loading process, leading to system crashes or data loss, and lack effective error handling and recovery mechanisms.
The design employs a partitioned image file, which includes an image header and an image entity. By performing a checksum and loading process in FLASH, data integrity is ensured, and the final partition initialization is performed in RAM. Combined with the checksum error monitoring mechanism in the image header, it provides powerful loading monitoring capabilities to promptly detect and handle loading errors.
It significantly improves the reliability of partition loading, prevents system failures, ensures data integrity and system stability, and is suitable for various embedded system platforms to meet the needs of different users.
Smart Images

Figure CN121918896A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of embedded computer application technology, and in particular relates to a highly reliable partition loading method for a partitioned embedded operating system. Background Technology
[0002] With the widespread application of embedded systems, the requirements for system complexity and reliability are increasing. In embedded systems, partition loading is one of the key steps in system startup and operation.
[0003] Traditional embedded system partition loading methods often focus solely on loading speed and efficiency, neglecting data integrity and security during the loading process. If an error occurs during partition image loading, it can lead to system crashes or data loss. When errors occur during loading, existing methods often only manage to terminate the loading process or provide a simple error message, lacking effective error handling and recovery mechanisms. Summary of the Invention
[0004] The purpose of this invention is to provide a highly reliable partition loading method for a partitioned embedded operating system in order to ensure the stability and reliability of the system.
[0005] This application provides a high-reliability partition loading method for a partitioned embedded operating system, the method comprising the following steps: Step 1: Composition and construction of partition image files; wherein, the partition image file includes a partition image header and a partition image entity; Step 2: Partition Image Fixing: The fixing software reads the FLASH fixing address and image entity length from the partition image header and fixes the partition image file onto the FLASH fixing address of the FLASH device; Step 3: Obtain the entry address of the partition boot program for each partition: The partition configuration table of the operating system describes the FLASH hard address of each partition, which is consistent with the FLASH hard address in the partition image header. The operating system obtains the FLASH hard address of each partition from the partition configuration table, adds the fixed size N of the partition image header, and obtains the entry address of the partition boot program for each partition. Step 4: Execute the partition boot program for each partition: After performing system-level initialization, the operating system jumps to the entry address of the first partition's boot program and executes it. Once the boot program is complete, the system returns to the entry address of the next partition's boot program and executes it. This process continues until all partition boot programs have been executed. After each partition has started booting, the operating system initiates normal task scheduling.
[0006] Preferably, the partition startup program includes seven steps in sequence: FLASH image verification, RAM loading, RAM checksum calculation, RAM loading fault reporting, RAM loading fault handling, jump to the starting address of the partition RAM, and RAM partition application initialization. The first six steps are executed in FLASH, and the last step is executed in RAM.
[0007] Preferably, the partition image header includes the image name, FLASH address, RAM load address, image entity length, image entity checksum, checksum type, and key partition flag, and the image header has a fixed size N.
[0008] Preferably, the partition image entity is constructed from the application partition source code and the boot library file provided by the operating system; the boot library file contains the partition boot program and the verification algorithm library; the partition boot program completes seven functions: FLASH image verification, RAM loading, RAM checksum calculation, RAM loading fault reporting, RAM loading fault handling, jump to the RAM application partition initialization address, and RAM application partition initialization, and the entry address of the partition boot program is constructed at the starting address of the partition image entity; the verification algorithm library includes three verification algorithms: cumulative check, CRC check, and vertical parity check.
[0009] Preferably, FLASH image verification includes: The FLASH fixed address, image entity length and verification type are obtained from the image header. The partition image entity fixed in the FLASH is verified according to the verification type. The verification result is compared with the image entity verification code in the image header. If they are inconsistent, a FLASH image entity fault is reported.
[0010] Preferably, RAM loading includes: The operating system obtains the FLASH hard address, RAM load address, and image entity length from the partition image header, and calculates the FLASH image body address based on the fixed size N of the image header; the program at the FLASH image body address is copied to the RAM load address, with the copy length being the image entity length.
[0011] Preferably, RAM checksum calculation includes: The verification type and image entity length are obtained from the image header. The corresponding verification algorithm is selected according to the verification type, and the program loaded into RAM is verified to obtain the RAM verification code.
[0012] Preferably, the RAM loading fault report includes: The RAM checksum is compared with the image entity checksum in the image header. If they are the same, the checksum is successful and a jump to the RAM start is executed. If they are different, the checksum is failed, the fault reporting interface provided by the operating system is called, and the loading fault information, including the image partition ID, RAM checksum, and FLASH checksum, is passed to the operating system. Then, the user mode is switched to privileged mode to execute RAM loading fault handling.
[0013] Preferably, RAM load failure handling includes: The operating system obtains the critical partition flag from the image header. If the critical partition flag indicates a critical partition, it loads the fault information and sends it to the serial port or network port, and records it in non-volatile memory. Then, it executes the system-level fault mitigation measures set by the operating system. If the critical partition flag indicates a non-critical partition, it loads the fault information and sends it to the serial port or network port, and records it in non-volatile memory.
[0014] Preferably, the jump to the RAM start address includes: the RAM start address is the RAM application partition initialization address, and the initialization operation of the application partition itself is completed.
[0015] The beneficial technical effects of this application are as follows: In partitioned embedded operating systems, the operating system typically handles the loading of all application partitions. The operating system's configuration table provides the FLASH address information, RAM address information, and segment length for each segment of every partition. After all segments of every partition are loaded into RAM, the operating system jumps to the partition initialization entry point in each partition's RAM to perform partition initialization operations. The entire partition loading process is completed in processor kernel mode, with the loading code running in RAM. When a partition loading verification error is detected, fault handling is performed directly in kernel mode. Attached Figure Description
[0016] Figure 1 This is a schematic diagram of a mirror structure; Figure 2 This is a flowchart of the high-reliability partition loading process; Figure 3 This is a flowchart of the partition boot process; Figure 4 This is a schematic diagram of the partitioning and loading process from FLASH space to RAM space. Detailed Implementation
[0017] The following is a description of the embodiments and appendices. Figure 1 - Appendix Figure 4 The present invention will be described in further detail, but the embodiments of the present invention are not limited thereto.
[0018] This invention proposes a highly reliable partition loading method for multi-partition embedded operating systems, aiming to improve the security, stability, and operating efficiency of the operating system. This method achieves partition loading from FLASH space to RAM space through a specific image structure design, and combines checksum and error monitoring mechanisms during the loading process to ensure data integrity and system reliability. Specifically, this method adopts a segmented structure design of image header and image entity, where the image header contains data information of the image file, such as filename, FLASH loading address, image length, and checksum. During the operating system initialization phase, each partition will automatically load its own image and move the image entity and its related information from FLASH to RAM. During the loading process, the system verifies the data accuracy through the checksum in the image header. This method also has strong loading monitoring capabilities, and can promptly detect and report errors that may occur during the loading process (such as image corruption or errors during copying) to the operating system. The operating system performs appropriate error handling according to the criticality of the partition, effectively preventing system failures caused by loading errors. Through two-level measures of implementing checksum and error monitoring after loading, this method significantly improves the reliability of partition loading. Currently, this method has been successfully applied in flight control systems, significantly improving the reliability of partitioned loading and providing strong support for the stable operation of the system.
[0019] The technical solution adopted in this invention is a high-reliability partition loading method for a partitioned embedded operating system, comprising the following steps: Step 1: Composition and Construction of Partition Image Files A partition image file contains a partition image header and a partition image entity.
[0020] The partition image header contains the image name, FLASH address, RAM load address, image entity length, image entity checksum, checksum type, and key partition flags. The image header has a fixed size N.
[0021] The partition image entity is constructed from the application partition source code and the boot library files provided by the operating system. The boot library files contain the partition bootloader and a verification algorithm library. The partition bootloader performs seven functions: FLASH image verification, RAM loading, RAM checksum calculation, RAM loading fault reporting, RAM loading fault handling, jump to the RAM application partition initialization address, and RAM application partition initialization. The entry address of the partition bootloader is constructed at the starting address of the partition image entity. The verification algorithm library includes three verification algorithms: cumulative checksum, CRC check, and vertical parity check.
[0022] Step 2: Partition Image Solidification The hardening software reads the FLASH hardening address and image entity length from the partition image header and hardens the partition image file onto the FLASH hardening address of the FLASH device.
[0023] Step 3: Obtain the entry address of the boot program for each partition. The operating system's partition configuration table describes the FLASH addresses of each partition, which are consistent with the FLASH addresses in the partition image header. The operating system obtains the FLASH addresses of each partition from the partition configuration table, adds them to the fixed size N of the partition image header, and obtains the entry address of the partition boot program for each partition.
[0024] Step 4: Execute the partition boot program for each partition. After performing system-level initialization, the operating system jumps to the entry address of the bootloader for the first partition, executes the bootloader for that partition, and returns to the operating system after completion. It then jumps to the entry address of the bootloader for the next partition, completing that bootloader's process. This process continues until the bootloaders for all partitions have been executed. Once all partitions have booted, the operating system initiates normal task scheduling.
[0025] The partition boot process consists of seven steps: FLASH image verification, RAM loading, RAM checksum calculation, RAM loading fault reporting, RAM loading fault handling, jump to the starting address of the partition RAM, and RAM partition application initialization. The first six steps are executed in FLASH, and the last step is executed in RAM.
[0026] Sub-step 1: FLASH Image Verification. Obtain the FLASH firmware address, image entity length, and verification type from the image header. Verify the partition image entity firmware in the FLASH according to the verification type, and compare the verification result with the image entity verification code in the image header. If they do not match, report a FLASH image entity failure.
[0027] Sub-step 2: RAM Loading. The operating system obtains the FLASH firmware address, RAM load address, and image entity length from the partition image header, and calculates the FLASH image body address based on the fixed size N of the image header. The program at the FLASH image body address is copied to the RAM load address, with the copy length being the image entity length.
[0028] Sub-step 3: RAM checksum calculation. Obtain the checksum type and image entity length from the image header, select the appropriate checksum algorithm based on the checksum type, and perform checksum verification on the program loaded into RAM to obtain the RAM checksum.
[0029] Sub-step 4: RAM Load Failure Reporting. Compare the RAM checksum with the image entity checksum in the image header. If they match, the verification succeeds, proceed to sub-step 6. If they differ, the verification fails, the operating system's fault reporting interface is called, and loading fault information, including the image partition ID, RAM checksum, and FLASH checksum, is passed to the operating system. Then, switch from user mode to privileged mode. Proceed to sub-step 5.
[0030] Sub-step 5: RAM Load Failure Handling. The operating system obtains the critical partition flag from the image header. If the critical partition flag indicates a critical partition, the loading failure information is sent to the serial port or network port and recorded in non-volatile memory. Then, the system-level fault mitigation measures set by the operating system are executed. If the critical partition flag indicates a non-critical partition, the loading failure information is sent to the serial port or network port and recorded in non-volatile memory.
[0031] Sub-step 6: Jump to the beginning of RAM. The beginning address of RAM is the initialization address of the RAM application partition, completing the initialization operation of the application partition itself.
[0032] Sub-step 7: Perform RAM partition application initialization operations at the RAM starting address.
[0033] In partitioned embedded operating systems, the operating system typically handles the loading of all application partitions. The operating system's configuration table provides the FLASH address information, RAM address information, and segment length for each segment of every partition. After all segments of every partition are loaded into RAM, the operating system jumps to the partition initialization entry point in each partition's RAM to perform partition initialization operations. The entire partition loading process is completed in processor kernel mode, with the loading code running in RAM. When a partition loading verification error is detected, fault handling is performed directly in kernel mode.
[0034] These partition loading methods involve complex partition operating system space configuration tables, requiring the inclusion of base addresses and lengths of all segments across all partitions in both FLASH and RAM. The operating system's partition restart functionality is also complex, as the restart interface needs to obtain the base addresses and lengths of each segment of the target partition in both FLASH and RAM. This results in deep coupling between the operating system and application software. Furthermore, the entire partition loading process runs in kernel mode, and errors in the loading process itself can lead to system-level failures. Moreover, RAM, unlike FLASH, lacks non-volatile characteristics, making its data reliability lower. Since the loading verification program itself runs in RAM, a single-event fault (SIF) in the RAM area containing the verification code can cause unpredictable failures during the loading verification process.
[0035] This application designs a method in which the partition loading process is completed by the application partition itself, running in user space along with the application software, and will not cause system-level failures due to errors in the partition loading process itself.
[0036] Furthermore, the partition loading code runs in FLASH, which offers higher reliability due to its non-volatile nature. The loading verification process itself is more trustworthy, reducing the possibility of system crashes or performance degradation caused by errors in the loading verification process.
[0037] Furthermore, this method provides partition verification and allows selection of a verification algorithm based on the partition verification type in the image header. Critical partitions can employ more secure and complex verification methods. Upon verification failure, a system call switches to privileged mode, and different fault handling methods can be selected based on the critical partition information in the image header. These methods further enhance the security and reliability of the partition loading process while providing users with flexible and diverse options. They can accommodate non-critical partition loading errors, allowing the system to continue operating and ensuring the integrity of basic functions. They are suitable for various embedded system platforms and application scenarios, meeting the needs of different users.
[0038] Furthermore, the operating system's partition configuration table only needs to provide the partition's FLASH loading information; during partition initialization, it simply jumps to the partition's FLASH address. The coupling between the operating system and the partition is low, facilitating the parallel development and integration of multi-partition application software.
[0039] 1. Initial Stage: System Hardware Platform Configuration In this embodiment of the invention, a high-reliability partition loading system for a multi-partition embedded operating system is implemented. Based on a flight control system project, a high-reliability partition loading design scheme for a partitioned embedded operating system is implemented on its flight control computer board, thereby achieving a highly secure partition loading system. The hardware resource configuration of the flight control computer board is as follows: (1) Processor: PowerPC755, operating frequency: 300 MHz, with 32-bit RISC architecture, supporting multi-level cache and memory management unit.
[0040] (2) Program memory (FLASH): 128MB capacity, using NOR FLASH technology, supports fast random access, and ensures efficient execution of the partition boot program in FLASH.
[0041] (3) Data storage (RAM): 128MB capacity, using SDRAM technology to provide sufficient runtime memory space for each partition.
[0042] (4) Timers and interrupts: There are 3 programmable timers and 2 timer interrupts, which provide a precise time reference for system scheduling and partition switching.
[0043] (5) 422 Display Serial Port: Programs and data can be transmitted through this serial port. The baud rate is configurable and supports debugging information output.
[0044] (6) W5100 Ethernet port: Programs and data can be transmitted through the Ethernet port, supporting TCP / IP protocol stack, with a transmission rate of up to 100Mbps.
[0045] Network connectivity detection mechanism In the high-reliability partition loading design of a multi-partition embedded operating system based on PowerPC 755, the system first determines whether the W5100 Ethernet port is connected by checking the IR bit of the Socket interrupt register S0. The specific implementation of this detection mechanism is as follows: Configure the W5100's network parameters during system initialization, including IP address, subnet mask, and gateway address; The physical connection status is determined by reading the PHY_LINK bit in the S0_IR register; If the W5100 Ethernet port is connected, the program will be loaded and transmitted through the network port; If the W5100 Ethernet port is not connected, the program will automatically switch to the serial port for transmission and loading.
[0046] 2. Detailed process of partition image construction stage (1) Composition and construction of partition image files The partition image is compiled using the software GNC-IDE2.0, which compiles the designed code into binary object code: A partition image.GNC. The operating system provides a dedicated partition boot library file for compiling and linking the application partition project.
[0047] The core functions of the partition boot library file include: FLASH image verification module; RAM loading module; RAM checksum calculation module; RAM loading fault reporting module; RAM loading fault handling module; and address jump module.
[0048] The partition boot code entry point in the partition boot library file is precisely linked to the starting address of the partition image entity in FLASH, ensuring that the partition boot program can be accurately located and executed during system startup. See the partition image structure below. Figure 1 .
[0049] (2) Partition mirroring process The POD 7.3.1 firmware supports multiple programming modes. The specific operation process is as follows: Network writing mode: Switch to the writing signal and power on the computer board; start the firmware software POD 7.3.1 and check the W5100 Ethernet port connection status; if the connection is normal, click network writing mode; select the A partition image .GNC file; after the software displays the GNC information, click the writing button; the system will automatically write the image to the Flash chip.
[0050] Serial port programming mode: If the network connection is abnormal, switch to serial port programming mode; configure serial port parameters (baud rate, data bits, stop bits, etc.); click the programming button to transmit the image data through the serial port; the system will program the image into the Flash chip.
[0051] After the burning process is complete, the system will automatically perform a post-burn verification. Once the verification is successful, a green light will illuminate, indicating that the burning process was successful. At this point, the burning software can be closed.
[0052] 3. Detailed Explanation of Partition Boot Program Execution (1) Obtain the entry address of the partition boot program for each partition. After the system boots up, the operating system obtains the FLASH address of each partition from the partition configuration table. This address is consistent with the FLASH address in the partition image header. By adding the fixed size N of the partition image header (usually 0x100 bytes) to the FLASH address, the entry address of the partition boot program for each partition is accurately calculated.
[0053] (2) Execute the partition boot program for each partition. Sub-step 1: FLASH image verification After removing the programming signal, the computer board is powered on, and the operating system executes the boot program. The operating system's partition configuration table is used to obtain the precise burning location of each partition image file in the FLASH memory. The verification process is as follows: Obtain the FLASH address, image entity length, and verification type from the image header; The partition image entity embedded in the FLASH is verified according to the verification type (cumulative check, CRC check, or vertical parity check); the verification result is compared with the image entity check code in the image header; if they do not match, the FLASH image entity fault is immediately reported and the fault information is recorded.
[0054] Sub-step 2: RAM loading and calculation Taking partition A as an example, the system performs the following operations: Obtain the address of the A partition image in FLASH; jump to the starting address of the A partition image entity in FLASH; run the partition boot library file to complete the RAM migration and verification of its own image; create a new BSS segment and stack in RAM and initialize them; after the A partition image is loaded, accumulate and calculate the loaded content in RAM.
[0055] Sub-step 3: RAM checksum verification The calculated cumulative sum is rigorously compared with the checksum information in the image header of partition A in FLASH to ensure the correctness and integrity of the loaded content. The verification process employs a dual verification mechanism to improve reliability.
[0056] Sub-step 4: RAM loading fault reporting If an error occurs in the summation and comparison result, the system reports the image error information through the fault reporting interface provided by the operating system, including: partition ID; fault type (RAM verification failure); RAM checksum value; FLASH checksum value; and fault occurrence timestamp. If the summation and comparison result is correct, the system jumps to sub-step 6 to start the RAM transfer.
[0057] Sub-step 5: RAM loading failure handling After receiving a report of a fault in the A partition image, the operating system adopts different fault handling strategies based on the key partition flag information in the A partition FLASH image header.
[0058] Critical partition failure handling: Immediately restart the system and reload the partition from FLASH; attempt a maximum of three restarts; if the three restarts still fail, suspend the system to prevent the fault from spreading; at the same time, send the fault information to the serial port or network port and record it in detail in non-volatile memory.
[0059] Non-critical partition fault handling: Mask the current partition to prevent it from affecting the overall system operation; record the fault information to non-volatile storage; the system continues to run other partitions to ensure the integrity of basic functions; send fault alarm information via serial port or network port.
[0060] Sub-step 6: Jump to RAM Startup: Based on the RAM application partition initialization address, the system completes the initialization operation of the application partition itself. The jump process includes: saving the current processor state; switching to user mode; and jumping to the application partition initialization address in RAM.
[0061] Sub-step 7: Perform partition application initialization Jump to the RAM application partition initialization address and execute the RAM partition application initialization operation at the RAM starting address. After initialization is complete, the partition enters normal operation state and waits for the operating system's task scheduling.
[0062] The entire partition boot process execution flow is as follows: Figure 3 As shown, the complete process from FLASH image verification to RAM partition application initialization is clearly demonstrated.
[0063] Execute the partition boot program for each partition. After performing system-level initialization, the operating system jumps to the entry address of the bootloader for the first partition, executes the bootloader for that partition, and returns to the operating system after completion. It then jumps to the entry address of the bootloader for the next partition, completing that bootloader's process. This process continues until the bootloaders for all partitions have been executed. Once all partitions have booted, the operating system initiates normal task scheduling.
[0064] Completed: System integration and verification In practical applications, this highly reliable partitioned loading method has been successfully applied in flight control systems. System tests show that this method can effectively handle various loading failures, including: corrupted FLASH images; data errors during RAM loading; memory errors caused by single-event upsets; and data loss during network transmission.
[0065] By implementing a two-tiered approach of verification and error monitoring after loading, this method significantly improves the reliability of partition loading and provides strong support for the stable operation of the system.
[0066] The above detailed embodiments are a description of the present invention. It should not be considered that the specific embodiments of the present invention are limited to these descriptions. For those skilled in the art, several simple deductions and substitutions can be made without departing from the concept of the present invention, and all of these should be considered to fall within the protection scope of the present invention.
Claims
1. A highly reliable partition loading method for a partitioned embedded operating system, characterized in that, The method includes the following steps: Step 1: Composition and construction of partition image files; wherein, the partition image file includes a partition image header and a partition image entity; Step 2: Partition Image Fixing: The fixing software reads the FLASH fixing address and image entity length from the partition image header and fixes the partition image file onto the FLASH fixing address of the FLASH device; Step 3: Obtain the entry address of the partition boot program for each partition: The partition configuration table of the operating system describes the FLASH hard address of each partition, which is consistent with the FLASH hard address in the partition image header. The operating system obtains the FLASH hard address of each partition from the partition configuration table, adds the fixed size N of the partition image header, and obtains the entry address of the partition boot program for each partition. Step 4: Execute the partition boot program for each partition: After performing system-level initialization, the operating system jumps to the entry address of the first partition's boot program and executes it. Once the boot program is complete, the system returns to the entry address of the next partition's boot program and executes it. This process continues until all partition boot programs have been executed. After each partition has started booting, the operating system initiates normal task scheduling.
2. The method according to claim 1, characterized in that, The partition startup procedure includes seven steps in sequence: FLASH image verification, RAM loading, RAM checksum calculation, RAM loading fault reporting, RAM loading fault handling, jump to the starting address of the partition RAM, and RAM partition application initialization. The first six steps are executed in FLASH, and the last step is executed in RAM.
3. The method according to claim 2, characterized in that, The partition image header contains the image name, FLASH address, RAM load address, image entity length, image entity checksum, checksum type, and key partition flags. The image header has a fixed size N.
4. The method according to claim 3, characterized in that, The partition image entity is built from the application partition source code and the boot library files provided by the operating system; the boot library files contain the partition boot program and verification algorithm library. The partition startup program completes seven functions: FLASH image verification, RAM loading, RAM checksum calculation, RAM loading fault reporting, RAM loading fault handling, jump to the RAM application partition initialization address, and RAM application partition initialization. The entry address of the partition startup program is built at the starting address of the partition image entity. The verification algorithm library includes three verification algorithms: cumulative check, CRC check, and vertical parity check.
5. The method according to claim 4, characterized in that, FLASH image verification includes: The FLASH fixed address, image entity length and verification type are obtained from the image header. The partition image entity fixed in the FLASH is verified according to the verification type. The verification result is compared with the image entity verification code in the image header. If they are inconsistent, a FLASH image entity fault is reported.
6. The method according to claim 5, characterized in that, RAM loading includes: The operating system obtains the FLASH hard address, RAM load address, and image entity length from the partition image header, and calculates the FLASH image body address based on the fixed size N of the image header; the program at the FLASH image body address is copied to the RAM load address, with the copy length being the image entity length.
7. The method according to claim 6, characterized in that, RAM checksum calculation includes: The verification type and image entity length are obtained from the image header. The corresponding verification algorithm is selected according to the verification type, and the program loaded into RAM is verified to obtain the RAM verification code.
8. The method according to claim 7, characterized in that, RAM load failure reports include: The RAM checksum is compared with the image entity checksum in the image header. If they are the same, the checksum is successful and a jump to the RAM start is executed. If they are different, the checksum is failed, the fault reporting interface provided by the operating system is called, and the loading fault information, including the image partition ID, RAM checksum, and FLASH checksum, is passed to the operating system. Then, the user mode is switched to privileged mode to execute RAM loading fault handling.
9. The method according to claim 8, characterized in that, RAM load failure handling includes: The operating system obtains the critical partition flag from the image header. If the critical partition flag indicates a critical partition, it loads the fault information and sends it to the serial port or network port, and records it in non-volatile memory. Then, it executes the system-level fault mitigation measures set by the operating system. If the critical partition flag indicates a non-critical partition, it loads the fault information and sends it to the serial port or network port, and records it in non-volatile memory.
10. The method according to claim 9, characterized in that, Jump to the RAM start address, which is the RAM application partition initialization address, to complete the initialization operation of the application partition itself.