A method for APP loading and on-orbit reconstruction in an operating system based on ROMFS

Abstract

The present invention provides a method for loading and reconfiguring apps in a ROMFS-based operating system on-orbit, comprising: encapsulating an app independently compiled into an ELF format into a ROMFS image, and burning and solidifying the image as a whole in three locations of a spacecraft operating system memory; defining a ROMFS segment with a fixed address in the memory; after the operating system is powered on, using boot software to load two of the three ROMFS images in the memory into the ROMFS segment; the operating system uses the ROMFS segment to establish a ROMFS file system; using an ELF loader to load and link the ELF-formatted app in the ROMFS into the spacecraft operating system space for execution; during on-orbit reconfiguration of the app, the ground injects the ROMFS image into a buffer packet by packet, and then burns the image into three areas in the memory using a FLASH burn instruction. The method of the present invention effectively solves the problem of the spacecraft operating system boot software reading and writing apps in the file system, thereby improving the reliability of on-orbit loading and reconfiguration of apps.

Description

Technical Field

[0001] The present invention relates to the technical field of APP loading, and in particular to a method for APP loading and on-orbit reconstruction in a ROMFS-based operating system. Background Art

[0002] There are generally two types of coexistence relationships between operating systems and APPs:

[0003] Method 1: The APP is compiled together with the operating system as part of the operating system and linked into the operating system address space to become one and solidify together; it is boot-loaded at the same time when power is turned on, and after the operating system is running, the main function of the application is called by the API to start the APP.

[0004] Method 2: The APP is independently compiled into a standard ELF file and stored in the file system of the operating system. After the operating system starts, the file system is mounted, and then the ELF loader is used to load the ELF format APP from the file system, link it to the operating system address space, and run it.

[0005] On-orbit reconstruction of spacecraft software differs significantly from ground-based software reconstruction. Since spacecraft transit over ground tracking and control stations is relatively short, the time available for ground-based software integration is relatively short. Large software integration typically requires multiple tracks, making the operation very complex. Traditional space-based RTOS (Real Time Operating System) systems with static memory allocation do not support dynamic loading. Applications are compiled and linked together with the operating system. On-orbit reconstruction requires only the application and RTOS to be rebuilt together. Due to the large size of the target file, software reconstruction takes a long time.

[0006] Traditional aerospace RTOS with static memory allocation does not support dynamic loading and can only use method 1. For operating systems that use separate compilation and dynamic loading technology, the operating system and APP are compiled separately and stored in different areas of EEPROM / FLASH. On-orbit reconstruction can reconstruct the APP or RTOS separately, which can effectively solve the above problems. However, there are several problems in aerospace applications:

[0007] (1) Dynamic loading of the operating system is to load the ELF format or other executable application target files from the file system. The application target files are usually stored in the FLASH file system, such as Yaffs, Fat32, Tffs, etc. However, the FLASH file system is usually large, and the spacecraft single-machine SRAM is generally small, which makes it difficult to support the FLASH file system.

[0008] (2) Applications are stored in EEPROM / FLASH, which is an erasable memory. Therefore, there is a possibility that the application and operating system will be abnormally rewritten on orbit, resulting in the system being unable to start. Therefore, spacecraft software generally requires a minimum system boot software to be solidified in the PROM to ensure that the application software or operating system can be repaired through the minimum system software when the above abnormal problems occur. However, since the minimum system software does not support the FLASH file system, it cannot access the ELF format application in the FLASH file system, resulting in the inability to reconstruct the ELF format application through the minimum system software.

[0009] (3) To ensure reliability, aerospace software generally requires that three copies of application software be stored in EEPROM / FLASH, and loaded into SRAM in a two-out-of-three manner during boot loading. However, the standard ELF loader of the operating system cannot dynamically load three ELF files in the file system in a two-out-of-three manner, which cannot meet the reliability requirements. Summary of the Invention

