Firmware upgrading method, electronic equipment and storage medium

Abstract

The embodiment of the invention relates to the technical field of firmware upgrading, in particular to a firmware upgrading method, electronic equipment and a storage medium, the method is used for the electronic equipment, the electronic equipment comprises reference firmware, and the reference firmware comprises a first component management module and a plurality of first functional components. According to the embodiment of the invention, the firmware is divided into a plurality of independent functional components, each functional component is compiled into a position-independent code, flexible loading and unloading in a memory are supported, and the to-be-upgraded functional component is automatically identified by comparing the components between the reference firmware and the target firmware, so that the upgrading efficiency is improved. Therefore, the component management module is used for accurately upgrading the to-be-upgraded functional component, firmware based on component management is efficiently and flexibly upgraded, firmware upgrading time is remarkably shortened, firmware upgrading efficiency and flexibility are improved, and service continuity can be guaranteed.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of firmware upgrade technology, and in particular to a firmware upgrade method, electronic device and storage medium. Background Technology

[0002] In embedded devices without an operating system or with a simple real-time operating system (RTOS), firmware code is compiled into a single binary file. Upgrading this firmware architecture requires replacing the entire binary file, i.e., downloading and replacing the complete firmware image, and restarting (or hot-resetting) the device to complete the update. During the upgrade, the device cannot provide normal service, impacting business continuity, and firmware upgrades are time-consuming. Related technologies use differential upgrades to reduce data packet downloads, but before loading the new firmware, the differential upgrade scheme still needs to reassemble the new firmware based on the differential information, and then load the complete new firmware to complete the upgrade. When fixing vulnerabilities, adding new features, or optimizing performance, even if only a small part of the firmware code is modified, a complete new firmware version needs to be generated. The entire firmware image is then rewritten to the device through a specific upgrade process (such as via NVMe commands, OTA, etc.), resulting in unchanged code being repeatedly written to storage. This leads to poor firmware upgrade flexibility and unnecessary write / erase cycles (especially on flash-based storage devices). Summary of the Invention

[0003] In view of this, one objective of the embodiments of the present invention is to provide a firmware upgrade method, electronic device and storage medium to improve the long firmware upgrade time and poor flexibility in the related art.

[0004] To address the aforementioned technical problems, the embodiments of the present invention provide the following technical solutions: In a first aspect, embodiments of the present invention provide a firmware upgrade method applied to an electronic device. The electronic device includes reference firmware, which includes a first component management module and a plurality of first functional components. The firmware upgrade method includes: Receive target firmware, which includes a second component management module and multiple second functional components, wherein the first functional components and the second functional components are compiled into position-independent code; If the first management version and the second management version are the same, the first component management module determines candidate functional components based on multiple first functional components and multiple second functional components. The first management version is the version of the first component management module, the second management version is the version of the second component management module, and the candidate functional components are the functional components to be upgraded. The first component management module controls the upgrade operation of candidate functional components.

[0005] In some embodiments, a first functional component has a first identifier and a first functional version, and a second functional component has a second identifier and a second functional version. Controlling the first component management module to determine candidate functional components based on multiple first functional components and multiple second functional components includes: The first component management module responds to the fact that the first reference identifier is different from any of the multiple second identifiers, and determines the first reference functional component as a candidate functional component of the first type. The first reference identifier is the first identifier of the first reference functional component, the first reference functional component is any of the multiple first functional components, and the first type is used to characterize the candidate functional component as a functional component to be deleted. The first component management module responds to the fact that the second reference identifier is different from any of the multiple first identifiers, and determines the second reference functional component as a candidate functional component of the second type. The second reference identifier is the second identifier of the second reference functional component, and the second reference functional component is any of the multiple second functional components. The second type is used to characterize the candidate functional component as a functional component to be added. The first component management module responds when the first reference identifier and the second reference identifier are the same, and the first reference function version and the second reference function version are different. It then determines the first reference function component and the second reference function component as candidate function components of the third type. The first reference function version is the first function version of the first reference function component, and the second reference function version is the second function version of the second reference function component. The third type is used to characterize the candidate function component as a function component to be updated.

[0006] In some embodiments, the candidate functional component has an upgrade type flag, and the first component management module controls the candidate functional component to perform an upgrade operation, including: The first component management module responds by marking the upgrade type of the candidate functional component as the marker corresponding to the first type, and then performs an uninstallation operation on the candidate functional component. The first component management module responds by marking the upgrade type of the candidate functional component with the corresponding mark of the second type and performs a loading operation on the candidate functional component. The first component management module responds to the upgrade type of the candidate functional component by marking it as the tag corresponding to the third type, and performs the target operation on the candidate functional component. The target operation includes uninstallation and loading operations.

[0007] In some embodiments, the first component management module responds to the upgrade type marker of the candidate functional component being the marker corresponding to the first type, and performs an uninstallation operation on the candidate functional component, including: A first target functional component is determined based on a first dependency relationship when the first functional component performs a first actual business. The first target functional component is a functional component to be uninstalled. The first target functional component includes candidate functional components. Alternatively, the first target functional component includes candidate functional components and a first baseline functional component. The first baseline functional component is a first functional component that depends on the candidate functional components when performing the first actual business. The response to the first target functional component includes candidate functional components, and an unloading operation is performed on the candidate functional components; The response to the first target functional component includes candidate functional components and a first baseline functional component, and an unloading operation is performed on the first target functional component.

[0008] In some embodiments, responding to a first target functional component includes candidate functional components, and performing an unloading operation on the candidate functional components includes: In response to a candidate functional component being offline, the system controls the candidate functional component to execute an unload function and release the first memory, which is the memory occupied by the candidate functional component.

[0009] In some embodiments, in response to a first target functional component including a candidate functional component and a first baseline functional component, an unloading operation is performed on the first target functional component, including: In response to the first benchmark functional component being offline, the first benchmark functional component is controlled to execute an unload function and release the second memory, which is the memory occupied by the first benchmark functional component; In response to a candidate functional component being offline, control the candidate functional component to execute an unload function and release the third memory, which is the memory occupied by the candidate functional component.

[0010] In some embodiments, the first component management module responds to the upgrade type marker of the candidate functional component being marked as the marker corresponding to the second type, and performs a loading operation on the candidate functional component, including: The second target functional component is determined based on the second dependency relationship when the candidate functional component executes the second actual business. The second target functional component is the first functional component that the candidate functional component depends on when executing the second actual business. In response to the second target functional component not being in a working state, control the second target functional component to perform an initialization operation so that the second target functional component enters and is in a working state; In response to all second target functional components being in a working state, perform a loading operation on the candidate functional components.

[0011] In some embodiments, in response to all second target functional components being in an active state, a loading operation is performed on the candidate functional components, including: Allocate a fourth memory segment for the candidate functional components; In response to a candidate functional component successfully referencing all second target functional components, control the candidate functional component to execute the loading function to configure the function table in the fourth memory.

