Multi-module firmware upgrading method, system and chip

Abstract

The invention relates to the technical field of firmware upgrading, and discloses a multi-module firmware upgrading method and system and a chip, and the method comprises the steps: receiving upgrading push information sent by a server, and downloading firmware files corresponding to a plurality of modules according to the upgrading push information; generating corresponding firmware verification data according to each firmware file, and verifying all the firmware verification data to obtain a verification result; when all the verification results are successful in verification, controlling the plurality of modules to synchronously start respective corresponding firmware files, and checking each module after firmware upgrading to obtain a checking result corresponding to each module; and when all the check results are that the self-check is passed, sending an upgrade success report to the server, and if an upgrade success response sent by the server according to the upgrade success report is received, completing firmware upgrade of the plurality of modules. According to the multi-module firmware upgrading method and device, the purpose of upgrading multiple module firmware in one upgrading session can be achieved, and the multi-module firmware upgrading efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of firmware upgrade technology, and in particular to a multi-module firmware upgrade method, system and chip. Background Technology

[0002] In related technologies, an increasing number of embedded terminal devices contain multiple modules, each running its own firmware. Product functionality is achieved through the collaborative work between these modules. Firmware upgrades are frequently used to fix vulnerabilities and add new features, thereby providing a better user experience. Related technologies define an upgrade session as follows: 1. The upgrade server sends an upgrade push to the terminal device; 2. The terminal accepts the upgrade; 3. The terminal downloads the upgrade package; 4. The terminal verifies the integrity and validity of the downloaded upgrade package; if successful, it installs the upgrade package; 5. After running the new firmware, the terminal reports the upgrade result to the upgrade server.

[0003] Currently, the industry typically upgrades the firmware of each module one by one, that is, only one module firmware is upgraded through one upgrade session. For terminals with multiple firmware, multiple independent upgrade sessions are required to upgrade multiple firmware.

[0004] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0005] The main purpose of this application is to provide a multi-module firmware upgrade method, system, and chip, which aims to solve the problem that in the prior art, when upgrading the firmware of multiple modules of a chip to another chip, it is necessary to upgrade the firmware of each module one by one, resulting in low efficiency and easy errors in multi-module firmware upgrade.

[0006] The first aspect of this application provides a multi-module firmware upgrade method, applied to a device, the multi-module firmware upgrade method comprising: Receive upgrade push information sent by the server, and download the firmware files corresponding to each of the multiple modules according to the upgrade push information; Generate corresponding firmware verification data based on each firmware file, and verify all the firmware verification data to obtain the verification result. When all the verification results are successful, control multiple modules to synchronously start their respective firmware files, and check each module after firmware upgrade to obtain the check result corresponding to each module. When all the above checks result in a self-test pass, an upgrade success report is sent to the server. If an upgrade success response is received from the server based on the upgrade success report, the firmware upgrade of multiple modules is completed.

[0007] Optionally, in one embodiment of this application, the step of receiving upgrade push information sent by the server further includes: The upgrade push information is parsed to obtain the upgrade information corresponding to each of the multiple modules; Obtain upgrade feedback from each module in response to the corresponding upgrade information; When all the upgrade feedback indicates agreement to upgrade, the firmware files corresponding to each of the multiple modules are downloaded according to the upgrade push information.

[0008] Optionally, in one embodiment of this application, the plurality of modules include a first module and a second module, the upgrade push information includes first push data of the first module and second push data of the second module, and the firmware file includes a first firmware file and a second firmware file; The step of downloading the firmware files corresponding to each of the multiple modules according to the upgrade push information specifically includes: A first instruction is obtained based on the first push data from the first module, and a second instruction is obtained based on the second push data from the second module; The first firmware file corresponding to the first module is downloaded according to the first instruction, and the second firmware file corresponding to the second module is downloaded according to the second instruction.

[0009] Optionally, in one embodiment of this application, the first push data includes a first firmware verification value corresponding to the first module provided by the server, the second push data includes a second firmware verification value corresponding to the second module provided by the server, the firmware verification data includes a first firmware verification value and a second firmware verification value, and the verification result includes verification success or verification failure. The step of generating corresponding firmware verification data based on each firmware file and verifying all the firmware verification data to obtain verification results specifically includes: A first firmware verification value is generated based on the first firmware file, and a second firmware verification value is generated based on the second firmware file; If the first firmware verification value is consistent with the first firmware verification value, and the second firmware verification value is consistent with the second firmware verification value, then the verification result is determined to be successful. If the first firmware verification value is inconsistent with the first firmware verification value, or the second firmware verification value is inconsistent with the second firmware verification value, then the verification result is determined to be a verification failure.