[0010] The technical problem solved by the present invention is: to overcome the shortcomings of the existing technology, and to provide a method for APP loading and on-orbit reconstruction under an operating system based on ROMFS, thereby effectively improving the reliability of on-orbit loading and reconstruction of spacecraft APP.

[0011] The technical solution of the present invention is:

[0012] A method for loading and reconstructing an APP in an operating system based on ROMFS includes the following steps:

[0013] (1) During the ground phase, the APP compiled independently into the ELF format is encapsulated into a ROMFS image, and the ROMFS image is burned and solidified in three locations of the spacecraft operating system ROM memory;

[0014] (2) Define a ROMFS segment with a fixed address in the spacecraft operating system memory;

[0015] (3) After the spacecraft operating system is powered on during the on-orbit phase, the boot software loads the ROMFS image in the memory into the ROMFS segment defined in the memory by taking two out of three words. If the loading is successful, the process proceeds to step (4); otherwise, the process proceeds to step (6).

[0016] (4) The spacecraft operating system uses the allocated ROMFS segment in the memory to build the ROMFS file system according to the loaded ROMFS image;

[0017] (5) The spacecraft operating system uses the ELF loader to load and link the ELF formatted APP in the ROMFS into the spacecraft operating system space for execution and exit method;

[0018] (6) The ground divides the APP's ROMFS image into multiple file packages and uploads them to the spacecraft operating system multiple times. Each uploaded file package is stored in the upload program buffer in the spacecraft operating system memory. When all file packages are uploaded, the APP's ROMFS image is burned to three locations in the spacecraft operating system memory according to the burning instructions sent from the ground, completing the APP on-orbit reconstruction and entering step (3).

[0019] Preferably, in step (1), the APP independently compiled into the ELF format is encapsulated into a ROMFS image, specifically as follows:

[0020] (11) Independently compile APP and generate ELF format files;

[0021] (12) Create a ROMFS file directory, create a new startup script file in it, and copy the ELF format file to the ROMFS file directory;

[0022] (13) Encapsulate the ROMFS file directory and the files therein into an image file in img format;

[0023] (14) The checksum and file length of the img format image file are appended to the front of the img format image file to form a bin format image file, which is the ROMFS image of the APP independently compiled into the ELF format.

[0024] Preferably, in step (5), the spacecraft operating system executes the startup script file in the ROMFS image, uses the ELF loader to load and link the APP in the ELF format in the ROMFS into the spacecraft operating system space for operation.

[0025] Preferably, the APP independently compiled into the ELF format uses the strip version in the compilation Release result.

[0026] Preferably, the spacecraft operating system ROM memory is a Flash memory.

[0027] Preferably, it is characterized in that the spacecraft operating system ROM memory is an EEPROM memory.

[0028] Preferably, it is characterized in that the spacecraft operating system memory is SRAM.

[0029] The advantages of the present invention compared with the prior art are:

[0030] (1) The present invention uses ROMFS to encapsulate the APP, which reduces the size of the operating system compared to the traditional method of storing the APP in the FLASH file system and solves the problem of the boot software reading and writing the APP in the file system;

[0031] (2) The present invention loads the entire ROMFS from EEPROM / FLASH to SRAM in a three-out-two manner before ROMFS is constructed, thereby solving the inherent problem that the operating system ELF loader cannot load ELF files in a three-out-two manner, thereby improving system reliability;

[0032] (3) The present invention performs secondary processing on the APP image in img format and appends the ROMFS length to the front of the image, so that the operating system can obtain the ROMFS size by reading the ROMFS starting address, solving the problem that the operating system does not know the ROMFS size when establishing ROMFS;

[0033] (4) The present invention allocates ROMFS to a specially defined ROMFS segment in the BSP link command file. Compared with the traditional method of compiling and linking the existing ROMFS image into the operating system code segment, the present invention solves the problem of unstable ROMFS address caused by changes in the operating system code segment. Compared with the traditional method of statically allocating ROMFS space addresses, the present invention solves the problem of conflict between ROMFS memory and dynamic memory allocation of the operating system. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 This is a schematic diagram of the ROMFS image packaging and on-orbit loading process of the APP of the present invention;

