High-reliability distributed software storage architecture based on FMQL45T900 and solidification method

Abstract

The invention relates to an FMQL45T900-based high-reliability distributed software storage architecture and a solidification method, and the architecture comprises a secondary bootstrap program mirror image area which is used for storing a secondary bootstrap program mirror image; the programmable logic program mirror image area is used for storing a programmable logic program mirror image; the programmable logic program mirror image backup area is used for storing a programmable logic program mirror image; the processing system program mirror image area is used for storing a processing system program mirror image; the processing system program mirror image backup area is used for storing a processing system program mirror image; the mirror image information area is used for storing the programmable logic program mirror image and the pre-stored file length and the pre-stored CRC check value of the processing system program mirror image, and the problems that an existing FMQL45T900 chip software storage architecture is lack of a backup mechanism and weak in anti-jamming capability can be solved; and when any part is updated, all contents need to be burnt again, so that the upgrading flexibility is insufficient.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of human-computer interaction, and particularly relates to a high-reliability distributed software storage architecture based on an FMQL45T900 and a solidification method. BACKGROUND

[0002] In the process of weapon equipment system development, the degree of localization of components is continuously improved. Among them, the FMQL45T900 full programmable fusion chip developed by Fudan Microelectronics integrates a four-core ARM Cortex-A7 hard core processing system (PS) and programmable logic (PL), has high-performance data processing and flexible hardware configuration capabilities, and has been applied in related fields.

[0003] Currently, the software storage architecture commonly used by the FMQL45T900 chip is as follows: a FLASH is used as a storage carrier, and a single binary (bin) image file is stored. The bin image file includes three core components: first, a secondary boot program (FSBL) for loading and booting the PL and PS programs; second, a programmable logic program (PL program); and third, a four-core ARM application program (PS program). The software storage architecture stores the entire software system in the FLASH in the form of a single image, without a redundant backup design, resulting in a lack of backup mechanism and weak anti-interference capability. The FSBL program, the PL program, and the PS program are integrated and packaged as a single bin image file, and the three are stored together, resulting in the need to reprogram all contents when updating any part, and insufficient upgrade flexibility. SUMMARY

[0004] The present application provides a high-reliability distributed software storage architecture based on an FMQL45T900 and a solidification method, which can solve the problems of the existing FMQL45T900 chip software storage architecture, such as a lack of backup mechanism, weak anti-interference capability, the need to reprogram all contents when updating any part, and insufficient upgrade flexibility.

[0005] In a first aspect, the present application provides a high-reliability distributed software storage architecture based on an FMQL45T900, comprising: a secondary boot program image area for storing a secondary boot program image; a programmable logic program image area for storing a programmable logic program image; a programmable logic program image backup area for storing a programmable logic program image; a processing system program image area for storing a processing system program image; The processing system program image backup area is used for storing the processing system program image. The mirror information area is used for storing the programmable logic program image, the pre-stored file length and the pre-stored CRC check value of the processing system program image.

[0006] In some embodiments, the storage capacity of the secondary boot program image area is 512K, and the secondary boot program image area stores three copies of the secondary boot program image. In some embodiments, the storage capacity of the mirror information area is 64K, and the mirror information area stores three copies of the programmable logic program image, the pre-stored file length and the pre-stored CRC check value of the processing system program image.

[0007] In some embodiments, the storage capacity of the programmable logic program image area is 13.4M, the storage capacity of the programmable logic program image backup area is 13.4M, the storage capacity of the processing system program image area is 2M, and the storage capacity of the processing system program image backup area is 2M.

[0008] In some embodiments, the processing system program image includes a first processing system program image, a second processing system program image, a third processing system program image and a fourth processing system program image. The processing system program image area includes a first system program image area, a second system program image area, a third system program image area and a fourth system program image area, and the processing system program image backup area includes a first system program image backup area, a second system program image backup area, a third system program image backup area and a fourth system program image backup area. The first system program image area and the first system program image backup area are used for storing a first processing system program image, the second system program image area and the second system program image backup area are used for storing a second processing system program image, the third system program image area and the third system program image backup area are used for storing a third processing system program image, and the fourth system program image area and the fourth system program image backup area are used for storing a fourth processing system program image.

