High-reliability starting method applied to aerospace embedded equipment

Abstract

The invention discloses a high-reliability starting method applied to aerospace embedded equipment. The high-reliability starting method comprises the following steps: storing a Linux component and a backup in a FLASH in advance; a correct operating system component is selected in a two-out-of-three mode to be started to ramfs; checking the NAND FLASH and rootfs and application data stored in the NAND FLASH in the ramfs, switching to the rootfs if the checking is successful, and otherwise, entering a repair mode; patrolling the components regularly in an operating system, and replacing error files in a repair mode; compared with other methods, the method has the advantages that the file is verified in the starting process and after starting is completed, the file damage risk caused by single event upset can be avoided, and reliable starting of the Linux operating system is guaranteed.

Description

Technical Field

[0001] The invention belongs to the technical field of operating system booting of aerospace embedded devices, and in particular relates to a high-reliability startup method applied to aerospace embedded devices. Background Art

[0002] Instruments and meters are important human-computer interaction channels for astronauts to obtain parameters and issue commands. With the continuous improvement of CPU computing power requirements and the complexity of interaction methods in recent years, aerospace equipment has gradually adopted the Linux operating system to manage CPU resources and complex business logic. The emergence of this solution shields the differences between different hardware devices, effectively reduces the workload of designers, and greatly speeds up the software design and development process.

[0003] However, unlike the general method of directly booting the operating system, the booting of the Linux operating system requires at least four types of files: BootLoader, Linux image, device tree, and file system. Due to volume limitations, these files need to be stored in large-capacity devices such as NOR FLASH and NAND FLASH. Since FLASH memory is susceptible to single-particle flip effects caused by space radiation in space applications, the stored data will change. Since the four types of files are indispensable, once the key position of any type of file flips, the operating system will not be able to run normally, causing the device function to be paralyzed. Therefore, a set of Linux boot methods with high fault tolerance and reliability is very important. Summary of the invention

[0004] In view of this, the purpose of the present invention is to provide a high-reliability startup method for aerospace embedded devices, reduce the risk of single-particle flips in storage devices NOR FLASH and NAND FLASH causing damage to Linux operating system components and failure to start normally, ensure the reliable startup of the aerospace equipment operating system, and improve the fault tolerance and stability of the equipment in a cost-effective manner.

[0005] The technical solution for implementing the present invention is as follows:

[0006] A high-reliability boot method for aerospace embedded devices, the aerospace embedded devices comprising DDR, NOR FLASH, NAND FLASH and a CPU supporting Linux operating system components, the Linux operating system components comprising boot0, uboot, Linux kernel image kernel, device tree dtb and a file system, the file system comprising a root file system rootfs and a memory file system ramfs;

[0007] Pre-store three copies of boot0, three copies of uboot, three copies of kernel images, three copies of dtb and three copies of ramfs in the NOR FLASH of the device; store three copies of rootfs, three copies of application software and three copies of user data in NAND FLASH; store three copies of md5 of all the above files in NORFLASH;

[0008] The boot process is as follows: select the correct operating system component by selecting two out of three to boot into ramfs; verify the NAND FLASH and the rootfs and application data stored in it in ramfs. If the verification is successful, it will switch to rootfs, otherwise it will enter the repair mode; the components will be inspected regularly in the operating system, and the wrong files will be replaced in the repair mode.

[0009] Furthermore, the startup process of the present invention is:

[0010] Step S1, after the device is powered on or reset, the CPU reads three boot0s from the NOR FLASH to the CPU internal storage space, and selects the correct boot0 to initialize the DDR memory by comparing two out of three.

[0011] Step S2, Boot0 reads three copies of uboot from NOR FLASH to three addresses of DDR, selects the correct uboot by comparing two out of three and copies it to the preset location of DDR, and the program jumps to DDR for execution, completing the hardware initialization work;

[0012] Step S3, uboot reads three kernels, three dtb, and three ramfs into DDR, selects the correct kernel, dtb, and ramfs for execution by comparing two out of three and verifying md5, and enters ramfs;

[0013] Step S4, check the NAND FLASH in ramfs, query the bad block status and try to mount; if there is a new bad block or NAND cannot be mounted correctly, it is necessary to reload the NAND; if the reload fails, execute step S7 to enter the repair mode;

[0014] Step S5, try to mount rootfs in ramfs, and verify the md5 values ​​of rootfs and various business codes stored therein. After successful mounting and verification, switch the file system from ramfs to rootfs, and execute the init program to start various services and application scripts; if all fail, execute step S7 to enter the repair mode;

[0015] Step S6: After the system is started and executes various business codes, the operating system background periodically inspects all files stored in the FLASH, and replaces the correctable error files based on the results of two out of three and the file md5 verification; if an uncorrectable error occurs that all three files are inconsistent, the system enters the repair mode;

