Firmware update method, processing unit, electronic device and storage medium

Abstract

This application provides a firmware update method, a processing unit, an electronic device, and a storage medium. The firmware update method is applied to a processing unit communicatively connected to a target unit. The processing unit is equipped with a first driver for controlling the target unit. The method includes: acquiring a second driver and mounting the second driver; loading various hardware resources required for firmware update of the target unit using the second driver, wherein at least some of the hardware resources cannot be loaded by the first driver; acquiring the first firmware and updating the target unit with the first firmware using the second driver based on the loaded hardware resources. This solution avoids the problem of firmware update failure caused by the system's built-in general-purpose driver failing to perform necessary operations before firmware update.

Description

Technical Field

[0001] This application relates to the field of electronic device technology, and in particular to a firmware update method, processing unit, electronic device, and storage medium. Background Technology

[0002] With the continuous development of electronic device technology, the application of pressure-sensitive touch devices, including but not limited to, has become a new trend. For mass-produced electronic devices currently in use by users (such as pressure-sensitive touch devices), there are often scenarios where it is necessary to update the embedded firmware running on the device module to optimize performance and user experience. Taking one type of pressure-sensitive touch device as an example, a pressure-sensitive touchpad is commonly used, which can achieve full-area pressing and can also provide tactile feedback at different pressure levels based on pressure levels, while working with a linear motor. When using this pressure-sensitive touch device, it is often necessary to update the firmware within the pressure-sensitive touchpad.

[0003] In related technologies, the operating system of electronic devices (such as pressure-sensitive touch devices) loads a built-in generic driver for electronic devices conforming to the HID over I2C standard protocol (this is just an example; other standard protocols may also apply). This generic driver cannot be forcibly uninstalled, and in some special cases, it can affect customized firmware updates of the electronic device. For example, when a customized firmware update requires pulling the reset pin of the electronic device high or low and limiting the pulse width, this operation is not included in the HID over I2C standard protocol. Therefore, such an operation cannot be achieved through the system's built-in generic driver, thus preventing the firmware update function from being implemented normally and affecting the subsequent use of the device. Therefore, a new technical solution is needed to avoid the problem of firmware updates failing due to the system's built-in generic driver's inability to perform the necessary operations before the firmware update. Summary of the Invention

[0004] In view of this, embodiments of this application provide a firmware update method, processing unit, electronic device, and storage medium, which can avoid the problem of firmware update failure caused by the inability of the built-in general driver to perform the necessary operations before firmware update.

[0005] According to one aspect of the embodiments of this application, a firmware update method is provided, applied to a processing unit communicatively connected to a target unit, the processing unit being equipped with a first driver for controlling the target unit, the method comprising:

[0006] Obtain the second driver and mount the second driver;

[0007] The second driver loads the hardware resources required for firmware update of the target unit using the first firmware, wherein at least some of the hardware resources cannot be loaded by the first driver.

[0008] The first firmware is obtained, and the second driver is used to update the first firmware to the target unit based on the loaded hardware resources.

[0009] In some optional embodiments, the method further includes: obtaining hardware resource configuration information required by the first firmware, the hardware resource configuration information including at least one of transmission bus resource configuration information, pin resource configuration information, and memory resource configuration information; the step of loading the hardware resources required for firmware update of the target unit using the first firmware through the second driver includes: configuring each hardware resource according to the hardware resource configuration information through the second driver, and loading each hardware resource after configuration.

[0010] In some optional embodiments, the processing unit is communicatively connected to the target unit via a first transmission bus, and the processing unit uses a first driver to control the target unit via the first transmission bus; the step of using the second driver to update the first firmware to the target unit based on the loaded hardware resources includes: using the second driver to update the first firmware to the target unit based on the loaded hardware resources via the first transmission bus, wherein the address used by the first driver is different from the address used by the second driver.

[0011] In some optional embodiments, the processing unit is communicatively connected to the target unit via a first transmission bus, and the processing unit is also communicatively connected to the target unit via a second transmission bus; the processing unit uses the first driver to control the target unit via the first transmission bus; the step of using the second driver to update the first firmware to the target unit based on the loaded hardware resources includes: using the second driver to update the first firmware to the target unit based on the loaded hardware resources via the second transmission bus.

[0012] In some optional embodiments, the processing unit is also mounted with a human-computer interaction program; the step of obtaining the first firmware includes: in response to a user's selection instruction to select the first firmware in the human-computer interaction program, obtaining the first firmware from a storage unit connected to the processing unit.

[0013] In some optional embodiments, the processing unit is also equipped with a human-computer interaction program; the step of updating the first firmware to the target unit using the second driver based on the loaded hardware resources includes: in response to an update command issued by the user through the human-computer interaction program, updating the first firmware to the target unit using the second driver based on the loaded hardware resources.

[0014] In some optional embodiments, after obtaining the first firmware, the method further includes: verifying the first firmware, and / or comparing the version number of the first firmware.

[0015] According to another aspect of the embodiments of this application, a processing unit is provided, the processing unit being communicatively connected to a target unit and having a first driver program for controlling the target unit mounted thereon, the processing unit comprising:

[0016] The acquisition module is used to acquire the second driver and mount the second driver.

[0017] A loading module is configured to load various hardware resources required for firmware update of the target unit using the first firmware via the second driver, wherein at least some of the hardware resources cannot be loaded via the first driver.

[0018] An update module is used to obtain the first firmware and use the second driver to update the first firmware to the target unit based on the loaded hardware resources.

[0019] According to another aspect of the embodiments of this application, an electronic device is provided, the electronic device including a target unit and a processing unit, the target unit being communicatively connected to the processing unit, the processing unit being mounted with a first driver for controlling the target unit, the processing unit being configured to: acquire a second driver and mount the second driver; load various hardware resources required for firmware update of the target unit using the second driver, wherein at least some of the hardware resources cannot be loaded by the first driver; acquire the first firmware and update the first firmware to the target unit using the second driver based on the loaded hardware resources.

[0020] According to another aspect of the embodiments of this application, a computer storage medium is provided, wherein the computer storage medium stores computer instructions for causing a computer to perform the firmware update method according to any of the preceding claims.

[0021] According to another aspect of the embodiments of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the firmware update method described in any of the preceding claims.

[0022] In summary, the technical solution in this application embodiment, because the processing unit can obtain and mount the second driver, can load the hardware resources required for firmware update of the target unit using the first firmware through the second driver. At least some of these hardware resources cannot be loaded through the first driver mounted on the processing unit for controlling the target unit. Finally, the first firmware can be obtained, and the second driver can be used to update the first firmware to the target unit based on the loaded hardware resources. Therefore, this application loads the hardware resources that cannot be mounted through the first driver by additionally mounting the second driver, thereby loading the hardware resources required for firmware update of the target unit using the first firmware. This allows the first firmware to be updated to the target unit through the second driver. When the first driver is a system-built-in general driver, the problem of firmware update failure due to the first driver's inability to perform necessary operations before firmware update is avoided, ensuring the subsequent use effect of the target unit and the electronic device with the target unit installed. Attached Figure Description

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

[0024] Figure 1 A schematic diagram of an exemplary electronic device according to an embodiment of this application is shown.

[0025] Figure 2 A flowchart of an exemplary firmware update method according to this application is shown.

[0026] Figure 3 A schematic diagram illustrating an exemplary hardware connection between the processing unit and the target unit according to this application is shown.

[0027] Figure 4 A schematic diagram of another exemplary hardware connection between the processing unit and the target unit according to this application is shown.

[0028] Figure 5 An exemplary software hierarchy diagram according to this application is shown.

[0029] Figure 6 Another exemplary software hierarchy diagram according to this application is shown.

[0030] Figure 7 A flowchart illustrating an exemplary firmware update process according to this application is shown.

[0031] Figure 8 A block diagram of an exemplary processing unit according to this application is shown. Detailed Implementation

[0032] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of this application.

[0033] In related technologies, the operating system of electronic devices (such as pressure-sensitive touch devices) loads a built-in generic driver for electronic devices conforming to the HID over I2C standard protocol (this is just an example; other standard protocols may also apply). This generic driver cannot be forcibly uninstalled, and in some special cases, it can affect customized firmware updates of the electronic device. For example, when a customized firmware update requires pulling the reset pin of the electronic device high or low and limiting the pulse width, this operation is not included in the HID over I2C standard protocol. Therefore, such an operation cannot be achieved through the system's built-in generic driver, thus preventing the firmware update function from being implemented normally and affecting the subsequent use of the device. Therefore, a new technical solution is needed to avoid the problem of firmware updates failing due to the system's built-in generic driver's inability to perform the necessary operations before the firmware update.

[0034] To address this issue, this application provides a firmware update solution that avoids the problem of firmware updates failing to function properly due to the inability of the system's built-in general-purpose drivers to perform the necessary operations before the firmware update. Figure 1 A schematic diagram of an exemplary electronic device according to an embodiment of this application is shown. (Refer to...) Figure 1As shown, optionally, the target unit 101 may belong to the same electronic device 100 as the processing unit 102. The firmware update method of this application can be applied to the processing unit 102, which is communicatively connected to the target unit 101. The processing unit 102 can update the firmware of the target unit 101 by executing the firmware update method of this application. Optionally, the processing unit 102 may include at least one chip for data processing, such as a CPU, MCU, DSP, FPGA, etc.

[0035] As an optional example, taking electronic device 100 as a touch device (such as a mobile phone, PAD, etc. with touch function), target unit 101 can be a touch screen, and processing unit 102 can be a processor on the touch device that is communicatively connected to the touch screen. For the sake of explaining this embodiment, the target unit 101 will be the touch screen in the following text.