[0012] In some embodiments, the candidate functional component includes a first reference functional component and a second reference functional component. The first component management module responds to the upgrade type flag of the candidate functional component being set to the flag corresponding to the third type, and performs a target operation on the candidate functional component, including: The third target functional component is determined based on the third dependency relationship when the first functional component performs the third actual business. The third target functional component is a functional component to be uninstalled. The third target functional component includes the first reference functional component. Alternatively, the third target functional component includes the first reference functional component and the second baseline functional component. The second baseline functional component is the first functional component that depends on the first reference functional component when performing the third actual business. The fourth target functional component is determined based on the fourth dependency relationship when the second reference functional component performs the fourth actual business. The fourth target functional component is the first functional component that the second reference functional component depends on when performing the fourth actual business. The response to the third target functional component includes the first reference functional component, and an unloading operation is performed on the first reference functional component; The response to the third target functional component includes the first reference functional component and the second baseline functional component, and an unloading operation is performed on the third target functional component; In response to the fourth target functional component not being in a working state, control the fourth target functional component to perform an initialization operation so that the fourth target functional component enters and is in a working state; In response to all fourth target functional components being in a working state, a loading operation is performed on the second reference functional component.

[0013] In some embodiments, the method further includes: In response to the difference between the first and second management versions, the reference firmware will be replaced with the target firmware.

[0014] In some embodiments, the method further includes: In response to a status query request sent by a first designated functional component, the first functional component corresponding to the status query request is determined to be a second designated functional component, and the first designated functional component is any one of a plurality of first functional components; In response to the second designated functional component being in an active state, a target tag is sent to the first designated functional component, wherein the target tag is used to indicate that the second designated functional component is in an active state; In response to a function call instruction sent by a first designated functional component, a pointer to a target function is sent to the first designated functional component, so that the first designated functional component calls the target function according to the pointer to the target function. The target function is the function in the function table of the second designated functional component that corresponds to the function call instruction.

[0015] In a second aspect, embodiments of the present invention provide an electronic device, comprising: The controller and reference firmware, wherein the reference firmware includes a first component management module and a plurality of first functional components, and the controller and the plurality of first functional components are all communicatively connected to the first component management module; The controller is configured to execute any of the firmware upgrade methods proposed in the first aspect, or to execute the steps in any of the firmware upgrade methods proposed in the first aspect.

[0016] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing processor-executable computer program instructions. When executed by a processor, the computer program instructions cause the computer to perform any of the firmware upgrade methods proposed in the first aspect, or to perform the steps in any of the firmware upgrade methods proposed in the first aspect.

[0017] The embodiments of the present invention have the following beneficial effects: Unlike related technologies, the firmware upgrade method provided by the embodiments of the present invention is applied to electronic devices, which include reference firmware, a first component management module, and multiple first functional components. The embodiments of the present invention divide the firmware into multiple independent functional components, each of which is compiled into position-independent code, supporting flexible loading and unloading in memory. By comparing the components between the reference firmware and the target firmware, the functional components to be upgraded are automatically identified. Thus, the component management module is used to accurately upgrade the functional components to be upgraded, achieving rapid and flexible upgrades of firmware based on component-based management. This significantly reduces firmware upgrade time, improves firmware upgrade efficiency and flexibility, and ensures business continuity. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or related technologies, the accompanying drawings used in the description of the related technologies or embodiments will be briefly introduced below. Obviously, the drawings described below only show some embodiments of the present invention and should not be considered as limiting the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 These are schematic diagrams illustrating application scenarios of the firmware upgrade method provided in some embodiments of the present invention; Figure 2a These are schematic diagrams of the structure of an electronic device provided in some embodiments of the present invention; Figure 2b These are schematic diagrams of the target firmware in some embodiments of the present invention; Figure 2c This is a schematic diagram of the structure of the controller in an electronic device provided in some embodiments of the present invention; Figure 3 This is a schematic diagram of the overall process of an electronic device performing a firmware upgrade operation in some embodiments of the present invention; Figure 4 This is a flowchart illustrating a firmware upgrade method provided in some embodiments of the present invention; Figure 5 This is an interactive schematic diagram of the uninstallation function component process provided in some embodiments of the present invention; Figure 6 This is an interactive schematic diagram of the uninstallation function component process provided in other embodiments of the present invention; Figure 7 This is an interactive schematic diagram of the loading process of functional components provided in some embodiments of the present invention; Figure 8 This is an interactive schematic diagram of the function call process between functional components provided in some embodiments of the present invention. Detailed Implementation

[0020] To make the objectives and advantages of the embodiments of the present invention more readily understood, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. The detailed description of the embodiments of the present invention in the accompanying drawings is not intended to limit the scope of protection claimed by the present invention, but only to illustrate selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] It should be noted that, unless there is a conflict, the various technical features involved in the embodiments of the present invention described below can be combined with each other, and all are within the protection scope of the present invention. Furthermore, although functional modules are divided in the device or structural schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. In addition, the terms "first," "second," "third," and other similar expressions used herein do not limit the data or execution order, but are only for illustrative purposes and to distinguish identical or similar items with substantially the same function and effect, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features.

[0022] Unless otherwise defined, the technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. It should be understood that the term "and / or" as used herein includes any and all combinations of one or more of the listed items.

[0023] In embedded devices with no operating system or a simple real-time operating system (RTOS), the firmware code is compiled into a single binary file. Upgrading this firmware architecture requires replacing the entire binary file, i.e., downloading and replacing the complete firmware image, and then restarting (or hot-resetting) the device to complete the update. During the upgrade process, the device cannot provide normal service, impacting business continuity, and firmware upgrades are time-consuming.

[0024] The relevant technology chooses differential upgrades to reduce data packet downloads. However, before loading new firmware, the differential upgrade scheme still needs to reassemble the new firmware based on the differential information, and then load the new firmware completely to complete the upgrade. When it is necessary to fix vulnerabilities, add new features, or optimize performance, even if only a small part of the firmware code is modified, a complete new firmware version needs to be generated. The entire firmware image is then rewritten to the device through a specific upgrade process (such as via NVMe commands, OTA, etc.). This results in the unchanged code being repeatedly written to storage, leading to poor flexibility in firmware upgrades and unnecessary wasted erase / write lifespan (especially on flash-based storage devices).

[0025] In view of this, embodiments of the present invention provide a firmware upgrade method, which divides the firmware into multiple independent functional components, each of which is compiled into position-independent code, supporting flexible loading and unloading in memory. By comparing the components between the reference firmware and the target firmware, the method automatically identifies the functional components to be upgraded, thereby using a component management module to accurately upgrade the functional components to be upgraded. This achieves fast and flexible upgrades of firmware based on component-based management, significantly reducing firmware upgrade time, improving firmware upgrade efficiency and flexibility, and ensuring business continuity.

[0026] Please see Figure 1 , Figure 1 The illustration shows a schematic diagram of an application scenario of the firmware upgrade method provided by some embodiments of the present invention.

[0027] See Figure 1As shown, this application scenario includes an electronic device 100 and a host computer 200. The electronic device 100 communicates with the host computer 200 via a network, where examples of networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The host computer 200 includes desktop computers, laptops, servers, smartphones, tablets, and other suitable types of devices or apparatuses. The electronic device 100 includes smart home devices (such as smart speakers, smart door locks, smart cameras, and cleaning robots), portable devices (such as laptops, tablets, smartphones, smartwatches, Bluetooth headsets, and smart bracelets), medical diagnostic devices (such as blood glucose meters, electrocardiogram monitors, and pulse oximeters), communication devices (such as routers and switches), flash memory devices (such as solid-state drives), and other suitable types of devices or apparatuses.