[0016] Step S7, in repair mode, the operating system sends a file damage request and waits for files transmitted via TTE, Ethernet, etc. After confirming that the file is correct, it will enter the ramfs environment to deploy and replace related files and synchronize the md5 value. After the synchronization is completed and verified to be correct, the system will be restarted.

[0017] Furthermore, the NAND reloading of the present invention includes: unmounting the partition where the NAND FLASH bad block is located, formatting the corresponding partition, remounting the formatted partition, and writing the backup file if there is a backup of the file lost due to formatting and it passes the md5 check.

[0018] Furthermore, the startup solution of the present invention first verifies the rootfs, NAND FLASH and various service codes in ramfs, and switches from ramfs to rootfs after verification and continues the startup process.

[0019] Furthermore, the startup scheme of the present invention will periodically verify all files stored in FLASH in the background after the system is normally started, and replace the wrong files through comprehensive judgment of the results of three-out-of-two verification and md5 verification.

[0020] Furthermore, the method described in step S1 of the boot scheme of the present invention can be specifically implemented as follows: the CPU first reads a boot0 from NORFLASH to the internal storage space of the CPU, and then reads another two boot0s to the internal storage space of the CPU by bootstrapping.

[0021] Furthermore, the startup solution described in the present invention has a repair mode, and after errors occur in the three backup files, new files can be transmitted via TTE or Ethernet for deployment and repair.

[0022] Furthermore, the CPU architecture used in the startup scheme described in the present invention is ARMV7.

[0023] Furthermore, the NOR FLASH described in the present invention is 32MB and has a radiation-resistant design.

[0024] Furthermore, the NAND FLASH described in the present invention is 4GB and has a radiation-resistant design.

[0025] Beneficial effects:

[0026] First, the method proposed in the present invention can avoid erroneous files during the startup process, use a two-out-of-three comparison method to select the correct Linux operating system component to execute, and detect and correct erroneous files during system operation, thereby reducing the risk of system startup failure.

[0027] Second, the method proposed by the present invention takes into account the single particle upset effect that is easy to occur in the aerospace environment. In view of the characteristics of NOR FLASH and NAND FLASH in terms of radiation resistance and storage capacity, files of different levels are stored according to their importance, and different levels of verification methods are used. The more important primary boot files boot0, uboot and kernel are stored in the more reliable NOR FLASH, and the less important rootfs, application programs, business codes and user data are stored in the NAND FLASH in the large-capacity storage. The stability and reliability of the device are improved.

[0028] Third, the method proposed in the present invention can be updated through TTE, Ethernet, etc. after errors occur in the three backup files. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0030] Figure 1 This is an overall flow chart of a high-reliability startup method for aerospace embedded devices according to the present invention;

[0031] Figure 2 is a flow chart of the NAND reloading method of the present invention;

[0032] Figure 3 It is a flowchart of the repair mode in the present invention. DETAILED DESCRIPTION

[0033] The embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0034] It should be noted that the following embodiments and features in the embodiments may be combined with each other in the absence of conflict; and, based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the field without making any creative work are within the scope of protection of the present disclosure.

[0035] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein may be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on the present disclosure, it should be understood by those skilled in the art that an aspect described herein may be implemented independently of any other aspect, and two or more of these aspects may be combined in various ways. For example, any number of aspects described herein may be used to implement the device and / or practice the method. In addition, other structures and / or functionalities other than one or more of the aspects described herein may be used to implement this device and / or practice this method.

[0036] The technical solution adopted by the present invention is mainly applied to aerospace embedded devices (hereinafter referred to as devices). The hardware in such devices should at least include DDR, NOR FLASH, NAND FLASH and a CPU capable of running Linux operating system components. As a better choice, NOR FLASH and NAND FLASH with radiation-resistant design can be selected to reduce the risk of bit errors caused by single-particle flips. Considering that the operation of the system mainly runs in the CPU, CPU internal storage and DDR, as a better choice, DDR and CPU with radiation-resistant design (such as YULONG810A) can be selected to reduce the probability of bit flipping in the verification link and the first and second level boot links boot0 and uboot in the present invention.

[0037] The Linux operating system components include UBOOT-SPL (hereinafter referred to as boot0), uboot, Linux kernel image (hereinafter referred to as kernel), device tree (hereinafter referred to as dtb), and file system, wherein the file system includes root file system (hereinafter referred to as rootfs) and memory file system (hereinafter referred to as ramfs). Of course, if any two or more of the file system, dtb, and kernel are merged in some Linux system components, the method of the present invention can still be applied.

