Equipment firmware update effective method and device, storage medium and electronic equipment

Abstract

The embodiment of the invention discloses an equipment firmware update effective method and device, a storage medium and electronic equipment, relates to the technical field of firmware update, and aims at avoiding the limitation of a'one-cut 'restart mode so as to improve the firmware version effective flexibility and real-time performance. The method comprises the following steps: acquiring version information of current version firmware and target version firmware, wherein the version information carries at least two types of update effective operation identifiers; performing consistency comparison on the update effective operation identification of the corresponding type in the version information of the current version firmware and the target version firmware; according to a comparison result, determining whether to execute an update effective operation indicated by the corresponding update effective operation identifier; the comparison result is used for indicating whether the firmware update effective operation identifier is changed or not. The method and the device are suitable for equipment firmware update effective scenes.

Description

Technical Field

[0001] The present invention relates to the field of firmware update technology, and in particular to a device firmware update validation method, apparatus, storage medium, and electronic device. Background Art

[0002] In modern chip systems, firmware updates are an important means of improving system performance, fixing problems, and adding new features. Firmware updates are mainly divided into two parts: upgrade and implementation. Traditional firmware update methods generally require a system restart (commonly known as a "one-size-fits-all") after loading a new firmware version for the new firmware version to take effect. Figure 1 This is a firmware upgrade validation flow chart provided in the prior art. Figure 1 Such indiscriminate restart will cause service interruption, affecting user experience or system operation. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a device firmware update validation method, apparatus, storage medium, and electronic device to avoid the limitations of a "one-size-fits-all" restart method, thereby improving the flexibility and real-time effectiveness of firmware versions.

[0004] In a first aspect, an embodiment of the present invention provides a device firmware update validation method, comprising: obtaining version information of a current version of firmware and a target version of firmware, wherein the version information carries at least two types of update validation operation identifiers; performing a consistency comparison on the corresponding types of update validation operation identifiers in the version information of the current version of firmware and the target version of firmware; and executing an update validation operation indicated by the update validation operation identifier based on the comparison result; the comparison result is used to indicate whether the firmware update validation operation identifier has changed.

[0005] According to one embodiment of the present invention, the update validation operation identifier includes: a system restart identifier, a hardware reset identifier, and a run identifier; and the update validation operation indicated by the update validation operation identifier is executed based on the comparison result, including: if the comparison result indicates that the system restart identifier in the firmware update validation operation identifier has changed, then executing a system restart to validate the target firmware update; if the comparison result indicates that the hardware reset identifier in the firmware update validation operation identifier has changed, then executing a device hardware reset and reinitialization to validate the target firmware update. If the comparison result indicates that the run identifier in the firmware update validation operation identifier has changed, then executing loading the target version firmware into memory and overwriting the current version to validate the target firmware update.

[0006] According to one embodiment of the present invention, the version information is stored in a structured firmware file, and the structured firmware file includes: identification area information, which stores the system restart identification, hardware reset identification and operation identification; parameter area information, which includes hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identification, and the software parameters are associated with the hardware reset identification and the operation identification; firmware area information, which is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness and operation effectiveness.

[0007] According to one embodiment of the present invention, performing a hardware reset and reinitialization of the device includes: sending a hardware reset signal to a reset pin of the device to perform a reset operation on the device; after the device completes the reset action, initializing the device; during the initialization process, running the target version firmware until the initialization is completed; or, determining a register address for reset based on a register mapping table of the device; writing a preset reset configuration value to the register to trigger the reset logic inside the device; after the device completes the reset action, initializing the device; during the initialization process, running the target version firmware until the initialization is completed.

[0008] According to an embodiment of the present invention, before obtaining the version information of the current version firmware and the target version firmware, the method further includes: configuring the program of the current version firmware to detect the difference in the update effectiveness operation identifiers of the current version firmware and the target version firmware in real time during operation.

[0009] In the second aspect, an embodiment of the present invention also provides a device firmware update validation method, including: obtaining version information of the current version firmware and the target version firmware, the version information carrying at least two types of update validation operation identifiers; performing a consistency comparison on the corresponding types of update validation operation identifiers in the version information of the current version firmware and the target version firmware; based on the comparison result, triggering the device to execute the update validation operation indicated by the corresponding update validation operation identifier; the comparison result is used to indicate whether the firmware update validation operation identifier has changed.

[0010] According to one embodiment of the present invention, the update effectiveness operation identifier includes: a system restart identifier, a hardware reset identifier and a running identifier; the triggering of the device to execute the update effectiveness operation indicated by the update effectiveness operation identifier based on the comparison result includes: if the comparison result indicates that the system restart identifier in the firmware update effectiveness operation identifier has changed, the device is triggered to execute a system restart to make the target firmware update effective; if the comparison result indicates that the hardware reset identifier in the firmware update effectiveness operation identifier has changed, the device is triggered to execute a device hardware reset and reinitialization to make the target firmware update effective; if the comparison result indicates that the running identifier in the firmware update effectiveness operation identifier has changed, the device is triggered to execute loading the target version firmware into the memory and overwrite the current version to run, so that the target firmware update takes effect.

[0011] According to one embodiment of the present invention, the version information is stored in a structured firmware file, and the structured firmware file includes: identification area information, which stores the system restart identification, hardware reset identification and operation identification; parameter area information, which includes hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identification, and the software parameters are associated with the hardware reset identification and the operation identification; firmware area information, which is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness and operation effectiveness.

[0012] According to one embodiment of the present invention, the triggering device performs a hardware reset and reinitialization of the device, including: sending a hardware reset signal to the reset pin of the device to perform a reset operation on the device; after the device completes the reset action, initializing the device; during the initialization process, running the target version firmware until the initialization is completed; or, determining the register address for reset based on the register mapping table of the device; writing a preset reset configuration value to the register to trigger the reset logic inside the device; after the device completes the reset action, initializing the device; during the initialization process, running the target version firmware until the initialization is completed.

[0013] In a third aspect, an embodiment of the present invention provides an electronic device, comprising: a first acquisition unit, for acquiring version information of a current version of firmware and a target version of firmware, wherein the version information carries at least two types of update effectiveness operation identifiers; a first comparison unit, for performing a consistency comparison between the corresponding types of update effectiveness operation identifiers in the version information of the current version of firmware and the target version of firmware; and a first execution unit, for executing the update effectiveness operation indicated by the update effectiveness operation identifier according to the comparison result.

[0014] According to one embodiment of the present invention, the update effectiveness operation identifier includes: a system restart identifier, a hardware reset identifier and a running identifier; the first execution unit includes: a first execution module, which is used to execute a system restart if the comparison result indicates that the system restart identifier in the firmware update effectiveness operation identifier has changed, so as to make the target firmware update effective; a second execution module, which is used to execute a device hardware reset and reinitialization if the comparison result indicates that the hardware reset identifier in the firmware update effectiveness operation identifier has changed, so as to make the target firmware update effective; a third execution module, which is used to execute loading the target version firmware into the memory and overwriting the current version to run if the comparison result indicates that the running identifier in the firmware update effectiveness operation identifier has changed, so as to make the target firmware update effective.