[0009] In a second aspect, the embodiments of the present application provide a high-reliability distributed software storage architecture solidification method based on FMQL45T900, applied to the high-reliability distributed software storage architecture based on FMQL45T900 in any of the first aspect, and including: Compiling a solidification TCL script; Compiling a user-executed solidification bat script; The user executes the solidification bat script to call the solidification TCL script and solidify the FMQL45T900-based high-reliability distributed software storage architecture according to any one of the first aspect to the target processor by executing the solidification TCL script.

[0010] In some embodiments, the compiling the solidification TCL script comprises: determining a plurality of target bin files based on the FMQL45T900-based high-reliability distributed software storage architecture according to any one of the first aspect; compiling a solidification TCL script for the target bin file.

[0011] In some embodiments, the compiling a solidification TCL script for the target bin file comprises: configuring the target processor to identify the target processor; initializing an emulator to connect the target processor through the emulator; configuring a path, a solidification address, a FLASH type and a connection parameter of the target bin file; starting a solidification operation.

[0012] In some embodiments, the plurality of target bin files correspond to the partitions of the FMQL45T900-based high-reliability distributed software storage architecture according to any one of the first aspect one by one; The compiling a solidification TCL script for the target bin file further comprises: quitting the solidification application software.

[0013] In some embodiments, the compiling the user-executed solidification bat script comprises: entering a solidification application software installation directory; starting a background running program of the solidification application software; starting the solidification TCL script.

[0014] Compared with the prior art, the above technical solutions provided by the embodiments of the present application have the following advantages: The high-reliability distributed software storage architecture and solidification method based on the FMQL45T900 provided by the embodiment of the application, by setting the programmable logic program image backup area and the processing system program image backup area, the core program can be double-stored, even if the main image area data is abnormal, the backup area program can be called to ensure the normal startup and operation of the chip; by independently storing the secondary boot program image, the programmable logic program image and the processing system program image partition area, there is no need to bundle them into a single bin image file, so that when updating a part of the program, only the corresponding partition content needs to be burned, and there is no need to burn all the programs again; by setting the image information area to store the pre-stored file length and pre-stored CRC check value of the programmable logic program image and the processing system program image, it can be verified whether the program is complete, damaged program loading is avoided, the problems of the existing FMQL45T900 chip software storage architecture, such as the lack of backup mechanism, weak anti-interference ability, the need to re-burn all the contents when updating any part and insufficient upgrade flexibility, can be solved. BRIEF DESCRIPTION OF DRAWINGS

[0015] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments consistent with the present application and, together with the description, further serve to explain the principles of the application.

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, for those skilled in the field, other drawings can also be obtained based on these drawings without any creative work.

[0017] One or more embodiments are exemplarily illustrated by pictures in the drawings corresponding thereto, and these exemplary illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, unless otherwise specified. The drawings in the drawings do not constitute a proportional limitation.

[0018] Figure 1 The high-reliability distributed software storage architecture based on the FMQL45T900 provided by the embodiment of the application is shown in the figure. Figure 2 The high-reliability distributed software storage architecture solidification method flowchart based on the FMQL45T900 provided by the embodiment of the application is shown in the figure. Figure 3 The high-reliability distributed software storage architecture solidification method code diagram based on the FMQL45T900 provided by another embodiment of the application is shown in the figure. DETAILED DESCRIPTION

[0019] In order to make the purposes, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0020] The following disclosure provides many different embodiments, or examples, for implementing different structures of the present application. For the purpose of simplification, the components and arrangements of specific examples are described in the following. Of course, they are only examples, and the purpose is not to limit the present application. In addition, the present application can repeatedly refer to numbers and / or letters in different examples. Such repetition is for the purpose of simplification and clarity, which itself does not indicate the relationship between the various embodiments and / or arrangements discussed.