[0028] Please see Figure 2a , Figure 2a The schematic diagram illustrates the structure of an electronic device provided in some embodiments of the present invention.

[0029] See Figure 2a As shown, the electronic device 100 includes a controller 110 and reference firmware 120. The reference firmware 120 includes a first component management module 121 and a plurality of first functional components 122, and the controller 110 and the plurality of first functional components 122 are all communicatively connected to the first component management module 121.

[0030] The first component management module 121 is configured to be controlled by the controller 110 to perform a firmware upgrade operation on the reference firmware 120. The controller 110 is configured to provide computing and control capabilities to execute corresponding business logic and functions, thereby executing the firmware upgrade method provided in this embodiment of the invention.

[0031] The host computer 200 is configured to send target firmware 300 to electronic device 100, and the target firmware 300 is the firmware of electronic device 100 to be upgraded.

[0032] Please see Figure 2bThe target firmware 300 includes a second component management module 310 and multiple second functional components 320, all of which are communicatively connected to the second component management module 310. Understandably, the first functional component 122 and the second functional component 320 are compiled into position-independent code. Position-independent code (PIC) refers to machine code that is compiled and linked and can be loaded into any address in memory and executed correctly (i.e., the execution of position-independent code does not depend on the absolute address in memory; it can execute correctly in any address space in memory) without requiring modification of the code itself. Simply put, position-independent code eliminates its dependence on absolute addresses through a special addressing mode, enabling it to run at any address it is loaded into.

[0033] Understandably, position-independent code is almost indispensable for implementing reliable, flexible, and secure upgrade strategies (especially dual-image and bootloader designs). The main reason is that position-independent code is highly flexible and can "settle anywhere" in memory, making it very suitable for scenarios such as bootloader, dynamic loading, and dual-image upgrades.

[0034] In contrast to position-independent code is position-dependent code (PDC). Position-dependent code is assigned a fixed execution address (link address) during compilation and linking. When position-dependent code is loaded into a location different from the preset address, it cannot run properly because the absolute address reference in the position-dependent code will point to the wrong location.

[0035] For example, after receiving the target firmware 300 sent by the host computer 200, the electronic device 100 parses the target firmware 300, extracts the version of the second component management module 310 (i.e., the second management version) from the target firmware 300, and obtains the version of the first component management module 121 (i.e., the first management version). The first management version is compared with the second management version. When the first management version and the second management version are the same, the first component management module 121 is controlled to determine the candidate functional components (i.e., the functional components to be upgraded) based on the multiple first functional components 122 and the multiple second functional components 320. That is, by comparing the multiple first functional components 122 and the multiple second functional components 320, the functional components that have changed among the multiple first functional components 122 and the multiple second functional components 320 are determined.

[0036] In this embodiment of the invention, after determining the candidate functional components (i.e. the functional components to be upgraded), the first component management module 121 is controlled to perform an upgrade operation on the candidate functional components. In this way, the functional components to be upgraded can be accurately upgraded, and the firmware based on component management can be upgraded quickly and flexibly.

[0037] It should be understood that, Figures 1 to 2b This illustration merely represents one scenario of upgrading the reference firmware of the electronic device 100, and does not limit the structure, type, or quantity of the electronic device 100 or the host computer 200 in other application scenarios or embodiments. For example, in some other application scenarios or embodiments, the electronic device 100 may also include more than Figure 2a The structure shown has more or fewer components, or has the same as Figure 1 The diagram shows different configurations of the structure.

[0038] Please see Figure 2c , Figure 2c The schematic diagram illustrates the structure of a controller in an electronic device provided in some embodiments of the present invention.

[0039] like Figure 2c As shown, the controller 110 includes at least one processor 111 and a memory 112 that are communicatively connected. Figure 2c Taking a bus system 113 and a processor 111 as an example, the various components of the controller 110 are coupled together through the bus system 113, which is used to realize the connection and communication between the various components. It is easy to understand that the bus system 113 may include not only a data bus, but also a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity and brevity, in... Figure 2c The general labels all buses as Bus System 113. Understandably, Figure 2c The structures shown in the embodiments are merely illustrative and do not limit the structure of the controller described above. For example, the controller may also include components that are more... Figure 2c The structure shown has more or fewer components, or has the same as Figure 2c The diagram shows different configurations of the structure.

[0040] The processor 111 is configured to provide computational and control capabilities to support the controller 110 in executing corresponding business logic and functions. For example, it supports the controller 110 in executing any firmware upgrade method provided in the embodiments of the present invention, or in executing the steps of any possible implementation of any firmware upgrade method provided in the embodiments of the present invention. Those skilled in the art will understand that the processor 111 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0041] The memory 112, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, instructions, and modules, such as the programs, instructions, and modules corresponding to the firmware upgrade method in the embodiments of the present invention. In some embodiments, the memory 112 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, and the data storage area may store data created according to the use of the processor 111. The processor 111 executes various functional applications and data processing of the controller 110 by running the non-transitory software programs, instructions, and modules stored in the memory 112 to implement any firmware upgrade method provided in the embodiments of the present invention, or to execute the steps in any possible implementation of any firmware upgrade method provided in the embodiments of the present invention. In some embodiments, the memory 112 may include high-speed random access memory and may also include non-transitory memory. For example, at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 112 may also include memory remotely located relative to the processor 111, and these remotely located memories may be connected to the processor 111 via a communication network. It is understood that examples of the aforementioned communication networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0042] As can be understood from the above, the implementing entity of any firmware upgrade method provided in the embodiments of the present invention can be any suitable type of controller with certain computing and control capabilities, such as the controller 110 of the aforementioned electronic device 100. In some feasible implementations, any firmware upgrade method provided in the embodiments of the present invention can be implemented by a processor executing computer program instructions stored in a memory.

[0043] The firmware upgrade method provided by the embodiments of the present invention will be described in detail below with reference to exemplary applications and implementations of the electronic devices provided in the embodiments of the present invention.

[0044] Please see Figure 3 , Figure 3 The diagram illustrates the overall process of an electronic device performing a firmware upgrade in some embodiments of the present invention.

[0045] Step S401: The electronic device receives the target firmware sent by the host computer via the network.

[0046] Step S402: The electronic device determines whether the target firmware is valid. If it is invalid, proceed to step S403; if it is valid, proceed to step S404.

[0047] Step S403: The electronic device determines that the firmware upgrade has failed.

[0048] Step S404: The electronic device parses the target firmware, obtains the version of the component management module in the target firmware, compares the version of the component management module in the target firmware with the version of the component management module in the reference firmware, and determines whether the versions of the component management modules are the same. If they are different, proceed to step S405; if they are the same, proceed to step S406.

[0049] Step S405: The electronic device replaces the reference firmware with the target firmware and restarts to complete the firmware upgrade.

[0050] Step S406: The electronic device compares the functional components in the target firmware with the functional components in the reference firmware to obtain the functional components to be upgraded: functional components to be deleted, to be updated, and to be added.

[0051] Step S407: The electronic device sequentially uninstalls the functional components to be deleted and updated.

[0052] Step S408: The electronic device updates the function component content using the new function component corresponding to the function component to be updated in the target firmware, that is, updates the function component to be updated in the reference firmware to the new function component corresponding to the function component to be updated in the target firmware.

[0053] Step S409: The electronic device sequentially loads the updated functional components and the functional components to be added.