[0015] According to one embodiment of the present invention, the version information is stored in a structured firmware file, and the structured firmware file includes: identification area information, which stores the system restart identification, hardware reset identification and operation identification; parameter area information, which includes hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identification, and the software parameters are associated with the hardware reset identification and the operation identification; firmware area information, which is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness and operation effectiveness.

[0016] According to one embodiment of the present invention, the second execution module includes: a first sending submodule, used to send a hardware reset signal to the reset pin of the device to perform a reset operation on the device; a first execution submodule, used to initialize the device after the device completes the reset action; or, used to determine the register address for reset based on the register mapping table of the device; write a preset reset configuration value to the register to trigger the reset logic inside the device; after the device completes the reset action, initialize the device; a first running submodule, used to run the target version firmware during the initialization process until the initialization execution is completed.

[0017] According to an embodiment of the present invention, the electronic device further comprises: a detection unit configured to detect in real time the difference between the update validation operation identifiers of the current version of firmware and the target version of firmware during the operation of the program configuring the current version of firmware.

[0018] In the fourth aspect, an embodiment of the present invention also provides an electronic device, including: a second acquisition unit, used to obtain version information of the current version firmware and the target version firmware, the version information carrying at least two types of update effectiveness operation identifiers; a second comparison unit, used to perform consistency comparison on the corresponding types of update effectiveness operation identifiers in the version information of the current version firmware and the target version firmware; a triggering unit, used to trigger the device to execute the update effectiveness operation indicated by the corresponding update effectiveness operation identifier based on the comparison result.

[0019] According to one embodiment of the present invention, the update effective operation identifier includes: a system restart identifier, a hardware reset identifier and a running identifier; the trigger unit includes: a first trigger module, which is used to trigger the device to perform a system restart if the comparison result indicates that the system restart identifier in the firmware update effective operation identifier has changed, so as to make the target firmware update effective; a second trigger module, which is used to trigger the device to perform a device hardware reset and reinitialization if the comparison result indicates that the hardware reset identifier in the firmware update effective operation identifier has changed, so as to make the target firmware update effective; a third trigger module, which is used to trigger the device to load the target version firmware into the memory and overwrite the current version if the comparison result indicates that the running identifier in the firmware update effective operation identifier has changed, so as to make the target firmware update effective.

[0020] According to one embodiment of the present invention, the version information is stored in a structured firmware file, and the structured firmware file includes: identification area information, which stores the system restart identification, hardware reset identification and operation identification; parameter area information, which includes hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identification, and the software parameters are associated with the hardware reset identification and the operation identification; firmware area information, which is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness and operation effectiveness.

[0021] According to one embodiment of the present invention, the second trigger module includes: a second sending submodule, used to send a hardware reset signal to the reset pin of the device to perform a reset operation on the device; a second execution submodule, used to initialize the device after the device completes the reset action; a second running submodule, used to run the target version firmware during the initialization process until the initialization execution is completed; or, used to determine the register address for reset based on the register mapping table of the device; write a preset reset configuration value to the register to trigger the reset logic inside the device; perform initialization on the device after the device completes the reset action; during the initialization process, run the target version firmware until the initialization execution is completed.

[0022] In a fifth aspect, an embodiment of the present invention provides a storage medium, including: the storage medium is configured to store device firmware, and the device firmware includes: an identification area, storing at least two types of operation identifiers indicating that the device firmware update is effective; a parameter area, containing hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identifier, and the software parameters are associated with the hardware reset identifier and the operation identifier; a firmware area, configured to store firmware instructions and data.

[0023] According to an embodiment of the present invention, the operation identifier includes: a system restart identifier, a hardware reset identifier and a run identifier; the firmware is divided into firmware sub-areas corresponding to the system restart effective, hardware reset effective and run effective.

[0024] In the sixth aspect, an embodiment of the present invention provides an electronic device, comprising: a processing unit, configured to execute firmware upgrade-related instructions, and send corresponding control instructions for the effectiveness of the firmware update based on the update effectiveness operation identifier in the firmware version information; a storage management unit, located between the processing unit and an external memory, wherein the target version firmware is stored in the external memory, and the storage management unit is configured to obtain the stored firmware file and send it to the processing unit; the external memory is a storage medium provided by any of the aforementioned embodiments; a communication interface unit, connected to the processing unit, configured to communicate with an external device, receive the current version firmware information sent by the external device and send it to the processing unit, and send the control instructions to the external device, so that the external device performs the update effectiveness operation indicated by the update effectiveness operation identifier. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0026] Figure 1 This is a firmware upgrade validation flow chart provided in the prior art; Figure 2 A flowchart of a device firmware update validation method provided by an embodiment of the present invention; Figure 3a A structural diagram of a firmware update and upgrade validation system provided by an embodiment of the present invention; Figure 3b Another firmware update and upgrade validation system structure diagram provided by an embodiment of the present invention; Figure 4 Another firmware upgrade validation flow chart provided by an embodiment of the present invention; Figure 5 A flowchart of firmware management with immediate effect provided by an embodiment of the present invention; Figure 6 A flow chart of device reset provided by an embodiment of the present invention; Figure 7 A flowchart of the burning tool provided by an embodiment of the present invention; Figure 8 Another flow chart of a device firmware update validation method provided by an embodiment of the present invention; Figure 9 A schematic diagram of an electronic device provided by an embodiment of the present invention; Figure 10 A schematic diagram of another electronic device provided by an embodiment of the present invention; Figure 11 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0027] The embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0028] It should be understood that the embodiments described are only a portion of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without creative work are within the scope of protection of the present invention.

[0029] Traditional firmware update methods typically require a system restart after loading a new firmware version for the new firmware to take effect. However, a restart can cause the device to temporarily stop service, impacting business continuity. For devices requiring high availability, such as network equipment and servers, a restart can significantly impact ongoing businesses. Furthermore, traditional methods cannot selectively implement differentiated updates for certain modules based on specific needs, and typically require a one-size-fits-all restart of the entire system.

[0030] Taking the above problems into consideration, an embodiment of the present application provides a device firmware update validation method. By introducing an update validation operation identifier, it supports multiple types of firmware update validation methods, such as restart, reset, reload, etc., which can avoid the problems existing in traditional firmware update validation methods and improve the device availability and business continuity.

[0031] In order to enable those skilled in the art to better understand the technical concepts, implementation plans and beneficial effects of the embodiments of the present application, specific examples are described in detail below.

[0032] See Figure 1 , an embodiment of the present application provides a method for validating a device firmware update, comprising: S11, obtaining version information of the current version firmware and the target version firmware, wherein the version information carries at least two types of update validation operation identifiers; The effectiveness of firmware updates is based on the system structure. Figure 3a and Figure 3b The system structure diagram for firmware update and upgrade is shown. The system structure includes the host side, the device side and the bus. In some cases, a host side can carry one device or multiple devices. Figure 3a and Figure 3b The firmware update process involves collaboration between the host and device. A bus connects the host and device to ensure the new firmware loads correctly and takes effect. In some examples, the host is a computer or server; the device can be an embedded device or network device. The bus can be a high-speed Peripheral Component Interconnect Express (PCIe) or Joint Test Action Group (JTAG). The host is the controller of the firmware update, responsible for managing the firmware update process. The device is the target of the firmware update.