[0010] Optionally, in one embodiment of this application, the first push data further includes a first firmware version, the second push data further includes a second firmware version, and the check result includes a first self-test result corresponding to the first module and a second self-test result corresponding to the second module; The process of checking each module after firmware upgrade and obtaining the corresponding check results for each module specifically includes: Obtain the first version of the first module and the second version of the second module after firmware upgrade; If the first version is consistent with the first firmware version, and the second version is consistent with the second firmware version, then the first module and the second module are respectively subjected to firmware upgrade self-test to obtain the first self-test result corresponding to the first module and the second self-test result corresponding to the second module.

[0011] Optionally, in one embodiment of this application, the step of checking each module after the firmware upgrade and obtaining the check result corresponding to each module further includes: If the first self-test result or the second self-test result indicates a self-test failure, an upgrade failure report is sent to the server, and a firmware rollback instruction is generated based on the upgrade failure report. The firmware rollback instruction is used to control the upgraded module to load the corresponding original firmware.

[0012] A second aspect of this application also provides a multi-module firmware upgrade method, which is applied to a server. The multi-module firmware upgrade method includes: Generate upgrade push information for the device and send the upgrade push information to the device; After the device controls multiple modules to synchronously start firmware upgrades and pass self-tests based on the upgrade push information, it receives an upgrade success report sent by the device. An upgrade success response is generated based on the upgrade success report, and the upgrade success response is sent to the device.

[0013] Optionally, in one embodiment of this application, the upgrade push information includes upgrade information corresponding to each of multiple modules; The upgrade push information generated on the device side specifically includes: The operator responds to the firmware version confirmation operations of multiple modules in the device and identifies the firmware file corresponding to each firmware version confirmation operation. Multiple upgrade information corresponding to each module is generated based on the multiple firmware files.

[0014] A third aspect of this application also provides a multi-module firmware upgrade system, wherein the multi-module firmware upgrade system includes a device side and a server side; The device is used to implement the steps of the multi-module firmware upgrade method as described in any of the above schemes; The server is used to implement the steps of the multi-module firmware upgrade method as described in any of the above schemes.

[0015] A fourth aspect of this application also provides a chip, wherein the chip includes: a memory, a processor, and a multi-module firmware upgrade program stored in the memory and executable on the processor. When the multi-module firmware upgrade program is executed by the processor, it implements the steps of the multi-module firmware upgrade method as described in any of the above solutions, or implements the steps of the multi-module firmware upgrade method as described in any of the above solutions.

[0016] Beneficial effects: This application provides a multi-module firmware upgrade method, system, and chip. By first downloading the new firmware of all modules to be upgraded to the corresponding modules, and then starting the new firmware almost simultaneously, this application avoids the scenario where the new firmware of some modules needs to work with the old firmware of other modules, eliminates the coupling between cross-modules and cross-versions, reduces the difficulty of communication protocols and communication methods between upgrade modules, and achieves the goal of upgrading the firmware of multiple modules simultaneously in one upgrade session, thereby improving the efficiency of multi-module firmware upgrade. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of a preferred embodiment of the multi-module firmware upgrade method of the first embodiment of this application; Figure 2 This is a flowchart of a preferred embodiment of the multi-module firmware upgrade method of the second embodiment of this application; Figure 3 This is a flowchart illustrating the specific implementation steps of the entire execution process in a preferred embodiment of the multi-module firmware upgrade method of this application. Figure 4 This is a structural diagram of a preferred embodiment of the chip in this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and effects of this application clearer and more explicit, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are only possible technical implementations of this application and not all possible implementations. Based on the embodiments in this application, those skilled in the art can obtain other embodiments without creative effort, and these embodiments are also within the protection scope of this application.