[0054] Step S410: The electronic device confirms that the firmware upgrade is complete.

[0055] The firmware upgrade method provided in the embodiments of the present invention will be described in detail below.

[0056] Please see Figure 4 , Figure 4 The schematic diagram illustrates a flowchart of a firmware upgrade method provided in some embodiments of the present invention.

[0057] It should be understood that the firmware upgrade method provided in this embodiment of the invention can be applied to the above-mentioned electronic devices (such as electronic device 100). Specifically, the execution subject of the firmware upgrade method is the controller of the electronic device.

[0058] like Figure 4 As shown, the firmware upgrade method includes, but is not limited to, the following steps S41-S43: S41: Receive target firmware.

[0059] In this embodiment, the target firmware includes a second component management module and multiple second functional components, and the first and second functional components are compiled into position-independent code.

[0060] For example, in embodiments of the present invention, the target firmware sent by the host computer is received via a network (e.g., Bluetooth, Wi-Fi network, etc.).

[0061] S42: In response to the fact that the first management version and the second management version are the same, the first component management module is controlled to determine the candidate functional components based on multiple first functional components and multiple second functional components.

[0062] In this embodiment, the first management version is the version of the first component management module, and the second management version is the version of the second component management module. Candidate functional components are functional components to be upgraded, including functional components to be deleted, functional components to be added, and functional components to be updated. It is easy to understand that the functional components to be updated can be upgraded or downgraded.

[0063] For example, after receiving the target firmware, this embodiment of the invention parses the target firmware, obtains the version of the second component management module in the target firmware as the second management version, compares the first management version with the second management version, and when the first management version and the second management version are consistent, controls the first component management module to determine candidate functional components based on multiple first functional components and multiple second functional components. That is, the first component management module compares each first functional component in the reference firmware with each second functional component in the target firmware to determine the functional components that have changed among the multiple first functional components and multiple second functional components. The functional components that have changed are the functional components to be upgraded (i.e., candidate functional components).

[0064] In one embodiment, the control first component management module determines candidate functional components based on a plurality of first functional components and a plurality of second functional components, specifically including but not limited to the following steps S421-S423: S421: The first component management module responds that the first reference identifier is different from any of the multiple second identifiers, and determines the first reference functional component as a candidate functional component of the first type.

[0065] In this embodiment, the first functional component has a first identifier and a first functional version, and the second functional component has a second identifier and a second functional version. The first reference identifier is the first identifier of the first reference functional component, and the first reference functional component is any one of a plurality of first functional components. The first type is used to indicate that the candidate functional component is a functional component to be deleted; that is, when the upgrade type of the candidate functional component is the first type, it indicates that the candidate functional component is a functional component to be deleted.

[0066] For example, when the first component management module compares the first functional component with the second functional component, if the first reference identifier (i.e., the first identifier of the first reference functional component) is different from any of the multiple second identifiers, it indicates that there is no second functional component corresponding to the first reference functional component in the target firmware, that is, the first reference functional component is a functional component to be deleted, and the upgrade type of the first reference functional component is assigned to the first type. In this way, the first reference functional component is a candidate functional component of the first type.

[0067] S422: The first component management module responds that the second reference identifier is different from any of the multiple first identifiers, and determines the second reference functional component as a candidate functional component of the second type.

[0068] In this embodiment, the second reference identifier is the second identifier of the second reference functional component, which is any one of a plurality of second functional components. The second type is used to characterize that the candidate functional component is a functional component to be added; that is, when the upgrade type of the candidate functional component is the second type, it indicates that the candidate functional component is a functional component to be added.

[0069] For example, when the first component management module compares the first functional component with the second functional component, if the second reference identifier (i.e. the second identifier of the second reference functional component) is different from any of the multiple first identifiers, it indicates that there is no first functional component corresponding to the second reference functional component in the reference firmware. That is, the second reference functional component is a functional component to be added. The upgrade type of the second reference functional component is assigned to the second type. Thus, the second reference functional component is a candidate functional component of the second type.

[0070] S423: The first component management module responds that the first reference identifier and the second reference identifier are the same, and the first reference function version and the second reference function version are different, and determines the first reference function component and the second reference function component as candidate function components of the third type.

[0071] In this step, the first reference function version is the first function version of the first reference function component, and the second reference function version is the second function version of the second reference function component. The third type is used to characterize a candidate function component as a function component to be updated.

[0072] For example, when the first component management module compares the first functional component and the second functional component, if the first reference identifier (i.e., the first identifier of the first reference functional component) and the second reference identifier (i.e., the second identifier of the second reference functional component) are the same, and the first reference functional version (i.e., the first functional version of the first reference functional component) and the second reference functional version (i.e., the second functional version of the second reference functional component) are different, it indicates that there are two functional components with the same component identifier in both the target firmware and the reference firmware, but the versions of the two functional components are different. The first reference functional component in the reference firmware needs to be updated to the second reference functional component in the target firmware. That is, the first reference functional component and the second reference functional component are functional components to be updated. The upgrade type of the first reference functional component and the second reference functional component is assigned to the third type. In this way, the first reference functional component and the second reference functional component are candidate functional components of the first type.

[0073] S43: Control the first component management module to perform upgrade operations on candidate functional components.

[0074] For example, after determining the candidate functional components (i.e. the functional components to be upgraded), the embodiments of the present invention control the first component management module to perform upgrade operations on the candidate functional components. For example, the first component management module is controlled to perform an uninstallation operation on the functional components to be deleted, thereby uninstalling the functional components to be deleted. Or, the first component management module is controlled to perform a loading operation on the functional components to be added, thereby loading the functional components to be added. In this way, the functional components to be upgraded can be accurately upgraded, and firmware upgrades can be completed quickly and flexibly.

[0075] For example, in some embodiments, the control of the first component management module to perform an upgrade operation on the candidate functional component includes, but is not limited to, the following steps S431-S433: S431: The first component management module responds to the upgrade type marker of the candidate functional component by setting it to the marker corresponding to the first type, and performs an uninstallation operation on the candidate functional component.

[0076] In this embodiment, the candidate functional component has an upgrade type marker, which includes a first marker, a second marker, and a third marker. The first marker corresponds to a first type, the second marker corresponds to a second type, and the third marker corresponds to a third type. Understandably, when the upgrade type of the candidate functional component is the first type, its upgrade type marker is the first marker; when the upgrade type of the candidate functional component is the second type, its upgrade type marker is the second marker; and when the upgrade type of the candidate functional component is the third type, its upgrade type marker is the third marker.

[0077] For example, the first component management module obtains the upgrade type tag of the candidate functional component. When the upgrade type tag of the candidate functional component is the first tag (i.e. the tag corresponding to the first type), it indicates that the candidate functional component is a functional component to be deleted. Then the first component management module performs an uninstallation operation on the candidate functional component to uninstall the candidate functional component.

[0078] In some embodiments, the first component management module responds to the upgrade type marker of the candidate functional component being the marker corresponding to the first type, and performs an uninstallation operation on the candidate functional component, specifically including but not limited to the following steps S4311-S4313: S4311: Determine the first target functional component based on the first dependency relationship when the first functional component performs the first actual business.

[0079] In this embodiment, the first target functional component is a functional component to be uninstalled. The first target functional component includes candidate functional components, or the first target functional component includes candidate functional components and a first benchmark functional component. The first benchmark functional component is a first functional component that depends on the candidate functional components when executing the first actual business.

