Dual-mode dynamic starting and security upgrading collaboration method for satellite communication module

Abstract

The invention relates to the technical field of satellite communication, in particular to a satellite communication module dual-mode dynamic start-up and security upgrade collaboration method, which comprises the following steps: an application processor sends an upgrade instruction to a communication processor, and the communication processor sets an upgrade flag bit at a Flash fixed address and triggers hardware reset; after resetting, the secondary bootstrap program detects the flag bit and notifies the application processor that the flag bit is ready, the two parties adaptively negotiate parameters through a baud rate, and the application processor transmits an upgrade mirror image packet; the communication processor performs verification and programming on the mirror image package, and updates the U-Boot environment variable partition of the corresponding starting mode; and when the communication processor is started, the secondary bootstrap program selects a starting mode according to the level state of the GPIO pin, loads corresponding starting parameters, and dynamically loads the firmware mirror image to a specified DDR address for operation. According to the method, the dynamic switching of the high and low rail modes is realized, and the method does not depend on hardware replacement and safe and reliable OTA firmware upgrading.

Description

Technical Field

[0001] The present invention relates to the field of satellite communication technology, and in particular to a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module. Background Art

[0002] Satellite communication systems are divided into high orbit (GEO) and low orbit (LEO) constellations according to their orbital characteristics. In scenarios such as emergency communications, aviation and navigation, communication modes need to be dynamically switched according to the satellite orbital characteristics.

[0003] Traditional satellite communication modules utilize a single firmware architecture, making it difficult to dynamically adapt to the demands of switching between high- and low-orbit networks. This results in low resource utilization, limited scenario adaptability, and an inability to meet the flexible deployment requirements of multi-orbit satellite communications. Regarding OTA firmware upgrades, existing solutions lack a unified address mapping mechanism for independently storing multi-mode system firmware. This makes the upgrade process prone to overwriting storage areas and causing system crashes.

[0004] Therefore, it is crucial to achieve dynamic switching between high and low orbit modes and safe and reliable OTA firmware upgrades on the same satellite communication module hardware platform. Summary of the Invention

[0005] In view of this, the present invention provides a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module to solve the problems in the prior art that high-orbit and low-orbit mode switching depends on hardware replacement and the OTA firmware upgrade failure rate is high.

[0006] In a first aspect, the present invention provides a dual-mode dynamic startup and security upgrade coordination method for a satellite communication module, wherein the method is applied to the satellite communication module, wherein the satellite communication module includes an application processor AP, a communication processor CP, and a GPIO pin; the method includes:

[0007] The application processor AP sends a firmware upgrade trigger instruction to the communication processor CP;

[0008] The communication processor CP responds to the firmware upgrade trigger instruction, sets an upgrade flag at a fixed physical address of the Flash memory, and triggers a hardware reset;

[0009] After the communication processor CP is reset, the upgrade flag is detected by the secondary boot program, and the application processor AP is notified to enter the transmission ready state;

[0010] The application processor AP and the communication processor CP synchronize communication parameters through baud rate adaptive negotiation and transmit an upgrade image package to the communication processor CP; the upgrade image package includes, in order, the number of files, the burning address of each file, the length of each file, the continuously stored file content, and the overall checksum;

[0011] After receiving the upgrade image package, the communication processor CP performs verification and burning, and updates the U-Boot environment variable partition corresponding to the startup mode;

[0012] When the communication processor CP starts, the secondary boot program identifies the startup mode according to the level state of the GPIO pin, and loads the startup parameters in the corresponding U-Boot environment variable partition according to the identified startup mode to load the firmware image to the specified DDR address for execution.

[0013] In an optional implementation, triggering a hardware reset includes:

[0014] The communication processor CP generates a reset signal through a watchdog to trigger a hardware reset operation.

[0015] In an optional implementation, the performing verification and programming includes:

[0016] The communication processor CP calculates a transmission checksum of the received upgrade image package and compares it with the overall checksum in the upgrade image package;

[0017] If the transmission verification fails, the communication processor CP notifies the application processor AP to retransmit the upgrade image package;

[0018] If the transmission verification is successful, the communication processor CP performs a burning process according to the corresponding file burning address in the upgrade image package;

[0019] The communication processor CP reads the written data and recalculates the writing check value, and performs a secondary comparison with the overall check value in the upgrade image package;

[0020] If the burning and verification is successful, the communication processor CP restart program will be entered;