[0020] In related technologies, the firmware of each module needs to work together and there are dependencies between them. The current industry method of upgrading the firmware of each module one by one has the following drawbacks: 1. It is inefficient and prone to errors because each module needs to be upgraded one by one in the designed order; 2. The new firmware of the module being upgraded first needs to be compatible with the firmware currently running on other modules that have not been upgraded. In particular, it is necessary to consider the different compatibility handling required for different versions of the modules that have not been upgraded, which increases the complexity of the new firmware of the module being upgraded first; 3. If the upgrade of a module fails, it is impossible to return to the state before the upgrade, and it may even cause the device to malfunction; 4. It is difficult to update the communication protocol or communication method between modules.

[0021] To address the issue that upgrading the firmware of multiple modules of a chip requires upgrading each module's firmware one by one, resulting in low efficiency and a high risk of errors, this application addresses this problem by first downloading the new firmware of all modules to be upgraded to their corresponding modules, and then starting the new firmware almost simultaneously. This avoids the scenario where the new firmware of some modules needs to work with the old firmware of other modules, eliminates the coupling between modules and versions, reduces the difficulty of communication protocols and methods between upgrade modules, and achieves the goal of upgrading the firmware of multiple modules simultaneously in one upgrade session, thereby improving the efficiency of multi-module firmware upgrades.

[0022] The following is a description of the terms used in the embodiments of this application: Server-side: Provides upgrade services, deploys upgrade tasks on the server, and pushes upgrade tasks to terminals, typically upgrading servers, mobile apps, etc.

[0023] Device side: The object being upgraded, which includes one or more modules. The modules can communicate directly or indirectly with each other; one of the modules is responsible for managing the upgrade process and is called the upgrade management module.

[0024] This application avoids scenarios where the new firmware of some modules needs to work with the old firmware of other modules by first downloading the new firmware of all modules to be upgraded to the corresponding modules, and then starting the new firmware almost simultaneously. This also avoids the scenario where the new firmware of the module being upgraded first needs to be compatible with the old firmware of the module being upgraded later. It eliminates the coupling between cross-modules and cross-versions; the new firmware only needs to consider working with the new firmware of other modules. This application greatly reduces the difficulty of communication protocols and methods between upgrade modules. In this application, if a module upgrade fails, or if communication between modules or between the device and the server fails after the upgrade, a mechanism is provided to revert to the firmware before the upgrade. This application does not need to consider the order of module upgrades.

[0025] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0026] First embodiment: Specifically, Figure 1 This is a flowchart illustrating a multi-module firmware upgrade method provided in an embodiment of this application.

[0027] like Figure 1 As shown, the multi-module firmware upgrade method is applied to the device side, and the multi-module firmware upgrade method includes the following steps: In step S101, the upgrade push information sent by the server is received, and the firmware files corresponding to each of the multiple modules are downloaded according to the upgrade push information.

[0028] In one possible implementation, after receiving upgrade push information sent by the server, the method further includes: parsing the upgrade push information to obtain upgrade information corresponding to each of the multiple modules; obtaining upgrade feedback from each module in response to the corresponding upgrade information; and when all the upgrade feedback is in agreement to upgrade, downloading the firmware files corresponding to each of the multiple modules according to the upgrade push information.

[0029] Specifically, this step is implemented as follows: The upgrade management module receives and parses upgrade push messages. It receives a complete upgrade push message from the server; this message is a data packet containing individual upgrade information for all modules to be upgraded (e.g., module A, module B). The upgrade management module needs to parse this data packet (e.g., parse a JSON array) to extract each upgrade push message specific to a particular module. Each message contains key fields such as module number, new firmware version, minimum firmware version, and checksum.

[0030] The upgrade management module iterates through and distributes the information to the corresponding modules. Based on the module number in each parsed message, it forwards the corresponding upgrade information to that module, sending upgrade information for module A to module A and upgrade information for module B to module B. This is an addressing and distribution process; the upgrade management module knows the addresses or communication methods of each module within the device to ensure accurate command delivery.

[0031] After collecting consent responses from each module and sending the upgrade information, the upgrade management module waits for feedback from each module. Each module, upon receiving the upgrade information for itself, assesses its own capabilities to determine whether to approve the upgrade. This assessment is typically based on the following conditions: Version check: The module checks if its current firmware version is not lower than the minimum firmware version required in the upgrade push. If the current version is too old (below the minimum), the upgrade may not be successfully applied (e.g., missing necessary upgrade packages), and therefore it will reject the upgrade; Resource check: The module checks if it has sufficient resources (such as storage space and memory) to download and install the new firmware; Status check: The module may determine if it is currently in a safe upgrade state (e.g., not performing a critical task). Feedback: Each module replies to the upgrade management module with its assessment result ("agree" or "reject").

