Method for upgrading a multi-processor oriented device, device and storage medium

Abstract

This application discloses a method, apparatus, and storage medium for upgrading multi-processor devices. The method can be applied to a first processor in a device to be upgraded, which also includes at least two second processors. The first and second processors are communicatively connected. The method includes: responding to a received device upgrade request, obtaining upgrade data transmission paths between the processors in the device to be upgraded; determining the upgrade priority of each processor based on the upgrade data transmission paths; obtaining upgrade data for each processor based on the upgrade priorities and sending the upgrade data to the corresponding processor for upgrade processing. This solution can improve device upgrade efficiency.

Description

Technical Field

[0001] This application relates to the field of device upgrade technology, and in particular to a method, device, and storage medium for upgrading multiprocessor devices. Background Technology

[0002] As electronic devices become increasingly feature-rich, a single processor can no longer meet the complex functional requirements. Therefore, more and more smart devices are adopting multi-processor architectures to achieve different functions.

[0003] In practical applications, these processors typically require periodic firmware upgrades for updating and maintaining smart devices. Commonly used device upgrade technologies include OTA (Over-The-Air), ISP (In-System Programming), and IAP (In-Application Programming), among others.

[0004] However, existing upgrade methods are usually pre-configured and static, requiring upgrades to be performed sequentially according to processor levels, from high to low or from low to high, with each processor upgrade completed before moving on to the next. This approach does not dynamically consider the actual operating conditions of the smart device, resulting in very low upgrade efficiency. Therefore, there is an urgent need for a method to optimize the upgrade process for smart devices with multiple processors. Summary of the Invention

[0005] This application provides at least one method, apparatus, device, and computer-readable storage medium for upgrading multiprocessor devices.

[0006] The first aspect of this application provides a method for upgrading a multi-processor device. This method is applicable to a first processor in a device to be upgraded, the device further comprising at least two second processors, the first processor and the second processors having a communication connection. The method includes: in response to a received device upgrade request, obtaining upgrade data transmission paths between the processors in the device to be upgraded; determining the upgrade priority of each processor based on the upgrade data transmission paths; obtaining upgrade data for each processor based on the upgrade priority and sending the upgrade data to the corresponding processor for upgrade processing.

[0007] In one embodiment, determining the upgrade priority of each processor based on the upgrade data transmission path includes: determining the transmission path distance between each second processor and the first processor based on the upgrade data transmission path; and determining the upgrade priority based on the transmission path distance, wherein the upgrade priority is positively correlated with the transmission path distance.

[0008] In one embodiment, determining the upgrade priority of each processor based on the upgrade data transmission path includes: obtaining an upgrade list corresponding to the device upgrade request, the upgrade list including the upgrade data volume corresponding to each processor; determining the upgrade time corresponding to each processor based on the communication rate and the upgrade data volume corresponding to each processor in the upgrade transmission path; and determining the upgrade priority of each processor based on the upgrade time, wherein the upgrade priority is positively correlated with the upgrade time.

[0009] In one embodiment, the step of obtaining upgrade data for each processor according to the upgrade priority and sending the upgrade data to the corresponding processor for upgrade processing includes: obtaining upgrade data for each processor according to the upgrade priority and verifying it; and sending the verified upgrade data to the corresponding processor for upgrade processing according to the upgrade data transmission path.

[0010] In one embodiment, the step of obtaining upgrade data for each processor according to the upgrade priority and sending the upgrade data to the corresponding processor for upgrade processing includes: obtaining the upgrade-required resources of each second processor and the remaining available upgrade resources of the device to be upgraded; selecting a parallel upgrade processing strategy or a serial upgrade processing strategy based on the resource quantity comparison result between the upgrade-required resources of each second processor and the remaining available upgrade resources; and sending the upgrade data to the corresponding second processor for upgrade processing according to the parallel upgrade processing strategy or the serial upgrade processing strategy.

[0011] In one embodiment, selecting a parallel upgrade processing strategy or a serial upgrade processing strategy based on the resource quantity comparison between the upgrade-required resources of each second processor and the remaining available upgrade resources includes: if the remaining available upgrade resources are greater than the sum of the upgrade-required resources of multiple second processors, the upgrade data of the multiple processors are obtained in parallel according to the upgrade priority, and the upgrade data is sent to the corresponding second processor for upgrade processing respectively; if the remaining available upgrade resources are less than the sum of the upgrade-required resources of at most two second processors, the upgrade data of each processor is obtained serially according to the upgrade priority, and the upgrade data is sent to the corresponding second processor for upgrade processing in sequence.

[0012] In one embodiment, the step of obtaining upgrade data for each processor according to the upgrade priority and sending the upgrade data to the corresponding processor for upgrade processing includes: determining whether each second processor has completed the upgrade; if so, performing upgrade processing according to the upgrade data of the first processor; if not, waiting for each second processor to complete the upgrade.

[0013] In one embodiment, the upgrade process based on the upgrade data of the first processor includes: performing a restart flash based on the upgrade data of the first processor to interrupt the communication connection between the first processor and the second processor, and causing the second processor to restart when the interruption time is greater than a preset time threshold; in response to the successful restart flash of the first processor, determining that the first processor has completed the upgrade process.

[0014] A second aspect of this application provides a device upgrade apparatus for multiprocessors, applicable to a first processor of a device to be upgraded, the device further comprising at least two second processors, the first processor and the second processors being communicatively connected. The apparatus includes: an acquisition module, configured to acquire upgrade data transmission paths between processors in the device to be upgraded in response to a received device upgrade request; a priority determination module, configured to determine the upgrade priority of each processor based on the upgrade data transmission paths; and an upgrade processing module, configured to acquire upgrade data for each processor based on the upgrade priorities and send the upgrade data to the corresponding processor for upgrade processing.