[0021] If the burning verification fails, the communication processor CP clears the current burning failed content and notifies the application processor AP to retransmit the upgrade image package.

[0022] In an optional implementation, identifying the startup mode according to the level state of the GPIO pin through the secondary boot program includes:

[0023] If the level state of the GPIO pin is low, the high-rail boot mode and the corresponding U-Boot environment variable partition are selected;

[0024] If the level state of the GPIO pin is high, the low rail startup mode and the corresponding U-Boot environment variable partition are selected.

[0025] In an optional implementation, the U-Boot environment variable partition includes the burning address of each firmware image in the corresponding startup mode, the length of each firmware image, and the designated DDR address corresponding to each firmware image.

[0026] In an optional implementation, the firmware image burning addresses and the firmware image lengths are consistent with file header information of the upgrade image package.

[0027] In an optional implementation, the U-Boot environment variable partition corresponding to the high-rail boot mode and the U-Boot environment variable partition corresponding to the low-rail boot mode are isolated in physical storage space.

[0028] In an optional implementation, the upgrade image package uses a binary file in a fixed format.

[0029] In a second aspect, the present invention provides a computer device comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to execute a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module according to the first aspect or any corresponding embodiment thereof.

[0030] In a third aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module according to the first aspect or any corresponding embodiment thereof.

[0031] In a fourth aspect, the present invention provides a computer program product comprising computer instructions, the computer instructions being used to enable a computer to execute a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module according to the first aspect or any corresponding embodiment thereof.

[0032] The technical solution provided by the present invention can have the following beneficial effects:

[0033] 1. The present invention identifies the startup mode by the level status of the hardware GPIO pin, and can dynamically switch between high-orbit and low-orbit modes without physically replacing the hardware, thereby enhancing the flexibility and adaptability of the satellite communication module, enabling it to quickly respond to the needs of different orbital environments and improve its scene adaptability.

[0034] 2. The upgrade image package of the present invention unifies the image package structure design, accurately records the burning address and length of each file, ensures reasonable storage space allocation when multi-mode firmware coexists, effectively avoids the risk of firmware overwriting, and ensures system stability and reliability.

[0035] 3. The present invention adopts the verification mechanism of the overall verification value to double-check the data integrity before transmission and burning, timely detect and correct data errors, prevent system failures, and improve upgrade reliability.

[0036] 4. The present invention utilizes the secondary boot program to manage the upgrade flag, combines baud rate adaptive adjustment and protocol transmission, enhances compatibility and fault tolerance, simplifies the OTA firmware upgrade process, and reduces the risk of failure.

[0037] 5. The present invention realizes dual-mode operation based on the same hardware platform, reuses computing resources through DDR address dynamic loading technology, reduces hardware redundancy, lowers costs, and improves resource utilization efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the specific embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0039] Figure 1 is a schematic structural diagram of a satellite communication module according to an embodiment of the present invention;

[0040] Figure 2 Flowchart of a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module according to an embodiment of the present invention;

[0041] Figure 3 is a flow chart of another dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module according to an embodiment of the present invention;

[0042] Figure 4 is a schematic diagram of the structure of an upgrade image package according to an embodiment of the present invention;

[0043] Figure 5 1 is a schematic diagram of an OTA firmware upgrade process according to an embodiment of the present invention;

[0044] Figure 6 is a schematic diagram of a startup process according to an embodiment of the present invention;

[0045] Figure 7 Schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0046] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present invention.

[0047] In this embodiment, a satellite communication module is provided. Figure 1 FIG. 1 is a schematic structural diagram of a satellite communication module according to an embodiment of the present invention. Figure 1 As shown, the satellite communication module includes an application processor AP, a communication processor CP and GPIO pins;

[0048] The application processor (AP) interacts with the communication processor (CP) via interfaces such as UART and USB, and its processing power directly impacts upgrade efficiency. During the upgrade control process, the AP is primarily responsible for: initiating the OTA firmware upgrade process by sending a firmware upgrade trigger command; parsing the upgrade image package (containing metadata such as the number of files, the burn address, and the length) and transmitting it to the communication processor (CP) via the XMODE protocol; performing baud rate adaptive negotiation with the communication processor (CP) to ensure satellite link transmission stability; and, upon receiving a verification failure notification from the communication processor (CP), retransmitting the upgrade image package or triggering a system rollback.