[0032] Finally, the results are summarized and a decision is made. The upgrade management module collects feedback from all modules to be upgraded. Unanimous approval: If all modules reply in agreement to the upgrade, it means the preconditions for the upgrade have been met. The upgrade management module declares internal readiness and the process proceeds to the download stage. Any rejection: If any module replies in refusal to upgrade, the upgrade management module will immediately terminate the entire upgrade process. This is to prevent a fragmented state where some modules upgrade successfully while others fail, leading to device malfunctions and incompatible communication between modules.

[0033] In one possible implementation, the multiple modules include a first module and a second module, the upgrade push information includes first push data of the first module and second push data of the second module, and the firmware file includes a first firmware file and a second firmware file. Step S101 specifically includes: obtaining a first instruction based on the first push data of the first module, and obtaining a second instruction based on the second push data of the second module; downloading the first firmware file corresponding to the first module according to the first instruction, and downloading the second firmware file corresponding to the second module according to the second instruction.

[0034] Specifically, step S101 is implemented as follows: Obtain download instructions and information. After confirming that all modules agree to the upgrade, the upgrade management module will send a separate "Start Download" instruction to each module to be upgraded (e.g., module A, module B). This instruction will include or include complete upgrade push information sent by the server to that module (especially the firmware download method field). After receiving the instruction, module A will know where to download from and what to download.

[0035] Perform the download. Based on the received firmware download method field, the module downloads the firmware file from the specified server (which could be the server itself or another file server). This is a standard file transfer process. The module needs to handle details such as network connectivity, packet reception, and flow control.

[0036] In step S102, corresponding firmware verification data is generated according to each firmware file, and all firmware verification data are verified to obtain verification results.

[0037] In one possible implementation, the first push data includes a first firmware verification value corresponding to the first module provided by the server, the second push data includes a second firmware verification value corresponding to the second module provided by the server, the firmware verification data includes a first firmware verification value and a second firmware verification value, and the verification result includes verification success or verification failure. Step S102 specifically includes: generating a first firmware verification value based on the first firmware file, and generating a second firmware verification value based on the second firmware file; if the first firmware verification value is consistent with the first firmware verification value, and the second firmware verification value is consistent with the second firmware verification value, then the verification result is determined to be verification success; if the first firmware verification value is inconsistent with the first firmware verification value, or the second firmware verification value is inconsistent with the second firmware verification value, then the verification result is determined to be verification failure.

[0038] Specifically, step S102 is implemented as follows: Download Completeness and Integrity Verification. After downloading the firmware file, the module immediately calculates its checksum. The calculation method must be completely consistent with the algorithm used by the server to generate the firmware checksum. Then, the module compares its calculated checksum byte-by-byte with the checksum provided by the server. Consistency: This proves that the file was not damaged or tampered with during the download process and is complete and correct; Inconsistency: This proves that the file encountered an error (network problem) or was maliciously tampered with during transmission and is unusable.

[0039] Result Judgment and Reporting. The module makes a judgment based on the verification result and reports it to the upgrade management module (and the server). Verification Successful (Consistent): The module reports successful download to the upgrade management module and may simultaneously report the status to the server. Upon receiving this, the upgrade management module marks the module's download as complete and allows the process to proceed to the next module's download or the next step. Verification Failed (Inconsistent): The module immediately reports download failure to the upgrade management module. Note that upgrade failures due to new firmware download failures or new firmware integrity verification failures will not trigger a rollback mechanism, because no module has been booted to the new firmware at this time.

[0040] In step S103, when all the verification results are successful, the multiple modules are controlled to synchronously start their respective firmware files, and each module after firmware upgrade is checked to obtain the check result corresponding to each module.

[0041] In one possible implementation, the first push data further includes a first firmware version, and the second push data further includes a second firmware version. The check result includes a first self-check result corresponding to the first module and a second self-check result corresponding to the second module. Step S103 specifically includes: obtaining the first version of the first module and the second version of the second module after firmware upgrade; if the first version is consistent with the first firmware version and the second version is consistent with the second firmware version, then performing firmware upgrade self-checks on the first module and the second module respectively to obtain the first self-check result corresponding to the first module and the second self-check result corresponding to the second module.