[0080] Understandably, dependency relationships include active dependency and passive dependency. Active dependency means that a certain functional component needs to rely on other functional components to provide services, while passive dependency means that a certain functional component is depended on by other functional components, that is, other functional components need to rely on this functional component to provide services.

[0081] Before uninstalling candidate functional components, it is necessary to determine whether the candidate functional components are depended upon by other functional components. Based on the first dependency relationships when the first functional component executes the first actual service, it is determined whether there is a first functional component (i.e., a first baseline functional component) in the reference firmware that depends on the candidate functional components. Understandably, different first functional components may execute the same or different first actual services; therefore, the first dependency relationships when the first functional components execute the first actual service may be the same or different. Clearly, the first dependency relationship is an active dependency relationship, which characterizes the functional components that the first functional component depends on when executing the first actual service.

[0082] When it is determined that a first benchmark functional component exists in the reference firmware, the candidate functional component and the first benchmark functional component are used as the first target functional component. When it is determined that a first benchmark functional component does not exist in the reference firmware, the candidate functional component is used as the first target functional component.

[0083] It is easy to understand that since the first reference functional component depends on the candidate functional component, the first reference functional component cannot provide services normally after the candidate functional component is uninstalled. Therefore, when the first reference functional component exists in the reference firmware, the first reference functional component needs to be uninstalled simultaneously. When the first reference functional component does not exist in the reference firmware, only the candidate functional component needs to be uninstalled.

[0084] It should be understood that the actual business executed by a functional component determines its dependencies. In practical applications, when each functional component executes different actual business, the first component management module can obtain the dependencies of that functional component when executing different actual business. For example, in some embodiments, the reference firmware includes functional component R, functional component S, functional component T, and functional component U. Functional components S, T, and U all depend on functional component R when executing the first actual business, and functional component U also depends on functional component T when executing the first actual business. The first dependencies of each functional component in the reference firmware when executing the first actual business are shown in Table 1 below: Table 1:

[0085] In this embodiment, according to Table 1, when functional component T is a candidate functional component, functional component T is dependent on functional component U (i.e., functional component U depends on functional component T when performing the first actual service). Therefore, functional component T and functional component U need to be unloaded simultaneously. In this case, the first target functional component includes the candidate functional component (i.e., functional component T) and the first baseline functional component (i.e., functional component U, which depends on functional component T when performing the first actual service). When functional component S is a candidate functional component, functional component S is not dependent on any other functional component. Therefore, only functional component S needs to be unloaded. In this case, the first target functional component includes the candidate functional component (i.e., functional component S).

[0086] S4312: In response to the first target functional component including candidate functional components, perform an unloading operation on the candidate functional components.

[0087] For example, when the first target functional component includes a candidate functional component, that is, only the candidate functional component needs to be uninstalled, the first component management module performs an uninstallation operation on the candidate functional component to uninstall the candidate functional component.

[0088] In some embodiments, the response to the first target functional component includes a candidate functional component, and an unloading operation is performed on the candidate functional component, specifically including but not limited to the following step S43121: S43121: In response to the candidate functional component being offline, control the candidate functional component to execute the unload function and release the first memory.

[0089] In this embodiment, the first memory is the memory occupied by the candidate functional components.

[0090] Please see Figure 5 , Figure 5 Taking functional component A as an example, the uninstallation process of a functional component is explained. The first component management module (i.e....) Figure 5The component management module receives a request from the controller to uninstall a functional component. Responding to the request, it sends an uninstallation instruction to functional component A. Upon receiving the uninstallation instruction, functional component A marks itself as pending offline and publishes this status change to the component management module, notifying it of its pending offline state. Once the reference count of functional component A reaches zero (meaning it is no longer referenced by other functional components), it switches its state to offline and publishes this status change to the component management module, notifying it of its offline state. After functional component A becomes offline, the component management module controls it to execute an uninstallation function (e.g., the `unload` function), releasing the occupied memory, cleaning up memory resources, and successfully uninstalling functional component A. After successfully uninstalling functional component A, the component management module sends a successful uninstallation message to the controller, notifying it that functional component A has been successfully uninstalled.

[0091] S4313: In response to the first target functional component including the candidate functional component and the first baseline functional component, perform an unloading operation on the first target functional component.

[0092] In some embodiments, when the first target functional component includes a candidate functional component and a first benchmark functional component, the candidate functional component and the first benchmark functional component need to be uninstalled simultaneously. The first component management module performs an uninstallation operation on the first target functional component. That is, it first performs an uninstallation operation on the first benchmark functional component to uninstall the first benchmark functional component, and then performs an uninstallation operation on the candidate functional component to uninstall the candidate functional component.

[0093] In some embodiments, in response to the first target functional component including a candidate functional component and a first baseline functional component, an unloading operation is performed on the first target functional component, specifically including but not limited to the following steps S43131-S43132: S43131: In response to the first reference function component being offline, control the first reference function component to execute the unload function and release the second memory.

[0094] S43132: In response to a candidate functional component being offline, control the candidate functional component to execute the unload function and release third-party memory.

[0095] In this embodiment, the second memory is the memory occupied by the first baseline functional component, and the third memory is the memory occupied by the candidate functional component.

[0096] Please see Figure 6 , Figure 6 Taking candidate functional components, including functional component A and functional component B, as an example, the process of uninstalling functional components is explained. The first component management module (i.e....) Figure 6The component management module receives a request from the controller to uninstall a functional component. Responding to the request, it sends an uninstallation command to functional component A. Upon receiving the uninstallation command, functional component A marks itself as pending offline and publishes this status change to the component management module. The component management module then notifies functional component B that its dependent component A has changed its status to pending offline. Knowing that functional component A is about to go offline, and since it depends on functional component A, functional component B also needs to uninstall synchronously, switching its own status to pending offline.

[0097] After functional component B switches to a pending offline state, it no longer references / depends on functional component A. The reference count of functional component A is decremented by 1, and functional component A sends a message to functional component B indicating that its reference count has been successfully decremented. When functional component B is not referenced by any other functional component and its reference count is 0, functional component B switches its own state to offline and publishes the state change to the component management module, notifying the module that it is offline. After functional component B is offline, the component management module controls functional component B to execute its unloading function (such as the `unload` function), releasing the occupied memory, cleaning up memory resources, and ultimately successfully unloading functional component B.

[0098] After the reference count reaches 0, meaning that functional component A is no longer referenced (i.e., depends on) by other functional components, functional component A switches its state to offline and publishes this state change to the component management module, notifying it that it is offline. Once functional component A is offline, the component management module controls it to execute an unloading function (e.g., the `unload` function), releasing the memory it occupies and cleaning up memory resources, ultimately successfully unloading functional component A. After successfully unloading functional components A and B, the component management module sends a successful unloading message to the controller, notifying it that functional components A and B have been successfully unloaded.

[0099] S432: The first component management module responds by setting the upgrade type marker of the candidate functional component to the marker corresponding to the second type, and performs a loading operation on the candidate functional component.

[0100] Specifically, when the upgrade type of a candidate functional component is marked as the second mark (i.e. the mark corresponding to the second type), it indicates that the candidate functional component is a functional component to be added. The first component management module performs a loading operation on the candidate functional component and loads the candidate functional component.