[0049] The communication processor CP is used to load the high-orbit (GEO) or low-orbit (LEO) satellite communication protocol stack and handle the physical layer and link layer communications of the satellite link. In the upgrade control process, the communication processor CP is mainly used to: after receiving the firmware upgrade trigger instruction from the application processor AP, set the upgrade flag at the fixed address of Flash and trigger a reset through the hardware watchdog; after resetting, enter the secondary boot program (U-Boot), detect the upgrade flag and notify the application processor AP to enter the transmission ready state; perform transmission verification and burning verification of the upgrade image package to ensure data integrity; read the GPIO level status at startup, load the U-Boot environment variable partition of the corresponding mode, and load the firmware image to the specified DDR address for execution.

[0050] This GPIO pin is a hardware mode trigger and status input interface. It typically connects to external pull-up / pull-down resistors and is configured via jumpers or DIP switches. This allows for quick field mode switching without re-flashing the firmware. When the satellite communication module is powered on, the communications processor (CP) reads the GPIO pin's level. A low level corresponds to high-orbit startup mode, while a high level corresponds to low-orbit startup mode. The GPIO pin's level directly determines the startup mode, making it more reliable than software configuration and suitable for the demanding environment of satellite communications.

[0051] Furthermore, the system also includes Flash memory and a watchdog. Flash memory is a non-volatile memory used to store important information such as firmware, configuration data, and upgrade images. In the satellite communication module, Flash memory is the storage unit of the communication processor CP to ensure fast data reading and writing and long-term storage. It can store data such as upgrade images, system configuration parameters, and logs. The watchdog is a hardware circuit used to monitor the operating status of the system. In the satellite communication module, the watchdog is integrated into the hardware control module and connected to the communication processor CP. When the system experiences an anomaly, such as a software deadlock or communication failure, the watchdog will detect it and trigger a reset signal to restart the system, ensuring system reliability and stability.

[0052] According to an embodiment of the present invention, an embodiment of a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0053] In this embodiment, a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module is provided, which can be used Figure 1 In the satellite communication module shown, Figure 2 FIG. 1 is a flow chart of a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0054] Step S201: The application processor AP sends a firmware upgrade trigger instruction to the communication processor CP.

[0055] Furthermore, the application processor AP sends a firmware upgrade trigger command to the communication processor CP, marking the starting point of the entire upgrade process. The application processor AP, as the system's control center, is responsible for initiating upgrade operations. When a firmware upgrade is required for the satellite communication module, the application processor AP generates and sends a specific command (i.e., a firmware upgrade trigger command, such as the AT+UPDATE command) to the communication processor CP, informing it to prepare to receive the new firmware image and upgrade, ensuring that the communication processor CP enters the upgrade preparation state.

[0056] Step S202 : The communication processor CP responds to the firmware upgrade trigger instruction, sets an upgrade flag at a fixed physical address of the Flash memory, and triggers a hardware reset.

[0057] Furthermore, upon receiving the firmware upgrade trigger from the application processor (AP), the communications processor (CP) sets an upgrade flag at a pre-set, fixed physical address in the flash memory, indicating that the communications processor (CP) is currently in the upgrade state. Subsequently, the communications processor (CP) triggers a hardware reset via the hardware watchdog circuit, restarting itself and preparing for the subsequent upgrade process. This step ensures that the communications processor (CP) enters a known initial state, safeguarding subsequent upgrade operations.

[0058] Step S203: After the communication processor CP is reset, the secondary boot program detects the upgrade flag and notifies the application processor AP to enter a transmission ready state.

[0059] After resetting, the communications processor CP launches the secondary bootloader (u-boot). During initialization, the u-boot program checks the upgrade flag in the flash memory. Once this flag is detected, the communications processor CP notifies the application processor AP through its communication interface, informing it that it is ready to receive the upgrade image package. The application processor AP can then begin data transmission. This step ensures communication synchronization between the application processor AP and the communications processor CP, preparing for subsequent image package transmission.

[0060] In step S204, the application processor AP and the communication processor CP synchronize communication parameters through baud rate adaptive negotiation, and transmit an upgrade image package to the communication processor CP; the upgrade image package includes the number of files, the burning address of each file, the length of each file, the continuously stored file content and the overall check value in sequence.