[0015] A third aspect of this application provides an electronic device including a memory and a processor, the processor being configured to execute program instructions stored in the memory to implement the aforementioned multiprocessor-oriented device upgrade method.

[0016] The fourth aspect of this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a processor, implement the above-described multiprocessor-oriented device upgrade method.

[0017] The above solution can be applied to the first processor of the device to be upgraded. The device also includes at least two second processors, and the first and second processors are communicatively connected. By using the first processor as the master controller, after receiving a device upgrade request, the first processor can obtain the upgrade data transmission path between the processors in the device to be upgraded. The upgrade data transmission path represents the transmission path of upgrade data between the processors during the upgrade process. Therefore, efficiency bottlenecks in the upgrade process can be analyzed based on the upgrade data transmission path, thereby determining the upgrade priority of each processor. Then, upgrade data for each processor is obtained according to the upgrade priority and sent to the corresponding processor for upgrade processing, thus prioritizing the handling of inefficient tasks during the upgrade process and significantly improving the overall upgrade efficiency.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0020] Figure 1 This is a schematic diagram of an exemplary smart lock system in the multiprocessor-oriented device upgrade method of this application; Figure 2 This is a flowchart illustrating an exemplary embodiment of the device upgrade method for multiprocessors according to this application; Figure 3 This is a block diagram illustrating a multiprocessor-oriented device upgrade apparatus as shown in an exemplary embodiment of this application; Figure 4 This is a schematic diagram of the structure of an embodiment of the electronic device of this application; Figure 5 This is a schematic diagram of the structure of an embodiment of the computer-readable storage medium of this application. Detailed Implementation

[0021] The solution of this embodiment will now be described in detail with reference to the accompanying drawings.

[0022] In the following description, specific details such as particular system architectures, interfaces, and technologies are presented for illustrative purposes rather than for limiting purposes, in order to provide a thorough understanding of this application.

[0023] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this document means two or more. Moreover, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of objects. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0024] For ease of understanding, one of the applicable scenarios of this application is illustrated by example.

[0025] As electronic devices become increasingly feature-rich, a single processor can no longer meet the complex functional requirements. Therefore, more and more smart devices are adopting multi-processor architectures to achieve different functions.

[0026] In practical applications, these processors typically require periodic firmware upgrades for updating and maintaining smart devices. Commonly used device upgrade technologies include OTA (Over-The-Air), ISP (In-System Programming), and IAP (In-Application Programming), among others.

[0027] However, existing upgrade methods are usually pre-configured and static, requiring upgrades to be performed sequentially according to processor levels, from high to low or from low to high, with each processor upgrade completed before moving on to the next. This approach does not dynamically consider the actual operating conditions of the smart device, resulting in very low upgrade efficiency. Therefore, there is an urgent need for a method to optimize the upgrade process for smart devices with multiple processors.

[0028] It should be noted that the smart device (the device to be upgraded) in this application can be an electronic device with certain data processing and communication capabilities and a multi-processor. The specific type of smart device is not limited here. For example, a smart device can be a mobile phone, computer, smartwatch, smart car, etc.

[0029] For ease of understanding, the following embodiments will primarily use smart door locks from the Internet of Things (IoT) as an example of the device to be upgraded. See also... Figure 1 , Figure 1 This is a simplified schematic diagram of an exemplary smart lock system in the multiprocessor-oriented device upgrade method of this application.

[0030] The smart lock system in this example may include at least the following modules: a first controller (main SoC) and several second controllers (slave SoC, main microcontroller, lock body microcontroller). Additionally, the smart lock system may include a communication module (depending on the actual application scenario, the communication module may or may not be considered a second controller; this is not limited here). Therefore, for ease of understanding, the following embodiments will primarily use the interaction between the first controller and the second controller as an example for illustration.

[0031] Among them, the main SoC (System on Chip) serves as the main controller (data hub and decision center) in the smart lock system. It can use a high-performance application processor, run Linux / RTOS, and integrate a communication module interface (to communicate with external devices through the communication module). It is responsible for core business logic, cloud communication, and global upgrade coordination.

[0032] From the SoC: It can use a dedicated security processor or a low-power coprocessor to support communication with the main SoC via a high-speed serial port (such as UART, SPI, etc.). In smart door lock applications, it can be responsible for security calculations or drive specific peripherals.

[0033] Master microcontroller: It can be responsible for real-time control such as lock body driving and sensor acquisition, and supports connection with slave SoC via serial ports such as UART.

[0034] The microcontroller (such as the lock body microcontroller) is responsible for controlling the motor / solenoid valve of the smart door lock and can communicate with the main microcontroller through proprietary protocols (such as UART, I2C, etc.).

[0035] Communication module: This module communicates with the main SoC and can be a standalone module or integrated within the main SoC; there are no restrictions here. This communication module may include, but is not limited to, one or more of the following: Wi-Fi module, cellular communication module, Bluetooth module, fixed-line communication module, etc.

[0036] In some application scenarios, the data processing capabilities (or communication rates) of the processors in a smart lock are typically ranked as follows: main SoC > slave SoC > main microcontroller.

[0037] Please see Figure 2 , Figure 2 This is a flowchart illustrating an exemplary embodiment of the multiprocessor-oriented device upgrade method of this application. Specifically, it may include the following steps: Step S110: In response to the received device upgrade request, obtain the upgrade data transmission path between the processors in the device to be upgraded.

[0038] The device upgrade request may be obtained by the first processor from other external devices that have a communication connection with the device to be upgraded, and / or may be generated internally by the device to be upgraded; this is not limited here.