[0033] When the device firmware update is effective, in one embodiment of the present application, after the firmware is updated, the device does not need to be restarted or only needs a short interruption to load the new firmware. This method can be understood as immediate effect. Figure 4 For another firmware upgrade flow chart, see Figure 4 During the immediate implementation of a device firmware update, the device may provide storage space for storing target firmware version information. In some examples, the target firmware data may be stored by some storage device in the device storage space, where the target firmware is the new firmware to be upgraded. At this time, the current firmware on the device continues to operate normally. The current firmware is the firmware version currently running on the device. While the current firmware is running, the device loads the target firmware through a dynamic loading mechanism and then switches the operating environment from the current firmware to the target firmware.

[0034] Therefore, for the device side, it is necessary to determine the target version of the firmware and load it, obtain the device firmware version information that matches the system structure, store it in the storage space, and update the current version of the firmware. Generally speaking, the existing device firmware version information mainly contains two important components, namely identification and data. Among them, the data includes two parts: the parameter area and the firmware area, as shown in Table 1. The identification part is the information data of the firmware file, which is mainly used to provide descriptive information of the firmware. This information is usually not directly involved in the operation of the device and is only used as information, such as time. The data part is the core of the firmware file, which contains the actual code and configuration information required for the operation of the device. This data will be loaded into the memory of the device side and executed after the device is started.

[0035]

[0036] In one embodiment of the present application, referring to Table 2, in the file structure of the firmware version, an update effectiveness operation identifier is added to the data part, so that the version information carries the update effectiveness operation identifier. When the device firmware update is effective, the version information of the current version firmware and the target version firmware is obtained. The version information includes at least two types of update effectiveness operation identifiers to achieve differentiated effectiveness during the device firmware update process.

[0037]

[0038] S12, performing consistency comparison between corresponding types of update validation operation identifiers in version information of the current version firmware and the target version firmware; After obtaining the version information of the current version firmware and the target version firmware, when the device starts, load the program that runs the current version firmware and configure its monitoring function. During operation, periodically or trigger-based comparison is performed on the update effective operation identifiers of the current version firmware and the target version firmware. The version information in the firmware file is read to generate a firmware operation list. The firmware operation list includes the storage version number and the running version number. The current running firmware version information is obtained from the device memory, and the target firmware version information is obtained from the storage medium. The running version number and the storage version number are compared to determine whether further comparison of the file list is required. If the version numbers are different, the file list is further compared to determine the specific update operation. If the version numbers are the same, the corresponding type of update effective operation identifiers in the version information of the current version firmware and the target version firmware are compared.

[0039] S13, determining whether to execute the update validation operation indicated by the update validation operation identifier based on the comparison result; the comparison result is used to indicate whether the firmware update validation operation identifier has changed.

[0040] If the output comparison result is consistent, that is, it indicates that the firmware update effectiveness operation identifier has not changed, then there is no need to execute the update effectiveness operation corresponding to the update effectiveness operation identifier; if the output comparison result is inconsistent, that is, it indicates that the firmware update effectiveness operation identifier has changed, then execute the update effectiveness operation corresponding to the changed update effectiveness operation identifier.

[0041] The device firmware update validation method provided in the embodiment of the present application obtains version information of the current version firmware and the target version firmware, wherein the version information carries at least two types of update validation operation identifiers; performs a consistency comparison on the corresponding types of update validation operation identifiers in the version information of the current version firmware and the target version firmware; and determines whether to execute the update validation operation indicated by the corresponding update validation operation identifier based on the comparison result. In this way, by introducing the update validation operation identifier and executing the update validation operation indicated by the update validation operation identifier, the method is not limited to a single firmware update validation method, avoids the limitations of a "one-size-fits-all" restart method, and thus improves the flexibility and real-time performance of firmware version validation.

[0042] Referring to Table 2 above, in some embodiments, the update validation operation identifier includes: a system restart identifier, a hardware reset identifier, and a run identifier. Determining whether to execute the update validation operation indicated by the update validation operation identifier based on the comparison result includes: if the comparison result indicates that the system restart identifier in the firmware update validation operation identifier has changed, then executing a system restart to validate the target firmware update; if the comparison result indicates that the hardware reset identifier in the firmware update validation operation identifier has changed, then executing a hardware reset and reinitialization of the device to validate the target firmware update; and if the comparison result indicates that the run identifier in the firmware update validation operation identifier has changed, then executing loading the target version of firmware into memory and overwriting the current version to validate the target firmware update.

[0043] Among them, the update effectiveness operation identifier includes the system restart identifier, hardware reset identifier, and run identifier. When the update effectiveness operation identifier of the corresponding type in the version information of the current version firmware and the target version firmware is compared for consistency, the state variables of the system restart identifier, hardware reset identifier, and run identifier are compared. Based on the comparison results, the corresponding update effectiveness operation is executed. If the system restart identifier changes, the system is restarted; if the hardware reset identifier changes, the device hardware is reset and reinitialized; if the run identifier changes, the target version firmware is loaded into the memory and overwrites the current version. This achieves differentiated effectiveness of the firmware update.

[0044] For example, Figure 5 For the firmware management immediate effect flow chart, see Figure 5As shown, let the system reboot identifier be REBOOT_ID (Note: The underscores in the English symbols used in various identifiers in this article are commonly used identifiers in program naming in this field. For ease of understanding, they are used here. Of course, other identifiers can be changed as needed). The system reboot identifier is used to indicate whether a device reboot is required for the firmware update to take effect. In terms of data type, REBOOT_ID can be a flag, an enumeration value, or a specific string. When comparing the system reboot identifier, if the data type of the system reboot identifier REBOOT_ID is a flag and the default value of the system reboot identifier REBOOT_ID of the current version of the firmware is 0, if the value of REBOOT_ID increases by 1, a reboot is required. If the REBOOT_ID value of the target version of the firmware remains the same as the current version of the firmware, a reboot is not required. That is, when REBOOT_ID = 1, the REBOOT_ID values ​​of the target version firmware and the current version firmware are different, indicating that a restart is required. When REBOOT_ID = 0, the REBOOT_ID values ​​of the target version firmware and the current version firmware are the same, indicating that a restart is not required. Furthermore, if three versions of firmware are released, namely version 1, version 2 and version 3, the REBOOT_ID value of version 1 is 0. If version 2 requires a restart for version 1, the REBOOT_ID value of version 2 is 1. If version 3 does not require a restart for version 2, the REBOOT_ID of version 3 is 1.During the upgrade, if the current version of the firmware is version 1 and the upgraded version is version 2 or version 3, if the REBOOT_ID is different, a restart is required; if the current version of the firmware is version 2, when upgrading to version 3, if the REBOOT_ID is the same, no restart is required; if the current version of the firmware is version 2, when rolling back to version 1, if the REBOOT_ID is different, a restart is required; if REBOOT_ID is an enumeration value, a new enumeration value is defined for each version that requires a restart, and the version that does not require a restart uses the previous enumeration value. Assume that 4 versions of firmware are released, namely version 1, version 2, version 3 and version 4, when the enumeration value REBOOT_ENUM_V000 = 0, when version 1 and version 2 require a restart, the enumeration value REBOOT_ENUM_V001 of version 1 = 1, the enumeration value REBOOT_ENUM_V002 of version 2 = 2, version 3 does not require a restart and keeps the enumeration value REBOOT_ENUM_V001 = 1, and when version 4 requires a restart, REBOOT_ENUM_V002 = 2 ENUM_V003 = 2, so that its enumeration value will change only when the next version requires a reboot; if REBOOT_ID is a string identifier, for example, REBOOT_ID = "REBOOT_V001", if the current version REBOOT_ID = "REBOOT_V000" is different, it means that an immediate reboot is required. If the current version REBOOT_ID = "REBOOT_V001" is the same, no reboot is required.