[0038] In order to maximize the effect of the present invention, it is necessary to store three copies of boot0, three copies of uboot, three copies of kernel images, three copies of dtb and three copies of ramfs in the NOR FLASH of the device in advance; store three copies of rootfs, application software and user data in NAND FLASH in advance; and store three copies of md5 of all the above files in NOR FLASH in advance. Therefore, the capacity of NOR FLASH should be at least larger than the space occupied by three copies of boot0, three copies of uboot, three copies of kernel images, three copies of dtb, three copies of ramfs and md5 of all files in FLASH; the capacity of NAND FLASH should be at least larger than the space occupied by three copies of rootfs, three copies of application software and three copies of user data. In this embodiment, 32MB NOR FLASH with radiation-resistant design and 4GB NAND FLASH with radiation-resistant design are used.

[0039] More specifically, under the same conditions, the radiation resistance performance index of NOR FLASH is about 10 times that of NAND FLASH. The boot scheme stores the more important first-level boot files boot0, uboot and kernel in the more reliable NOR FLASH, and stores the less important rootfs, application programs, business codes and user data in the NAND FLASH in the large-capacity storage.

[0040] The process of this method is as follows: select the correct operating system component by selecting two out of three to boot into ramfs; verify the NAND FLASH and the rootfs and application data stored therein in ramfs, and if the verification is successful, switch to rootfs, otherwise enter the repair mode; regularly inspect the components in the operating system and replace the erroneous files in the repair mode.

[0041] like Figure 1 As shown, the specific implementation method includes the following steps:

[0042] Step S1, after the device is powered on or reset, the CPU reads three boot0s from the NOR FLASH to the CPU internal storage space, and selects the correct boot0 to initialize the DDR memory by comparing two out of three. Further, reading three boot0s can be specifically described as: the CPU first reads one boot0 from the NOR FLASH to the CPU internal storage space, and then reads the other two boot0s to the CPU internal SRAM by bootstrapping.

[0043] Step S2, boot0 reads three copies of uboot from NOR FLASH to three addresses of DDR, selects the correct uboot by comparing two out of three and copies it to the preset location of DDR, and the program jumps to DDR for execution, completing the hardware initialization work.

[0044] Step S3, uboot reads three copies of kernel, three copies of dtb, and three copies of ramfs into DDR, selects the correct kernel, dtb, and ramfs for execution by comparing two out of three and verifying md5, and enters ramfs.

[0045] Step S4, check the NAND FLASH in ramfs, query the bad block status and try to mount; if new bad blocks appear or NAND cannot be mounted correctly, reload NAND. Figure 2 As shown, the NAND reload includes: unmounting the partition where the NAND FLASH bad block is located, formatting the corresponding partition, and remounting the formatted partition. For files lost due to formatting, if there is a backup in other partitions where no errors are found and the backup file passes the md5 check, otherwise if the reload fails, execute step S7 to enter the repair mode.

[0046] Step S5, try to mount rootfs in ramfs, and verify the md5 values ​​of rootfs and various business codes stored therein. After successful mounting and verification, switch the file system from ramfs to rootfs, and execute the init program to start various services and application scripts; if all fail, execute step S7 to enter the repair mode.

[0047] Furthermore, since the operating system has certain requirements on the startup time and CPU computing power during the startup process, different verification methods can be selected according to the startup time margin: if there is sufficient time, a complete three-out-of-two verification can be performed on the rootfs and various business codes, and the md5 values ​​of all files can be calculated and compared with the md5 stored in NORFLASH; otherwise, if there is insufficient time, only the md5 value of any one of them can be calculated and compared with the md5 stored in NOR FLASH. After the verification passes, the startup process is directly executed and the three-out-of-two verification is skipped.

[0048] Step S6, after the system completes startup and executes various business codes, the operating system background performs regular inspections, checks all FLASH files, and replaces correctable error files through comprehensive judgment of the results of three-out-of-two verification and md5 verification; if an uncorrectable error occurs in which all three files are inconsistent, the repair mode is entered.

[0049] Furthermore, after the operating system is started, there is no longer a constraint on the startup time. Therefore, from the perspective of reliability, all files should be regularly compared bit by bit and the md5 values ​​should be verified while limiting the computing power usage.

[0050] Step S7, in the repair mode, as shown in the attached Figure 3 As shown, the operating system sends a file damage request and waits for files transmitted through TTE, Ethernet, etc. After confirming that the file is correct, it will enter the ramfs environment to deploy and replace related files and synchronize the md5 value. After the synchronization is completed and verified, the system will be restarted.