[0039] For example, the main SoC has a communication connection with a communication module (such as a Wi-Fi module), so it can receive device upgrade requests from the cloud (or other device terminals) through the Wi-Fi module.

[0040] In another example, a processor in the device to be upgraded can generate a device upgrade request in response to an upgrade event and send the device upgrade request to the cloud (or other device terminal) via a Wi-Fi module. For example, the device to be upgraded can periodically generate device upgrade requests according to a preset upgrade cycle; or the device to be upgraded can generate a device upgrade request in response to certain interactive operations (such as a user issuing an upgrade command directly on the operation panel of the device to be upgraded).

[0041] Another example is that, within a preset response time period, after receiving a device upgrade request sent by another external device and a device upgrade request generated internally by the device to be upgraded (more authentication processes can be set as needed, which will not be elaborated here), the subsequent upgrade process can begin. Authentication of the upgrade request by at least two parties, both internal and external, makes the upgrade process more secure.

[0042] Furthermore, after the first processor confirms receipt of the device upgrade request, it can connect to the upgrade server used to obtain upgrade data in preparation for downloading the upgrade data. The upgrade data can exist in the form of an upgrade package, which will not be elaborated upon here.

[0043] In addition to downloading from the cloud, methods for obtaining upgrade data may also include obtaining it from terminal devices or storage media with a communication connection, and no limitation is made here.

[0044] It should also be noted that the upgrade data transmission path can be pre-set in the device to be upgraded (such as the storage medium of the device to be upgraded); or it can be obtained from the cloud, which is not limited here.

[0045] For example, after the device to be upgraded and the upgrade server establish a communication connection, the device to be upgraded can receive a structured upgrade manifest sent by the upgrade server. This upgrade manifest not only includes the upgrade package URL, version information, hash value, etc. of each module in the device to be upgraded (main SoC, slave SoC, main microcontroller, lock body microcontroller, Wi-Fi module, etc.), but also identifies the type of upgrade package (such as a complete package for full upgrade / a differential package for differential upgrade) and the estimated size of the upgrade package (used to characterize the upgrade data volume).

[0046] Therefore, after receiving the upgrade list, the main SoC can analyze the upgrade list to obtain the target module that needs to be upgraded for this device upgrade request, that is, it can determine the corresponding upgrade data transmission path based on the system architecture of the device to be upgraded.

[0047] Step S120: Determine the upgrade priority of each processor based on the upgrade data transmission path.

[0048] For ease of understanding and explanation, the embodiments of this application use a typical upgrade data transmission path as an example. For example: main SoC -> slave SoC -> main microcontroller (and its subordinate lock body microcontrollers).

[0049] In other words, during the upgrade process, if the main SoC downloads the upgrade data corresponding to the main microcontroller from the cloud (the upgrade data for the main microcontroller and the lock body microcontroller can be packaged together as needed and upgraded together), the main SoC needs to first send the upgrade data corresponding to the main microcontroller to the slave SoC, and then the slave SoC forwards the received upgrade data corresponding to the main microcontroller (and / or the upgrade data corresponding to the lock body microcontroller) to the main microcontroller. Thus, the main microcontroller can perform the upgrade process upon receiving the corresponding upgrade data.

[0050] Similarly, if the master SoC downloads the corresponding upgrade data for the slave SoC from the cloud, the master SoC will send the upgrade data from the slave SoC to the slave SoC. Thus, the slave SoC can perform the upgrade process upon receiving the corresponding upgrade data.

[0051] It should be noted that, generally speaking, the longest transmission path also means the longest upgrade time, which may become the bottleneck in the overall upgrade process. Therefore, in one possible implementation, the main SoC can be determined as the transmission origin, and the upgrade priority of each processor can be determined according to the length of the transmission path between each processor and the main SoC.

[0052] The length of the transmission path can be positively correlated (or approximately positively correlated) with the upgrade priority. That is, the longer the transmission path, the higher the upgrade priority (the higher the priority for upgrade processing).

[0053] Step S130: Obtain upgrade data for each processor according to the upgrade priority and send the upgrade data to the corresponding processor for upgrade processing.

[0054] Based on the steps described above, after determining the upgrade priority of each processor according to the upgrade data transmission path, the main SoC can obtain the upgrade data of each processor in the order of upgrade priority, and then send the upgrade data to the corresponding processor for upgrade processing.

[0055] For example, in the application scenario described above, based on the determined upgrade priority, the main SoC first obtains the upgrade data corresponding to the main microcontroller and forwards it to the main microcontroller for upgrade processing via the slave SoC; then, the main SoC obtains the upgrade data corresponding to the slave SoC and sends it to the slave SoC for upgrade processing; finally, the main SoC obtains its own corresponding upgrade data and performs upgrade processing.

[0056] As can be seen, this application can be applied to the first processor of a device to be upgraded. The device to be upgraded also includes at least two second processors. The first processor and the second processors are connected in communication. By using the first processor as the master controller, after receiving a device upgrade request, the first processor can obtain the upgrade data transmission path between the processors in the device to be upgraded. The upgrade data transmission path represents the transmission path of upgrade data between the processors during the upgrade process. Therefore, efficiency bottlenecks in the upgrade process can be analyzed based on the upgrade data transmission path, thereby determining the upgrade priority of each processor. Then, upgrade data for each processor is obtained according to the upgrade priority and sent to the corresponding processor for upgrade processing, thus prioritizing the handling of inefficient tasks during the upgrade process and significantly improving the upgrade efficiency of the entire upgrade process.

[0057] Based on the above embodiments, this embodiment describes the method in step S120.

[0058] Specifically, the method for determining the upgrade priority of each processor based on the upgrade data transmission path in this embodiment includes at least the following steps S210 to S220: Step S210: Determine the transmission path distance between each second processor and the first processor based on the upgrade data transmission path.