[0045] After comparing the system reboot identifier, if a system reboot is not required, the hardware reset identifier is compared. Set the hardware reset identifier to RESET_ID. RESET_ID is an enumeration or identifier used to identify the device reset type. The judgment process is similar to REBOOT_ID. After comparing the hardware reset identifier, if a hardware reset is not required, the operation identifier is compared. Set the operation identifier to RELOAD_ID. RELOAD_ID is an enumeration or identifier used to identify a device or system reload operation. The judgment process is similar to REBOOT_ID and is not repeated here.

[0046] In some embodiments, the version information is stored in a structured firmware file, and the structured firmware file includes: identification area information, which stores the system restart identification, hardware reset identification and operation identification; parameter area information, which includes hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identification, and the software parameters are associated with the hardware reset identification and the operation identification; firmware area information, which is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness and operation effectiveness.

[0047] Referring to Table 2, the firmware version information in the device is stored in a structured firmware file, which includes identification area information, parameter area information, and firmware area information. The identification area information includes a system restart identifier, a hardware reset identifier, and a run identifier, wherein the restart identifier is used to indicate whether the new firmware needs to be validated by a system restart; the hardware reset identifier can indicate whether the new firmware needs to be validated by a hardware reset; and the run identifier indicates whether the new firmware can be validated by dynamic loading. The parameter area information includes hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identifier and store hardware-related configuration parameters, such as register values, clock frequencies, etc.; the software parameters are associated with the hardware reset identifier and the run identifier and store software-related configuration parameters.

[0048] The firmware area information is divided into firmware sub-area 1 information, firmware sub-area 2 information and firmware sub-area 3 information. Firmware sub-area 1 information corresponds to system restart and takes effect, and stores firmware instructions and data that need to be taken effect by system restart; firmware sub-area 2 information corresponds to hardware reset and takes effect, and stores firmware instructions and data that need to be taken effect by hardware reset; firmware sub-area 3 information corresponds to operation and takes effect, and stores firmware instructions and data that can be taken effect by dynamic loading.

[0049] Specifically, when a device firmware update takes effect, a structured firmware file is retrieved from a server or storage device. The firmware file is generally first verified, such as with a cyclic redundancy check (CRC) or hash check, to ensure its integrity and correctness. The system restart flag, hardware reset flag, and run flag in the identification area are read, and then the hardware parameters and software parameters in the parameter area are read. Based on the instructions in the identification area, the appropriate update implementation method is selected. Specifically, if the system restart flags of the target version firmware and the current version firmware are different, then system restart is selected for implementation; if the hardware reset flags of the target version firmware and the current version firmware are different, then hardware reset is selected for implementation; and if the run flags of the target version firmware and the current version firmware are different, then run is selected for implementation.

[0050] First, write the firmware to the correct sub-area so that subsequent validation operations can correctly read the new firmware. Validation operations include restarting and resetting. Depending on the selected update validation method, the corresponding firmware sub-area is loaded. If a system restart is enabled, the information in firmware sub-area 1, firmware sub-area 2, and firmware sub-area 3 is loaded, and the system restart operation is executed. If a hardware reset is enabled, the information in firmware sub-area 2 and firmware sub-area 3 is loaded, and the hardware module reset operation is executed. If a run is enabled, the information in firmware sub-area 3 is loaded, and the dynamic loading of the new firmware is executed.

[0051] In some embodiments, performing a hardware reset and reinitialization of the device includes: sending a hardware reset signal to a reset pin of the device to perform a reset operation on the device; after the device completes the reset action, initializing the device; during the initialization process, running the target version firmware until the initialization is completed; or, determining a register address for reset based on a register mapping table of the device; writing a preset reset configuration value to the register to trigger the reset logic inside the device; after the device completes the reset action, initializing the device; during the initialization process, running the target version firmware until the initialization is completed.

[0052] Figure 6 This is a reset flow chart in the device embodiment scenario, see Figure 6 When performing a hardware reset and reinitialization of a device, before the reset operation, it is necessary to determine whether the device needs to be unbound. This is to unbind the device from certain external systems, services, or resources. This is usually to ensure that the reset process does not affect the binding party, or to prevent the binding relationship from becoming invalid after the reset. Of course, from the perspective of firmware update effectiveness, whether the device is bound or unbound does not affect the effectiveness of the updated firmware.

[0053] After determining whether to unbind the device, a device reset is performed. The device's reset pin is typically a GPIO pin with an active-low state. By controlling the device's reset pin, a hardware reset signal is sent. This pulls the reset pin low for a period of time, such as 10ms, and then restores the reset pin high to complete the reset operation. In one example, a device reset can also be implemented using registers. The device's register map determines the register address for the reset. After determining the reset register, the documentation is consulted to understand the required reset bit pattern. The bit pattern can be a single bit or a combination of multiple bits. A specific bit pattern, such as 0x01 or 0x80, is set. A write operation is then performed to write the specified reset configuration value to the reset register. After writing the reset value, the device's internal reset logic is triggered to begin the reset operation. The reset completion flag is polled through the status register or a fixed delay is waited for.

[0054] After the device is reset, it performs initialization operations, first initializing hardware peripherals such as GPIO, UART, and I2C, loading default configurations or user configurations from storage media. In some examples, the storage medium can be Flash memory or electrically erasable programmable read-only memory (EEPROM), and then starting system services such as task scheduling and timers.

[0055] Finally, run the target version firmware. During the initialization process, load and run the target version firmware, read the target version firmware from the storage medium, jump to the entry address of the target version firmware, and start execution until the initialization execution is completed.

[0056] In one embodiment, during the firmware update and upgrade validation process, the target version of the firmware can be written into the storage area of ​​the device through a burning tool (Firmware Flashing Tool). During the use of the device, the firmware update and validation are realized through the interaction between the burning tool and the firmware in the device. Figure 7 For the workflow diagram of the burning tool, see Figure 7 First, read the firmware file, erase the entire storage medium, and then burn the target version firmware file into the storage medium of the device. The function of the burning tool can also be implemented by a processor, etc.