[0021] In the process of weapon equipment systematization development in China, the localization of core components and independent controllability have become the key demand to ensure the reliability and safety of equipment. FMQL45T900 full programmable fusion chip developed by Fudan Microelectronics is one of the representative products of domestic core components, which integrates four-core ARM Cortex-A7 hard-core processing system (PS) and programmable logic (PL), and has high-performance data processing and flexible hardware configuration capabilities, and has been applied in related fields.

[0022] Currently, the software storage architecture commonly used in FMQL45T900 chips is as follows: FLASH is used as the storage medium to store a single binary (bin) image file. This image file adopts an integrated packaging design and contains three core components: First, the secondary bootloader (FSBL), which serves as the core boot module for chip startup and is responsible for initializing and loading the PL and PS programs; second, the programmable logic program (PL program), which carries the hardware logic configuration and implementation of dedicated functions; and third, the quad-core ARM application program (PS program, or processing system program), which implements core business functions such as complex data processing and task scheduling. Although this storage architecture achieves integrated storage and startup of the software system, it has the following shortcomings in terms of reliability, maintainability, and fault tolerance: 1) Lack of backup mechanism and weak anti-interference capability: The entire software system is stored in FLASH in the form of a single image without redundant backup design. Due to the complex electromagnetic environment or long-term use of FLASH, the system is vulnerable to interference. 1) Bit flipping faults are prone to occur. Once the critical bits of the image file are damaged, it will directly lead to program loading failure or abnormal operation, which will seriously affect the reliability of the chip and even the entire equipment system. 2) The integrated packaging design lacks upgrade flexibility: The FSBL program, PL program and PS program are integrated and packaged into a single bin image file. The three are stored together. When it is necessary to upgrade or iterate any part of the program or repair faults, the complete image must be regenerated and fully burned. This not only increases the complexity and time consumption of the upgrade operation, but also increases the overall system risk caused by the upgrade operation. 3) Poor upgrade fault tolerance and high fault repair cost: During the software upgrade process, if there is a sudden power outage, burning interruption or other abnormal situation, the original image file in FLASH is easily damaged and the new image has not been written, resulting in an unusable state. At this time, the chip usually needs to be disassembled and repaired by changing the external boot circuit and connecting a special burning device. The operation is complicated and the maintenance cost is extremely high.

[0023] Firstly, such as Figure 1 As shown, to address the aforementioned technical problems, this application provides a high-reliability distributed software storage architecture based on FMQL45T900, including: The secondary bootloader image area is used to store the secondary bootloader image; Programmable logic program image area, used to store programmable logic program images; Programmable logic program image backup area, used to store programmable logic program images; The system program image area is used to store the system program image. The system program image backup area is used to store the system program image. The image information area is used to store the pre-stored file length and pre-stored CRC check value of the programmable logic program image and the processing system program image.

[0024] It should be noted that, in this embodiment, the 32MB FLASH memory is divided into six independent areas: the secondary boot program image area (FSBL program image area), the programmable logic program image area (PL program image area), the programmable logic program image backup area (PL program image backup area), the processing system program image area (PS program image area), the processing system program image backup area (PS program image backup area), and the image information area. By setting the programmable logic program image area, the programmable logic program image backup area, the processing system program image area, and the processing system program image backup area, independent backup areas can be set for both the programmable logic program and the processing system program, avoiding program failure caused by FLASH bit flips. This allows for dual storage of the core program (the programmable logic program and the processing system program). Even if the data in the main image area is abnormal, the backup program can be called to ensure the chip starts up and runs normally.

[0025] It should be noted that by storing the secondary bootloader image, the programming logic program image, and the processing system program image in separate partitions, without bundling them into a single .bi file, when updating a part of the program, only the corresponding partition content needs to be burned, without re-burning the entire program, thus reducing update costs and time. By setting the image information area and storing the pre-stored file length and pre-stored CRC check value within it, the integrity of the program can be quickly verified, avoiding the loading of corrupted programs. Furthermore, when upgrading the program, only the target partition is operated on. Even in the event of an abnormal power outage, the unaffected core boot sector and backup sector remain unaffected, and booting can be restored without modifying the external boot circuit.