[0059] Step S220: Determine the upgrade priority based on the transmission path distance. The upgrade priority is positively correlated with the transmission path distance.

[0060] Referring to the foregoing embodiments, the first processor, as the main controller of the device to be upgraded, can connect to the communication module and acquire upgrade data. Therefore, the first processor (main SoC) can be used as the origin of the upgrade data transmission path, and from there, it can begin receiving upgrade data and distributing data to each of the second processors.

[0061] Therefore, the transmission path distance between each second processor and the first processor can be determined based on the upgrade data transmission path. Then, the upgrade priority can be determined based on the transmission path distance, which is positively correlated (or approximately positively correlated) with the transmission path distance. That is, the second processor that is farther away from the first processor has a higher upgrade priority.

[0062] Therefore, based on the aforementioned example method, the second processor, which is the furthest away (and usually the one with the longest upgrade time), can be prioritized for upgrade processing.

[0063] Understandably, the first processor, as the transmission origin, can be the last processor to undergo upgrade processing. For example, after the upgrades of each of the second processors are completed, the upgrade data of the first processor is obtained and the upgrade processing of the first processor is performed.

[0064] Based on the above embodiments, this embodiment describes the method in step S120.

[0065] Specifically, the method for determining the upgrade priority of each processor based on the upgrade data transmission path in this embodiment includes at least the following steps S310 to S330: Step S310: Obtain the upgrade list corresponding to the device upgrade request. The upgrade list includes the upgrade data volume corresponding to each processor.

[0066] Step S320: Determine the upgrade time for each processor based on the communication rate and upgrade data volume of each processor in the upgrade transmission path.

[0067] Step S330: Determine the upgrade priority of each processor based on the upgrade time. The upgrade priority is positively correlated with the upgrade time.

[0068] The above embodiments will be used as a reference for the description of the upgrade manifest and the upgrade data volume, which will not be repeated here.

[0069] It should be noted that, in the process of determining the upgrade priority of each processor based on the upgrade data transmission path, in addition to referring to the method of the aforementioned embodiment to determine the corresponding upgrade priority based on the transmission path distance between each second processor and the first processor in the upgrade data transmission path, it is also possible to determine the upgrade time corresponding to each processor based on the communication rate and upgrade data volume corresponding to each processor in the upgrade transmission path, and thereby determine the upgrade priority of each processor.

[0070] In practical applications, the amount of upgrade data may be the same or different for different processors during the upgrade process; this is not a limitation here.

[0071] For example, in some upgrade processes, the amount of data that needs to be updated when the processor at the end of the upgrade data transmission path (such as the master microcontroller) is upgraded may be significantly less than the amount of data that needs to be updated when the processor in the middle of the upgrade data transmission path (such as the slave SoC) is upgraded. And / or, in some upgrade processes, the communication rate between the master SoC and the slave SoC may be less than the communication rate between the slave SoC and the master microcontroller.

[0072] Therefore, when faced with different upgrade processes, the device upgrade method of this application can determine the upgrade time for each processor by analyzing the communication rate and upgrade data volume of each processor during each upgrade process. The upgrade process with the longest upgrade time is the efficiency bottleneck in this upgrade process.

[0073] Therefore, the main SoC can obtain the upgrade data volume corresponding to each processor participating in this upgrade process in the upgrade list, and can also obtain the communication rate corresponding to each processor in the upgrade transmission path (which can be obtained in real time or pre-stored, and is not limited here).

[0074] Therefore, for each processor, the upgrade time can be determined by the ratio between the amount of upgrade data it needs to receive and the communication rate.

[0075] Similarly, upgrade time is positively correlated (or nearly positively correlated) with upgrade priority. That is, the longer the upgrade process takes, the higher the upgrade priority.

[0076] Optionally, for processors that require data forwarding (such as the main microcontroller needing to forward data from the SoC), the upgrade time can be determined based on the corresponding upgrade data volume and communication rate during the upgrade time calculation process. Alternatively, the overall time can be determined by combining this with the forwarding time of the upgrade data volume during the data forwarding process (e.g., calculated based on the upgrade data volume of the main microcontroller and the communication rate between the slave SoC and the main SoC). The overall time can still be positively correlated (or approximately positively correlated) with the upgrade priority.

[0077] Optionally, in addition to determining the upgrade time based on the upgrade data volume and communication rate in the aforementioned example, the processing time can also be determined based on the upgrade data volume and processing rate (which can be obtained in real time or pre-stored, without limitation here); similarly, the upgrade priority can be determined based on the upgrade time, or the processing time, or the sum of the upgrade time and the processing time.

[0078] Based on the above embodiments, it should also be noted that in some possible implementations, in addition to determining the upgrade priority based on the transmission path distance or the upgrade time, the upgrade priority can also be determined based on the upgrade data volume (which is positively correlated). This will not be elaborated here.

[0079] Based on the above embodiments, this embodiment describes the method in step S130.

[0080] Specifically, the method in this embodiment for obtaining upgrade data for each processor according to upgrade priority and sending the upgrade data to the corresponding processor for upgrade processing includes at least the following steps S410 to S420: Step S410: Obtain and verify the upgrade data of each processor according to the upgrade priority.

[0081] The verification methods can refer to data verification technologies in this field, including but not limited to one or more of the following: security verification, integrity verification, and consistency verification, which will not be elaborated here.

[0082] For example, the main SoC can verify the upgrade data according to a preset data verification algorithm when acquiring the upgrade data. For example, this may include verification before acquiring the upgrade data, and / or verification during the acquisition of the upgrade data, and / or verification after the acquisition of the upgrade data.