[0057] In some embodiments, before obtaining the version information of the current version firmware and the target version firmware, the method further includes: during the operation of the program configured for the current version firmware, detecting in real time the difference between the update validation operation identifiers of the current version firmware and the target version firmware. In other words, in this application, during the operation of the program pre-configured for the current version firmware, it synchronizes in real time with the state of the target version firmware in the storage medium to detect the difference between the update validation operation identifiers of the current version firmware and the target version firmware, and automatically completes the firmware update validation.

[0058] See also Figure 7 In this application, after the above configuration is performed, the burning tool burns the target version firmware file into the storage medium, that is, the firmware begins to take effect immediately, notifies the running current version firmware to synchronize the version according to the above configuration, and obtains the synchronization status of the firmware operation based on the feedback of the program of the current version firmware running on the device, that is, specifically: real-time detection of the difference in the update effectiveness operation identifiers of the current version firmware and the target version firmware, and returns the corresponding effectiveness operation identifier according to the difference in the update effectiveness operation identifier. If the restart operation identifier is returned, a restart is required, and the synchronization cannot be successful during the operation of the current version. If the restart operation identifier is not returned, that is, if the hardware reset or operation identifier is returned, there is no need to restart, that is, the immediate effectiveness can be completed successfully during the operation of the current version, that is, the synchronization is successful in the figure. Of course, sometimes the failure to take effect may be caused by defects in the firmware itself, that is, synchronization failure.

[0059] It should be noted that the real-time detection of the difference between the update effectiveness operation identifiers of the current version firmware and the target version firmware can also be performed by the burning tool. Therefore, in other embodiments, the present application also provides an embodiment of a device firmware update effectiveness method, including: receiving an update effectiveness operation instruction sent by the burning tool, the instruction is generated by the burning tool as a result of comparing the update effectiveness operation identifiers of the current version firmware and the target version firmware, and the instruction is used to instruct the execution of the update effectiveness operation indicated by the update effectiveness operation identifier; according to the update effectiveness operation instruction, determine whether to execute the update effectiveness operation indicated by the update effectiveness operation identifier.

[0060] Specifically, if the update validation operation instruction is a hardware reset identifier, the device hardware is reset and reinitialized to achieve immediate validation success, that is, the synchronization is successful as described in the figure.

[0061] If the instruction is a running identifier, the target version firmware is dynamically loaded into the memory in the current running environment, overwriting the current version to achieve immediate success, that is, the synchronization is successful as described in the figure.

[0062] In addition, see Figure 8 , an embodiment of the present application further provides a device firmware update validation method, comprising: S21, obtaining version information of the current version firmware and the target version firmware, wherein the version information carries at least two types of update validation operation identifiers; Among them, the device firmware update validation method provided in the embodiment of the present application can be applied to the host, and the host implements the differential update validation of the device firmware by interactively connecting with the device. During the device firmware upgrade process, the host needs to obtain the version information of the current version firmware and the target version firmware to ensure the correctness and integrity of the upgrade. When obtaining the current version firmware information, the host sends a query instruction to the device, such as GET_FIRMWARE_VERSION, requesting the device to return the current firmware version. After receiving the instruction, the device reads the firmware version information from the firmware storage area and returns it to the host.

[0063] The firmware version information is usually a string, and the format is generally major version number, minor version number, and revision number. The host parses the version information returned by the device and records it. Then, the target version firmware information is obtained. The target version firmware usually exists in the form of a firmware upgrade package, which contains the target version information. The host parses the information data of the firmware upgrade package and extracts the target version information. In some examples, the information data of the upgrade package can be header information or a configuration file. Determine the storage location of the version information. The header of the firmware upgrade package may contain a version field. If the upgrade package is a file, the version information may be stored in a specific location of the file, such as the beginning or end. Finally, the host verifies the extracted target version information to ensure that its format is correct and valid.

[0064] In this embodiment, an update validation operation identifier is added to the target version firmware data portion so that the version information carries the update validation operation identifier. The update validation operation identifier includes at least two types, which are used to indicate the validation operation mode after the firmware update to achieve differentiated update validation.

[0065] S22: performing consistency comparison between corresponding types of update validation operation identifiers in version information of the current version firmware and the target version firmware.

[0066] The host extracts the target version firmware information from the firmware upgrade package, including the version number and the update effective operation identifier, parses the version information of the current version and the target version, and extracts the update effective operation identifier. The current version number is compared with the target version number for consistency to determine whether an upgrade is required. In some examples, if the version numbers are the same and the business logic does not allow repeated upgrades, there is no need to compare the update effective operation identifier and re-update the firmware; if the version numbers are the same but the business logic allows repeated upgrades, it is necessary to continue to compare the update effective operation identifier. In another example, if the version numbers of the current version firmware and the target version firmware are different, the host needs to continue to compare the update effective operation identifier to determine what update effective operation the device needs to perform in order to make the device take effect after the update.

[0067] S23: Based on the comparison result, the triggering device determines whether to execute the update validation operation indicated by the update validation operation identifier.

[0068] In this embodiment, as described above, if the comparison result indicates that the version information has changed, the host sends a corresponding validation operation instruction based on the changed update validation operation identifier, causing the device to perform the corresponding validation operation to implement the new firmware.

[0069] The embodiment of the present application provides a device firmware update validation method, which obtains version information of the current version firmware and the target version firmware, wherein the version information carries at least two types of update validation operation identifiers; performs a consistency comparison on the corresponding types of update validation operation identifiers in the version information of the current version firmware and the target version firmware; and determines whether to execute the update validation operation indicated by the corresponding update validation operation identifier based on the comparison result. In this way, by introducing the update validation operation identifier and executing the update validation operation indicated by the update validation operation identifier, the method is not limited to a single firmware update validation method, avoids the limitations of a "one-size-fits-all" restart method, and thus improves the flexibility and real-time performance of firmware version validation.

[0070] In some embodiments, the update effectiveness operation identifier includes: a system restart identifier, a hardware reset identifier and a running identifier; according to the comparison result, the device is triggered to execute the update effectiveness operation indicated by the corresponding update effectiveness operation identifier, including: if the comparison result indicates that the system restart identifier in the firmware update effectiveness operation identifier has changed, then the device is triggered to execute a system restart to make the target firmware update effective; if the comparison result indicates that the hardware reset identifier in the firmware update effectiveness operation identifier has changed, then the device is triggered to execute a device hardware reset and reinitialization to make the target firmware update effective; if the comparison result indicates that the running identifier in the firmware update effectiveness operation identifier has changed, then the device is triggered to execute loading the target version firmware into the memory and overwrite the current version to make the target firmware update effective.

[0071] For example, when the device is triggered to perform the above-mentioned corresponding operation according to the comparison result, if the restart flag reboot_required is true, indicating that a restart is required to take effect, at this time, the host sends a reoperation instruction to the device, so that the device executes a restart and loads the new firmware to take effect; if the hardware reset flag reset_required is true, the host sends a reset instruction to the device, and the reset instruction is, for example, RESET_DEVICE, so that the device resets and runs the new firmware to take effect; if the operation flag (reload flag) reload_required is true, the host sends a reload instruction, such as RELOAD_FIRMWARE, to the device to reload the firmware.