[0026] In some embodiments, the storage capacity of the secondary bootloader image area is 512K, and the secondary bootloader image area stores three copies of the secondary bootloader image.

[0027] In some embodiments, the storage capacity of the image information area is 64K, and the image information area stores three copies of the programmable logic program image, the pre-stored file length of the processing system program image, and the pre-stored CRC check value.

[0028] It should be noted that the secondary bootloader image area is located in Sector 0 to 7, occupying 8 sectors and a total of 512K. By storing three copies of the secondary bootloader image, the fault tolerance capability far exceeds that of a single backup. It can resist bit flips or partial data corruption in multiple areas of FLASH. Even if 1-2 copies of the image fail due to a fault, there are still usable copies to ensure that the secondary bootloader is loaded normally, avoiding chip startup failure. In addition, the fixed sector range (0 to 7 sectors) makes it easy for the chip to quickly locate the image position during startup, improving boot loading efficiency.

[0029] It should be noted that the image information area is located in Sector 255, which is 64K in total. By storing the pre-stored file length and pre-stored CRC check value of the three programmable logic program images and the processing system program image, the verification failure caused by the corruption of a single verification information can be avoided. Even if some verification information is corrupted due to problems such as FLASH bit flipping, the program integrity verification can still be completed through the remaining valid information to prevent the loading of abnormal programs. The 64K capacity (1 sector) can accommodate three verification information without occupying too much FLASH storage space, which is conducive to the efficient use of storage resources. The independent area fixed in Sector 255 makes it easy for the chip to quickly locate the verification information, shorten the verification time before program loading, and improve the startup efficiency.

[0030] In some embodiments, the storage capacity of the programmable logic program image area is 13.4M, the storage capacity of the programmable logic program image backup area is 13.4M, the storage capacity of the processing system program image area is 2M, and the storage capacity of the processing system program image backup area is 2M.

[0031] It should be noted that the programmable logic program image area is located in Sector 8 to 222, with 215 sectors totaling 13.4M; the processing system program image area is located in Sector 223 to 254, with 32 sectors totaling 2M, and is used to store 4 ARM software images (i.e., the processing system program images); the programmable logic program image backup area is located in Sector 256 to 470, with 215 sectors totaling 13.4M; and the processing system program image backup area is located in Sector 471 to 502, with 32 sectors totaling 2M, and stores 4 ARM software images (i.e., the processing system program images).

[0032] It should be noted that the PL program image area and the PL program image backup area are each 13.4M, and the PS program image area and the PS program image backup area are each 2M. The capacity fully matches the storage requirements of the two types of programs. There is no need to compress or split the programs. It can completely store all the functional code of the programmable logic program image (PL program image) and the processing system program image (PS program image), avoiding functional loss due to insufficient capacity.

[0033] In some embodiments, the processing system program image includes a first processing system program image, a second processing system program image, a third processing system program image, and a fourth processing system program image; The processing system program image area includes a first system program image area, a second system program image area, a third system program image area, and a fourth system program image area; the processing system program image backup area includes a first system program image backup area, a second system program image backup area, a third system program image backup area, and a fourth system program image backup area. The first system program image area and the first system program image backup area are used to store the first processing system program image, the second system program image area and the second system program image backup area are used to store the second processing system program image, the third system program image area and the third system program image backup area are used to store the third processing system program image, and the fourth system program image area and the fourth system program image backup area are used to store the fourth processing system program image.

[0034] It should be noted that each of the four ARM applications (i.e., the first processing system program image ARM0, the second processing system program image ARM1, the third processing system program image ARM2, and the fourth processing system program image ARM3) has its own independent main storage area and backup area, realizing "one core, one image, one backup" dedicated storage. When the program of a single core is damaged or abnormal, the corresponding backup area program can be directly called to start, without affecting the normal operation of other cores, which greatly reduces the risk of the entire PS system being paralyzed due to the failure of a single program. Moreover, the four-core program can be updated independently, without having to burn all the content as in the original architecture, and without having to update the programs of other cores as well. When upgrading the function or fixing bugs of a specific core, only the main and backup partitions corresponding to that core need to be operated, reducing the amount of data updated, shortening the upgrade time, and reducing the probability of errors during the upgrade process.