[0083] Furthermore, after data verification processing, the upgrade data can be distinguished into verified upgrade data or verified upgrade data. Upgrade data for multiple processors can include verified upgrade data and / or verified upgrade data.

[0084] Step S420: The verified upgrade data is sent to the corresponding processor for upgrade processing according to the upgrade data transmission path.

[0085] Based on the steps described above, after data verification, the verified upgrade data can be sent to the corresponding processor for upgrade processing according to the upgrade data transmission path.

[0086] For upgrade data that fails verification, the main SoC can re-request the corresponding upgrade data until it obtains verified upgrade data or the number of re-requests exceeds a preset threshold. Alternatively, it can refuse to upgrade the processor corresponding to the upgrade data during the upgrade process corresponding to this device upgrade request; or it can refuse all upgrade processes corresponding to this device upgrade request, which will not be elaborated here.

[0087] Based on the above embodiments, this embodiment describes the method in step S130.

[0088] Specifically, the method in this embodiment includes at least the following steps S510 to S530: Step S510: Obtain the resources required for upgrading each second processor and the remaining available resources for upgrading the device to be upgraded.

[0089] The resources required for upgrading each processor can be obtained from the manifest file or calculated based on the size of the upgrade data. For details, please refer to the relevant technologies in this field, which will not be elaborated here.

[0090] Upgrade remaining available resources refer to the resources currently remaining available among those used for upgrade processing. Exemplarily, these resources may include, but are not limited to, one or more of the following: memory resources, processor resources, storage resources, network resources, etc., without limitation here. For ease of understanding and explanation, the embodiments of this application mainly use memory resources as an example for description.

[0091] Step S520: Based on the comparison of the resources required for upgrading each second processor with the remaining available resources for upgrading, select either a parallel upgrade processing strategy or a serial upgrade processing strategy.

[0092] Based on the steps described above, by comparing the resources required for upgrading each processor with the remaining available resources, we can obtain a comparison of the resource quantities required for upgrading each processor with the remaining available resources.

[0093] The resource quantity comparison results can indicate whether the remaining available resources for the current upgrade can support multiple processors to perform parallel upgrade processing. If they cannot support parallel upgrade processing, then serial upgrade processing needs to be selected.

[0094] The serial upgrade processing strategy and / or parallel upgrade processing strategy can be preset or temporarily generated according to preset upgrade processing rules based on the actual application scenario, and there is no limitation here.

[0095] A serial upgrade processing strategy includes at least one step: each processor performs the upgrade process sequentially according to its upgrade priority. A parallel upgrade processing strategy includes at least one step: at least two processors can perform the upgrade process simultaneously, according to their upgrade priorities.

[0096] Step S530: According to the parallel upgrade processing strategy or the serial upgrade processing strategy, the upgrade data is sent to the corresponding second processor for upgrade processing.

[0097] Therefore, after determining whether to use a parallel upgrade processing strategy or a serial upgrade processing strategy, the main SoC can send upgrade data to the corresponding processor for upgrade processing according to the specific upgrade processing strategy.

[0098] Based on the above embodiments, this embodiment further explains that, in some devices to be upgraded, theoretically sufficient resources can be pre-deployed for these devices during the product development stage. Therefore, in the upgrade process of the above example, the process of comparing the resources required for the upgrade with the remaining available resources can be omitted, and a parallel upgrade processing strategy is adopted by default.

[0099] In this regard, it is only necessary to determine which types of processors can be upgraded in parallel during the specific upgrade process, which will not be elaborated here.

[0100] Based on the above embodiments, this embodiment describes the method in step S520.

[0101] Specifically, in this embodiment, the method for selecting a parallel upgrade processing strategy or a serial upgrade processing strategy based on the comparison between the resources required for upgrading each second processor and the remaining available resources for upgrading includes at least the following steps S610 to S620: Step S610: If the remaining available resources for upgrading are greater than the sum of the resources required for upgrading multiple second processors, upgrade data for multiple processors are obtained in parallel according to the upgrade priority, and the upgrade data is sent to the corresponding second processor for upgrade processing.

[0102] Referring to the foregoing embodiments, in an application scenario where the upgrade priority is master microcontroller -> slave SoC -> master SoC, the second processor includes the master microcontroller and the slave SoC. If the remaining available resources for upgrading are greater than the sum of the resources required for upgrading multiple second processors (e.g., greater than the sum of the resources required for upgrading the master microcontroller and the resources required for upgrading the slave SoC), then the master SoC can choose a parallel upgrade processing strategy.

[0103] For example, the main SoC immediately begins downloading the upgrade data package for the main microcontroller (or a combined upgrade package for the main microcontroller and the lock microcontroller). Simultaneously, since the upgradeable device has ample remaining upgrade resources, it can also choose to begin downloading the upgrade data package for the slave SoC in parallel. This stage fully utilizes the main SoC's high-speed network bandwidth and memory resources, allowing the most time-consuming and second-most time-consuming download tasks to proceed first.

[0104] If the upgrade data is downloaded and verified successfully by the master microcontroller, the master SoC can immediately send it to the slave SoC via UART / SPI. After receiving the data, the slave SoC immediately forwards it to the master microcontroller. Thus, the master microcontroller can begin its own upgrade process based on the received upgrade data (typically including verification, bootloader entry, and flashing steps, which will not be elaborated here). In common scenarios, the microcontroller upgrade process is relatively slower than the upgrade process of other processors.

[0105] Meanwhile, the master SoC may have already downloaded the upgrade data package to the slave SoC. Therefore, after sending the microcontroller's upgrade data package, the master SoC can immediately send the slave SoC's upgrade data package to the slave SoC. It should be noted that at this time, the slave SoC may still be forwarding the microcontroller's upgrade data package to the microcontroller (or may have already completed the forwarding), but most common SoCs from current manufacturers usually support full-duplex communication or can have the slave SoC's bootloader receive its own upgrade data package, thereby achieving parallel data transmission.