[0061] Furthermore, before beginning to transmit the upgrade image package, the application processor AP and the communication processor CP must first synchronize their communication parameters, such as baud rate, data bits, and stop bits, through baud rate adaptive negotiation to ensure the accuracy and reliability of subsequent data transmission. Once the negotiation is complete, the application processor AP can send the upgrade image package to the communication processor CP according to the agreed-upon communication parameters. The upgrade image package is organized in a specific format, sequentially containing information such as the number of files, the burn address of each file, the length, the continuously stored file contents, and the overall checksum, so that the communication processor CP can correctly receive, parse, and process this data. This step ensures that the image package can be accurately transmitted from the application processor AP to the communication processor CP.

[0062] In step S205 , the communication processor CP performs verification and burning after receiving the upgrade image package, and updates the U-Boot environment variable partition corresponding to the startup mode.

[0063] Furthermore, after the communication processor CP receives the upgrade image package sent by the application processor AP, it will first verify the integrity of the data based on the overall checksum value in the upgrade image package. If the check passes, the firmware images will be burned one by one to the corresponding locations of the Flash memory according to the burning address and length information of each file in the image package. After the burning is completed, the communication processor CP will also update the U-Boot environment variable partition corresponding to the current boot mode to contain the new firmware configuration information, such as the burning address, length and corresponding DDR address of each firmware image, so that the new firmware can be correctly loaded and run at the next startup. This step ensures the integrity and correctness of the upgrade image package.

[0064] Step S206, when the communication processor CP starts, the secondary boot program identifies the startup mode according to the level state of the GPIO pin, and loads the startup parameters in the corresponding U-Boot environment variable partition according to the identified startup mode to load the firmware image to the specified DDR address for execution.

[0065] Furthermore, when the communication processor CP starts, its secondary boot program (u-boot) will first read the level status of the GPIO pin, and determine the current boot mode to be adopted based on the correspondence between the preset level and the boot mode (such as low level indicates high-orbit boot mode, and high level indicates low-orbit boot mode). Then, the secondary boot program will load the boot parameters in the U-Boot environment variable partition corresponding to the boot mode, and load the corresponding firmware image from the Flash memory to the specified location of the DDR memory according to the firmware image burning address and DDR address specified in the boot parameters, and jump to the address to start running the firmware, thereby realizing the dynamic switching of the satellite communication module between high-orbit and low-orbit modes. This step ensures that the system can start correctly according to the hardware configuration and run the corresponding firmware.

[0066] In summary, the technical solution provided by this embodiment can have the following beneficial effects:

[0067] 1. This embodiment identifies the startup mode by the level status of the hardware GPIO pin, and can dynamically switch between high-orbit and low-orbit modes without physically replacing the hardware. This enhances the flexibility and adaptability of the satellite communication module, enabling it to quickly respond to the needs of different orbital environments and improve its adaptability to different scenarios.

[0068] 2. The upgrade image package of this embodiment unifies the image package structure design, accurately records the burning address and length of each file, ensures reasonable storage space allocation when multi-mode firmware coexists, effectively avoids the risk of firmware overwriting, and ensures system stability and reliability.

[0069] 3. This embodiment adopts a dual-mode unified upgrade framework, uses a secondary boot program to manage the upgrade flag, combines baud rate adaptive adjustment and protocol transmission, enhances compatibility and fault tolerance, simplifies the upgrade process, and reduces the risk of failure.

[0070] 4. This embodiment implements dual-mode operation based on the same hardware platform, reuses computing resources through DDR address dynamic loading technology, reduces hardware redundancy, lowers costs, and improves resource utilization efficiency.

[0071] In this embodiment, another dual-mode dynamic startup and security upgrade collaborative method of a satellite communication module is provided, which can be used Figure 1 In the satellite communication module shown, Figure 3 FIG. 1 is a flow chart of another method for coordinating dual-mode dynamic startup and security upgrade of a satellite communication module according to an embodiment of the present invention. Figure 3 As shown, the process includes the following steps:

[0072] Step S301: The application processor AP sends a firmware upgrade trigger instruction to the communication processor CP.

[0073] In step S302, the communication processor CP responds to the firmware upgrade trigger instruction, sets the upgrade flag at a fixed physical address of the Flash memory, and generates a reset signal through the watchdog to trigger a hardware reset operation; the upgrade image package uses a binary file in a fixed format, such as the upgrade image package uses a binary file in a fixed format.