[0042] Specifically, step S103 is implemented as follows: Execute the startup command. After confirming that the firmware packages for all modules have been downloaded and successfully verified, the upgrade management module simultaneously sends a "Start New Firmware" command to all modules to be upgraded (Module A, Module B). This command is issued simultaneously to ensure that all modules begin restarting and switching at the same time, thereby reducing the time window for device malfunctions due to module version incompatibility.

[0043] New firmware operation and self-test. Each module (Module A, Module B) will perform the following operations upon receiving the startup command: Reboot and load new firmware: The module will reboot and load the newly downloaded firmware image from a backup storage area (such as another partition of Flash) to run. Version verification: After the new firmware boots up, it will first check whether the version number it reports matches the new firmware version in the upgrade push. Run self-test program: The new firmware will execute a set of preset self-test programs to check: its own peripherals: whether sensors, actuators, memory, etc. are working properly; inter-module communication: whether the communication link with other modules (especially the upgrade management module) is unobstructed and whether the data exchange is correct.

[0044] Enable confirmation timer: After the module starts, a timer will begin. If a "confirm new firmware" command is not received from the upgrade management module before this timer expires, it will automatically revert to the old firmware. This is to prevent the device from "getting stuck" in an unknown state due to communication failure after a successful upgrade. This step is the self-verification phase.

[0045] In step S104, when all the inspection results are self-test passed, an upgrade success report is sent to the server. If an upgrade success response is received from the server based on the upgrade success report, the firmware upgrade of multiple modules is completed.

[0046] Specifically, step S104 is implemented as follows: Result Reporting and Confirmation. Module Reporting: If both Module A and Module B successfully verify their versions and pass self-tests, they will report a "successful upgrade" status to the upgrade management module (and the server). Management Module Summary: The upgrade management module waits for reports from all modules. If all modules report success within the specified time, it will report the upgrade task as successful to the server. Server Response: After receiving the success report, the server will send back an "upgrade successful response." Send Confirmation Command: After receiving the server's response, the upgrade management module will send a "confirm new firmware" command to all modules. End Session: After receiving the "confirmation" command, each module will delete the old firmware backup (if designed this way), officially "solidify" the new firmware, and end the upgrade session, restoring the device to normal operation. It should be noted that the new firmware confirmation is not issued by the server, but by the upgrade management module. After receiving the "successful upgrade response," the upgrade management module indicates that all modules on the device have upgraded to the new firmware, and bidirectional communication between the device and the server is normal. The upgrade management module then sends a confirmation command for the new firmware to each module.

[0047] In one possible implementation, after determining the corresponding check results for each module, the method further includes: if the first self-check result or the second self-check result is a self-check failure, then sending an upgrade failure report to the server, generating a firmware rollback instruction based on the upgrade failure report, and controlling the upgraded module to load the corresponding original firmware based on the firmware rollback instruction.

[0048] Specifically, this step is implemented as follows: Failure handling and rollback constitute a fault-tolerance and recovery path; any failure in any step will trigger this process. Triggering conditions (any of the following conditions must occur): Version verification of some modules failed (the version was found to be incorrect after booting the new firmware); self-test of some modules failed (hardware failure, communication failure, etc.); the upgrade management module did not receive a report from a certain module within the specified time (the module may have been bricked or communication may have been completely interrupted); the upgrade management module did not receive a "successful upgrade response" from the server (there may have been a network interruption and the server did not receive the final confirmation); a certain module did not receive a "confirm new firmware" instruction before the timer expired.

[0049] Reporting Failure: Once the upgrade management module detects any of the above failure conditions, it will immediately report "upgrade failed" to the server; Executing Rollback: The upgrade management module sends a "rollback to old firmware" command to all modules that have successfully upgraded; Module Rollback: After receiving the command, these modules will restart and reload the backed-up old firmware, restoring them to their state before the upgrade; Ending Session: After the device rollback, the upgrade session ends, and the device attempts to continue running with the old firmware, waiting for the next upgrade opportunity. This is the safety net of the entire solution. Its core design philosophy is: it is better to return to a safe old state than to remain in an uncertain intermediate state. This minimizes the risk of the device becoming unusable due to upgrade failure and ensures minimum availability of the device.