[0051] The method proposed in the present invention takes into account the single particle upset effect that is prone to occur in the aerospace environment. According to the characteristics of NORFLASH and NAND FLASH in terms of radiation resistance and storage capacity, files of different levels are stored according to their importance, and verification methods of different levels are used. Error files can be avoided during the startup process, and error files can be detected and corrected during system operation. When errors occur in all three backup files, they are updated through TTE, Ethernet, etc., thereby reducing the risk of system startup failure and improving the stability and reliability of the equipment.

[0052] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A high-reliability startup method for aerospace embedded devices, characterized in that: The embedded device applied to aerospace includes DDR, NOR FLASH, NAND FLASH and a CPU supporting Linux operating system components, wherein the Linux operating system components include boot0, uboot, Linux kernel image kernel, device tree dtb and file system, wherein the file system includes a root file system rootfs and a memory file system ramfs; Pre-store three copies of boot0, three copies of uboot, three copies of kernel images, three copies of dtb and three copies of ramfs in the NOR FLASH of the device; store three copies of rootfs, three copies of application software and three copies of user data in NAND FLASH; store three copies of md5 of all the above files in NOR FLASH; The boot process is as follows: select the correct operating system component by selecting two out of three to boot into ramfs; verify the NAND FLASH and the rootfs and application data stored in it in ramfs. If the verification is successful, it will switch to rootfs, otherwise it will enter the repair mode; the components will be inspected regularly in the operating system, and the wrong files will be replaced in the repair mode.

2. The high-reliability startup method for aerospace embedded devices according to claim 1, characterized in that: The startup process is: Step S1, after the device is powered on or reset, the CPU reads three boot0s from the NOR FLASH to the CPU internal storage space, and selects the correct boot0 to initialize the DDR memory by comparing two out of three. Step S2, Boot0 reads three copies of uboot from NOR FLASH to three addresses of DDR, selects the correct uboot by comparing two out of three and copies it to the preset location of DDR, and the program jumps to DDR for execution, completing the hardware initialization work; Step S3, uboot reads three kernels, three dtb, and three ramfs into DDR, selects the correct kernel, dtb, and ramfs for execution by comparing two out of three and verifying md5, and enters ramfs; Step S4, check the NAND FLASH in ramfs, query the bad block status and try to mount; if there is a new bad block or NAND cannot be mounted correctly, it is necessary to reload the NAND; if the reload fails, execute step S7 to enter the repair mode; Step S5, try to mount rootfs in ramfs, and verify the md5 values ​​of rootfs and various business codes stored therein. After successful mounting and verification, switch the file system from ramfs to rootfs, and execute the init program to start various services and application scripts; If all fail, execute step S7 to enter the repair mode; Step S6: After the system is started and executes various business codes, the operating system background periodically inspects all files stored in the FLASH, and replaces correctable error files based on the results of two out of three and the file md5 verification. If an uncorrectable error occurs where all three files are inconsistent, the repair mode is entered; Step S7, in repair mode, the operating system sends a file damage request and waits for files transmitted via TTE, Ethernet, etc. After confirming that the file is correct, it will enter the ramfs environment to deploy and replace related files and synchronize the md5 value. After the synchronization is completed and verified to be correct, the system will be restarted.

3. The high-reliability startup method for aerospace embedded devices according to claim 2, characterized in that: The NAND reloading includes: unmounting the partition where the NAND FLASH bad block is located, formatting the corresponding partition, remounting the formatted partition, and writing the backup file if there is a backup of the file lost due to formatting and it passes the md5 check.

4. The high-reliability startup method for aerospace embedded devices according to claim 2, characterized in that: In ramfs, rootfs, NAND FLASH and various business codes are first verified. After they are correct, ramfs switches to rootfs and continues the startup process.

5. The high-reliability startup method for aerospace embedded devices according to claim 2, characterized in that: After the system starts normally, all files stored in FLASH will be checked regularly in the background. The wrong files will be replaced through comprehensive judgment based on the results of three-out-of-two check and md5 check.

6. The high-reliability startup method for aerospace embedded devices according to claim 2, characterized in that: The method described in step S1 is specifically as follows: the CPU first reads a copy of boot0 from the NOR FLASH to the internal storage space of the CPU, and then reads another two copies of boot0 to the internal storage space of the CPU in a bootstrap manner.

7. The high-reliability startup method for aerospace embedded devices according to claim 2, characterized in that: In the repair mode, after errors occur in all three backup files, new files can be transferred via TTE or Ethernet for deployment and repair.

8. The high-reliability startup method for aerospace embedded devices according to claim 2, characterized in that: The CPU architecture used in the startup scheme is ARMV7.

9. The high-reliability startup method for aerospace embedded devices according to claim 2, characterized in that: The NOR FLASH is 32MB and has a radiation-resistant design.

10. The high-reliability startup method for aerospace embedded devices according to claim 2, characterized in that: The NAND FLASH is 4GB and has a radiation-resistant design.

Images