[0101] In some embodiments, the first component management module responds to the upgrade type marker of the candidate functional component being marked as the marker corresponding to the second type, and performs a loading operation on the candidate functional component, specifically including but not limited to the following steps S4321-S4323: S4321: Determine the second target functional component based on the second dependency relationship when the candidate functional component performs the second actual business.

[0102] In this embodiment, the second target functional component is the first functional component that the candidate functional component depends on when performing the second actual business.

[0103] Before loading candidate functional components, it is necessary to determine whether they depend on other functional components. This requires determining whether the candidate functional component depends on other first functional components in the reference firmware based on the second dependency relationships when executing the second actual service. Understandably, different candidate functional components may execute the same or different second actual services; therefore, their second dependency relationships may be the same or different. Clearly, the second dependency relationship is an active dependency relationship, representing the functional components that the candidate functional component depends on when executing the second actual service.

[0104] When a candidate functional component depends on other first functional components in the reference firmware, the first functional component that the candidate functional component depends on is determined as the second target functional component. Understandably, when a candidate functional component does not depend on other first functional components in the reference firmware, a loading operation can be directly performed on the candidate functional component.

[0105] It is easy to understand that since the candidate functional component depends on the second target functional component, when loading the candidate functional component, the second target functional component needs to be loaded first, and then the candidate functional component is loaded, so that after the candidate functional component is loaded, the candidate functional component is in a working state and can provide services normally.

[0106] For example, please refer to Table 1. When functional component T is a candidate functional component, according to Table 1, in the second dependency relationship, functional component T depends on functional component R and functional component S. That is, functional component R and functional component S are the second target functional components. Therefore, functional component R and functional component S are loaded first, and functional component T is loaded later.

[0107] S4322: In response to the second target functional component not being in a working state, control the second target functional component to perform an initialization operation so that the second target functional component enters and is in a working state.

[0108] S4323: In response to all second target functional components being in a working state, perform a loading operation on the candidate functional components.

[0109] Please see Figure 7 , Figure 7 Taking functional component A as a candidate functional component and functional component B as the second target functional component as an example, the loading process of functional components is explained. The first component management module (i.e....) Figure 7 The component management module (in the module) receives a request from the controller to load a functional component. In response, it performs component initialization operations, namely verifying the legitimacy of functional component A, allocating memory resources for functional component A, and setting the state of functional component A to offline. Functional component A registers a component state listener, waiting for its dependent functional component (functional component B in this embodiment) to be in a working state. The component management module sends a registration success message to functional component A, notifying it that the component state listener has been successfully registered.

[0110] Functional component A performs operations that reference a dependent functional component that is already in a working state. Specifically, it listens to the component management module through a registered component state listener to check whether its dependent functional component (functional component B in this example) is in a working state. After functional component B becomes working, the component management module notifies functional component A that its dependent functional component B is now working. Functional component A then references its dependent functional component B, incrementing the reference count of functional component B by 1. Functional component B sends a reference success message to functional component A, notifying it that it has successfully referenced functional component B.

[0111] When functional component B is not in a working state, the component management module controls the second target functional component (i.e., functional component B) to perform an initialization operation, so that functional component B enters and becomes working. After functional component B completes initialization, it updates its own state to working state and publishes a state change event to the component management module, notifying the component management module that it is in a working state. The component management module notifies functional component A, which is listening, that a component state has changed. Functional component A obtains the corresponding component information, and the component management module sends the component information to functional component A. Functional component A determines whether it depends on the corresponding functional component based on the component information, that is, whether the functional component whose component state has changed is functional component B, which it depends on, and whether functional component B is in a working state. If so, functional component A references the dependent functional component B, causing functional component B's reference count to increment by 1. Functional component B sends a reference success message to functional component A, notifying functional component A that it has successfully referenced functional component B.

[0112] After all the second target functional components are in working order, the first component management module performs a loading operation on the candidate functional components to load them.

[0113] In some embodiments, in response to all second target functional components being in a working state, a loading operation is performed on the candidate functional components, specifically including but not limited to the following steps S43231-S43232: S43231: Allocate fourth memory for candidate functional components.

[0114] S43232: In response to a candidate functional component successfully referencing all second target functional components, control the candidate functional component to execute the loading function to configure the function table in the fourth memory.