[0050] Second embodiment: Specifically, Figure 2 This is a flowchart illustrating a multi-module firmware upgrade method provided in an embodiment of this application.

[0051] like Figure 2 As shown, this multi-module firmware upgrade method is applied to the server side, and the multi-module firmware upgrade method includes: Step S201: Generate upgrade push information for the device and send the upgrade push information to the device.

[0052] In one possible implementation, the upgrade push information includes upgrade information corresponding to each of multiple modules. Step S201 specifically includes: responding to the operator's confirmation operation on the firmware version corresponding to each of the multiple modules on the device, identifying the firmware file corresponding to each firmware version confirmation operation; and generating upgrade information corresponding to each of the multiple modules based on the multiple firmware files.

[0053] Specifically, step S201 is implemented as follows: The first step is for the server (such as upgrading a server or mobile app) to create an "upgrade task". This task is usually managed by the operator through a management interface.

[0054] Select target devices: On the server's management interface, the operator selects one or more devices that need to be upgraded; Select upgrade modules: The operator specifies which modules to update in this upgrade, such as module A and module B. The server confirms the module numbers of these modules.

[0055] Upload or specify firmware version: For each module to be upgraded (A and B), the operator uploads the new firmware file to the server (or a file server accessible to the server); after receiving the firmware file, the server will automatically calculate its firmware checksum and firmware length.

[0056] The operator specifies a minimum firmware version for each module. This field is crucial as it ensures that only modules with a current version no lower than this minimum can be upgraded, preventing upgrade failures due to missing intermediate versions ("skip-up" upgrades may not be supported).

[0057] Configure the upgrade strategy: Specify where the firmware will be downloaded from. This can be a direct download from the server, a more specialized file server (such as an FTP or HTTP server), or even a P2P method. This provides flexibility and can distribute the download load. Timeout: Define the timeout for the entire upgrade session and the duration of subsequent steps. Retry policy: Define whether retries are allowed after download or verification failures, and the number of retries. After completing the above configuration, an "upgrade task" containing upgrades to modules A and B is deployed on the server. This task is essentially a structured data packet containing all the necessary upgrade information.

[0058] Step 2: Build the upgrade push message. When the operator clicks "send" or "start upgrade", the server starts to execute the push logic.

[0059] Assembling the Push Notification Content: Based on the task created in the first step, the server generates an independent upgrade push notification for each module to be upgraded. Push notification for module A: {Module ID: A, New Firmware Version: v2.0, Minimum Firmware Version: v1.1, Firmware Checksum: xxx, Firmware Length: 1024KB, Firmware Download Method: http: / / server / firmware_A.bin}. Push notification for module B: {Module ID: B, New Firmware Version: v1.5, Minimum Firmware Version: v1.0, Firmware Checksum: yyy, Firmware Length: 512KB, Firmware Download Method: http: / / server / firmware_B.bin}. Packaging: The server packages these push notifications prepared for different modules into a complete "upgrade push" message.

[0060] Step 3: Send the upgrade push notification.

[0061] Establish Connection: The server establishes a communication connection with the target device. Send Data: Through this established connection, the server sends the packaged "upgrade push" message from step two to the device. Status Mark: After successful transmission, the server marks the upgrade task status of the device as "push sent" or "waiting for device response" in its database and starts timing to wait for subsequent actions from the device (such as downloading, reporting upgrade results, etc.).

[0062] Step S202: After the device controls multiple modules to synchronously start firmware upgrade and pass self-test according to the upgrade push information, it receives an upgrade success report sent by the device.

[0063] Step S203: Generate an upgrade success response based on the upgrade success report, and send the upgrade success response to the device.

[0064] See Figure 3 The specific implementation of this application is described below with reference to a specific application scenario. In this embodiment, the upgrade task includes upgrading module A and module B: S1: After the server-side deployment and upgrade, an upgrade push is sent to the device. The push message consists of upgrade push information for each module and includes the following fields: 1. Module Number: Indicates the module to be upgraded; 2. New Firmware Version: The new firmware version; 3. Minimum Firmware Version: The current firmware version of the module should not be lower than the minimum firmware version required for upgrading; 4. Firmware Checksum: Indicates the integrity checksum of the new firmware, used by the module to determine if the downloaded firmware is complete; 5. Firmware Length: Indicates the length of the new firmware; 6. Firmware Download Method: For example, downloading directly from the server, downloading from another file server, etc.