[0035] Secondly, such as Figure 2 , 3As shown, this application provides a method for solidifying a high-reliability distributed software storage architecture based on FMQL45T900, applied to the high-reliability distributed software storage architecture based on FMQL45T900 as described in any one of the first aspects, including: S101: Compile and solidify TCL scripts; S102: Compile a user-executed batch script; S103: Execute the user-executed hardening bat script to call the hardening TCL script and harden the high-reliability distributed software storage architecture based on FMQL45T900 as described in any one of the first aspects onto the target processor by executing the hardening TCL script.

[0036] It should be noted that in the embedded system development and production process, burning the compiled application binary files (bin files) to the FLASH storage medium is a crucial step. The PROCISE software developed by Shanghai Fudan Microelectronics is currently a commonly used tool for this function. The general process of burning FLASH using PROCISE is as follows: open the burning interface, select the bin file to be burned, configure parameters such as the burning address, FLASH type, and connection speed, click "burn," and exit the burning interface after completion. This process has the following shortcomings: 1) Because it requires configuring a series of parameters, users need a certain level of professional knowledge; 2) Burning multiple bin files to FLASH requires repeatedly opening the software interface and configuring parameters, making the operation cumbersome; 3) Burning multiple bin files to FLASH usually takes about 30 minutes, requiring users to wait and operate throughout the process, resulting in low work efficiency.

[0037] It should be noted that traditional file fixing requires manual operation of the software interface, such as selecting files, configuring parameters, and clicking "start." This method automates these steps through scripts. Users only need to double-click the user-execute-fixing batch script to start the entire fixing process until completion, reducing manual intervention. For complex distributed software storage architectures, which may involve multiple files, multiple nodes, or multiple fixing operations, the script can execute according to a preset logical order, avoiding delays and errors caused by manual operation and significantly shortening the fixing time. This is especially suitable for batch production or frequently updated scenarios, improving production efficiency. Furthermore, the automated script allows fixing tasks to be started during non-working hours (such as at night) without the need for personnel to be on duty, making full use of time resources and achieving unattended operation.

[0038] In some embodiments, the process of compiling and fixing the TCL script includes: Multiple target bin files are determined based on the high-reliability distributed software storage architecture based on FMQL45T900 as described in any of the first aspects; A TCL script is compiled and solidified for the target bin file.

[0039] It should be noted that by "determining multiple target bin files based on the high-reliability distributed software storage architecture based on FMQL45T900 as described in any of the first aspects", it is ensured that the hardened script is built around the preset high-reliability distributed software storage architecture. That is, the hardened script is not a collection of scattered and isolated commands, but an automated execution scheme tailored to achieve a specific hardware architecture (FMQL45T900) and a specific software storage strategy (layering, partitioning, redundant backup), so as to accurately write each bin file (such as the secondary boot program image, PL program, PS program partition images) into the FLASH address specified by the architecture.

[0040] It should be noted that for the complex distributed storage architecture described in the first aspect, which includes multiple image areas (secondary bootloader, PL program, PS program, backup area, and image information area), manual hardening requires repeated configuration and operation. Scripts, however, can integrate this complex process into a single, one-click executable task, greatly simplifying the operation and reducing the professional requirements and workload for operators. Users do not need to worry about where each file should be written or what parameters are required; they only need to run the script.

[0041] In some embodiments, the step of compiling and embedding a TCL script for the target bin file includes: Configure the target processor to identify the target processor; Initialize the emulator to connect to the target processor via the emulator; Configure the path, firmware address, FLASH type, and connection parameters of the target bin file; Initiate the curing process.