[0072] In some embodiments, the version information is stored in a structured firmware file, and the structured firmware file includes: identification area information, which stores the system restart identification, hardware reset identification and operation identification; parameter area information, which includes hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identification, and the software parameters are associated with the hardware reset identification and the operation identification; firmware area information, which is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness and operation effectiveness.

[0073] The firmware version information in the device is stored in a structured firmware file. The structured firmware file includes an identification area, a parameter area, and a firmware area. Please refer to Table 2 above and will not be described in detail.

[0074] In some embodiments, the triggering device performs a hardware reset and reinitialization of the device, including: sending a hardware reset signal to a reset pin of the device to perform a reset operation on the device; after the device completes the reset action, initializing the device; during the initialization process, running the target version firmware until the initialization is completed; or, determining the register address for reset based on the register mapping table of the device; writing a preset reset configuration value to the register to trigger the reset logic inside the device; after the device completes the reset action, initializing the device; during the initialization process, running the target version firmware until the initialization is completed.

[0075] See Figure 6 In some embodiments, when the control device hardware is reset and reinitialized, before the reset operation, it is necessary to determine whether the device needs to be unbound, and to unbind the device from certain external systems, services or resources. This is usually to ensure that the reset process does not affect the binding party, or to avoid the binding relationship from becoming invalid after the reset.

[0076] After determining whether to unbind the device, the host sends a reset command to reset the device. The device's reset pin is typically an active-low GPIO. By controlling the device's reset pin and sending a hardware reset signal, the reset pin is pulled low for a period of time, such as 10ms, and then restored to a high level, completing the reset operation. In one example, device reset can also be achieved through registers. The device's register map determines the register address for reset. After determining the reset register, the host consults the documentation to understand the required reset bit pattern. The bit pattern can be a single bit or a combination of multiple bits. To set the specific bit pattern, such as 0x01 or 0x80, a write operation is performed to write the specified reset configuration value to the reset register. After writing the reset value, the device's internal reset logic is triggered to begin the reset operation. The reset completion flag is polled through the status register or after a fixed delay.

[0077] After the device is reset, an initialization operation is performed. The specific process can be found in the embodiment described above for the device side, and will not be described in detail here.

[0078] The embodiments of the present application provide an electronic device that avoids the limitations of a "one-size-fits-all" restart method, thereby improving the flexibility and real-time effectiveness of firmware versions.

[0079] Figure 9 This is a schematic diagram of an electronic device provided in an embodiment of the present application, see Figure 9 , an embodiment of the present application provides an electronic device, including: The first acquiring unit 31 is configured to acquire version information of the current version firmware and the target version firmware, wherein the version information carries at least two types of update validation operation identifiers; A first comparison unit 32 is configured to compare the update validation operation identifiers of the corresponding types in the version information of the current version firmware and the target version firmware for consistency; The first execution unit 33 is configured to execute the update validation operation indicated by the update validation operation identifier according to the comparison result; the comparison result is used to indicate whether the firmware update validation operation identifier has changed.

[0080] An embodiment of the present application provides an electronic device that obtains version information of a current version of firmware and a target version of firmware, wherein the version information carries at least two types of update validation operation identifiers; performs a consistency comparison on the corresponding types of update validation operation identifiers in the version information of the current version of firmware and the target version of firmware; and executes the update validation operation indicated by the update validation operation identifier based on the comparison result. In this way, by introducing the update validation operation identifier and executing the update validation operation indicated by the update validation operation identifier, the system is not limited to a single firmware update validation method, avoids the limitations of a "one-size-fits-all" restart method, and thereby improves the flexibility and real-time performance of firmware version validation.

[0081] In some embodiments, the update effectiveness operation identifier includes: a system restart identifier, a hardware reset identifier and a running identifier; the first execution unit includes: a first execution module, which is used to execute a system restart if the comparison result indicates that the system restart identifier in the firmware update effectiveness operation identifier has changed, so as to make the target firmware update effective; a second execution module, which is used to execute a device hardware reset and reinitialization if the comparison result indicates that the hardware reset identifier in the firmware update effectiveness operation identifier has changed, so as to make the target firmware update effective; a third execution module, which is used to execute loading the target version firmware into the memory and overwriting the current version to run if the comparison result indicates that the running identifier in the firmware update effectiveness operation identifier has changed, so as to make the target firmware update effective.

[0082] In some embodiments, the version information is stored in a structured firmware file, and the structured firmware file includes: identification area information, which stores the system restart identification, hardware reset identification and operation identification; parameter area information, which includes hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identification, and the software parameters are associated with the hardware reset identification and the operation identification; firmware area information, which is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness and operation effectiveness.

[0083] In some embodiments, the second execution module includes: a first sending submodule, used to send a hardware reset signal to the reset pin of the device to perform a reset operation on the device; a first execution submodule, used to initialize the device after the device completes the reset action; or, used to determine the register address for reset according to the register mapping table of the device; write a preset reset configuration value to the register to trigger the reset logic inside the device; after the device completes the reset action, initialize the device; a first running submodule, used to run the target version firmware during the initialization process until the initialization execution is completed.

[0084] In some embodiments, the electronic device further comprises: a detection unit configured to detect in real time the difference between the update validation operation identifiers of the current version of firmware and the target version of firmware during the running of the program configuring the current version of firmware.

[0085] The present application also provides an electronic device in an embodiment, avoiding the limitations of a "one-size-fits-all" restart method, thereby improving the flexibility and real-time effectiveness of firmware versions.

[0086] Figure 10 Another electronic device schematic diagram provided in one embodiment of the present application is shown in FIG. Figure 10 , an embodiment of the present application further provides an electronic device, including: The second acquiring unit 41 is configured to acquire version information of the current version firmware and the target version firmware, wherein the version information carries at least two types of update validation operation identifiers; The second comparison unit 42 compares the update validation operation identifiers of the corresponding types in the version information of the current version firmware and the target version firmware for consistency; The triggering unit 43 is configured to trigger the device to execute the update validation operation indicated by the update validation operation identifier according to the comparison result; the comparison result is used to indicate whether the firmware update validation operation identifier has changed.

[0087] The embodiment of the present application also provides an electronic device, which obtains version information of the current version firmware and the target version firmware, wherein the version information carries at least two types of update validation operation identifiers; performs a consistency comparison on the corresponding types of update validation operation identifiers in the version information of the current version firmware and the target version firmware; and executes the update validation operation indicated by the update validation operation identifier based on the comparison result. In this way, by introducing the update validation operation identifier and executing the update validation operation indicated by the update validation operation identifier, the system is not limited to a single firmware update validation method, avoids the limitations of a "one-size-fits-all" restart method, and thus improves the flexibility and real-time performance of firmware version validation.