[0036] In a specific scenario of this application, the processing unit 102 is equipped with a first driver for controlling the target unit 101. Specifically, both the processing unit 102 and the target unit 101 conform to a standard protocol. For example, in some embodiments, the standard protocol is the HID over I2C standard protocol, but it should be understood that this is only an example and other standard protocols may also be used (but for the sake of illustration, the standard protocol will be the HID over I2C standard protocol in the following text). The first driver is a built-in general driver required to conform to the standard protocol and cannot be forcibly uninstalled. By mounting the first driver, the processing unit 102 can achieve data interaction and control functions with the target unit 101 through a communication link based on the standard protocol (for example, a transmission bus; taking the aforementioned HID over I2C standard protocol as an example, the communication link can be an I2C bus connecting the processing unit 102 and the target unit 102). For example, taking the aforementioned HID over I2C standard protocol as an example, in normal working mode (i.e., when no firmware update is performed), the first driver can cooperate with the firmware already running on the target unit 101 to implement HID function.

[0037] Figure 2 A flowchart illustrating an exemplary firmware update method according to this application is shown. (Refer to...) Figure 2 As shown, the method includes the following steps S101, S102 and S103.

[0038] Step S101: Obtain the second driver and mount the second driver.

[0039] The second driver in this application can be used to subsequently update the firmware of the target unit 101 using the first firmware. Its specific implementation will be described in detail below and will not be repeated here. In this application, the second driver can be obtained by the processing unit 102 from a storage unit electrically connected to the processing unit 102. This storage unit can be a memory, database, etc. After obtaining the second driver, the processing unit 101 responds to user instructions or runs it automatically, thereby mounting it. Optionally, the second driver can be provided by the supplier of the target unit 101.

[0040] For example, in some optional embodiments, the processing unit 102 is also equipped with a human-computer interaction program. In this case, step S101 may include: in response to a user's selection instruction to choose a second driver in the human-computer interaction program, retrieving the second driver from a storage unit connected to the processing unit 102, and in response to a user's mounting instruction issued through the human-computer interaction program, mounting the first driver. In this way, customized selection of the second driver can be achieved, and customized firmware updates of the target unit 101 can be implemented using the second driver and the first firmware. The human-computer interaction program will be further described below and will not be repeated here.

[0041] Step S102: Load the hardware resources required for firmware update of the target unit using the first firmware through the second driver.

[0042] In step S102, at least some of the hardware resources cannot be loaded by the first driver.

[0043] Specifically, updating the firmware of the target unit 101 using the first firmware means updating the firmware that was originally running in the target unit 101 to the first firmware. Specifically, the first firmware can be written into the storage medium of the target unit 101, so that the target unit 101 can switch from the original firmware to the first firmware.

[0044] Optionally, the second driver in this application can enumerate the hardware resources required for firmware update of target unit 101 using the first firmware after mounting, and load the hardware resources required for firmware update of target unit 101 using the first firmware. If at least some hardware resources cannot be loaded by the first driver, this may mean that the first driver does not support loading these hardware resources. For example, as mentioned above, during customized firmware updates, when it is necessary to pull the reset pin of the electronic device high or low and limit the pulse width, this operation is not included in the HID over I2C standard protocol (as an example), and therefore such an operation cannot be implemented through the system's built-in general driver (i.e., loading these hardware resources is completed by the first driver).

[0045] In some optional embodiments, the firmware update method further includes: obtaining hardware resource configuration information required for the first firmware, wherein the hardware resource configuration information includes at least one of the following: transmission bus resource configuration information, pin resource configuration information, and memory resource configuration information; then step S102 includes: configuring each hardware resource according to the hardware resource configuration information through the second driver, and loading each hardware resource after configuration.

[0046] In this application, the hardware resources for firmware updates can be configured according to the hardware resource configuration information required by different first firmwares, so that the hardware resources after loading can meet the needs of custom firmware updates of the target unit 101 using the first firmware.

[0047] Optionally, the transmission bus resource configuration information may indicate at least one of the following: which transmission buses (e.g., I2C bus) are used when updating firmware using the first firmware, and which addresses are used when using these transmission buses; alternatively, the pin resource configuration information may indicate at least one of the following: which pins are used when updating firmware using the first firmware (e.g., GPIO used for the reset pin of the device), which voltage level is used when using these pins, and how long this voltage level is maintained; alternatively, the memory resource configuration information may indicate at least one of the following: how much memory is used when updating firmware using the first firmware, and which part of the memory is used. It should be understood that this is not intended to limit the scope of this application.

[0048] Of course, the hardware resource configuration information may also include other hardware resource configuration information, which can be determined according to the specific needs when performing customized firmware updates on the target unit 101 using the first firmware. This application does not impose any special restrictions here. For example, the hardware resource configuration information may also include interrupt resource configuration information, etc.

[0049] Optionally, in this application, hardware resource configuration information can be represented as hardware resource descriptions. "Obtaining the hardware resource configuration information required for the first firmware" can be achieved by adding an additional device node to the processing unit 101 and inputting the corresponding hardware resource description. The processing unit 101 then obtains the specific hardware resource configuration information through the hardware resource description. For example, assuming both the processing unit 102 and the target unit 101 conform to the HID over I2C standard protocol, hardware resource descriptions (such as I2C hardware resource descriptions, pin hardware resource descriptions (e.g., GPIO used for the reset pin), memory hardware resource descriptions, and other necessary hardware resource descriptions) can be added using the ACPI (Advanced Configuration and Power Management Interface) of the processing unit 101 in the ASL (ACPI Source Language). The processing unit 101 obtains the specific hardware resource configuration information through this hardware resource description, enabling the processing unit 102 to configure each hardware resource through the second driver, ensuring that the loaded hardware resources meet the requirements for customized firmware updates of the target unit 101 using the first firmware.