[0074] For further information, see Figure 4The schematic diagram of the upgrade image package is shown. The upgrade image package is packaged into a BIN file, which contains the number of files, the flash memory address of each file, the length, the content, and the overall MD5 checksum (i.e., the overall checksum). The BIN file begins with a 4-byte field that records the number of files included subsequently, helping the parser understand the scope and quantity of subsequent file information. For file 1, the first 4-byte field is used to record the start address of file 1 in the flash memory. This address specifies the storage location of file 1 in the flash memory. Next is a 4-byte field that records the size of file 1, i.e., the number of data bytes in file 1. For file 2, the first 4-byte field records the start address of file 2 in the flash memory. Next is a 4-byte field that records the size of file 2. After the address and length information of all files, the actual content of the files is displayed. The file contents are arranged in order, starting with the content of file 1, followed by the content of file 2, and so on. After all the file contents, there is a 16-byte MD5 checksum. This checksum is used to verify the integrity and correctness of all the previous data. This BIN file format ensures the integrity and correctness of the upgrade image, facilitating verification during transmission and burning to prevent data corruption or loss. By specifying the burning address and length of each file, the risk of firmware overwriting due to image size issues can be avoided, ensuring a safe and reliable upgrade process.

[0075] Step S303: After the communication processor CP is reset, the secondary boot program detects the upgrade flag and notifies the application processor AP to enter a transmission ready state.

[0076] In step S304, the application processor AP and the communication processor CP synchronize communication parameters through baud rate adaptive negotiation, and transmit an upgrade image package to the communication processor CP; the upgrade image package includes the number of files, the burning address of each file, the length of each file, the continuously stored file content and the overall check value in sequence.

[0077] Step S305 : After receiving the upgrade image package, the communication processor CP performs verification and burning, and updates the U-Boot environment variable partition corresponding to the startup mode.

[0078] For further information, see Figure 5The OTA firmware upgrade process diagram shown is as follows: the user sends a firmware upgrade trigger command (such as the upgrade AT+UPDATE command) to the communication processor CP through the application processor AP. The communication processor CP sets the upgrade flag to the Flash memory. The hardware watchdog reset signal causes the communication processor CP to restart to the secondary boot program (u-boot). After detecting the upgrade flag, the upgrade process begins and reports to the application processor AP that it is ready. The application processor AP resets the baud rate to notify the communication processor CP. The image is transmitted according to the XMODE protocol. After the transmission is completed, an MD5 check is performed. If they are the same, the image is burned. If they are different, the transmission fails and the upgrade process is re-entered. The burning address and length are based on the image content to avoid firmware overwriting.

[0079] like Figure 5 As shown, specifically:

[0080] When the user wants to upgrade the communication processor CP, the user first sends a firmware upgrade trigger instruction (such as the upgrade AT+UPDATE instruction) to the communication processor CP through the application processor AP. At this time, the communication processor CP may be in high-orbit startup mode (S) or low-orbit startup mode (L). The firmware upgrade trigger instruction serves as a trigger signal for the entire upgrade process, informing the communication processor CP that a firmware upgrade operation is about to be performed, so that the communication processor CP can make corresponding preparations. After the communication processor CP receives the upgrade AT instruction from the application processor AP, regardless of whether it is in high-orbit startup mode (S) or low-orbit startup mode (L), it will set the upgrade flag to the Flash memory (i.e. Figure 5 This step is to allow the communication processor CP to clearly enter the upgrade state and prepare for the subsequent reset and upgrade process.

[0081] After the upgrade flag is set, the hardware watchdog generates a reset signal. The hardware watchdog is a circuit used to monitor the operating status of the system. When a system anomaly is detected or a reset signal is received, it will force the system to reset. In this embodiment, the hardware watchdog reset ensures that the communication processor CP can restart from a known good state. After receiving the reset signal, the communication processor CP restarts and boots into the secondary boot program (u-boot). The secondary boot program (u-boot) is a program in an embedded system responsible for initializing hardware and loading the operating system kernel. During the upgrade process, the secondary boot program (u-boot) is responsible for detecting the upgrade flag and performing subsequent upgrade operations.

[0082] After the secondary bootloader (u-boot) detects that the upgrade flag is set, it begins the upgrade process and reports its readiness to the communication processor (CP). This step ensures synchronization between the application processor (AP) and the communication processor (CP), ensuring that the AP is aware of the CP's readiness to receive subsequent upgrade data. The AP and CP then reset the baud rate. The baud rate is a crucial parameter in serial communication, representing the number of bits transmitted per second. Through adaptive baud rate negotiation, the AP and CP ensure that both transmit data at the same rate, improving data transmission accuracy and reliability.

[0083] The application processor (AP) transmits the upgrade image package to the communication processor (CP) using the XMODE protocol. XMODE is a reliable data transmission protocol that ensures data integrity and accuracy during transmission. After the transmission is complete, an MD5 checksum is performed on the entire transmitted image and compared with the last transmitted MD5 checksum. If the checksum results match, the transmission is successful; if they differ, the transmission fails and the upgrade process must be restarted.

[0084] After the upgrade image package is successfully transferred, the communications processor (CP) performs the flashing operation based on the flashing address and length information in the package. The flashing address and length are derived from the contents of the sent upgrade image package. This allows flashing to be performed based on the actual size of the upgrade image package, preventing the issue of subsequent firmware being overwritten due to a BIN file being too large. After flashing is complete, the communications processor (CP) sends a flashing completion notification to the application processor (AP). If flashing fails, the communications processor (CP) notifies the application processor (AP) of the transfer failure and re-enters the upgrade process, repeating the image transfer and flashing operation until the upgrade is successful.

[0085] Figure 5 By performing an MD5 checksum on the entire transmitted upgrade image package and comparing it with the last transmitted MD5 checksum, the correctness and integrity of the transmitted data can be ensured, effectively preventing system failures caused by transmission errors or storage media anomalies. During the burning process, the firmware image is burned according to the burning address and length information in the upgrade image package, ensuring that the firmware image is correctly written to the specified location in the Flash memory, avoiding the risk of firmware overwriting and improving upgrade reliability.

[0086] In an optional embodiment, the “performing verification and burning” in step S305 includes:

[0087] The communication processor CP calculates a transmission checksum of the received upgrade image packet and compares it with the overall checksum in the upgrade image packet;

[0088] If the transmission verification fails, the communication processor CP notifies the application processor AP to retransmit the upgrade image packet;

[0089] If the transmission verification is successful, the communication processor CP performs the burning process according to the corresponding file burning address in the upgrade image package;

[0090] The communication processor CP reads the programmed data and recalculates the programming check value, and performs a secondary comparison with the overall check value in the upgrade image package;

[0091] If the burning and verification is successful, the communication processor CP restart program will be entered;

[0092] If the burning verification fails, the communication processor CP clears the current burning failed content and notifies the application processor AP to retransmit the upgrade image package.

[0093] Furthermore, first, the communication processor CP calculates the transmission check value of the received upgrade mirror package and compares it with the overall check value contained in the mirror package to ensure that the data is not damaged during the transmission process. If the check fails, the communication processor CP will notify the application processor AP to retransmit the mirror package. If the check is successful, the burning operation is performed according to the file burning address specified in the mirror package. After the burning is completed, the communication processor CP will read the burned data again and display it, and recalculate the burning check value, and perform a second comparison with the overall check value in the mirror package to ensure that the data is correctly burned into the memory. If the burning check is successful, the communication processor CP will enter the restart program to complete the upgrade process. On the contrary, if the burning check fails, the communication processor CP will clear the current content that failed to be burned, and notify the application processor AP to retransmit the upgrade mirror package to ensure the reliability of the upgrade process and the integrity of the data. This process effectively prevents upgrade failures caused by data transmission or burning errors through a two-check mechanism, thereby ensuring the security and stability of satellite communication module firmware upgrades.

[0094] Step S306: When the communication processor CP starts, if the level state of the GPIO pin is low, the high-rail startup mode and the corresponding U-Boot environment variable partition are selected; if the level state of the GPIO pin is high, the low-rail startup mode and the corresponding U-Boot environment variable partition are selected.

[0095] In an optional embodiment, the U-Boot environment variable partition corresponding to the high-rail boot mode is isolated from the U-Boot environment variable partition corresponding to the low-rail boot mode in physical storage space. The U-Boot environment variable partition includes the firmware image burn address, the firmware image length, and the designated DDR address corresponding to each firmware image in the corresponding boot mode. The firmware image burn address and the firmware image length are consistent with the file header information of the upgrade image package.

[0096] Furthermore, the U-Boot environment variable partitions corresponding to the high-orbit and low-orbit boot modes are isolated from each other in physical storage space, ensuring that the boot parameters of the two modes are stored independently and do not interfere with each other, thereby enhancing the stability and reliability of the system. At the same time, when updating the U-Boot environment variable partition, key parameters such as the burning address of each firmware image in the corresponding mode, the length of the firmware image, and the corresponding DDR address will be written. These parameters are strictly consistent with the file header information of the upgrade image package to ensure the accuracy of image burning and loading. Specifically, the burning address and length of each firmware image are completely matched with the records in the upgrade image package, ensuring the correct storage of the image in the Flash memory and the accurate loading from the memory to the internal memory, thereby avoiding problems such as firmware overwriting or loading errors caused by inconsistent parameters, and effectively ensuring the reliability of system upgrades and operations.

[0097] In step S307 , the communication processor CP loads the corresponding startup parameters in the U-Boot environment variable partition according to the identified startup mode, so as to load the firmware image to the designated DDR address for execution.

[0098] For further information, see Figure 6 The startup process diagram shown is as follows: Figure 6 As shown, the process includes:

[0099] The communication processor CP is powered on and starts the initialization process. When the communication processor CP receives the power-on signal, its internal hardware circuit starts working, provides the necessary power support for the subsequent startup process, and triggers the initial startup program.

[0100] The communications processor (CP) executes the Secondary Program Loader (SPL), a primary bootloader responsible for basic hardware initialization, such as setting the clock and resetting peripherals. The SPL is stored at a fixed address in the Flash memory and automatically executes upon power-up, preparing the environment for loading the more complex u-boot bootloader.

[0101] The communications processor CP loads and executes the secondary boot program (u-boot). u-boot is a boot program that is responsible for completing more complex hardware initialization tasks. It can further configure system parameters such as the memory controller and communication interfaces, and prepare to load the operating system or firmware image.

[0102] The communication processor (CP) reads the level status of the GPIO pin to determine the boot mode (high-rail boot mode or low-rail boot mode). After the secondary boot program (u-boot) is started, it reads the level status of the L / S boot mode pin (GPIO pin). If it is low, it indicates that the high-rail boot mode (S mode) is to be started, and if it is high, it indicates that the low-rail boot mode (L mode) is to be started. Then, based on the boot mode, the corresponding U-Boot environment variable partition (U-BOOT-ENV) is loaded to obtain the required boot parameters, including the Flash address of the image, the image size, and the DDR address to which the image is to be loaded. These parameters ensure that the firmware image can be correctly loaded into memory.

[0103] The communications processor (CP) reads the corresponding image file from the Flash memory based on the Flash address and image size recorded in the U-Boot environment variable partition (U-BOOT-ENV) and loads it to the specified DDR address, thereby loading the firmware image into memory and preparing it for subsequent operation. The Flash programming address and image size recorded in the U-Boot environment variable partition (U-BOOT-ENV) are consistent with those in the programming image, ensuring that the image file is correctly loaded into memory and avoiding loading errors or system failures caused by inconsistent parameters. By ensuring the integrity and correctness of the image file, system startup failures caused by image corruption or loading errors can be effectively prevented.

[0104] After loading is complete, the communication processor CP's secondary boot program (u-boot) jumps to the loaded image address and starts running the corresponding firmware image. The system enters the specified boot mode (high rail or low rail mode) and completes the boot process.

[0105] In summary, the technical solution provided by this embodiment can have the following beneficial effects:

[0106] 1. This embodiment identifies the startup mode by the level status of the hardware GPIO pin, and can dynamically switch between high-orbit and low-orbit modes without physically replacing the hardware. This enhances the flexibility and adaptability of the satellite communication module, enabling it to quickly respond to the needs of different orbital environments and improve its adaptability to different scenarios.

[0107] 2. The upgrade image package of this embodiment unifies the image package structure design, accurately records the burning address and length of each file, ensures reasonable storage space allocation when multi-mode firmware coexists, effectively avoids the risk of firmware overwriting, and ensures system stability and reliability.

[0108] 3. This embodiment uses a verification mechanism of the overall verification value to double-check data integrity before transmission and burning, detect and correct data errors in a timely manner, prevent system failures, and improve upgrade reliability.

[0109] 4. This embodiment adopts a dual-mode unified upgrade framework, uses a secondary boot program to manage the upgrade flag, combines baud rate adaptive adjustment and protocol transmission, enhances compatibility and fault tolerance, simplifies the upgrade process, and reduces the risk of failure.

[0110] 5. This embodiment implements dual-mode operation based on the same hardware platform, reuses computing resources through DDR address dynamic loading technology, reduces hardware redundancy, lowers costs, and improves resource utilization efficiency.

[0111] The present invention also provides a computer device. Figure 7 , Figure 7 is a structural diagram of a computer device provided by an optional embodiment of the present invention, such as Figure 7 As shown, the computer device includes: one or more processors 10, memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components utilize different buses to communicate with each other and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in the memory or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Equally, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 7 A processor 10 is taken as an example.

[0112] The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.

[0113] The memory 20 stores instructions that can be executed by at least one processor 10, so as to enable at least one processor 10 to execute the method shown in the above embodiment.

[0114] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created based on the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0115] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0116] The computer device further includes a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0117] The embodiment of the present invention also provides a computer-readable storage medium. The above-mentioned method according to the embodiment of the present invention can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