[0042] It should be noted that by writing each key operation step in the hardening process (from hardware identification to final write execution) into script instructions, the entire hardening process can be completed fully automatically without human intervention. Users only need to start the script and can leave with peace of mind, without the need for full-time monitoring, which greatly improves work efficiency and user experience. Moreover, the script fixes all error-prone manual configuration steps (such as processor model selection, emulator parameter settings, file path and address input, etc.) in precise code form, eliminating the possibility of human error and ensuring that every hardening operation is strictly executed according to the preset and verified process and parameters. Whether for a single product or mass production, it can guarantee a high degree of consistency and reliability of the results, effectively avoiding hardening failure or product failure caused by configuration errors.

[0043] It should be noted that the entire solidified logic, all parameters used, and files are clearly recorded in the solidified TCL script. When problems occur, the cause can be quickly located by consulting the script, facilitating troubleshooting and version rollback. If it is necessary to adjust the solidified parameters or process, only the corresponding part of the script needs to be modified and version management implemented, eliminating the need to retrain all operators and making process updates and maintenance more efficient and standardized. Furthermore, the TCL scripting language supports programming logic such as conditional statements and loops, allowing for the implementation of more complex solidification strategies within the script. For example, checking for file existence before solidification, performing verification after solidification, and selecting different configuration files based on different hardware versions can further enhance the robustness and intelligence of the solidification process.

[0044] In some embodiments, the plurality of target bin files correspond one-to-one with a partition of the high-reliability distributed software storage architecture based on FMQL45T900 as described in any one of the first aspects; The process of compiling and solidifying a TCL script for the target bin file further includes: Exit the firmware application.

[0045] It should be noted that the "one-to-one correspondence" ensures that each target bin file (e.g., the secondary bootloader, PL, PS subsystem programs, etc.) has its own clearly corresponding and unique storage partition. This allows the hardening script to write the correct file to the precise location specified by the architecture, ensuring that the hardened FLASH memory strictly follows the preset high-reliability distributed storage architecture. Furthermore, the "one-to-one correspondence" clearly defines in the script which file is written to which address, preventing errors such as misplaced files or overlapping addresses when hardening multiple files. This improves the accuracy and reliability of the hardening process and avoids serious problems such as system startup failure or malfunction due to file corruption. The hardening application software mentioned is PROCISE.

[0046] In some embodiments, the process of compiling a user-executed batch script includes: Navigate to the installation directory of the solidified application software; The background running program of the solidified application software is launched; Start the firmware TCL script.

[0047] It should be noted that by creating a user-executed batch script, users no longer need to worry about where the PROCISE software is installed, how to launch it from the command line, or how to pass the TCL script as a parameter. Users only need to double-click a batch file (i.e., the user-executed batch script), allowing non-professional users or users unfamiliar with the command line to easily complete complex firmware operations. This achieves one-click execution, significantly reducing the barrier to entry and the risk of human error. In particular, the batch script simplifies the series of tedious manual steps of "opening the command line - changing the directory - entering the complex startup command - pressing Enter" into an automated double-click action, saving a lot of preparation time for each firmware operation. This is especially important in the development phase where frequent firmware testing is required, thus improving work efficiency.

[0048] It should be noted that the "enter the installation directory of the embedded application software" command in the embedded batch script ensures that the PROCISE program can always be launched in its correct installation path, avoiding problems such as missing files and DLL loading failures due to different current working directories. Users do not need to understand the startup parameters of PROCISE.exe, the calling method of the embedded TCL script, or other low-level technical details. These complexities are encapsulated by the batch script, reducing the cognitive burden on users and allowing them to focus on their core tasks (such as development and testing) instead of spending energy learning and memorizing how to use the tools.

[0049] It should be noted that the solidification method provided in this application embodiment only requires delivering a batch script (i.e., the user executes the solidification batch script) and a TCL script (i.e., the solidification TCL script) to the user. After receiving it, the user can use it without any configuration, which is conducive to sharing within the team, deploying on the production line, or distributing to customers. It can ensure that everyone uses the same standard and verified solidification process.