[0050] Figure 3 A schematic diagram illustrating an exemplary hardware connection between the processing unit and the target unit according to this application is shown. (Refer to...) Figure 3 As shown, in some optional embodiments, the processing unit 101 is communicatively connected to the target unit 102 via a first transmission bus ZXA, and the processing unit 102 is also communicatively connected to the target unit 102 via a second transmission bus ZXB. Specifically, when hardware resources are sufficient, the processing unit 101 and the target unit 102 can have two communication connections, and the two communication connections formed by the first transmission bus ZXA and the second transmission bus ZXB can be independent of each other, and different functions can be implemented through the two communication connections respectively.

[0051] Optionally, the type of the first transmission bus ZXA and the second transmission bus ZXB is determined according to the standard protocol. For example, both are I2C buses, and both communication connections are I2C connections. The two I2C connections between the processing unit 101 and the target unit 102 can be independent of each other, and different functions can be implemented through the two I2C connections respectively.

[0052] Reference Figure 3In the example shown, the dashed box L1 represents the hardware resource connection between the processing unit 101 and the target unit 102 that conforms to the HID over I2C standard protocol. This connection is used to implement the standard functions of the HID over I2C standard protocol, including an I2C bus (i.e., the first transmission bus ZXA) and an interrupt line for the target unit 101 to notify the processing unit 102 to read the HID report. The dashed box L2 represents the hardware resource connection between the processing unit 101 and the target unit 102 for firmware updates. This connection includes an I2C bus (i.e., the second transmission bus ZXB), a reset pin (for resetting the target unit 101's general purpose input / output pins (GPIO)), and other necessary hardware connections (such as memory resources) for customized firmware updates.

[0053] exist Figure 3 In this example, after processing unit 102 loads the hardware resources required for firmware update of target unit 101 using the second driver, the hardware connections in dashed box L2 are loaded, thus enabling the subsequent firmware update process. It should be understood that... Figure 3 The hardware connection diagrams in this application are not intended to limit the scope of this application.

[0054] Figure 4 A schematic diagram illustrating another exemplary hardware connection between the processing unit and the target unit according to this application is shown. (Refer to...) Figure 4 As shown, in some optional embodiments, the processing unit 101 is communicatively connected to the target unit 102 via the first transmission bus ZXA. Specifically, when hardware resources are limited, the processing unit 101 and the target unit 102 may have only one communication connection, and different functions may be implemented through the communication connection formed by the first transmission bus ZXA.

[0055] Optionally, the type of the first transmission bus ZXA is determined according to the standard protocol. For example, the first transmission bus ZXA can be an I2C bus to realize I2C connection. Different functions can be realized through the I2C connection formed by the first transmission bus ZXA.

[0056] Reference Figure 4In the example shown, dashed box L1 represents the hardware resource connection between processing unit 101 and target unit 102 that conforms to the HID over I2C standard protocol. This connection is used to implement the standard functions of the HID over I2C standard protocol, including an I2C bus (i.e., the first transmission bus ZXA) and an interrupt line for target unit 101 to notify processing unit 102 to read the HID report. Dashed box L2 represents the hardware connection between processing unit 101 and target unit 102 for firmware updates. This connection includes the I2C bus (i.e., the first transmission bus ZXA) in dashed box L1, a reset pin (a general-purpose input / output pin (GPIO) for resetting target unit 101), and other necessary hardware connections (e.g., memory resources) for customized firmware updates. The hardware connections in dashed boxes L1 and L2 share the first transmission bus ZXA.

[0057] exist Figure 4 In this example, after processing unit 102 loads the hardware resources required for firmware update of target unit 101 using the second driver, the hardware connections in dashed box L2 are loaded, thus enabling the subsequent firmware update process. It should be understood that... Figure 4 The hardware connection diagrams in this application are not intended to limit the scope of this application.

[0058] To achieve this, different addresses (which could be communication addresses, such as I2C addresses) are used for different functions. Specifically, different I2C addresses are used for functions implementing the HID over I2C standard protocol and for functions used to update the customized firmware of the target unit 101. Specifically, this can be achieved by configuring the hardware resource description (e.g., the I2C hardware resource description). The processing unit 101 obtains specific hardware resource configuration information (corresponding to the aforementioned transmission bus resource configuration information) through this description. This allows the processing unit 102 to configure the I2C bus hardware resources using the second driver, ensuring that the loaded I2C bus hardware resources meet the requirements for updating the target unit 101 using the first firmware.

[0059] Step S103: Obtain the first firmware and use the second driver to update the first firmware to the target unit based on the loaded hardware resources.

[0060] The firmware update method in this application, because the processing unit 102 can obtain and mount the second driver, can load the hardware resources required for firmware update of the target unit 101 using the first firmware through the second driver. At least some of the hardware resources cannot be loaded by the first driver mounted on the processing unit for controlling the target unit. Finally, the first firmware can be obtained, and the second driver can be used to update the first firmware to the target unit based on the loaded hardware resources. Therefore, by additionally mounting the second driver, the hardware resources that cannot be mounted by the first driver are loaded, so as to realize the loading of the hardware resources required for firmware update of the target unit 101 using the first firmware, the first firmware can be updated to the target unit 101 through the second driver. When the first driver is a system-built-in general driver, the problem of firmware update failure caused by the first driver not being able to perform the necessary operations before firmware update is avoided, ensuring the subsequent use effect of the target unit 101 and the electronic device on which the target unit 101 is installed.

[0061] Figure 5 An exemplary software hierarchy diagram according to this application is shown. In some alternative embodiments, reference is made to... Figure 3 and Figure 5 As shown, the processing unit 102 is communicatively connected to the target unit 101 via the first transmission bus ZXA, and the processing unit 102 is also communicatively connected to the target unit 101 via the second transmission bus ZXB; the processing unit 101 uses the first driver to control the target unit 101 via the first transmission bus ZXA; the step S103 of "updating the first firmware to the target unit based on the loaded hardware resources using the second driver" includes: updating the first firmware to the target unit based on the loaded hardware resources using the second driver via the second transmission bus.

[0062] Regarding the communication connection between processing unit 102 and target unit 101 via the first transmission bus ZXA and the second transmission bus ZXB, the details can be found in step S102 above. Figure 3 The relevant explanations will be understood here, and will not be repeated.

[0063] Taking the HID over I2C standard protocol as an example, both the first driver and the second driver use I2C addresses, and both the first transmission bus ZXA and the second transmission bus ZXB are I2C buses. Since an I2C bus can only be used for one purpose at a time, the first driver and the second driver use different I2C buses (i.e., the first transmission bus ZXA). To achieve this, according to the I2C standard, the I2C addresses used by the first driver and the second driver can be the same or different. The first driver implements the standard functions of the HID over I2C standard protocol; processing unit 101 uses this first driver to control target unit 101 via the first transmission bus ZXA. The second driver is used for customized firmware updates to target unit 101; processing unit 102 uses the second driver via the first transmission bus ZXA to update the first firmware to target unit 101 based on the loaded hardware resources. Therefore, the first driver and the second driver can use the same I2C address, or they can use different I2C addresses. Specifically, by setting the same or different I2C addresses in the aforementioned hardware resource description (e.g., I2C hardware resource description) (e.g., when the I2C addresses are the same, the first driver is set to "address 1, bus ZXA", and the second driver is set to "address 1, bus ZXB"; or, when the I2C addresses are different, the first driver is set to "address 1, bus ZXA", and the second driver is set to "address 2, bus ZXB"), the processing unit 101 obtains specific hardware resource configuration information (corresponding to the aforementioned transmission bus resource configuration information) through the hardware resource description. This allows the processing unit 102 to configure the I2C bus hardware resources through the second driver, ensuring that the loaded I2C bus hardware resources meet the requirements for customized firmware updates of the target unit 101 using the first firmware. It should be understood that these descriptions are only for illustrative purposes and are not intended to limit the scope of this application.

[0064] Figure 6 Another exemplary software hierarchy diagram according to this application is shown. In some alternative embodiments, reference is made to... Figure 4 and Figure 6As shown, the processing unit 102 is communicatively connected to the target unit 101 via the first transmission bus ZXA. The processing unit 102 uses a first driver to control the target unit 101 via the first transmission bus ZXA. Step S103, "updating the first firmware to the target unit using the second driver based on the loaded hardware resources," includes: updating the first firmware to the target unit using the second driver via the first transmission bus based on the loaded hardware resources. The addresses used by the first driver and the second driver are different. This implementation method consumes fewer hardware resources. The first driver and the second driver use different addresses (which can be communication addresses, such as I2C addresses), enabling multiplexing of a single hardware communication link.

[0065] Regarding the connection between processing unit 102 and target unit 101 via the first transmission bus ZXA, this can be discussed in conjunction with the previous steps S102. Figure 4 The relevant explanations will be understood here, and will not be repeated.

[0066] Taking the HID over I2C standard protocol as an example, both the first driver and the second driver use I2C addresses, and the first transmission bus ZXA is an I2C bus. Since the I2C bus can only be used for one purpose at a time, both the first and second drivers use the same I2C bus (i.e., the first transmission bus ZXA). To achieve this, due to the constraints of the I2C standard, different addresses must be used for different functions. Specifically, different I2C addresses are used for the standard functions implementing the HID over I2C standard protocol and for updating the customized firmware of the target unit 101. The first driver implements the standard functions of the HID over I2C standard protocol, and the processing unit 101 uses this first driver to control the target unit 101 via the first transmission bus ZXA. The second driver updates the customized firmware of the target unit 101, and the processing unit 102 uses the second driver to update the first firmware to the target unit 101 based on the loaded hardware resources via the first transmission bus ZXA. Therefore, different I2C addresses are required for the first and second drivers. Specifically, by setting different I2C addresses in the aforementioned hardware resource description (e.g., I2C hardware resource description) (e.g., the first driver is set to "address 1, bus ZXA", and the second driver is set to "address 2, bus ZXA"), the processing unit 101 obtains specific hardware resource configuration information (corresponding to the aforementioned transmission bus resource configuration information) through the hardware resource description. This allows the processing unit 102 to configure the I2C bus hardware resources through the second driver, ensuring that the loaded I2C bus hardware resources meet the requirements for customized firmware updates of the target unit 101 using the first firmware. It should be understood that these descriptions are only for illustrative purposes and are not intended to limit the scope of this application.

[0067] Next, let's combine Figure 5 and Figure 6 A further explanation of the software layers in this application is provided for easier understanding. (Refer to...) Figure 5 and Figure 6As shown, optionally, the processing unit 102 is equipped with a first driver, a second driver, and a human-machine interaction program, while the target unit 101 is equipped with a firmware boot program. The top-level human-machine interaction program is mounted on the processing unit 102 and can be used by the user to specify the firmware file on the system side (e.g., select the first firmware), display the progress of firmware updates on the target unit 101, etc. (This human-machine interaction program has been briefly described above and will be further described in detail below, so it will not be repeated here). The first and second drivers in the intermediate layer are both mounted on the processing unit 102, forming the driver layer. The first driver can be used to control the target unit 101. It can be an automatically mounted system-built-in HID over I2C driver. This driver cannot be forcibly unloaded and replaced with a device vendor's driver. When the device is in normal operating mode (i.e., not updating the firmware of the target unit 101), this driver can work with the firmware already running on the target unit 101 to implement HID functionality. The second driver can be used to update the firmware of the target unit 101. This driver can be provided by the supplier of the target unit 101. It is mainly responsible for implementing customized firmware update logic, controlling and loading hardware resources outside the HID over I2C standard (i.e., hardware resources that cannot be driven and loaded by the first driver), etc. The lowest-level firmware boot program is mounted on the target unit 101. It is responsible for writing firmware data (e.g., including the first firmware for firmware update) transmitted through the I2C bus (such as the first transmission bus ZXA) to the storage medium of the target unit 101, verifying the integrity of the firmware data, and jumping to the updated first firmware for execution, etc. (Refer to...) Figure 6 As shown, this is a scenario where the processing unit 102 communicates with the target unit 101 via a single I2C bus. The first driver and the second driver share the same I2C bus, but the I2C addresses used by the first driver and the second driver are different. (Refer to...) Figure 5 The diagram illustrates a scenario where the processing unit 102 communicates with the target unit 101 via two I2C buses. The first driver and the second driver use different I2C buses, and the I2C addresses used by the first driver and the second driver can be the same or different. It should be understood that the above description is not intended to limit the scope of this application.

[0068] In some optional embodiments, the processing unit 101 is also equipped with a human-machine interface program. Step S103, "obtain the first firmware," includes: in response to a user's selection instruction to choose the first firmware in the human-machine interface program, obtaining the first firmware from a storage unit connected to the processing unit 102. This application enables customized selection of the first firmware in this manner, utilizing the second driver and the first firmware to perform customized firmware updates on the target unit 101. The storage unit can be a memory, a database, etc.

[0069] Optionally, taking an electronic device 100 as a mobile phone, a target unit 101 as the touchscreen of the mobile phone, and a processing unit 102 as the processor of the mobile phone as an example, a human-computer interaction program is mounted on the processing unit 102. The human-computer interaction program may include a human-computer interaction interface, which has buttons or options for selection and operation, and can be displayed on the target unit 101 during operation. The user can select the first firmware by touching the buttons or options of the target unit 101, thereby issuing a selection command for selecting the first firmware through the human-computer interaction program. The processing unit 102 obtains the first firmware from the storage unit connected to the processing unit 102 through the human-computer interaction program for customized firmware updates of the target unit 101.

[0070] In some optional embodiments, the processing unit 101 is also equipped with a human-computer interaction program. The step S103 of "updating the first firmware to the target unit using the second driver based on the loaded hardware resources" includes: in response to the update command issued by the user through the human-computer interaction program, updating the first firmware to the target unit using the second driver based on the loaded hardware resources.

[0071] This application achieves two advantages: First, it enables human-computer interaction and driver coordination during firmware updates of the target unit 101, allowing users to control customized firmware updates using the second driver and the first firmware via a human-computer interaction program. Second, some firmware boot programs mounted on the target unit 101 (used for writing firmware data to the target unit 101's storage medium, verifying firmware data integrity, and jumping to the updated first firmware) do not support the HID over I2C standard protocol. Therefore, the firmware boot program cannot parse the firmware data encapsulated in the protocol, leading to firmware updates failing. In this solution, the processing unit 101 responds to the update command issued by the user through the human-computer interaction program, using the second driver to update the first firmware to the target unit 101 based on the loaded hardware resources. This eliminates the need for the target unit 101's firmware boot program to parse the firmware data encapsulated in the HID over I2C standard protocol (equivalent to the second driver program directly sending the firmware data that the firmware boot program can parse to the firmware boot program). Therefore, this method also achieves compatibility with HID over I2C. The I2C standard protocol avoids the problem of firmware updates failing because the firmware boot program cannot parse the firmware data encapsulated in the protocol. On the other hand, different protocols can be selected through the human-machine interface program to interact with the firmware boot program of the target unit 101 to achieve firmware updates, increasing the flexibility of firmware updates and making it easier to complete the process of customized firmware updates for the target unit 101.

[0072] In some optional embodiments, after obtaining the first firmware, the firmware update method further includes: verifying the first firmware, and / or comparing the version number of the first firmware. Verifying the first firmware may include at least one of correctness verification, integrity verification, and legality verification, which can be used to prevent the first firmware from being tampered with and to prevent security issues after the firmware update of the target unit 101. Comparing the version number of the first firmware can determine whether the obtained first firmware is the required version (e.g., the latest version), to ensure that the first firmware can meet the requirements of the customized firmware update for the target unit 101, and to ensure that the customized firmware update achieves the expected results.

[0073] Figure 7 A flowchart illustrating an exemplary firmware update process according to this application is shown. The following is in conjunction with... Figure 7 The illustrated working process further explains step S103 of this application. This example includes the following steps S701 to S706.

[0074] Step S701: The user selects the first firmware through the human interaction program mounted on the processing unit.

[0075] Step S702: The processing unit obtains the first firmware from the storage unit through the human-machine interaction program and performs a correctness check on the first firmware.

[0076] Optionally, step S702 can be used to prevent the first firmware from being tampered with.

[0077] Step S703: The processing unit verifies the conditions for updating the target unit using the first firmware through a human-machine interaction program.

[0078] Optionally, step S703 may include comparing the version number of the first firmware, which may be to determine whether the obtained first firmware is the required version (e.g., the latest version).

[0079] Step S704: The processing unit sends an instruction through the human-machine interaction program to enter the firmware update state.

[0080] Optionally, the processing unit 102 loads the hardware resources required for firmware update of the target unit 101 using the first firmware via the second driver, thereby enabling it to enter the firmware update state.

[0081] Step S705: The processing unit interacts with the target unit through the human-machine interaction program using the second driver to complete the firmware update process.

[0082] Optionally, the processing unit 102 uses the second driver to update the first firmware to the target unit 101 based on the loaded hardware resources, thereby completing the firmware update process.

[0083] Step S706: The processing unit sends an instruction through the human-machine interaction program to cause the target unit to run the first firmware updated in the target unit through the second driver program.

[0084] Based on this, through the above working process, the purpose of updating the first firmware to the target unit 101 can be achieved, thereby completing the customized firmware update of the target unit 101.

[0085] It is understood that the above embodiments are merely examples of firmware update methods in this application, and not any limitation thereof.

[0086] Therefore, through the technical solutions in the above optional embodiments, this embodiment can realize the customized firmware update requirements of the target unit 101 of the electronic device 100 that conforms to the HID over I2C standard protocol. When it is necessary to control hardware connections outside the standard protocol to realize firmware update, or when the firmware boot program of the target unit 101 does not support the HID over I2C standard protocol, this embodiment can realize firmware update and upgrade without disassembly or restart at the user end.

[0087] In summary, the firmware update scheme of this embodiment can effectively avoid the problem of firmware update failure caused by the inability of the aforementioned built-in general driver to perform the necessary operations before firmware update.

[0088] Based on the same inventive concept as the aforementioned firmware update method embodiments, and according to another aspect of the implementation of this application, referring to... Figure 8 As shown, a processing unit 102 is provided, which is communicatively connected to a target unit 101 and is equipped with a first driver program for controlling the target unit 101. The processing unit 102 includes:

[0089] The acquisition module 1021 is used to acquire the second driver and mount the second driver;

[0090] The loading module 1022 is used to load the hardware resources required for firmware update of the target unit 101 using the first firmware through the second driver, wherein at least some of the hardware resources cannot be loaded by the first driver.

[0091] The update module 1023 is used to obtain the first firmware and use the second driver to update the first firmware to the target unit 101 based on the loaded hardware resources.

[0092] The processing unit 102 in this application embodiment has been described in detail in the aforementioned firmware update method embodiment. Therefore, its related content and beneficial effects can be understood by referring to the content of the various optional embodiments of the above method, and will not be repeated here.

[0093] According to another aspect of the embodiments of this application, referring to Figure 1 As shown, an electronic device 100 is provided, which includes a target unit 101 and a processing unit 102. The target unit 101 is communicatively connected to the processing unit 102. The processing unit 102 is equipped with a first driver for controlling the target unit. The processing unit 102 is configured to: acquire a second driver and load the second driver; load the hardware resources required for firmware updates of the target unit using the second driver, wherein at least some of the hardware resources cannot be loaded by the first driver; acquire the first firmware and update the first firmware to the target unit 101 using the second driver based on the loaded hardware resources.

[0094] The electronic device 100 in this application embodiment has been described in detail in the aforementioned firmware update method embodiment. Therefore, its related content and beneficial effects can be understood by referring to the above method embodiment, and will not be repeated here.

[0095] According to another aspect of the embodiments of this application, a computer storage medium is provided, wherein the computer storage medium stores computer instructions for causing a computer to perform the firmware update method according to any of the preceding claims.

[0096] According to another aspect of the embodiments of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the firmware update method described in any of the preceding claims.

[0097] As the embodiments of computer storage media and computer program products are basically similar to the above method embodiments, the description is relatively simple. For relevant details, please refer to the description of the above method embodiments, and they will not be repeated here.

[0098] It is understood that the above embodiments are merely experimental examples of some examples in the embodiments of this application, and are not any limitation on the firmware update method, processing unit, electronic device, computer storage medium, or computer program product in the embodiments of this application.

[0099] It should be noted that the term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are only used to distinguish different devices, modules, or units, and are not used to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0100] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0101] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of this application, and are not intended to limit them; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A firmware update method characterized by comprising: The method is applied to a processing unit in communication connection with a target unit, the processing unit is mounted with a first driver for controlling the target unit, and the method comprises: obtaining a second driver and mounting the second driver; loading, by the second driver, each hardware resource required when the target unit is updated with a first firmware, wherein at least part of the hardware resources cannot be loaded by the first driver; obtaining the first firmware and updating the first firmware to the target unit based on the loaded hardware resources by the second driver; The method further comprises obtaining hardware resource configuration information required by the first firmware, wherein the hardware resource configuration information at least comprises at least one of transmission bus resource configuration information, pin resource configuration information and memory resource configuration information; The method further comprises obtaining hardware resource configuration information required by the first firmware, wherein the hardware resource configuration information at least comprises at least one of transmission bus resource configuration information, pin resource configuration information and memory resource configuration information; The method further comprises obtaining hardware resource configuration information required by the first firmware, wherein the hardware resource configuration information at least comprises at least one of transmission bus resource configuration information, pin resource configuration information and memory resource configuration information; The processing unit is in communication connection with the target unit through a first transmission bus, and the processing unit controls the target unit through the first transmission bus by using the first driver; The method further comprises obtaining hardware resource configuration information required by the first firmware, wherein the hardware resource configuration information at least comprises at least one of transmission bus resource configuration information, pin resource configuration information and memory resource configuration information; 2. The method of claim 1, wherein: the processing unit is in communication connection with the target unit through a first transmission bus, and the processing unit is also in communication connection with the target unit through a second transmission bus; the processing unit controls the target unit through the first transmission bus by using the first driver; The method further comprises obtaining hardware resource configuration information required by the first firmware, wherein the hardware resource configuration information at least comprises at least one of transmission bus resource configuration information, pin resource configuration information and memory resource configuration information; The method further comprises obtaining hardware resource configuration information required by the first firmware, wherein the hardware resource configuration information at least comprises at least one of transmission bus resource configuration information, pin resource configuration information and memory resource configuration information; The processing unit is also mounted with a human-computer interaction program; 3. The method of claim 1, wherein, The method further comprises obtaining the first firmware, comprising: in response to a selection instruction of the first firmware selected by a user in the human-computer interaction program, obtaining the first firmware from a storage unit connected to the processing unit. The processing unit is also mounted with a human-computer interaction program; 4. The method of claim 1, wherein, The method further comprises obtaining hardware resource configuration information required by the first firmware, wherein the hardware resource configuration information at least comprises at least one of transmission bus resource configuration information, pin resource configuration information and memory resource configuration information; in response to an update instruction issued by a user through the human-computer interaction program, updating the first firmware to the target unit based on the loaded hardware resources by the second driver. ​ 5. The method according to any one of claims 1 to 4, characterized in that, The method further comprises: checking the first firmware, and / or comparing version numbers of the first firmware.