[0118] A portion of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the form in which the computer program instruction exists in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc. Accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium that can be accessed by the computer.

[0119] Although the embodiments of the present invention have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the defined scope.

Claims

1. A dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module, characterized in that: The method is applied to the satellite communication module, which includes an application processor AP, a communication processor CP, and a GPIO pin; the method includes: The application processor AP sends a firmware upgrade trigger instruction to the communication processor CP; The communication processor CP responds to the firmware upgrade trigger instruction, sets an upgrade flag at a fixed physical address of the Flash memory, and triggers a hardware reset; After the communication processor CP is reset, the upgrade flag is detected by the secondary boot program, and the application processor AP is notified to enter the transmission ready state; The application processor AP and the communication processor CP synchronize communication parameters through baud rate adaptive negotiation and transmit an upgrade image package to the communication processor CP; the upgrade image package includes, in order, the number of files, the burning address of each file, the length of each file, the continuously stored file content, and the overall checksum; After receiving the upgrade image package, the communication processor CP performs verification and burning, and updates the U-Boot environment variable partition corresponding to the startup mode; When the communication processor CP starts, the secondary boot program identifies the startup mode according to the level state of the GPIO pin, and loads the startup parameters in the corresponding U-Boot environment variable partition according to the identified startup mode to load the firmware image to the specified DDR address for execution.