[0035] Figure 2 This is a schematic diagram of the ROMFS image storage format of the APP of the present invention;

[0036] Figure 3 A schematic diagram of a ROMFS segment program that defines a fixed address for the present invention;

[0037] Figure 4 A schematic diagram of the process of APP loading and on-track reconstruction method under the ROMFS-based operating system of the present invention. DETAILED DESCRIPTION

[0038] The following detailed description of the present invention will make the features and advantages of the present invention more clear and explicit.

[0039] like Figure 1 As shown, a method for loading and reconstructing an APP in an operating system based on ROMFS includes the following steps:

[0040] S1: Compile the APP independently into ELF format.

[0041] Specifically, ROMFS is a lightweight read-only file system. The file system itself increases very little relative to the content in the file system. Therefore, encapsulating the APP into a ROMFS image will not make the APP too bloated.

[0042] Furthermore, the APP is compiled independently to generate the ELF format target file xxx.elf. In order to reduce the size of the APP, the strip version (without compiling the Debug statement) in the Release result is used (without compiling the Debug statement) (without symbol information and debugging information).

[0043] S2: Encapsulate the APP and startup script startup.sh compiled independently into ELF format into a ROMFS image.

[0044] Specifically, create an APP startup script startup.sh file in the romfs directory (used in step S7 to implement dynamic loading and running of the APP), the content of which is:

[0045] / mnt / romfs / usr / xxx&

[0046] Copy xxx.elf to the romfs / usr directory;

[0047] Use the genromfs.exe tool outside the romfs directory to encapsulate the romfs directory and its files into a ROMFS image romfs.img. The execution command is:

[0048] genromfs.exe–d. / romfs–f. / romfs.img

[0049] Specifically, ROMFS is a lightweight read-only file system. The file system itself increases very little relative to the content in the file system. Therefore, encapsulating the APP into a ROMFS image will not make the APP too bloated.

[0050] S3: Calculate the checksum of romfs.img and append the length and checksum of romfs.img to generate romfs.bin file. The execution command is:

[0051] sumromfs.exe. / romfs.img

[0052] And burn romfs.bin to three locations in Flash / EEPROM. The storage format of each location is as follows: Figure 2In this way, if one of the three data at the same offset address in ROMFS in Flash / EEPROM is wrong, the correct data can still be obtained by taking two out of three.

[0053] S4: Define the ROMFS segment with a fixed address in the SRAM (Static Random Access Memory) in the spacecraft operating system BSP (BSP Board Support Package) link command file, and map romfs to the ROMFS segment. The program is as follows: Figure 3 As shown in the figure, burn the compiled operating system image (including BSP) into the Flash / EEPROM.

[0054] Steps S1 to S4 are performed before the spacecraft is launched, completing the ROMFS image packaging of the APP. Figure 1 shown.

[0055] S5: If Figure 4 As shown in the figure, when the spacecraft operating system is powered on and the boot software runs for 10 seconds or receives a jump instruction within 10 seconds, the boot software first loads the operating system in FLASH / EEPROM to SRAM in a three-out-two manner. If the loading fails, it waits for the ground to re-load the operating system and then loads again until the loading is successful.

[0056] S6: After the operating system is loaded successfully, the boot software loads two out of three romfs.bin files in the FLASH / EEPROM into the predefined ROMFS segment in the operating system. If the two out of three loading is successful, the process proceeds to step S7; if the two out of three loading fails, the process proceeds to step S9;

[0057] S7: During the boot process, the operating system uses the ROMFS segment to create a ROMFS file system in the BSP initialization phase and mounts it under / mnt;

[0058] S8: The operating system executes the commands in the startup.sh startup script in the / mnt / romfs directory, and uses the ELF loader to load and link the ELF format APP software in the ROMFS into the operating system space for execution;