[0106] In summary, during the upgrade process of the second controller, the upgrade processes of the SoC processor and the main microcontroller can largely overlap and run in parallel, thereby shortening the overall upgrade time of the device to be upgraded. For example, the upgrade data packet sending operation of the SoC can highly overlap or run in parallel with the upgrade flashing operation of the main microcontroller.

[0107] Step S620: If the remaining available resources for upgrading are less than the sum of the resources required for upgrading at most two second processors, the upgrade data of each processor is obtained serially according to the upgrade priority, and the upgrade data is sent to the corresponding second processor in sequence for upgrade processing.

[0108] In conjunction with the preceding steps, if the remaining available upgrade resources are less than the sum of the resources required for the upgrade of at most two second processors, meaning the remaining available upgrade resources of the device to be upgraded are insufficient to support parallel upgrade processing by the two second processors, then the main SoC can refer to conventional device upgrade methods in the field, serially acquire upgrade data for each processor according to upgrade priority, and send the upgrade data to the corresponding second processor in sequence for upgrade processing.

[0109] Based on the above embodiments, this embodiment describes the method in step S130.

[0110] Specifically, the method in this embodiment for obtaining upgrade data for each processor according to upgrade priority and sending the upgrade data to the corresponding processor for upgrade processing includes at least the following steps S710 to S730: Step S710: Determine whether each second processor has completed the upgrade.

[0111] Step S720: If yes, then perform upgrade processing based on the upgrade data of the first processor.

[0112] Step S730: If not, wait for each second processor to complete the upgrade.

[0113] In conjunction with the foregoing embodiments, the first processor, as the origin of the upgrade process, can be upgraded sequentially according to the upgrade priority determined by the foregoing example method, or it can be selected to upgrade only after ensuring that each second processor has successfully completed the upgrade, thereby achieving atomicity in the upgrade process.

[0114] If not all second processors successfully complete the upgrade, the first processor may wait for all second processors to complete the upgrade, or the first processor may reject the upgrade operation of this device upgrade request; no restrictions are imposed here.

[0115] For example, in an application scenario where the upgrade priority is master microcontroller -> slave SoC -> master SoC, when the master SoC detects that the upgrade data packet of the slave SoC has been sent, it can choose to obtain its own upgrade data packet for upgrade processing.

[0116] In another example, if the communication module connected to the main SoC also needs to be upgraded, the aforementioned embodiment can be referred to, and the main SoC can simultaneously start downloading the upgrade data package of the communication module and the upgrade data package of the main SoC.

[0117] After the upgrade data package for the communication module is downloaded, the main SoC sends it to the corresponding communication module (such as the Wi-Fi module) and commands the Wi-Fi module to enter self-upgrade mode.

[0118] The download speed of the main SoC's upgrade data package may be faster or slower than that of the communication module's upgrade data package; this is not a limitation here. However, the Wi-Fi module will cause the device to be upgraded to enter a network outage state during the upgrade process, which may result in incomplete download of the main SoC's upgrade data package. Therefore, if the main SoC still has communication connections with other communication modules that do not need to participate in this upgrade process, the main SoC can maintain its connection with the cloud through backup links provided by other communication modules (such as cellular, Bluetooth, fixed-line, etc.), or wait for Wi-Fi to restart before continuing to download its upgrade data (where breakpoint resume and other data transmission technologies in this field can be referenced, but will not be elaborated here).

[0119] After the main SoC completes its own upgrade data package download, the upgrade flashing process will not begin immediately. Instead, wait for the signals indicating that the upgrades of other modules have been completed before proceeding with the upgrade.

[0120] In the above example process, the main SoC, slave SoC, and main microcontroller modules can report their status to the main SoC (or the main SoC reports to the cloud via a backup link) at each key node of the upgrade (such as start download, download completion, start flashing, flashing success / failure, etc.) through the existing link, so that the main SoC can maintain the global upgrade state machine of the device to be upgraded.

[0121] Furthermore, the main SoC can continuously collect the "upgrade complete" status reports from each secondary processor. The main SoC will only execute its own upgrade process after confirming that all modules (except the main SoC itself) have reported successful upgrades and that its own upgrade package is ready.

[0122] Based on the above embodiments, this embodiment describes the method in step S720.

[0123] Specifically, the method for upgrading based on the upgrade data of the first processor in this embodiment includes at least the following steps S810 to S820: Step S810: Reboot and rewrite according to the upgrade data of the first processor to interrupt the communication connection between the first processor and the second processor, and cause the second processor to reboot when the interruption time exceeds a preset time threshold.

[0124] In step S820, in response to the successful reboot and flashing of the first processor, it is determined that the first processor has completed the upgrade process.

[0125] Referring to the foregoing embodiments, after the main SoC confirms that all other modules have completed their upgrades and that it has successfully acquired its own upgrade data package, it can send a global reboot command to all other modules.

[0126] Furthermore, the main SoC performs a reboot and rewrite process based on its own upgrade data. During this process, the second processor detects an interruption in the communication connection with the main SoC. Therefore, if the interruption time exceeds a preset time threshold, the second processor can uniformly perform a reboot process to load the upgrade data package.

[0127] Therefore, the "unified restart" mechanism provided in this embodiment ensures that all modules in the device to be upgraded either upgrade to the new version or remain in the old version (if any step fails, no success flag will be set, and each module can roll back or remain in its original state according to the preset recovery strategy), thus achieving the atomicity of the upgrade process.