[0065] S2: The upgrade management module will distribute the upgrade push to the corresponding modules according to the module number. If all modules to be upgraded agree to the upgrade, proceed to the next step; otherwise, terminate the upgrade process.

[0066] S3~S5: The device downloads the upgrade package of module A. After the download is completed, it calculates whether the verification value of the downloaded upgrade package is consistent with the verification value of the upgrade push. 1) If they are inconsistent, it means that the download has failed and the upgrade is terminated; 2) If they are consistent, it means that the download is successful, the server is notified and the next step is taken.

[0067] S6~S10: The device downloads the upgrade package of module B. After the download is completed, it calculates whether the verification value of the downloaded upgrade package is consistent with the verification value of the upgrade push. 1) If they are inconsistent, it means that the download has failed and the upgrade is stopped; 2) If they are consistent, it means that the download is successful, the server is notified and the next step is taken.

[0068] S11: If all modules for this upgrade have been downloaded and the integrity verification is successful, proceed to the next step; otherwise, terminate the upgrade.

[0069] S12: Upgrade management module command for all modules in this upgrade, and start the new firmware.

[0070] S13: After each upgrade module boots to the new firmware, a timer is started to determine if the new firmware confirmation has timed out. The upgrade result is taken as whether the version number of the currently running firmware matches the version number in the upgrade push; then a self-test program is run to confirm whether the peripherals on the module and the communication between modules are normal, and this is taken as the self-test result. In addition, the upgrade management module starts a timer to periodically query the upgrade results from each upgrade module.

[0071] S14~S17: If all upgrade modules successfully upgrade and pass self-test within the specified time and report the upgrade success to the server, the upgrade management module will send a confirmation of the new firmware to each upgrade module after receiving the upgrade success response from the server, thereby ending the upgrade session; if no response is received from the server, each module will be notified to revert to the version before the upgrade.

[0072] S18~S20: If, within the specified time, a module fails to upgrade or fails the self-test, or if the upgrade management module does not find the upgrade and self-test results of a certain upgrade module, the upgrade management module will report the upgrade failure to the server and order all successfully upgraded modules to revert to the firmware before the upgrade.

[0073] S21: If a module has been successfully upgraded but does not receive a new firmware confirmation instruction within the specified time, it must also automatically revert to the firmware before the upgrade. For example, in scenarios where the module cannot communicate with other modules after a successful upgrade.

[0074] Based on the above embodiments, this application also provides a multi-module firmware upgrade system, wherein the multi-module firmware upgrade system includes a device side and a server side; The device is used to implement the steps of the multi-module firmware upgrade method as described in any of the above schemes; The server is used to implement the steps of the multi-module firmware upgrade method as described in any of the above schemes.

[0075] Figure 4 A structural diagram of a chip provided in an embodiment of this application. The chip may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0076] When the processor 502 executes the program, it implements the multi-module firmware upgrade method provided in the above embodiments.

[0077] Furthermore, the chip also includes: Communication interface 503 is used for communication between memory 501 and processor 502.

[0078] The memory 501 is used to store computer programs that can run on the processor 502.

[0079] Memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0080] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EIS) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0081] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0082] Processor 502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0083] This embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the multi-module firmware upgrade method described above.

[0084] One embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements the features described in this application. Figure 1 The multi-module firmware upgrade method provided in any of the corresponding embodiments.

[0085] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0086] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0087] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0088] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable storage medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable storage medium could be paper or other suitable media on which the program can be printed, since the program can be obtained electronically by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0089] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0090] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0091] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0092] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

[0093] It should be understood that the application of this application is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

[0094] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A multi-module firmware upgrade method, characterized in that, Applied to the device side, the multi-module firmware upgrade method includes: Receive upgrade push information sent by the server, and download the firmware files corresponding to each of the multiple modules according to the upgrade push information; Generate corresponding firmware verification data based on each firmware file, and verify all the firmware verification data to obtain the verification result. When all the verification results are successful, control multiple modules to synchronously start their respective firmware files, and check each module after firmware upgrade to obtain the check result corresponding to each module. When all the above checks result in a self-test pass, an upgrade success report is sent to the server. If an upgrade success response is received from the server based on the upgrade success report, the firmware upgrade of multiple modules is completed.