[0059] S9: The ground uploads a new romfs.bin program block to the spacecraft. After the boot software receives romf.bin, it first caches it in the uploaded program buffer in SRAM. After receiving the burning instruction from the ground, it burns the uploaded romf.bin file to EEPROM / FLASH and waits for the ground to send a jump instruction. After receiving the jump instruction sent by the ground, it enters step S6.

[0060] In order to achieve dynamic loading, the application or driver needs to be compiled into a position-independent operating system loadable file. ELF (Executable and Linking Format) is a commonly used loadable file format for APPs. When the operating system establishes ROMFS, it needs to know the size of ROMFS. Since ROMFS changes with the size of the APP in it, and APP is compiled independently from RTOS, the RTOS cannot know the size of ROMFS. Therefore, ROMFS needs to be processed secondary to append the size of ROMFS to the front of the ROMFS file. In order to ensure flexible startup, the operating system generally does not execute APP directly, but puts the commands to start each APP in a dedicated script file. After the operating system starts, all APPs are started by executing the startup script.

[0061] The above is only a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by any technician familiar with this technical field within the technical scope disclosed by the present invention should be covered by the scope of protection of the present invention.

[0062] The contents not described in detail in the specification of the present invention belong to the common knowledge of those skilled in the art.

Claims

1. A method for loading and reconstructing APP in an operating system based on ROMFS, characterized in that The following steps are involved: (1) During the ground phase, the APP independently compiled into the ELF format is encapsulated into a ROMFS image, and the ROMFS image is burned and solidified in three locations of the spacecraft operating system ROM memory; (2) Define a ROMFS segment with a fixed address in the spacecraft operating system memory; (3) After the spacecraft operating system is powered on during the on-orbit phase, the boot software loads the ROMFS image in the memory into the ROMFS segment defined in the memory according to the three-out-of-three ratio; if the loading is successful, proceed to step (4); otherwise, proceed to step (6); (4) The spacecraft operating system uses the allocated ROMFS segment in the memory to build the ROMFS file system according to the loaded ROMFS image; (5) The spacecraft operating system uses the ELF loader to load and link the ELF formatted APP in the ROMFS into the spacecraft operating system space for execution and exit method; (6) The ground divides the APP's ROMFS image into multiple file packages and uploads them to the spacecraft operating system multiple times. Each uploaded file package is stored in the upload program buffer in the spacecraft operating system memory. When all file packages are uploaded, the APP's ROMFS image is burned to three locations in the spacecraft operating system memory according to the burning instructions sent from the ground, completing the APP on-orbit reconstruction and entering step (3).

2. The method for loading and reconstructing an APP in an operating system based on ROMFS according to claim 1, characterized in that: In the step (1), the APP independently compiled into the ELF format is encapsulated into a ROMFS image, specifically: (11) Independently compile the APP and generate an ELF format file; (12) Create a ROMFS file directory, create a new startup script file in it, and copy the ELF format file to the ROMFS file directory; (13) Encapsulate the ROMFS file directory and the files therein into an image file in img format; (14) The checksum and file length of the img format image file are appended to the front of the img format image file to form a bin format image file, which is the ROMFS image of the APP independently compiled into the ELF format.

3. The method for loading and reconstructing an APP in an operating system based on ROMFS according to claim 2, characterized in that: In step (5), the spacecraft operating system executes the startup script file in the ROMFS image, uses the ELF loader to load and link the ELF format APP in the ROMFS into the spacecraft operating system space for operation.

4. The method for loading and reconstructing an APP in an operating system based on ROMFS according to claim 3, characterized in that: The APP independently compiled into ELF format uses the strip version in the compilation Release result.

5. A method for loading and reconstructing an APP in an operating system based on ROMFS according to any one of claims 1 to 4, characterized in that: The spacecraft operating system ROM memory is a Flash memory.

6. A method for loading and reconstructing an APP in a ROMFS-based operating system according to any one of claims 1 to 4, characterized in that: The spacecraft operating system ROM memory is an EEPROM memory.

7. A method for loading and reconstructing an APP in a ROMFS-based operating system according to any one of claims 1 to 4, characterized in that: The spacecraft operating system memory is SRAM.

Images