[0115] Please continue reading. Figure 7 In this embodiment, the first component management module (i.e. Figure 7 The component management module allocates fourth memory for the candidate functional component (i.e., functional component A). After functional component A successfully references all the second target functional components (functional component B in this embodiment), the component management module controls functional component A to execute a loading function (e.g., the init function), causing functional component A to configure an export function table / function table in the fourth memory. Functional component A performs an initialization operation, entering and entering a working state. After functional component A completes initialization, it updates its own state to the working state and notifies the component management module that it is in the working state. Subsequently, the component management module records the state of functional component A as the working state, publishes a component state change event, and notifies the functional components that are listening that there has been a component state change. Finally, the component management module sends a loading success message to the controller, notifying the controller that functional component A has been successfully loaded.

[0116] In this embodiment of the invention, the "pending offline" state refers to a functional component that will no longer provide new services to the outside world, and will actively switch to the offline state after the services currently being provided to the outside world have ended. The offline state is marked as such when a functional component no longer provides services to other functional components. The working state is marked as such when a functional component can safely and normally provide services to other functional components.

[0117] It should be understood that functional components, based on their own business logic, monitor the status of other functional components in real time and automatically determine whether they can provide services normally and securely, proactively switching their state accordingly. Each time a state change occurs, the functional component publishes a state change event to the first component management module. Other functional components then monitor these events to capture the state changes of the functional component in real time.

[0118] S433: The first component management module responds to the upgrade type marker of the candidate functional component by setting it to the marker corresponding to the third type, and performs the target operation on the candidate functional component.

[0119] In this embodiment, the target operations include unloading and loading operations.

[0120] For example, when the upgrade type of the candidate functional component is marked as the third mark (i.e. the mark corresponding to the third type), it indicates that the candidate functional component is a functional component to be updated. At this time, the candidate functional component includes the first reference functional component and the second reference functional component. The first component management module performs the target operation on the first reference functional component and the second reference functional component, that is, first uninstalls the first reference functional component in the reference firmware, and then loads the second reference functional component in the target firmware.

[0121] In some embodiments, the first component management module responds to the upgrade type marker of the candidate functional component being the marker corresponding to the third type, and performs a target operation on the candidate functional component, specifically including but not limited to the following steps S4331-S4336: S4331: Determine the third target functional component based on the third dependency relationship when the first functional component performs the third actual business.

[0122] In this step, the candidate functional components include a first reference functional component and a second reference functional component.

[0123] In this embodiment, the third target functional component is the functional component to be uninstalled. The third target functional component includes a first reference functional component, or the third target functional component includes a first reference functional component and a second baseline functional component. The second baseline functional component is a first functional component that depends on the first reference functional component when executing the third actual service.

[0124] For example, before uninstalling the first reference functional component, it is necessary to determine whether the first reference functional component is depended upon by other functional components. Based on the third dependency relationship when the first functional component performs the third actual service, it is determined whether there is a first functional component (i.e., a second baseline functional component) in the reference firmware that depends on the first reference functional component. It is understood that the third actual services performed by different first functional components may be the same or different; therefore, the third dependency relationship when the first functional component performs the third actual service may be the same or different. Clearly, the third dependency relationship is an active dependency relationship, representing the functional component that the first functional component depends on when performing the third actual service.

[0125] When it is determined that a second reference functional component exists in the reference firmware, the first reference functional component and the second reference functional component are used as the third target functional component. When it is determined that a second reference functional component does not exist in the reference firmware, the first reference functional component is used as the third target functional component.

[0126] S4332: Determine the fourth target functional component based on the fourth dependency relationship when the second reference functional component performs the fourth actual business.

[0127] The fourth target functional component is the first functional component that the second reference functional component depends on when performing the fourth actual business.

[0128] For example, before loading the second reference functional component, it is necessary to determine whether the second reference functional component depends on other functional components. Based on the fourth dependency relationship when the second reference functional component performs the fourth actual service, it is determined whether the second reference functional component depends on the first functional component in the reference firmware. Understandably, different second reference functional components may perform the same or different fourth actual services; therefore, the fourth dependency relationship when the second reference functional component performs the fourth actual service may be the same or different. Clearly, the fourth dependency relationship is an active dependency relationship, representing the functional components that the second reference functional component depends on when performing the fourth actual service.

[0129] When the second reference functional component depends on the first functional component in the reference firmware, the first functional component that the second reference functional component depends on is identified as the fourth target functional component. It is understood that when the second reference functional component does not depend on the first functional component in the reference firmware, a loading operation can be performed directly on the second reference functional component.

[0130] S4333: In response to the third target functional component including the first reference functional component, perform an unloading operation on the first reference functional component.

[0131] It is understood that the execution process of step S4333 is the same as the specific execution process of the aforementioned step S4312 and its detailed steps. For details, please refer to the aforementioned step S4312 and its detailed steps, which will not be repeated here.

[0132] S4334: In response to the third target functional component including the first reference functional component and the second baseline functional component, perform an unloading operation on the third target functional component.

[0133] It is understood that the execution process of step S4334 is the same as the specific execution process of the aforementioned step S4313 and its detailed steps. For details, please refer to the aforementioned step S4313 and its detailed steps, which will not be repeated here.

[0134] S4335: In response to the fourth target functional component not being in a working state, control the fourth target functional component to perform an initialization operation so that the fourth target functional component enters and is in a working state.

[0135] S4336: In response to all fourth target functional components being in a working state, perform a loading operation on the second reference functional component.

[0136] It is understood that the execution process of steps S4335 and S4336 is the same as the specific execution process of the detailed steps of steps S4322, S4323 and S4323 mentioned above. For details, please refer to the detailed steps of steps S4322, S4323 and S4323 mentioned above, which will not be repeated here.

[0137] It should be understood that after the firmware upgrade is completed, the functional components to be deleted and the functional components to be updated in the reference firmware are uninstalled from the electronic device, the functional components to be added in the target firmware and the new functional components corresponding to the functional components to be updated are loaded into the electronic device, the original functional components in the reference firmware (i.e. the functional components that have not been uninstalled) and the functional components loaded into the target firmware in the electronic device run normally in the electronic device, and the firmware upgrade of the electronic device is successful.

[0138] In some embodiments, the firmware upgrade method further includes, but is not limited to, the following step S44: S44: In response to the difference between the first and second management versions, replace the reference firmware with the target firmware.

[0139] Specifically, in this embodiment of the invention, the first management version is compared with the second management version. When the first management version is different from the second management version, the reference firmware is replaced with the target firmware, that is, the reference firmware is replaced with the target firmware, and the device is restarted to complete the firmware upgrade.

[0140] In some embodiments, the firmware upgrade method further includes, but is not limited to, the following steps S45-S47: S45: In response to the status query request sent by the first designated functional component, determine that the first functional component corresponding to the status query request is the second designated functional component.

[0141] S46: In response to the second designated functional component being in an active state, send the target tag to the first designated functional component.

[0142] S47: In response to a function call instruction sent by the first designated functional component, a pointer to the target function is sent to the first designated functional component, so that the first designated functional component calls the target function according to the pointer to the target function.

[0143] In this embodiment, the first designated functional component is any one of a plurality of first functional components. The target marker is used to indicate that the second designated functional component is in a working state. It should be understood that the target function is the function corresponding to the function call instruction in the function table of the second designated functional component.

[0144] Please see Figure 8 , Figure 8The following example illustrates the function call process between functional components, using functional component A calling a function of functional component B. First, the first designated functional component (functional component A in this example) sends a status query request to the first component management module (i.e.,...). Figure 8 The component management module queries the status of the second designated functional component (functional component B in this embodiment). The component management module responds to the status query request sent by functional component A and determines functional component B corresponding to the status query request as the second designated functional component. After determining that functional component B is in a working state, the component management module sends a target flag to functional component A to notify functional component A that functional component B is in a working state. Functional component A obtains the exported function func_B_1 (i.e., the target function) of functional component B from the component management module, that is, it sends a function call instruction to the component management module. The component management module responds to the function call instruction sent by functional component A and sends the pointer func_B_1(1) of the exported function func_B_1 to functional component A, so that functional component A calls the exported function func_B_1 according to the pointer func_B_1(1), that is, functional component A initiates a function call to functional component B to call the exported function func_B_1. The index count of functional component B is incremented by 1, for example, from 1 to 2. Then, functional component B executes the exported function func_B_1. After functional component B executes the exported function func_B_1, the index count of functional component B is decremented by 1, for example, from 2 to 1. Functional component B then sends the data obtained from executing the exported function to functional component A. In this way, functional component A calls the function of functional component B.

[0145] In summary, the firmware upgrade method provided by this invention divides the firmware into multiple independent functional components. Each functional component is compiled into position-independent code, which supports flexible loading and unloading in memory. By comparing the components between the reference firmware and the target firmware, the functional components to be upgraded are automatically identified. Thus, the component management module is used to accurately upgrade the functional components to be upgraded, achieving fast and flexible upgrades of firmware based on component management. This significantly reduces firmware upgrade time, improves firmware upgrade efficiency and flexibility, and ensures business continuity.

[0146] This invention provides a computer-readable storage medium storing processor-executable computer program instructions. When executed by a processor, the computer program instructions cause a computer to perform any firmware upgrade method provided in this invention, or to perform steps in any possible implementation of any firmware upgrade method provided in this invention.

[0147] Those skilled in the art will understand that the embodiments provided by this invention are merely illustrative. The order in which the steps in the methods of the embodiments are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The order can be adjusted, merged, and deleted according to actual needs. Modules or sub-modules, units or sub-units in the apparatus or system of the embodiments can be merged, divided, and deleted according to actual needs. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For another example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0148] Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, and of course, it can also be implemented using hardware. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. It should be understood that the storage medium can be flash memory, hard disk, optical disk, register, magnetic surface memory, removable disk, CD-ROM, random access memory (RAM), read-only memory (ROM), electrically programmable ROM, and electrically erasable programmable ROM, etc.

[0149] It should be noted that the above embodiments are for illustrating the technical concept and features of the present invention, and are intended to enable those skilled in the art to understand the content of the present invention and implement it accordingly. They should not be construed as limiting the scope of protection of the present invention. Those skilled in the art can understand that all or part of the processes of the above embodiments can be implemented by modifying the technical solutions described in the embodiments of the present invention, or by making equivalent substitutions for some of the technical features. It is understood that these 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 the present invention, and should be considered as equivalent changes and modifications made based on the embodiments of the present invention, all of which should fall within the scope of the claims of the present invention.

