A dual-mode dynamic starting and safe upgrading cooperation method of a satellite communication module

Abstract

The application relates to the technical field of satellite communication, in particular to a dual-mode dynamic starting and safe upgrading cooperation method of a satellite communication module, which comprises the following steps: an application processor sends an upgrading instruction to a communication processor; the communication processor sets an upgrading flag bit at a fixed address of a Flash and triggers a hardware reset; after the reset, a secondary boot program detects the flag bit and informs the application processor that it is ready; parameters are negotiated by baud rate self-adaption between the two parties; the application processor transmits an upgrading image package; the communication processor performs checking and burning on the image package and updates a U-Boot environment variable partition corresponding to a starting mode; when the communication processor starts, the secondary boot program selects a starting mode according to the level state of a GPIO pin, loads corresponding starting parameters, and dynamically loads a firmware image to a specified DDR address for running. The application realizes dynamic switching of high-orbit and low-orbit modes, does not depend on hardware replacement, and is safe and reliable in OTA firmware upgrading.

Description

Technical Field

[0001] This invention relates to the field of satellite communication technology, and specifically to a method for the coordinated dual-mode dynamic startup and security upgrade of a satellite communication module. Background Technology

[0002] Satellite communication systems are classified into two types based on their orbital characteristics: high orbit (GEO) and low orbit (LEO) constellations. In scenarios such as emergency communication, aviation, and maritime communication, it is necessary to dynamically switch communication modes according to the satellite's orbital characteristics.

[0003] Traditional satellite communication modules employ a single firmware architecture, making it difficult to dynamically adapt to the switching requirements between high-Earth orbit and low-Earth orbit networks. This results in low resource utilization, limited scenario adaptability, and an inability to meet the flexible deployment requirements of multi-orbit satellite communication. Regarding OTA firmware upgrades, existing solutions lack a unified address mapping mechanism when multi-mode system firmware is stored independently. The upgrade process is prone to memory overwriting, leading to system crashes and other problems.

[0004] Therefore, it is crucial to achieve dynamic switching between high and low orbit modes and secure 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 satellite communication modules to solve the problems of existing technologies, such as reliance on hardware replacement for high-Earth orbit mode switching and high failure rate of OTA firmware upgrades.

[0006] In a first aspect, the present invention provides a method for coordinated dual-mode dynamic startup and security upgrade of a satellite communication module, the method being applied to the satellite communication module, the satellite communication module including an application processor (AP), a communication processor (CP), and GPIO pins; the method includes:

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

[0008] In response to the firmware upgrade trigger command, the communication processor CP sets an upgrade flag bit at a fixed physical address in the Flash memory and triggers a hardware reset.

[0009] After the communication processor CP is reset, it detects the upgrade flag bit through the secondary boot program and notifies the application processor AP 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 AP transmits an upgrade image package to the communication processor CP. The upgrade image package includes, in sequence, the number of files, the burning address of each file, the length of each file, the content of the continuously stored files, and the overall checksum.

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

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

[0013] In one optional implementation, the triggering of the hardware reset includes:

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

[0015] In one optional implementation, the verification and programming process includes:

[0016] The communication processor CP calculates the transmission verification value of the received upgrade image package and compares it with the overall verification value 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 the burning process according to the corresponding file burning address in the upgrade image package;

[0019] The communication processor CP reads the burned data and recalculates the burning verification value, and then compares it with the overall verification value in the upgrade image package.

[0020] If the programming verification is successful, the communication processor CP restart program will be initiated.

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

[0022] In one optional implementation, the step of identifying the boot mode based on the level state of the GPIO pin via a secondary bootloader includes:

[0023] If the GPIO pin is at a low level, then select the high-track boot mode and the corresponding U-Boot environment variable partition;

[0024] If the GPIO pin is at a high level, then the low-track boot mode and the corresponding U-Boot environment variable partition are selected.

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

[0026] In one optional implementation, the burning address and length of each firmware image are consistent with the header information of the upgrade image package.

[0027] In one optional implementation, the U-Boot environment variable partition corresponding to the high-orbit boot mode is physically isolated from the U-Boot environment variable partition corresponding to the low-orbit boot mode.

[0028] In one alternative implementation, the upgrade image package is 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, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module as described in the first aspect or any corresponding embodiment.

[0030] Thirdly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module as described in the first aspect or any corresponding embodiment.

[0031] Fourthly, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module as described in the first aspect or any of its corresponding embodiments.