6. A processing unit, characterized by The processing unit is in communication connection with a target unit, and is mounted with a first driver for controlling the target unit, and the processing unit comprises: an obtaining module, configured to obtain a second driver and mount the second driver; a loading module, configured to load, by the second driver, each hardware resource required when the target unit is updated with the first firmware, wherein at least part of the hardware resources cannot be loaded by the first driver; an updating module, configured to obtain the first firmware and update the first firmware to the target unit based on the loaded hardware resources by the second driver; The processing unit is further configured to obtain hardware resource configuration information required by the first firmware, and the hardware resource configuration information at least comprises at least one of transmission bus resource configuration information, pin resource configuration information and memory resource configuration information; The loading module is configured to: configure each hardware resource according to the hardware resource configuration information by the second driver, and load each hardware resource after the configuration is completed; The processing unit is in communication connection with the target unit through a first transmission bus, and the processing unit controls the target unit through the first transmission bus by using a first driver; The loading module is further configured to: update the first firmware to the target unit based on the loaded hardware resources by the second driver through the first transmission bus, wherein an address used by the first driver is different from an address used by the second driver.

7. An electronic device using the firmware updating method according to any one of claims 1-5.

8. A computer storage medium, characterized in that, The computer storage medium stores computer instructions for causing a computer to execute the firmware updating method according to any one of claims 1-5.

9. A computer program product, characterised in that, The computer program, when executed by a processor, implements the firmware updating method according to any one of claims 1-5.

Images