[0088] In some embodiments, the update validation operation identifier includes: a system restart identifier, a hardware reset identifier, and a run identifier; the trigger unit includes: a first trigger module, configured to trigger the device to perform a system restart if the comparison result indicates that the system restart identifier in the firmware update validation operation identifier has changed, so as to make the target firmware update effective; The second trigger module is used to trigger the device to perform a hardware reset and reinitialization of the device if the comparison result indicates that the hardware reset identifier in the firmware update effectiveness operation identifier has changed, so that the target firmware update can take effect; the third trigger module is used to trigger the device to load the target version firmware into the memory and overwrite the current version to run if the comparison result indicates that the running identifier in the firmware update effectiveness operation identifier has changed, so that the target firmware update can take effect.

[0089] In some embodiments, the version information is stored in a structured firmware file, and the structured firmware file includes: identification area information, which stores the system restart identification, hardware reset identification and operation identification; parameter area information, which includes hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identification, and the software parameters are associated with the hardware reset identification and the operation identification; firmware area information, which is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness and operation effectiveness.

[0090] In some embodiments, the second trigger module includes: a second sending submodule, used to send a hardware reset signal to the reset pin of the device to perform a reset operation on the device; a second execution submodule, used to initialize the device after the device completes the reset action; a second running submodule, used to run the target version firmware during the initialization process until the initialization execution is completed; or, used to determine the register address for reset according to the register mapping table of the device; write a preset reset configuration value to the register to trigger the reset logic inside the device; perform initialization on the device after the device completes the reset action; during the initialization process, run the target version firmware until the initialization execution is completed.

[0091] Based on the aforementioned firmware file structure improvement, the present application also provides a storage medium in an embodiment, which is configured to store device firmware, and the device firmware includes: an identification area, storing at least two types of operation identifiers indicating that the device firmware update is effective; a parameter area, containing hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart identifier, and the software parameters are associated with the hardware reset identifier and the operation identifier; a firmware area, configured to store firmware instructions and data.

[0092] It should be noted that the storage medium of this application includes cloud storage, local storage and physical storage medium. When the device firmware needs to be updated, it can interact with the storage medium provided by this application to reproduce the method embodiment process of the firmware upgrade effectiveness in this application.

[0093] In some embodiments, the operation identifier includes: a system restart identifier, a hardware reset identifier, and a run identifier; the firmware is divided into firmware sub-areas corresponding to the system restart effective, hardware reset effective, and run effective.

[0094] look Figure 11 , the present application also provides an electronic device according to an embodiment, including: a processing unit 61, used to execute firmware upgrade related instructions, and send corresponding control instructions for the effectiveness of the firmware update based on the update effectiveness operation identifier in the firmware version information; a storage management unit 62, located between the processing unit 61 and the external memory 63, the external memory 63 stores the target version firmware 64, the storage management unit 62 is configured to obtain the stored firmware file and send it to the processing unit 61; the external memory 63 is a storage medium provided by any of the aforementioned embodiments; a communication interface unit 65, connected to the processing unit 61, configured to communicate with an external device, receive the current version firmware information sent by the external device and send it to the processing unit 62, and send the control instruction to the external device, so that the external device performs the update effectiveness operation indicated by the update effectiveness operation identifier.

[0095] In summary, the technical solutions provided in the embodiments of the present application can be applied to firmware update scenarios of chips or chip peripheral devices or equipment. By carrying at least two types of update effectiveness operation identifiers in the firmware version information, differentiated effectiveness operation instructions can be executed according to actual conditions. For some scenarios, the instant effectiveness feature of the upgraded firmware can be achieved without restarting, thereby improving the effectiveness time of the firmware update and thus enhancing the user upgrade experience.

[0096] In addition, this application also improves the upgrade firmware, and divides and judges the three types of data: reboot, reset, and reload according to the effective operation identifier. After the device reads the firmware, for some scenarios, the firmware upgrade and update can be effective immediately, solving the problem that traditional firmware updates may cause by restarting without any difference.

[0097] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0098] The various embodiments in this specification are described in a related manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments.

[0099] For the convenience of description, the electronic devices described above are divided into various functional units / circuits / modules according to their functions. Of course, when implementing this application, the functions of each unit / module can be implemented in the same or multiple software and / or hardware.

[0100] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A device firmware update validation method, characterized in that: include: Obtaining version information of the current version firmware and the target version firmware, wherein the version information carries at least two types of update validation operation identifiers; Comparing the update validation operation identifiers of the corresponding types in the version information of the current version firmware and the target version firmware for consistency; According to the comparison result, it is determined whether to execute the update validation operation indicated by the update validation operation identifier; the comparison result is used to indicate whether the firmware update validation operation identifier has changed.

2. The device firmware update validation method according to claim 1, characterized in that: The update validation operation identifier includes: system restart identifier, hardware reset identifier and operation identifier; The determining, based on the comparison result, whether to execute the update validation operation indicated by the update validation operation identifier includes: If the comparison result indicates that the system restart identifier in the firmware update validation operation identifier has changed, performing a system restart to make the target firmware update effective; If the comparison result indicates that the hardware reset flag in the firmware update validation operation flag has changed, performing a hardware reset and reinitialization of the device to validate the target firmware update; If the comparison result indicates that the running identifier in the firmware update validation operation identifier has changed, the target version firmware is loaded into the memory and overwritten with the current version to enable the target firmware update to take effect.

3. The device firmware update validation method according to claim 2, characterized in that: The version information is stored in a structured firmware file, which includes: Identification area information, storing the system restart identification, hardware reset identification and operation identification; Parameter area information, including hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart flag, and the software parameters are associated with the hardware reset flag and the running flag; The firmware area information is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness, and operation effectiveness.

4. The device firmware update validation method according to claim 2, characterized in that: The execution of device hardware reset and reinitialization includes: Sending a hardware reset signal to a reset pin of a device to perform a reset operation on the device; After the device completes the reset action, initializing the device; During the initialization process, running the target version firmware until the initialization is completed; or, Determine the register address for reset according to the device's register mapping table; Writing a preset reset configuration value to the register to trigger the reset logic inside the device; After the device completes the reset action, initializing the device; During the initialization process, the target version firmware is run until the initialization is completed.

5. The device firmware update validation method according to claim 1, characterized in that: Before obtaining the version information of the current version firmware and the target version firmware, the method further includes: configuring the program of the current version firmware to detect the difference between the update validation operation identifiers of the current version firmware and the target version firmware in real time during operation.

6. A method for validating device firmware update, characterized in that: include: Obtaining version information of the current version firmware and the target version firmware, wherein the version information carries at least two types of update validation operation identifiers; Comparing the update validation operation identifiers of the corresponding types in the version information of the current version firmware and the target version firmware for consistency; According to the comparison result, the trigger device determines whether to execute the update validation operation indicated by the update validation operation identifier; the comparison result is used to indicate whether the firmware update validation operation identifier has changed.

7. The device firmware update validation method according to claim 6, characterized in that: The update validation operation identifier includes: system restart identifier, hardware reset identifier and operation identifier; The triggering, based on the comparison result, of whether the device executes the update validation operation indicated by the update validation operation identifier includes: If the comparison result indicates that the system restart identifier in the firmware update validation operation identifier has changed, triggering the device to perform a system restart to make the target firmware update effective; If the comparison result indicates that the hardware reset flag in the firmware update validation operation flag has changed, triggering the device to perform a device hardware reset and reinitialization to make the target firmware update effective; If the comparison result indicates that the running identifier in the firmware update validation operation identifier has changed, the device is triggered to execute loading the target version firmware into the memory and overwriting the current version to make the target firmware update effective.