[0032] The technical solution provided by this invention may include the following beneficial effects:

[0033] 1. This invention identifies the startup mode by the level state of the hardware GPIO pins, and can dynamically switch between high-orbit and low-orbit modes without physical hardware replacement, which 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 scenario adaptability.

[0034] 2. The upgraded image package of this invention unifies the image package structure design, accurately records the burning address and length of each file, ensures reasonable allocation of storage space when multiple firmware modes coexist, effectively avoids firmware overwrite risk, and ensures system stability and reliability.

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

[0036] 4. This invention utilizes a two-level bootloader to manage upgrade flags, combined with adaptive baud rate adjustment and protocol transmission, to enhance compatibility and fault tolerance, simplify the OTA firmware upgrade process, and reduce the risk of failure.

[0037] 5. This invention achieves 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. Attached Figure Description

[0038] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

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

[0040] Figure 2 This is a 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 This is a flowchart 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;

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

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

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

[0045] Figure 7 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0047] This embodiment provides a satellite communication module. Figure 1 This is a schematic diagram of the structure of a satellite communication module according to an embodiment of the present invention, such as... 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 / USB, and its processing power directly affects the upgrade efficiency. In 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 file count, burning address, and length) and transmitting it to the communication processor (CP) via the XMODE protocol; performing adaptive baud rate negotiation with the communication processor (CP) to ensure satellite link transmission stability; and retransmitting the upgrade image package or triggering a system rollback upon receiving a verification failure notification from the communication processor (CP).

[0049] The communication processor (CP) loads the GEO or LEO satellite communication protocol stack and handles the physical layer and link layer communication of the satellite link. In the upgrade control process, the CP is mainly used for: receiving the firmware upgrade trigger command from the application processor (AP), setting the upgrade flag at a fixed address in Flash, and triggering a reset through a hardware watchdog; after reset, entering the secondary boot program (U-Boot), detecting the upgrade flag and notifying the application processor (AP) to enter the transmission ready state; performing transmission verification and burning verification of the upgrade image package to ensure data integrity; and reading the GPIO level status at startup, loading the corresponding U-Boot environment variable partition, and loading the firmware image to the specified DDR address for execution.

[0050] This GPIO pin serves as a hardware mode trigger and status input interface. It is typically connected to external pull-up / pull-down resistors, and its level is configured via jumpers or DIP switches, supporting rapid mode switching in the field without requiring firmware reprogramming. When the satellite communication module powers on, the communication processor (CP) reads the GPIO pin's level. A low level corresponds to high-orbit startup mode, and a high level corresponds to low-orbit startup mode. The GPIO pin's level directly determines the startup mode, offering greater reliability than software configuration and adapting to the demanding environment of satellite communication.

[0051] Furthermore, the system also includes Flash memory and a watchdog timer. 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 serves as the storage unit for the communication processor (CP), ensuring fast data read / write and long-term data retention. It can store data such as upgrade images, system configuration parameters, and logs. The watchdog timer is a hardware circuit used to monitor the system's operating status. In the satellite communication module, the watchdog timer is integrated into the hardware control module and connected to the communication processor (CP). When a system anomaly occurs, such as a software deadlock or communication failure, the watchdog timer detects it and triggers a reset signal, causing the system to restart and ensuring system reliability and stability.

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

[0053] This embodiment provides a method for the coordinated dual-mode dynamic startup and security upgrade of a satellite communication module, which can be used for... Figure 1 In the satellite communication module shown, Figure 2 This is a 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, such as... Figure 2 As shown, the process includes the following steps:

[0054] In step S201, the application processor AP sends a firmware upgrade trigger command to the communication processor CP.

[0055] Furthermore, the application processor (AP) sends a firmware upgrade trigger command to the communication processor (CP), serving as the starting point for the entire upgrade process. The application processor (AP), as the system's control center, is responsible for initiating the upgrade operation. When a firmware upgrade of the satellite communication module is required, 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 perform the upgrade, ensuring that the communication processor (CP) can enter the upgrade preparation state.

[0056] In step S202, the communication processor CP responds to the firmware upgrade trigger instruction by setting an upgrade flag bit at a fixed physical address in the Flash memory and triggering a hardware reset.