[0128] For example, after the main SoC is ready for the upgrade, it can send a global reboot command to the main microcontroller.

[0129] After receiving the global reboot command, the main microcontroller will not reboot immediately, ensuring that the lock body is in a preset safe state (such as locked), and will notify the lock body microcontroller. Then, the main microcontroller can reply with a "ready" signal to the main SoC.

[0130] After receiving the "ready" signal, the main SoC can save the upgrade success flag of the main microcontroller, then trigger itself to restart and enter the bootloader to complete the final flashing. The slave SoC can also perform a corresponding restart process.

[0131] Therefore, after the main microcontroller detects a communication interruption with the main SoC (i.e., the main SoC restarts), it delays for a short period of time and can coordinate its own microcontroller and the lock body microcontroller to restart simultaneously.

[0132] If the first processor restarts and flashes successfully, it can be determined that the first processor has completed the upgrade process (or that the device to be upgraded has completed the upgrade process); conversely, if the first processor restarts and flashes fail, it can be determined that the first processor has not completed the upgrade process (or that the device to be upgraded has not completed the upgrade process).

[0133] In summary, the device upgrade method of this application has several advantages. First, it enables intelligent analysis based on bottlenecks in the upgrade process, prioritizing the parallel download of inefficient upgrade data packages, which significantly reduces the total download time. This advantage is particularly pronounced when the upgrade package from the processor is large.

[0134] Secondly, the processing flow of downloading, forwarding, and flashing operations forms a pipeline between modules. For example, when the main microcontroller is being flashed, the SoC is receiving or flashing its own upgrade data packet, which compresses the total time window of the "upgrade operation" and further reduces the downtime of the device to be upgraded.

[0135] Thirdly, download priority can be bound to resource information such as memory status, allowing for parallel downloads when resources are sufficient and sequential downloads or intelligent waiting and forwarding when resources are insufficient, thus making more efficient use of limited resources and avoiding upgrade failures due to insufficient resources.

[0136] Fourthly, after receiving the main SoC signal, the main microcontroller coordinates the underlying modules to perform an atomic restart, which greatly enhances the reliability of the upgrade process and effectively prevents the device to be upgraded from becoming a "half-new, half-old" bricked device.

[0137] Fifthly, each secondary processor can report in a distributed manner, and the primary processor can centrally detect the data. As a result, each module can proactively report key progress during the upgrade process, and the main SoC can grasp the status view of the entire upgrade process, which can facilitate problem location and user prompts during the upgrade process, thereby improving user experience and operational efficiency.

[0138] Therefore, the equipment upgrade method of this application transforms the upgrade process from a sequentially executed batch processing task into an intelligently scheduled, parallel pipeline project, and ensures consistency through atomic commit at the end, resulting in significant improvements in both speed and reliability.

[0139] It should be further noted that the entity executing the multiprocessor-oriented device upgrade method can be a multiprocessor-oriented device upgrade device. For example, the multiprocessor-oriented device upgrade method can be executed by a terminal device, a server, or other processing devices. The terminal device can be a user equipment (UE), computer, mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. In some possible implementations, this multiprocessor-oriented device upgrade method can be implemented by the processor calling computer-readable instructions stored in memory.

[0140] Figure 3This is a block diagram illustrating a multiprocessor-oriented device upgrade apparatus as shown in an exemplary embodiment of this application. Figure 3 As shown, this exemplary multiprocessor-oriented device upgrade apparatus 300 includes: an acquisition module 310, a priority determination module 320, and an upgrade processing module 330. Specifically: The acquisition module 310 is used to acquire the upgrade data transmission path between the processors in the device to be upgraded in response to the received device upgrade request.

[0141] Priority determination module 320 is used to determine the upgrade priority of each processor based on the upgrade data transmission path.

[0142] The upgrade processing module 330 is used to obtain the upgrade data of each processor according to the upgrade priority and send the upgrade data to the corresponding processor for upgrade processing.

[0143] In this exemplary multi-processor-oriented device upgrade apparatus, the apparatus can be applied to a first processor of the device to be upgraded. The device also includes at least two second processors, and the first and second processors are communicatively connected. By using the first processor as the master controller, after receiving a device upgrade request, the first processor can obtain the upgrade data transmission path between the processors in the device to be upgraded. The upgrade data transmission path characterizes the transmission path of upgrade data between the processors during the upgrade process. This allows for the analysis of efficiency bottlenecks in the upgrade process based on the upgrade data transmission path, thereby determining the upgrade priority of each processor. Then, based on the upgrade priority, the upgrade data for each processor is obtained and sent to the corresponding processor for upgrade processing, thus prioritizing the handling of inefficient tasks during the upgrade process and significantly improving the overall upgrade efficiency.

[0144] It should be noted that the apparatus and method provided in the above embodiments belong to the same concept, and the specific ways in which each module and unit performs operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the apparatus provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the apparatus can be divided into different functional modules to complete all or part of the functions described above, and this is not a limitation.

[0145] The functions of each module can be found in the embodiments of the device upgrade method for multiprocessors, and will not be repeated here.

[0146] Please see Figure 4 , Figure 4This is a schematic diagram of the structure of an embodiment of the electronic device of this application. The electronic device 100 includes a memory 101 and a processor 102. The processor 102 is used to execute program instructions stored in the memory 101 to implement the steps in any of the above embodiments of the device upgrade method for multiprocessors. In a specific implementation scenario, the electronic device 100 may include, but is not limited to, a microcomputer or a server. In addition, the electronic device 100 may also include mobile devices such as laptops and tablets, which are not limited here.