8. The device firmware update validation method according to claim 7, characterized in that: The version information is stored in a structured firmware file, which includes: Identification area information, storing the system restart identification, hardware reset identification and operation identification; Parameter area information, including hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart flag, and the software parameters are associated with the hardware reset flag and the running flag; The firmware area information is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness, and operation effectiveness.

9. The device firmware update validation method according to claim 7, characterized in that: The triggering device performs a hardware reset and reinitialization of the device, including: Sending a hardware reset signal to a reset pin of a device to perform a reset operation on the device; After the device completes the reset action, initializing the device; During the initialization process, running the target version firmware until the initialization is completed; or, Determine the register address for reset according to the device's register mapping table; Writing a preset reset configuration value to the register to trigger the reset logic inside the device; After the device completes the reset action, initializing the device; During the initialization process, the target version firmware is run until the initialization is completed.

10. An electronic device, characterized in that: include: A first acquiring unit is configured to acquire version information of a current version of firmware and a target version of firmware, wherein the version information carries at least two types of update validation operation identifiers; A first comparison unit is used to compare the update validation operation identifiers of corresponding types in the version information of the current version firmware and the target version firmware for consistency; The first execution unit is configured to execute the update validation operation indicated by the update validation operation identifier according to the comparison result; the comparison result is used to indicate whether the firmware update validation operation identifier has changed.

11. The electronic device according to claim 10, characterized in that The update validation operation identifier includes: a system restart identifier, a hardware reset identifier, and a running identifier; the first execution unit includes: a first execution module, configured to execute a system restart to make the target firmware update effective if the comparison result indicates that the system restart identifier in the firmware update effective operation identifier has changed; a second execution module, configured to, if the comparison result indicates that the hardware reset identifier in the firmware update validation operation identifier has changed, perform a hardware reset and reinitialization of the device to validate the target firmware update; The third execution module is used to execute loading the target version firmware into the memory and overwriting the current version to make the target firmware update effective if the comparison result indicates that the running identifier in the firmware update effectiveness operation identifier has changed.

12. The electronic device according to claim 11, wherein: The version information is stored in a structured firmware file, which includes: Identification area information, storing the system restart identification, hardware reset identification and operation identification; Parameter area information, including hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart flag, and the software parameters are associated with the hardware reset flag and the running flag; The firmware area information is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness, and operation effectiveness.

13. The electronic device according to claim 11, wherein: The second execution module includes: a first sending submodule, configured to send a hardware reset signal to a reset pin of a device to perform a reset operation on the device; A first execution submodule is configured to initialize the device after the device completes the reset action; or to determine a register address for reset based on a register mapping table of the device; write a preset reset configuration value to the register to trigger the reset logic within the device; and initialize the device after the device completes the reset action; The first running submodule is used to run the target version firmware during the initialization process until the initialization is completed.

14. The electronic device according to claim 10, wherein: The electronic device further comprises: The detection unit is used to detect the difference between the update validation operation identifiers of the current version of firmware and the target version of firmware in real time during the operation of the program configured for the current version of firmware.

15. An electronic device, characterized in that: include: A second acquiring unit is configured to acquire version information of the current version firmware and the target version firmware, wherein the version information carries at least two types of update validation operation identifiers; A second comparison unit compares the update validation operation identifiers of corresponding types in the version information of the current version firmware and the target version firmware for consistency; The triggering unit is used to trigger the device to execute the update validation operation indicated by the update validation operation identifier according to the comparison result.

16. The electronic device according to claim 15, characterized in that The update validation operation identifier includes: system restart identifier, hardware reset identifier and operation identifier; The trigger unit includes: a first triggering module configured to trigger a system restart of the device to make the target firmware update effective if the comparison result indicates that the system restart identifier in the firmware update effective operation identifier has changed; a second triggering module configured to trigger the device to perform a hardware reset and reinitialization of the device if the comparison result indicates that the hardware reset identifier in the firmware update validation operation identifier has changed, so as to validate the target firmware update; The third trigger module is used to trigger the device to load the target version firmware into the memory and overwrite the current version if the comparison result indicates that the running identifier in the firmware update effectiveness operation identifier has changed, so as to make the target firmware update effective.

17. The electronic device according to claim 16, wherein: The version information is stored in a structured firmware file, which includes: Identification area information, storing the system restart identification, hardware reset identification and operation identification; Parameter area information, including hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart flag, and the software parameters are associated with the hardware reset flag and the running flag; The firmware area information is configured to store firmware instructions and data, and the firmware area is divided into firmware sub-areas corresponding to system restart effectiveness, hardware reset effectiveness, and operation effectiveness.

18. The electronic device according to claim 16, wherein: The second trigger module includes: a second sending submodule, configured to send a hardware reset signal to a reset pin of a device to perform a reset operation on the device; A second execution submodule, configured to initialize the device after the device completes the reset action; The second running submodule is used to run the target version firmware during the initialization process until the initialization is completed; or to determine the register address for reset based on the register mapping table of the device; write a preset reset configuration value to the register to trigger the reset logic inside the device; after the device completes the reset action, initialize the device; during the initialization process, run the target version firmware until the initialization is completed.

19. A device firmware update validation method, characterized in that: include: Receive an update validation operation instruction, the instruction is generated by the master control end based on the comparison result of the update validation operation identifier of the current version firmware and the target version firmware, and the instruction is used to instruct to execute the update validation operation corresponding to the update validation operation identifier; According to the update validation operation instruction, the update validation operation corresponding to the update validation operation identifier is executed.

20. A storage medium, characterized in that include: The storage medium is configured to store device firmware, the device firmware including: an identification area storing at least two types of operation identifications indicating that a device firmware update is effective; The parameter area includes hardware parameters and software parameters, wherein the hardware parameters are associated with the system restart flag, and the software parameters are associated with the hardware reset flag and the running flag; A firmware area is configured to store firmware instructions and data.

21. The storage medium according to claim 20, wherein: The operation identifier includes: a system restart identifier, a hardware reset identifier and a running identifier; the firmware is divided into firmware sub-areas corresponding to the system restart effective, hardware reset effective and running effective.

22. An electronic device, characterized in that: include: A processing unit, configured to execute firmware upgrade related instructions and send corresponding firmware update validation mode control instructions based on the update validation operation identifier in the firmware version information; A storage management unit, located between the processing unit and the external memory, wherein the target version of the firmware is stored in the external memory, and the storage management unit is configured to obtain the stored firmware file and send it to the processing unit; the external memory is the storage medium according to any one of claims 20 to 21; A communication interface unit is connected to the processing unit and is configured to communicate with an external device, receive the current version firmware information sent by the external device and send it to the processing unit, and send the control instruction to the external device so that the external device performs the update validation operation corresponding to the update validation operation identifier indication.

Images