[0057] Furthermore, after receiving the firmware upgrade trigger command from the application processor (AP), the communication processor (CP) sets an upgrade flag at a pre-defined fixed physical address in the Flash memory. This flag indicates that the communication processor (CP) is currently in an upgrade state. Subsequently, the communication processor (CP) triggers a hardware reset operation through a hardware watchdog circuit, restarting itself and preparing for the subsequent upgrade process. This step ensures that the communication processor (CP) can enter a known initial state, providing a guarantee for subsequent upgrade operations.

[0058] In step S203, after the communication processor CP is reset, it detects the upgrade flag bit through the secondary boot program and notifies the application processor AP to enter the transmission ready state.

[0059] Furthermore, after the communication processor (CP) is reset, it starts the secondary bootloader (u-boot), which checks the upgrade flag in the Flash memory during initialization. Once the flag is detected, the communication processor (CP) sends a notification to the application processor (AP) through the 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 communication 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 the AP transmits an upgrade image package to the communication processor CP. The upgrade image package includes, in sequence, the number of files, the burning address of each file, the length of each file, the content of the continuously stored files, and the overall checksum.

[0061] Furthermore, before transmitting the upgrade image package, the application processor (AP) and the communication processor (CP) need to 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. After negotiation, the application processor (AP) can send the upgrade image package to the communication processor (CP) according to the agreed communication parameters. The upgrade image package is organized in a specific format, containing information such as the number of files, the burning address of each file, its length, the contiguously stored file content, 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 transmitted accurately from the application processor (AP) to the communication processor (CP).

[0062] In step S205, 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 boot mode.

[0063] Furthermore, after receiving the upgrade image package from the application processor (AP), the communication processor (CP) first verifies the integrity of the data based on the overall checksum in the upgrade image package. If the verification passes, the firmware image is burned one by one to the corresponding location in the Flash memory according to the burning address and length information of each file in the image package. After burning is complete, the communication processor (CP) also updates the U-Boot environment variable partition corresponding to the current boot mode to include 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 on the next boot. This step ensures the integrity and correctness of the upgrade image package.

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

[0065] Furthermore, when the communication processor CP boots, its secondary bootloader (u-boot) first reads the voltage levels of the GPIO pins. Based on the pre-defined correspondence between voltage levels and boot modes (e.g., low voltage indicates high-Earth orbit boot mode, high voltage indicates low-Earth orbit boot mode), it determines the appropriate boot mode. Then, the secondary bootloader loads the boot parameters from the U-Boot environment variable partition corresponding to that boot mode. Following the firmware image burning address and DDR address specified in the boot parameters, it loads the corresponding firmware image from the Flash memory to the designated location in the DDR memory and jumps to that address to begin running the firmware. This enables dynamic switching between high-Earth orbit and low-Earth orbit modes for the satellite communication module. This step ensures that the system can boot correctly according to the hardware configuration and run the corresponding firmware.

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

[0067] 1. This embodiment identifies the startup mode by the level state of the hardware GPIO pins, and can dynamically switch between high-orbit and low-orbit modes without physical hardware replacement. 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 scenario adaptability.

[0068] 2. The upgrade image package in this embodiment has a unified image package structure design, accurately records the burning address and length of each file, ensures reasonable allocation of storage space when multiple firmware modes coexist, effectively avoids firmware overwrite risk, and ensures system stability and reliability.

[0069] 3. This embodiment adopts a dual-mode unified upgrade framework, uses a two-level bootloader to manage upgrade flags, and combines baud rate adaptive adjustment and protocol transmission to enhance compatibility and fault tolerance, simplify the upgrade process, and reduce the risk of failure.

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

[0071] This embodiment provides another method for the coordinated dual-mode dynamic startup and security upgrade of satellite communication modules, which can be used for... Figure 1 In the satellite communication module shown, Figure 3 This is a flowchart 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, such as... Figure 3 As shown, the process includes the following steps:

[0072] In step S301, the application processor AP sends a firmware upgrade trigger command to the communication processor CP.

[0073] In step S302, the communication processor CP responds to the firmware upgrade trigger instruction by setting an upgrade flag bit at a fixed physical address in the Flash memory and generating a reset signal through a watchdog timer to trigger a hardware reset operation; the upgrade image package uses a fixed-format binary file, such as the upgrade image package using a fixed-format binary file.