[0050] The device / system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0051] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0052] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also mean including the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not to be construed as requiring them to be performed in a particular order described or illustrated unless the order of execution is explicitly indicated. It should also be understood that additional or alternative steps may be used. The above description is merely a specific embodiment of the invention to enable those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A high-reliability distributed software storage architecture based on FMQL45T900, characterized in that, include: The secondary bootloader image area is used to store the secondary bootloader image; Programmable logic program image area, used to store programmable logic program images; Programmable logic program image backup area, used to store programmable logic program images; The system program image area is used to store the system program image. The system program image backup area is used to store the system program image. The image information area is used to store the pre-stored file length and pre-stored CRC check value of the programmable logic program image and the processing system program image.

2. The high-reliability distributed software storage architecture based on FMQL45T900 according to claim 1, characterized in that, The storage capacity of the secondary bootloader image area is 512K, and the secondary bootloader image area stores three copies of the secondary bootloader image.

3. The high-reliability distributed software storage architecture based on FMQL45T900 according to claim 1, characterized in that, The storage capacity of the image information area is 64K. The image information area stores three copies of the programmable logic program image and the processing system program image, along with their pre-stored file lengths and pre-stored CRC check values.

4. The high-reliability distributed software storage architecture based on FMQL45T900 according to claim 1, characterized in that, The storage capacity of the programmable logic program image area is 13.4M, the storage capacity of the programmable logic program image backup area is 13.4M, the storage capacity of the processing system program image area is 2M, and the storage capacity of the processing system program image backup area is 2M.

5. The high-reliability distributed software storage architecture based on FMQL45T900 according to claim 1, characterized in that, The processing system program image includes a first processing system program image, a second processing system program image, a third processing system program image, and a fourth processing system program image. The processing system program image area includes a first system program image area, a second system program image area, a third system program image area, and a fourth system program image area; the processing system program image backup area includes a first system program image backup area, a second system program image backup area, a third system program image backup area, and a fourth system program image backup area. The first system program image area and the first system program image backup area are used to store the first processing system program image, the second system program image area and the second system program image backup area are used to store the second processing system program image, the third system program image area and the third system program image backup area are used to store the third processing system program image, and the fourth system program image area and the fourth system program image backup area are used to store the fourth processing system program image.

6. A method for solidifying a high-reliability distributed software storage architecture based on FMQL45T900, characterized in that, Applied to any one of the high-reliability distributed software storage architectures based on FMQL45T900 as described in any one of claims 1-5, comprising: Compile and solidify TCL scripts; Create a user-executed batch script; The user executes the hardening bat script to call the hardening TCL script and harden the high-reliability distributed software storage architecture based on FMQL45T900 as described in any one of claims 1-5 onto the target processor by executing the hardening TCL script.

7. The method for solidifying a high-reliability distributed software storage architecture based on FMQL45T900 according to claim 6, characterized in that, The process of compiling and fixing the TCL script includes: Multiple target bin files are determined based on the high-reliability distributed software storage architecture based on FMQL45T900 as described in any one of claims 1-5; A TCL script is compiled and solidified for the target bin file.

8. The method for solidifying a high-reliability distributed software storage architecture based on FMQL45T900 according to claim 7, characterized in that, The process of compiling and embedding a TCL script for the target bin file includes: Configure the target processor to identify the target processor; Initialize the emulator to connect to the target processor via the emulator; Configure the path, firmware address, FLASH type, and connection parameters of the target bin file; Initiate the curing process.

9. The method for solidifying a high-reliability distributed software storage architecture based on FMQL45T900 according to claim 7, characterized in that, Each of the target bin files corresponds one-to-one with a partition of the high-reliability distributed software storage architecture based on FMQL45T900 as described in any one of claims 1-5; The process of compiling and solidifying a TCL script for the target bin file further includes: Exit the firmware application.

10. The method for solidifying a high-reliability distributed software storage architecture based on FMQL45T900 according to claim 6, characterized in that, The process of creating a user-executed batch script includes: Navigate to the installation directory of the solidified application software; The background running program of the solidified application software is launched; Start the firmware TCL script.

Images