2. The multi-module firmware upgrade method according to claim 1, characterized in that, The process of receiving upgrade push information sent by the receiving server also includes: The upgrade push information is parsed to obtain the upgrade information corresponding to each of the multiple modules; Obtain upgrade feedback from each module in response to the corresponding upgrade information; When all the upgrade feedback indicates agreement to upgrade, the firmware files corresponding to each of the multiple modules are downloaded according to the upgrade push information.

3. The multi-module firmware upgrade method according to claim 2, characterized in that, The multiple modules include a first module and a second module, the upgrade push information includes first push data of the first module and second push data of the second module, and the firmware file includes a first firmware file and a second firmware file; The step of downloading the firmware files corresponding to each of the multiple modules according to the upgrade push information specifically includes: A first instruction is obtained based on the first push data from the first module, and a second instruction is obtained based on the second push data from the second module; The first firmware file corresponding to the first module is downloaded according to the first instruction, and the second firmware file corresponding to the second module is downloaded according to the second instruction.

4. The multi-module firmware upgrade method according to claim 3, characterized in that, The first push data includes the first firmware verification value corresponding to the first module provided by the server, the second push data includes the second firmware verification value corresponding to the second module provided by the server, the firmware verification data includes the first firmware verification value and the second firmware verification value, and the verification result includes verification success or verification failure. The step of generating corresponding firmware verification data based on each firmware file and verifying all the firmware verification data to obtain verification results specifically includes: A first firmware verification value is generated based on the first firmware file, and a second firmware verification value is generated based on the second firmware file; If the first firmware verification value is consistent with the first firmware verification value, and the second firmware verification value is consistent with the second firmware verification value, then the verification result is determined to be successful. If the first firmware verification value is inconsistent with the first firmware verification value, or the second firmware verification value is inconsistent with the second firmware verification value, then the verification result is determined to be a verification failure.

5. The multi-module firmware upgrade method according to claim 4, characterized in that, The first push data also includes a first firmware version, the second push data also includes a second firmware version, and the check result includes a first self-test result corresponding to the first module and a second self-test result corresponding to the second module; The process of checking each module after firmware upgrade and obtaining the corresponding check results for each module specifically includes: Obtain the first version of the first module and the second version of the second module after firmware upgrade; If the first version is consistent with the first firmware version, and the second version is consistent with the second firmware version, then the first module and the second module are respectively subjected to firmware upgrade self-test to obtain the first self-test result corresponding to the first module and the second self-test result corresponding to the second module.

6. The multi-module firmware upgrade method according to claim 5, characterized in that, The process of checking each module after firmware upgrade and obtaining the check results for each module further includes: If the first self-test result or the second self-test result indicates a self-test failure, an upgrade failure report is sent to the server, and a firmware rollback instruction is generated based on the upgrade failure report. The firmware rollback instruction is used to control the upgraded module to load the corresponding original firmware.

7. A multi-module firmware upgrade method, characterized in that, Applied to the server side, the multi-module firmware upgrade method includes: Generate upgrade push information for the device and send the upgrade push information to the device; After the device controls multiple modules to synchronously start firmware upgrades and pass self-tests based on the upgrade push information, it receives an upgrade success report sent by the device. An upgrade success response is generated based on the upgrade success report, and the upgrade success response is sent to the device.

8. The multi-module firmware upgrade method according to claim 7, characterized in that, The upgrade push information includes upgrade information corresponding to each of the multiple modules; The upgrade push information generated on the device side specifically includes: The operator responds to the firmware version confirmation operations of multiple modules in the device and identifies the firmware file corresponding to each firmware version confirmation operation. Multiple upgrade information corresponding to each module is generated based on the multiple firmware files.

9. A multi-module firmware upgrade system, characterized in that, The multi-module firmware upgrade system includes a device side and a server side; The device is used to implement the steps of the multi-module firmware upgrade method as described in any one of claims 1-6; The server is used to implement the steps of the multi-module firmware upgrade method as described in claim 7 or 8.

10. A chip, characterized in that, The chip includes: a memory, a processor, and a multi-module firmware upgrade program stored in the memory and executable on the processor. When the multi-module firmware upgrade program is executed by the processor, it implements the steps of the multi-module firmware upgrade method as described in any one of claims 1-6, or implements the steps of the multi-module firmware upgrade method as described in claim 7 or 8.

Images