[0074] For further details, please see Figure 4The diagram shows the structure of the upgrade image package, which is packaged into a BIN file. This file contains the number of files, the flash address for each file, its length, content, and the overall MD5 checksum. The BIN file begins with a 4-byte field recording the number of files included, helping the parser understand the range and quantity of subsequent file information. For file 1, the first 4-byte field records the starting address for writing file 1 in the flash memory, specifying its storage location. The next 4-byte field records the size of file 1, i.e., the number of bytes of data in file 1. For file 2, the first 4-byte field records the starting address for writing file 2 in the flash memory, followed by a 4-byte field recording its size. After the address and length information of all files, the actual content of the files is presented. The file content is arranged sequentially, starting with the content of file 1, then file 2, and so on. Following all the file content is a 16-byte MD5 checksum. This checksum is used to verify the integrity and correctness of all preceding data. This BIN file format ensures the integrity and correctness of the upgrade image, facilitating verification during transmission and flashing to prevent data corruption or loss. By specifying the flashing 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] In step S303, after the communication processor CP is reset, it detects the upgrade flag bit through the secondary boot program and notifies the application processor AP to enter the 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 the AP transmits an upgrade image package to the communication processor CP. The upgrade image package includes, in sequence, the number of files, the burning address of each file, the length of each file, the content of the continuously stored files, and the overall checksum.

[0077] In 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 boot mode.

[0078] For further details, please see Figure 5The diagram illustrates the OTA firmware upgrade process. The user sends a firmware upgrade trigger command (e.g., AT+UPDATE command) to the communication processor CP via the application processor (AP). The communication processor CP sets an upgrade flag in the Flash memory. A hardware watchdog reset signal causes the communication processor CP to reboot into the secondary bootloader (u-boot). Upon detecting the upgrade flag, the application processor CP enters the upgrade process and reports to the application processor AP that it is ready. The application processor AP resets the baud rate and notifies the communication processor CP to transmit the image according to the XMODE protocol. After transmission, an MD5 checksum is performed. If the values ​​match, the image is burned; otherwise, the transmission fails and the upgrade process restarts. The burning address and length are derived from the image content to avoid firmware overwriting.

[0079] like Figure 5 As shown, specifically:

[0080] When a user wants to upgrade the communication processor (CP), the application processor (AP) first sends a firmware upgrade trigger command (such as the AT+UPDATE command) to the CP. At this time, the CP may be in high-track boot mode (S) or low-track boot mode (L). This firmware upgrade trigger command serves as the trigger signal for the entire upgrade process, informing the CP that a firmware upgrade operation is imminent and allowing the CP to prepare accordingly. After receiving the AT upgrade command from the application processor (AP), the CP, regardless of whether it is in high-track boot mode (S) or low-track boot mode (L), will set the upgrade flag in the Flash memory (i.e.,...). Figure 5 This step involves specifying the same address location as the nand in the code. This step is to explicitly put the communication processor (CP) into upgrade mode and prepare for subsequent reset and upgrade procedures.

[0081] After the upgrade flag is set, the hardware watchdog generates a reset signal. A hardware watchdog is a circuit used to monitor the system's operating status; when it detects a system abnormality or receives a reset signal, it forces the system to reset. In this embodiment, the hardware watchdog reset ensures that the communication processor CP can restart from a known good state. Upon receiving the reset signal, the communication processor CP restarts and boots into the secondary bootloader (u-boot). The secondary bootloader (u-boot) is the program in the embedded system responsible for initializing the hardware and loading the operating system kernel. During the upgrade process, the secondary bootloader (u-boot) is responsible for detecting the upgrade flag and performing subsequent upgrade operations.

[0082] After the level 2 bootloader (u-boot) detects that the upgrade flag is set, it enters the upgrade process and reports to the communication processor (CP) that it is ready. This step ensures synchronization between the application processor (AP) and the communication processor (CP), letting the application processor (AP) know that the communication processor (CP) is ready to receive subsequent upgrade data. The application processor (AP) and the communication processor (CP) then reset the baud rate. The baud rate is an important parameter in serial communication, representing the number of bits transmitted per second. Through adaptive baud rate negotiation, the application processor (AP) and the communication processor (CP) can ensure that both transmit data at the same communication rate, thereby improving the accuracy and reliability of data transmission.

[0083] The application processor (AP) transmits the upgrade image packet to the communication processor (CP) according to the XMODE protocol. XMODE is a reliable data transmission protocol that ensures data integrity and accuracy during transmission. After transmission, an MD5 checksum is performed on the entire transmitted image and compared with the MD5 checksum of the last transmitted image. If the checksums match, the transmission was successful; otherwise, the transmission failed, and the upgrade process needs to be restarted.