[0147] Specifically, processor 102 controls itself and memory 101 to implement the steps in any of the above-described embodiments of the multiprocessor-oriented device upgrade method. Processor 102 may also be referred to as a CPU (Central Processing Unit). Processor 102 may be an integrated circuit chip with signal processing capabilities. Processor 102 may also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. A general-purpose processor may be a microprocessor or any conventional processor. Furthermore, processor 102 may be implemented using integrated circuit chips.

[0148] In this exemplary electronic device, by receiving a device upgrade request, the upgrade data transmission path between the processors in the device to be upgraded can be obtained. The upgrade data transmission path represents the transmission path of upgrade data between the processors during the upgrade process. This allows for the analysis of efficiency bottlenecks in the upgrade process based on the upgrade data transmission path, thereby determining the upgrade priority of each processor. Then, based on the upgrade priority, the upgrade data for each processor is obtained and sent to the corresponding processor for upgrade processing, thus prioritizing the handling of inefficient tasks during the upgrade process and significantly improving the overall upgrade efficiency.

[0149] Please see Figure 5 , Figure 5 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present application. The computer-readable storage medium 110 stores program instructions 111 that can be executed by a processor. The program instructions 111 are used to implement the steps in any of the above embodiments of the multiprocessor-oriented device upgrade method.

[0150] In this exemplary storage medium, after receiving a device upgrade request by running program instructions within the storage medium, the upgrade data transmission path between processors in the device to be upgraded can be obtained. The upgrade data transmission path characterizes the transmission path of upgrade data between processors during the upgrade process. This allows for the analysis of efficiency bottlenecks in the upgrade process based on the upgrade data transmission path, thereby determining the upgrade priority of each processor. Then, based on the upgrade priority, the upgrade data for each processor is obtained and sent to the corresponding processor for upgrade processing, thus prioritizing the handling of inefficient tasks during the upgrade process and significantly improving the overall upgrade efficiency.

[0151] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0152] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0153] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0154] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for upgrading multiprocessor-based devices, characterized in that, The method is applied to a first processor of a device to be upgraded, the device further comprising at least two second processors, the first processor and the second processors having a communication connection, the method comprising: In response to a received device upgrade request, the upgrade data transmission path between the processors in the device to be upgraded is obtained; The upgrade priority of each processor is determined based on the upgrade data transmission path. According to the upgrade priority, the upgrade data of each processor is obtained and the upgrade data is sent to the corresponding processor for upgrade processing.

2. The method according to claim 1, characterized in that, The step of determining the upgrade priority of each processor based on the upgrade data transmission path includes: The transmission path distance between each second processor and the first processor is determined based on the upgrade data transmission path; The upgrade priority is determined based on the transmission path distance, and the upgrade priority is positively correlated with the transmission path distance.

3. The method according to claim 1, characterized in that, The step of determining the upgrade priority of each processor based on the upgrade data transmission path includes: Obtain the upgrade list corresponding to the device upgrade request, the upgrade list including the upgrade data volume corresponding to each processor; The upgrade time for each processor is determined based on the communication rate of each processor in the upgrade transmission path and the upgrade data volume of each processor. The upgrade priority of each processor is determined based on the upgrade time, and the upgrade priority is positively correlated with the upgrade time.

4. The method according to any one of claims 1 to 3, characterized in that, The step of obtaining upgrade data for each processor according to the upgrade priority and sending the upgrade data to the corresponding processor for upgrade processing includes: The upgrade data for each processor is obtained and verified according to the upgrade priority. The verified upgrade data will be sent to the corresponding processor for upgrade processing according to the upgrade data transmission path.

5. The method according to any one of claims 1 to 3, characterized in that, The step of obtaining upgrade data for each processor according to the upgrade priority and sending the upgrade data to the corresponding processor for upgrade processing includes: Obtain the resources required for upgrading each second processor and the remaining available resources for upgrading the device to be upgraded; Based on the comparison of the resources required for upgrading each second processor with the remaining available resources for upgrading, a parallel upgrade processing strategy or a serial upgrade processing strategy is selected. The upgrade data is sent to the corresponding second processor for upgrade processing according to the parallel upgrade processing strategy or the serial upgrade processing strategy.

6. The method according to claim 5, characterized in that, The step of selecting a parallel upgrade processing strategy or a serial upgrade processing strategy based on the resource comparison results between the resources required for upgrading each second processor and the remaining available resources for upgrading includes: If the remaining available resources for the upgrade are greater than the sum of the resources required for the upgrade of multiple second processors, the upgrade data of the multiple processors are obtained in parallel according to the upgrade priority, and the upgrade data is sent to the corresponding second processor for upgrade processing. If the remaining available resources for the upgrade are less than the sum of the resources required for the upgrade of at most two second processors, the upgrade data of each processor is obtained serially according to the upgrade priority, and the upgrade data is sent to the corresponding second processor in sequence for upgrade processing.

7. The method according to any one of claims 1 to 3, characterized in that, The step of obtaining upgrade data for each processor according to the upgrade priority and sending the upgrade data to the corresponding processor for upgrade processing includes: Determine whether each secondary processor has completed the upgrade; If so, then perform the upgrade process based on the upgrade data of the first processor; If not, then wait for each secondary processor to complete its upgrade.

8. The method according to claim 7, characterized in that, The upgrade process based on the upgrade data of the first processor includes: The upgrade data of the first processor is used to perform a reboot and flash, so as to interrupt the communication connection between the first processor and the second processor, and cause the second processor to reboot when the interruption time exceeds a preset time threshold. Upon successful reboot and flashing of the first processor, the upgrade process of the first processor is determined to be complete.

9. An electronic device, characterized in that, The method includes a memory and a processor, the processor being configured to execute program instructions stored in the memory to implement the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the method described in any one of claims 1 to 8.

Images