2. The method according to claim 1, characterized in that The triggering of hardware reset includes: The communication processor CP generates a reset signal through a watchdog to trigger a hardware reset operation.

3. The method according to claim 1, characterized in that The execution verification and burning includes: The communication processor CP calculates a transmission checksum of the received upgrade image package and compares it with the overall checksum in the upgrade image package; If the transmission verification fails, the communication processor CP notifies the application processor AP to retransmit the upgrade image package; If the transmission verification is successful, the communication processor CP performs a burning process according to the corresponding file burning address in the upgrade image package; The communication processor CP reads the written data and recalculates the writing check value, and performs a secondary comparison with the overall check value in the upgrade image package; If the burning and verification is successful, the communication processor CP restart program will be entered; If the burning verification fails, the communication processor CP clears the current burning failed content and notifies the application processor AP to retransmit the upgrade image package.

4. The method according to claim 1, wherein The identifying the startup mode according to the level state of the GPIO pin by the secondary boot program includes: If the level state of the GPIO pin is low, the high-rail boot mode and the corresponding U-Boot environment variable partition are selected; If the level state of the GPIO pin is high, the low rail startup mode and the corresponding U-Boot environment variable partition are selected.

5. The method according to claim 4, characterized in that The U-Boot environment variable partition includes each firmware image writing address under the corresponding startup mode, each firmware image length and a designated DDR address corresponding to each firmware image.

6. The method according to claim 5, characterized in that The firmware image writing addresses and the firmware image lengths are consistent with the file header information of the upgrade image package.

7. The method according to claim 4, characterized in that The U-Boot environment variable partition corresponding to the high-orbit startup mode and the U-Boot environment variable partition corresponding to the low-orbit startup mode are isolated in the physical storage space.

8. The method according to any one of claims 1 to 7, characterized in that The upgrade image package uses a binary file in a fixed format.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the dual-mode dynamic startup and security upgrade collaborative method of a satellite communication module according to any one of claims 1 to 8 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, which are used to enable a computer to execute a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module according to any one of claims 1 to 8.

Images