[0084] After the upgrade image package is successfully transmitted, the communication processor (CP) performs the flashing operation based on the flashing address and length information in the upgrade image package. The flashing address and length are derived from the content of the sent upgrade image package. This ensures that flashing is performed according to the actual size of the upgrade image package, avoiding the problem of subsequent firmware being overwritten due to an excessively large BIN file. After flashing is complete, the communication processor (CP) sends a flashing completion notification to the application processor (AP). If flashing fails, the communication processor (CP) notifies the application processor (AP) of the transmission failure and re-enters the upgrade process, re-transmitting the image and flashing the image until the upgrade is successful.

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

[0086] In one optional implementation, the "perform verification and programming" step S305 includes:

[0087] The communication processor CP calculates the transmission check value of the received upgrade image package and compares it with the overall check value within the upgrade image package;

[0088] If the transmission verification fails, the communication processor (CP) notifies the application processor (AP) to retransmit the upgrade image package.

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

[0090] The communication processor CP reads the burned data and recalculates the burning verification value, then compares it a second time with the overall verification value in the upgrade image package.

[0091] If the programming verification is successful, the communication processor CP restart program will be initiated.

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

[0093] Furthermore, firstly, the communication processor (CP) calculates the transmission checksum of the received upgrade image package and compares it with the overall checksum contained within the image package to ensure that the data has not been corrupted during transmission. If the checksum fails, the CP notifies the application processor (AP) to retransmit the image package. If the checksum succeeds, the burning operation is performed according to the file burning address specified in the image package. After burning, the CP reads the burned data again and recalculates the burning checksum, comparing it a second time with the overall checksum within the image package to ensure that the data is correctly burned into the memory. If the burning checksum succeeds, the CP enters the restart procedure to complete the upgrade process. Conversely, if the burning checksum fails, the CP clears the currently failed burning content and notifies the AP to retransmit the upgrade image package to ensure the reliability of the upgrade process and the integrity of the data. This process, through a two-step checksum mechanism, effectively prevents upgrade failures caused by data transmission or burning errors, ensuring the security and stability of satellite communication module firmware upgrades.

[0094] In step S306, when the communication processor CP starts up, if the level of the GPIO pin is low, the high-track startup mode and the corresponding U-Boot environment variable partition are selected; if the level of the GPIO pin is high, the low-track startup mode and the corresponding U-Boot environment variable partition are selected.

[0095] In one optional implementation, the U-Boot environment variable partition corresponding to the high-track boot mode is physically isolated from the U-Boot environment variable partition corresponding to the low-track boot mode. The U-Boot environment variable partition includes the firmware image burning address, firmware image length, and specified DDR address for each firmware image in the corresponding boot mode. The firmware image burning address and firmware image length are consistent with the header information of the upgrade image package.

[0096] Furthermore, the U-Boot environment variable partitions corresponding to the high-track and low-track boot modes are physically isolated from each other, ensuring that the boot parameters for the two modes are stored independently without interference, thus enhancing system stability and reliability. Simultaneously, when updating the U-Boot environment variable partitions, key parameters such as the burning address, firmware image length, and corresponding DDR address of each firmware image in the corresponding mode are written. These parameters are strictly consistent with the header information of the upgrade image package, ensuring the accuracy of image burning and loading. Specifically, the burning address and length of each firmware image completely match the records in the upgrade image package, guaranteeing the correct storage of the image in Flash memory and accurate loading from flash memory to main memory. This avoids firmware overwriting or loading errors caused by inconsistent parameters, effectively ensuring the reliability of system upgrades and operation.

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

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

[0099] When the communication processor CP is powered on, the initialization process begins. After the communication processor CP receives the power-on signal, its internal hardware circuitry starts working, providing the necessary power support for the subsequent startup process and triggering the initial startup program.

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

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

[0102] The communication processor (CP) reads the voltage levels of the GPIO pins to determine the boot mode (high-track boot mode or low-track boot mode). After the secondary bootloader (u-boot) starts, it reads the voltage levels of the L / S boot mode pins (GPIO pins). A low level indicates high-track boot mode (S mode), and a high level indicates low-track boot mode (L mode). Then, based on the boot mode, it loads the corresponding U-Boot environment variable partition (U-BOOT-ENV) to obtain the necessary boot parameters, including the image's Flash address, image size, and the DDR address where the image will be loaded. These parameters ensure that the firmware image can be correctly loaded into memory.