Claims

1. A firmware upgrading method applied to an electronic device, characterized in that, The electronic device includes reference firmware, which includes a first component management module and multiple first functional components. The firmware upgrade method includes: Receive target firmware, the target firmware including a second component management module and a plurality of second functional components, wherein the first functional component and the second functional components are compiled into position-independent code; If the first management version and the second management version are the same, the first component management module is controlled to determine candidate functional components based on multiple first functional components and multiple second functional components. The first management version is the version of the first component management module, the second management version is the version of the second component management module, and the candidate functional components are functional components to be upgraded. The first component management module is controlled to perform an upgrade operation on the candidate functional components.

2. The method of claim 1, wherein, The first functional component has a first identifier and a first functional version, and the second functional component has a second identifier and a second functional version. The control module for the first component management determines candidate functional components based on multiple first functional components and multiple second functional components, including: The first component management module responds when the first reference identifier is different from any of the multiple second identifiers, and determines the first reference functional component as a candidate functional component of the first type. The first reference identifier is the first identifier of the first reference functional component, the first reference functional component is any of the multiple first functional components, and the first type is used to characterize the candidate functional component as a functional component to be deleted. The first component management module responds to the second reference identifier being different from any of the multiple first identifiers, and determines the second reference functional component as a candidate functional component of the second type. The second reference identifier is the second identifier of the second reference functional component, the second reference functional component is any of the multiple second functional components, and the second type is used to characterize the candidate functional component as a functional component to be added. The first component management module responds to the first reference identifier being the same as the second reference identifier and the first reference function version being different from the second reference function version, and determines the first reference function component and the second reference function component as candidate function components of the third type, wherein the first reference function version is the first function version of the first reference function component, the second reference function version is the second function version of the second reference function component, and the third type is used to characterize the candidate function component as a function component to be updated.

3. The method of claim 2, wherein, The candidate functional component has an upgrade type marker, and controlling the first component management module to perform an upgrade operation on the candidate functional component includes: The first component management module responds by marking the upgrade type of the candidate functional component as the marker corresponding to the first type, and then performs an uninstallation operation on the candidate functional component; The first component management module responds by setting the upgrade type of the candidate functional component to the tag corresponding to the second type, and then performs a loading operation on the candidate functional component; The first component management module responds to the upgrade type of the candidate functional component by marking it with the tag corresponding to the third type, and performs a target operation on the candidate functional component, the target operation including the uninstallation operation and the loading operation.

4. The method according to claim 3, characterized in that, The first component management module responds to the upgrade type marker of the candidate functional component being set to the marker corresponding to the first type, and performs an uninstallation operation on the candidate functional component, including: A first target functional component is determined based on the first dependency relationship when the first functional component performs the first actual business. The first target functional component is a functional component to be uninstalled. The first target functional component includes the candidate functional component. Alternatively, the first target functional component includes the candidate functional component and a first benchmark functional component. The first benchmark functional component is a first functional component that depends on the candidate functional component when performing the first actual business. In response to the first target functional component including the candidate functional component, an unloading operation is performed on the candidate functional component; In response to the first target functional component including the candidate functional component and the first baseline functional component, an unloading operation is performed on the first target functional component.

5. The method according to claim 4, characterized in that, The response to the first target functional component includes the candidate functional component, and the unloading operation is performed on the candidate functional component, including: In response to the candidate functional component being offline, the candidate functional component is controlled to execute an unload function and release the first memory, which is the memory occupied by the candidate functional component.

6. The method according to claim 4, characterized in that, The response to the first target functional component includes the candidate functional component and the first baseline functional component, and the unloading operation is performed on the first target functional component, including: In response to the first benchmark function component being offline, the first benchmark function component is controlled to execute an unload function and release the second memory, which is the memory occupied by the first benchmark function component; In response to the candidate functional component being in the offline state, the candidate functional component is controlled to execute an unload function and release third memory, which is the memory occupied by the candidate functional component.

7. The method according to claim 3, characterized in that, The first component management module responds to the upgrade type flag of the candidate functional component being set to the flag corresponding to the second type, and performs a loading operation on the candidate functional component, including: A second target functional component is determined based on the second dependency relationship when the candidate functional component performs the second actual business. The second target functional component is the first functional component that the candidate functional component depends on when performing the second actual business. In response to the second target functional component not being in a working state, control the second target functional component to perform an initialization operation so that the second target functional component enters and is in the working state; In response to all the second target functional components being in the working state, a loading operation is performed on the candidate functional components.

8. The method according to claim 7, characterized in that, The response that all the second target functional components are in a working state, and the loading operation performed on the candidate functional components, includes: Allocate a fourth memory for the candidate functional components; In response to the candidate functional component successfully referencing all the second target functional components, the candidate functional component is controlled to execute a loading function to configure the function in the fourth memory table.

9. The method according to claim 3, characterized in that, The candidate functional component includes a first reference functional component and a second reference functional component. The first component management module responds to the upgrade type flag of the candidate functional component being set to the flag corresponding to the third type, and performs a target operation on the candidate functional component, including: A third target functional component is determined based on the third dependency relationship when the first functional component performs the third actual business. The third target functional component is a functional component to be uninstalled. The third target functional component includes the first reference functional component. Alternatively, the third target functional component includes the first reference functional component and a second baseline functional component. The second baseline functional component is a first functional component that depends on the first reference functional component when performing the third actual business. The fourth target functional component is determined based on the fourth dependency relationship when the second reference functional component performs the fourth actual service. The fourth target functional component is the first functional component that the second reference functional component depends on when performing the fourth actual service. In response to the third target functional component including the first reference functional component, an unloading operation is performed on the first reference functional component; In response to the third target functional component including the first reference functional component and the second baseline functional component, an unloading operation is performed on the third target functional component; In response to the fourth target functional component not being in a working state, control the fourth target functional component to perform an initialization operation so that the fourth target functional component enters and is in a working state; In response to all the fourth target functional components being in a working state, a loading operation is performed on the second reference functional component.

10. The method according to any one of claims 1-9, characterized in that, The method further includes: In response to the difference between the first management version and the second management version, the reference firmware is replaced with the target firmware.

11. The method according to any one of claims 1-9, characterized in that, The method further includes: In response to a status query request sent by a first designated functional component, the first functional component corresponding to the status query request is determined to be a second designated functional component, wherein the first designated functional component is any one of a plurality of first functional components; In response to the second designated functional component being in a working state, a target tag is sent to the first designated functional component, wherein the target tag is used to characterize the second designated functional component being in the working state; In response to a function call instruction sent by the first designated functional component, a pointer to a target function is sent to the first designated functional component, so that the first designated functional component calls the target function according to the pointer to the target function, wherein the target function is a function in the function table of the second designated functional component that corresponds to the function call instruction.

12. An electronic device, characterized in that, include: The controller and reference firmware, wherein the reference firmware includes a first component management module and a plurality of first functional components, and the controller and the plurality of first functional components are all communicatively connected to the first component management module; The controller is configured to perform the firmware upgrade method as described in any one of claims 1-11.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores processor-executable computer program instructions, which, when executed by the processor, cause the computer to perform the firmware upgrade method as described in any one of claims 1-11.

Images