[0103] The communication 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 into the specified DDR address, thus loading the firmware image into memory and preparing it for subsequent operation. The Flash writing address and image size recorded in the U-Boot environment variable partition (U-BOOT-ENV) are consistent with those in the writing image, ensuring that the image file can be loaded into memory correctly and avoiding loading errors or system failures caused by inconsistent parameters. By ensuring the integrity and correctness of the image file, system boot failures due to image corruption or loading errors can be effectively prevented.

[0104] After loading is complete, the communication processor CP's secondary bootloader (u-boot) jumps to the loaded image address and begins 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 in this embodiment can include the following beneficial effects:

[0106] 1. This embodiment identifies the startup mode by the level state of the hardware GPIO pins, and can dynamically switch between high-orbit and low-orbit modes without physical hardware replacement. 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 scenario adaptability.

[0107] 2. The upgrade image package in this embodiment has a unified image package structure design, accurately records the burning address and length of each file, ensures reasonable allocation of storage space when multiple firmware modes coexist, effectively avoids firmware overwrite risk, and ensures system stability and reliability.

[0108] 3. This embodiment adopts an overall check value verification mechanism to double-check data integrity before transmission and burning, promptly detect and correct data errors, prevent system failures, and improve upgrade reliability.

[0109] 4. This embodiment adopts a dual-mode unified upgrade framework, uses a two-level bootloader to manage upgrade flags, and combines baud rate adaptive adjustment and protocol transmission to enhance compatibility and fault tolerance, simplify the upgrade process, and reduce the risk of failure.

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

[0111] This invention also provides a computer device; please refer to [link / reference]. Figure 7 , Figure 7 This is a schematic diagram of the structure of a computer device provided in 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 the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 7 Take a processor 10 as an example.

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

[0113] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

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

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

[0116] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0117] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0118] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

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

Claims

1. A method for coordinated dual-mode dynamic startup and security upgrade of 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 GPIO pins; the method includes: The application processor (AP) sends a firmware upgrade trigger command to the communication processor (CP); In response to the firmware upgrade trigger command, the communication processor CP sets an upgrade flag bit at a fixed physical address in the Flash memory and triggers a hardware reset. After the communication processor CP is reset, it detects the upgrade flag bit through the secondary boot program and notifies the application processor AP to enter the transmission ready state. The application processor AP and the communication processor CP synchronize communication parameters through baud rate adaptive negotiation, and AP transmits an upgrade image package to the communication processor CP. The upgrade image package includes, in sequence, the number of files, the burning address of each file, the length of each file, the content of the continuously stored files, and the overall checksum. After receiving the upgrade image package, the communication processor CP performs verification and flashing, and updates the U-Boot environment variable partition corresponding to the boot mode; When the communication processor CP starts, the secondary boot program identifies the boot mode based on the level state of the GPIO pins, and loads the boot parameters in the corresponding U-Boot environment variable partition according to the identified boot mode, so as to load the firmware image to the specified DDR address for execution; The process of identifying the boot mode based on the level state of the GPIO pins through a secondary bootloader includes: If the GPIO pin is at a low level, then select the high-track boot mode and the corresponding U-Boot environment variable partition; If the GPIO pin is at a high level, then the low-track boot mode and the corresponding U-Boot environment variable partition are selected.

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

3. The method according to claim 1, characterized in that, The execution of verification and programming includes: The communication processor CP calculates the transmission verification value of the received upgrade image package and compares it with the overall verification value 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 the burning process according to the corresponding file burning address in the upgrade image package; The communication processor CP reads the burned data and recalculates the burning verification value, and then compares it with the overall verification value in the upgrade image package. If the programming verification is successful, the communication processor CP restart program will be initiated. If the flashing verification fails, the communication processor CP clears the currently failed flashing content and notifies the application processor AP to retransmit the upgrade image package.

4. The method according to claim 1, characterized in that, The U-Boot environment variable partition includes the burning address of each firmware image in the corresponding boot mode, the length of each firmware image, and the specified DDR address corresponding to each firmware image.

5. The method according to claim 4, characterized in that, The burning address and length of each firmware image are consistent with the header information of the upgrade image package.

6. The method according to claim 1, characterized in that, The U-Boot environment variable partition corresponding to the high-orbit boot mode is physically isolated from the U-Boot environment variable partition corresponding to the low-orbit boot mode.

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

8. A computer device, characterized in that, include: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes the computer instructions to perform a dual-mode dynamic startup and security upgrade collaborative method for a satellite communication module as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the 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 7.

Images