Firmware upgrading method and device, electronic equipment and readable storage medium

Abstract

The invention provides a firmware upgrading method and device, electronic equipment and a readable storage medium, and relates to the technical field of servers, the firmware upgrading method is applied to a server, the server comprises a plurality of core boards, and the firmware upgrading method comprises the steps that an upgrading firmware file is obtained based on the fastboot technology, the upgrade firmware file comprises a plurality of upgrade data packets; after an upgrading starting signal is received, all the core boards are traversed in sequence, the traversed core boards serve as first core boards, and a first hardware version type of the first core boards is determined; a target upgrading data packet corresponding to the first hardware version type is determined according to the upgrading data packets, firmware upgrading is carried out on the first core board according to the target upgrading data packet, and upgrading data packets corresponding to different hardware version types of the core boards are different. According to the method and the device, the server comprising different types of hardware equipment can be subjected to firmware upgrading.

Description

Technical Field

[0001] The present application relates to the field of server technology, and in particular to a firmware upgrade method, device, electronic device, and readable storage medium. Background Art

[0002] The server contains two boards: BMC (Baseboard Management Controller) and core board. BMC is responsible for controlling and obtaining device information and data of the core board, and the core board supports specific business functions. Fasboot upgrade is usually a software update method used by R&D personnel. In this upgrade mode, the device does not need to be powered on normally. Through fastboot upgrade, a certain image can be burned separately. In server products, fastboot is also often used as a standard device software update method. When BMC is used for fastboot (fast boot) upgrade, it updates and upgrades the firmware version of the server and performs other operations. Specifically, the firmware of the core board (or business board) can be upgraded to achieve the update and upgrade of the server.

[0003] In the existing fastboot upgrade process, since the version types of the hardware devices of all core boards included in the server are consistent, the same upgrade data package is often used to uniformly upgrade the firmware versions of all core boards. However, different types of hardware devices may exist in the same project. If the same firmware version is used to upgrade different types of hardware devices, the device may not be able to start normally, affecting the normal use of the server. Summary of the invention

[0004] The main purpose of the present application is to provide a firmware upgrade method, device, electronic device and readable storage medium, aiming to solve the technical problem of how to upgrade the firmware of a server including different types of hardware devices.

[0005] To achieve the above object, the present application provides a firmware upgrade method, which is applied to a server, wherein the server includes multiple core boards, and the firmware upgrade method includes:

[0006] Obtaining an upgrade firmware file based on fastboot technology, wherein the upgrade firmware file includes multiple upgrade data packets;

[0007] After receiving the upgrade start signal, traverse each of the core boards in turn, take the traversed core board as the first core board, and determine the first hardware version type of the first core board;

[0008] A target upgrade data packet corresponding to the first hardware version type is determined according to each of the upgrade data packets, and the target upgrade data packet is burned into the first core board, wherein different hardware version types of each of the core boards correspond to different upgrade data packets.

[0009] Optionally, the step of determining the first hardware version type of the first core board includes:

[0010] Acquire status information of the first core board, wherein the status information includes a function type to which the first core board belongs, and the function type includes at least one of a charging support function type, a charging non-support function type, a camera support function type, and a camera non-support function type;

[0011] Based on a first mapping relationship between the state information and the hardware version type, the hardware version type corresponding to the state information is determined, and the hardware version type is used as the first hardware version type of the first core board.

[0012] Optionally, the first core board includes: a pull-up and pull-down resistor, and the step of determining the first hardware version type of the first core board includes:

[0013] Obtain the pull-up and pull-down resistance values ​​of the pull-up and pull-down resistors, wherein the pull-up and pull-down resistance values ​​corresponding to different hardware version types of the core boards are different;

[0014] Based on a second mapping relationship between the pull-up and pull-down resistance values ​​and the hardware version type, the hardware version type corresponding to the pull-up and pull-down resistance values ​​is determined, and the hardware version type is used as the first hardware version type of the first core board.

[0015] Optionally, the method further comprises:

[0016] After each of the core boards is powered on, the status information of each of the core boards is obtained, wherein the status information includes the function type to which each of the core boards belongs, and the function type includes at least one of a charging support function type, a charging non-support function type, a camera support function type, and a camera non-support function type;

[0017] Based on the first mapping relationship between the state information and the hardware version type, the hardware version type corresponding to each state information is updated, and each hardware version type is used as the hardware version type of each core board.

[0018] Optionally, after the step of determining the target upgrade data packet corresponding to the first hardware version type according to each of the upgrade data packets, the method further includes:

[0019] Determine an upgrade preservation storage area corresponding to the first core board, and write the target upgrade data packet into the upgrade preservation storage area;

[0020] The attribute value of the upgrade identification state bit of the first core board is set to a first preset attribute value to identify that the first core board is to be upgraded in firmware.

[0021] Optionally, after the step of setting the attribute value of the upgrade identification status bit of the target core board to a first preset attribute value, the method further includes:

[0022] When the attribute value is a first preset attribute value, determining the working state of the first core board;

[0023] When the working state of the first core board is an idle state, creating an upgrade thread corresponding to the first core board, or, when the working state of the first core board is running, interrupting the operation of the first core board and creating an upgrade thread corresponding to the first core board;

[0024] Based on the upgrade thread corresponding to the first core board, the first core board is controlled to retrieve the target upgrade data packet from the upgrade storage area to perform firmware upgrade.

[0025] Optionally, after the step of controlling the first core board to retrieve the target upgrade data packet from the upgrade storage area to perform firmware upgrade, the method further includes:

[0026] Detect whether the firmware upgrade of the first core board is successful;

[0027] If the firmware upgrade of the first core board is successful, the attribute value of the upgrade identification status bit of the first core board is set to a second preset attribute value to indicate that the first core board has completed the firmware upgrade;

[0028] If the current firmware upgrade of the first core board fails, the cumulative number of upgrade failures of the first core board is increased by one;

[0029] If the accumulated number of times is less than a preset error number threshold, the step of burning the target upgrade data package into the first core board is re-executed.

[0030] The present application also provides a firmware upgrade device, which is a virtual device. The firmware upgrade device is applied to a server, and the server includes multiple core boards. The firmware upgrade device includes:

[0031] An acquisition module, used for acquiring an upgrade firmware file based on the fastboot technology, wherein the upgrade firmware file includes a plurality of upgrade data packets;

[0032] A determination module, configured to, after receiving a start upgrade signal, sequentially traverse each of the core boards, take the traversed core board as a first core board, and determine a first hardware version type of the first core board;

[0033] An upgrade module is used to determine a target upgrade data packet corresponding to the first hardware version type based on each of the upgrade data packets, and burn the target upgrade data packet into the first core board, wherein the upgrade data packets corresponding to different hardware version types of each of the core boards are different.

[0034] The present application also provides an electronic device, which is a physical device, and includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the steps of the firmware upgrade method as described above.

[0035] The present application also provides a readable storage medium, which is a computer-readable storage medium. A program for implementing a firmware upgrade method is stored on the computer-readable storage medium. The program for implementing the firmware upgrade method is executed by a processor to implement the steps of the firmware upgrade method as described above.

[0036] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned firmware upgrade method when executed by a processor.

[0037] In this application, the server obtains the upgrade firmware file based on the fastboot technology, and the BMC obtains the upgrade firmware file. After receiving the signal to start the upgrade, each core board is traversed in sequence, and the core board traversed is used as the first core board, and the target upgrade data packet corresponding to the hardware version type of the first core board is determined, and the target upgrade data packet is burned into the first core board, wherein the upgrade firmware file includes multiple upgrade data packets, and the upgrade data packets corresponding to the different hardware version types of the core board are different. In this way, compared with the firmware upgrade method that can only use the same firmware version for the same server in the prior art to upgrade firmware, the implementation of the present application is to set the different hardware version types of the core board to correspond to different upgrade data packets, and the target upgrade data packet corresponding to each core board can be automatically identified and selected according to the hardware version type of each core board. Each core board completes the firmware upgrade according to the target upgrade data packet selected by each core board, thereby enabling the server containing multiple different types of hardware devices to complete the firmware upgrade at one time. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The accompanying drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the description are used to explain the principles of the present application.

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without any creative work.

[0040] Figure 1 This is a flowchart of the first embodiment of the firmware upgrade method of the present application;

[0041] Figure 2 This is a detailed flow chart of step S20 in the first embodiment of the firmware upgrade method of this application;

[0042] Figure 3 This is a flowchart of the third embodiment of the firmware upgrade method of the present application;

[0043] Figure 4 This is a schematic diagram of the module structure of the firmware upgrade device according to an embodiment of the present application;

[0044] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the firmware upgrade device in the embodiment of the present application.

[0045] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0046] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part 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 ordinary technicians in this field without creative work belong to the scope of protection of the present invention.

[0047] Embodiment 1

[0048] Firmware upgrade refers to the manufacturer upgrading the embedded firmware of electronic devices to improve device functions, enhance device stability, and patch device vulnerabilities.

[0049] The server contains two boards: BMC (Baseboard Management Controller) and core board. BMC is responsible for controlling and obtaining device information and data of the core board, and the core board supports specific business functions. Fasboot upgrade is usually a software update method used by R&D personnel. In this upgrade mode, the device does not need to be powered on normally. Through fastboot upgrade, a certain image can be burned separately. In server products, fastboot is also often used as a standard device software update method. When BMC is used for fastboot (fast boot) upgrade, it updates and upgrades the firmware version of the server and performs other operations. Specifically, the firmware of the core board (or business board) can be upgraded to achieve the update and upgrade of the server.

[0050] In the existing fastboot upgrade process, since the version types of the hardware devices of all core boards included in the server are consistent, the same upgrade data package is often used to uniformly upgrade the firmware versions of all core boards. However, different types of hardware devices may exist in the same project. If the same firmware version is used to upgrade different types of hardware devices, the device may not be able to start normally, affecting the normal use of the server.

[0051] Furthermore, when there are differences in hardware version types between multiple core boards on the server, if an incorrect upgrade data packet is used to upgrade the firmware, the user device will be unable to boot up. For example, the firmware version of some cores on the server is a version type that supports Charger, and the firmware version of some core boards is a version type that does not support Charger. In this case, after the core board whose hardware version type does not support Charger uses the upgrade data packet corresponding to the hardware version type that supports Charger to perform a firmware upgrade, the user device will not be able to boot up.

[0052] Based on this, this application proposes a firmware upgrade method of the first embodiment, please refer to Figure 1 , the firmware upgrade method is applied to a server, the server includes multiple core boards, and the firmware upgrade method includes:

[0053] Step S10, obtaining an upgrade firmware file based on the fastboot technology, wherein the upgrade firmware file includes a plurality of upgrade data packets;

[0054] The execution subject of the firmware upgrade method of this embodiment may be a BMC (Baseboard Management Controller).

[0055] In the present embodiment, the upgrade firmware file includes multiple upgrade data packets. Optionally, the mode of obtaining the upgrade firmware file using fastboot technology can be: the electronic device is connected to the computer by a USB (Universal Serial Bus) data cable, and the upgrade firmware file is transferred offline to the electronic device by a USB data cable. Optionally, the upgrade firmware file includes the upgrade data packet corresponding to each different hardware version type of the core board on the server, and usually BMC can repackage multiple upgrade data packets into the upgrade firmware file of the image file format, and before executing the firmware upgrade, the upgrade firmware file is restored to the state before packaging. For example, 6 core boards are included on the server, namely core board A, core board B, core board C, core board D, core board E, core board F, and the corresponding hardware version types are respectively [type 1, type 1, type 1, type 2, type 2, type 2], so the upgrade firmware file includes the upgrade data packet 1 corresponding to the hardware version type 1 and the upgrade data packet 2 corresponding to the hardware version type 2. Assuming that upgrade data packet 1 is fastboot_1.zip and upgrade data packet 2 is fastboot_2.zip, BMC can repackage fastboot_1.zip and fastboot_2.zip to obtain the upgrade firmware file fastboot.img. It should be noted that the naming of the core board, hardware version type, upgrade data packet, upgrade firmware file, etc. in this application is an illustrative naming for example, and does not limit its actual specific naming. For example: the naming of the upgrade data packet, such as fastboot_1.zip, fastboot_2.zip, etc., is to distinguish two different upgrade data packets, and does not limit the actual specific naming of the upgrade data packet. Similarly, the naming of the upgrade firmware file, such as fastboot.img, does not limit the actual specific naming of the upgrade firmware file.

[0056] In addition, the firmware versions corresponding to the same hardware version type may be different. If the firmware versions corresponding to the same hardware version type are different, all core boards belonging to the same hardware version type can be upgraded to the corresponding latest firmware version. For example, assuming that the firmware versions corresponding to core board A, core board B, core board C, core board D, core board E, and core board F are: [Type 1_V1.0, Type 1_V1.0, Type 1_V2.0, Type 2_V1.0, Type 2_V2.0, Type 2_V3.0], the latest firmware version in the upgrade data packet corresponding to type 1 is type 1_V3.0, and the latest firmware version in the upgrade data packet corresponding to type 2 is type 2_V4.0. Then, after the firmware upgrade of all core boards on the server is completed, the firmware versions corresponding to core board A, core board B, core board C, core board D, core board E, and core board F are: [Type 1_V3.0, Type 1_V3.0, Type 1_V3.0, Type 2_V4.0, Type 2_V4.0, Type 2_V4.0].

[0057] It is known to those skilled in the art that the upgrade data packet is used to perform a firmware upgrade on the core board, and the upgrade data packet can specifically be a full upgrade data packet or a differential upgrade data packet, and the present embodiment does not specifically limit this. Specifically, the upgrade data packet is used to upgrade the current firmware version of the core board to the target firmware version.

[0058] Step S20, after receiving the upgrade start signal, traverse each of the core boards in turn, take the traversed core board as the first core board, and determine the first hardware version type of the first core board;

[0059] As an example, the start upgrade signal may be that the user needs to force the core board to perform a firmware upgrade, and a start upgrade signal to the core board is sent through a button on the corresponding function interface. As another example, when the server detects that the core board needs to be upgraded immediately, a start upgrade signal to the first core board is sent. This embodiment does not limit this.

[0060] In the present embodiment, after obtaining the upgrade firmware file, if BMC receives the start upgrade signal, for example, after the technician checks fastboot.img on BMC, the upgrade firmware file can be decompressed to obtain multiple data packets. For example, the upgrade firmware file obtained by BMC is fastboot.img, and fastboot.img can be decompressed to obtain multiple upgrade data packets, such as multiple .zip type data packets. Each core board included in the server is traversed sequentially, and for each core board (i.e., the first core board) traversed, its hardware version type is determined and step S30 is performed. Optionally, the status information of the first core board can be obtained, and the hardware version type (i.e., the first hardware version type) of the first core board is determined by the status information. Wherein, the status information is used to distinguish the hardware version type of the core board, such as the status information can include whether the core board supports Charger, if the core board A supports Charger, the hardware version type of the core board A is type 1, and if the core board D does not support Charger, the hardware version type of the core board D is type 2. After the core board is started, BMC can save the status information of whether each core board supports Charger to the core board device, such as stored in attributes or databases.

[0061] Step S30, determining a target upgrade data packet corresponding to the first hardware version type according to each of the upgrade data packets, and burning the target upgrade data packet into the first core board, wherein the upgrade data packets corresponding to different hardware version types of each of the core boards are different.

[0062] Optionally, the mapping relationship between the preset hardware version type and the upgrade data packet, the upgrade data packets corresponding to the different hardware version types of the core board are different, and the target upgrade data packet corresponding to the hardware version type of each core board is burned onto the core board, and the BMC controls each core board to perform firmware upgrades according to the target upgrade data packet burned thereon. For example, the server includes 6 core boards, namely core board A, core board B, core board C, core board D, core board E, and core board F, and the corresponding hardware version types are respectively [type 1, type 1, type 2, type 2, type 3, type 3], and the upgrade data packet corresponding to hardware version type 1 is fastboot_1.zip, and the upgrade data packet corresponding to hardware version type 2 is fastboot_2.zip, and the upgrade data packet corresponding to hardware version type 2 is fastboot_3.zip, then the target upgrade data packets burned by the 6 core boards on the server are respectively [fastboot_1.zip, fastboot_1.zip, fastboot_ 2.zip, fastboot_2.zip, fastboot_3.zip, fastboot_3.zip], core board A performs firmware upgrade according to the upgrade data packet fastboot_1.zip, core board B performs firmware upgrade according to the upgrade data packet fastboot_1.zip, core board C performs firmware upgrade according to the upgrade data packet fastboot_2.zip, core board D performs firmware upgrade according to the upgrade data packet fastboot_2.zip, core board E performs firmware upgrade according to the upgrade data packet fastboot_3.zip, and core board F performs firmware upgrade according to the upgrade data packet fastboot_3.zip.

[0063] In the present embodiment, the server obtains the upgrade firmware file based on the fastboot technology, and the BMC obtains the upgrade firmware file. After receiving the signal to start the upgrade, each core board is traversed in sequence, and the core board traversed is used as the first core board, and the target upgrade data packet corresponding to the hardware version type of the first core board is determined, and the target upgrade data packet is burned into the first core board, wherein the upgrade firmware file includes multiple upgrade data packets, and the upgrade data packets corresponding to the different hardware version types of the core board are different. In this way, compared with the firmware upgrade mode that can only use the same firmware version for firmware upgrade for the same server in the prior art, the present application implements different upgrade data packets corresponding to the different hardware version types of the core board by setting the hardware version type of each core board, and the target upgrade data packet corresponding to each core board can be automatically identified and selected according to the hardware version type of each core board, and each core board completes the firmware upgrade according to the target upgrade data packet selected by each core board, so that the server containing multiple different types of hardware devices can complete the firmware upgrade at one time.

[0064] In one possible implementation, please refer to Figure 2 , the step of determining the first hardware version type of the first core board includes:

[0065] Step S21, obtaining the status information of the first core board, wherein the status information includes the function type to which the first core board belongs, and the function type includes at least one of a charging support function type, a charging non-support function type, a camera support function type, and a camera non-support function type;

[0066] Wherein, the status information can be stored on the first core board equipment, such as stored in attributes or databases.It is understandable that each core board is each stored with corresponding status information, and the hardware version type of each core board can be determined according to the status information corresponding to each core board.Further, when the core board is turned on or started, the status information of the core board can be updated, or the status information of a core board can be regularly updated, or the status information update condition of the core board can be preset for him, when the status information update condition of the core board is reached, the status information of the core board is updated, such as the cumulative number of failures in the core board firmware upgrade process is greater than the preset error number threshold, then the status information of the core board is updated.In addition, the status information update condition corresponding to each core board can be the same or different, and the present embodiment does not limit the status information update condition.

[0067] The status information of the core board is used to record the function type to which the core board belongs, wherein the function type includes but is not limited to supporting charging function type (i.e. supporting Charger), not supporting charging function type (i.e. not supporting Charger), supporting camera function type, and not supporting camera function type.

[0068] Step S22: based on a first mapping relationship between the state information and the hardware version type, determine the hardware version type corresponding to the state information, and use the hardware version type as the first hardware version type of the first core board.

[0069] The hardware version type of each core board is distinguished by the status information of each core board. Among them, the preset first mapping relationship can be set in advance by the user, which includes the correspondence between different status information and hardware version types. For example, the support charging function type and the support camera function type are recorded as status information 1, the unsupported charging function type and the support camera function type are recorded as status information 2, the support charging function type and the unsupported camera function type are recorded as status information 3, and the unsupported charging function type and the unsupported camera function type are recorded as status information 4. The preset first mapping relationship can refer to Table 1.

[0070] Status Information Hardware version type Status information 1 Hardware version type 1 Status information 2 Hardware version type 2 Status message 3 Hardware version type 3 Status message 4 Hardware version type 4

[0071] Table 1

[0072] In this embodiment, the hardware version type of the core is determined based on the status information of the core board, and different hardware version types are distinguished by different status information, so that the present application can effectively and accurately obtain the hardware version type of each core board, thereby ensuring that the hardware version type of each core board automatically identifies and selects the correct upgrade data package, thereby ensuring that each core board completes the firmware upgrade according to the correct upgrade data package.

[0073] In order to help understand the technical concept or technical principle of the present application, a specific embodiment is listed:

[0074] The upgrade process in this specific embodiment is:

[0075] Using hardware that supports Charger and hardware that does not support Charger as examples, the triggering of fastboot upgrade actions and the management of upgrade packages are explained. For ease of operation, BMC often repackages the upgrade package (with the extension zip) and changes the extension to img. Before executing the upgrade, it is restored to the state before packaging, that is, the upgrade firmware file is decompressed to obtain multiple upgrade data packages.

[0076] (1) Since there are two sets of hardware, there will be two sets of firmware versions. The upgrade data packages corresponding to the two types of hardware versions are marked as fastboot_Charger.zip and fastboot_Non_Charger.zip respectively. Only one upgrade package is provided to the user, so these two upgrade packages are packaged into the same fastboot.img.

[0077] (2)) When the BMC performs a fastboot upgrade, for example, after fastboot.img is checked on the BMC, the upgrade package fastboot.img is restored to a zip file package, and then decompressed to obtain two upgrade packages fastboot_Charger.zip and fastboot_Non_Charger.zip. Finally, the upgrade package is decompressed to obtain all upgrade images.

[0078] (4) BMC triggers the core board to enter fastboot mode, and obtains the status of whether the device hardware supports Charger in fastboot mode. If Charger is supported, the upgrade image after decompressing fastboot_Charger.zip is burned into the core board. If Charger is not supported, the upgrade image after decompressing fastboot_Non_Charger.zip is burned into the core board.

[0079] In another possible implementation, the first core board includes: a pull-up and pull-down resistor, and the step of determining the first hardware version type of the first core board includes:

[0080] Step S23, obtaining the pull-up and pull-down resistance values ​​of the pull-up and pull-down resistors, wherein the pull-up and pull-down resistance values ​​corresponding to different hardware version types of the core boards are different;

[0081] It is understandable that each core board is provided with pull-up and pull-down resistors, and the resistance values ​​of the pull-up and pull-down resistors on core boards of different hardware version types are different. The hardware version type of each core board can be determined according to the pull-up and pull-down resistor values ​​corresponding to each core board.

[0082] Step S24, based on the second mapping relationship between the pull-up and pull-down resistance values ​​and the hardware version types, determine the hardware version types corresponding to the pull-up and pull-down resistance values, and use the hardware version types as the first hardware version type of the first core board.

[0083] The hardware version type of each core board is distinguished by the pull-up and pull-down resistance values ​​of each core board. Among them, the preset second mapping relationship can be set in advance by the user, which includes the corresponding relationship between different pull-up and pull-down resistance values ​​and hardware version types. For example, the pull-up and pull-down resistance values ​​of the pull-up and pull-down resistors that support the charging function type and the camera function type are pull-up and pull-down resistance values ​​of 1, the pull-up and pull-down resistance values ​​of the pull-up and pull-down resistors that do not support the charging function type and the camera function type are pull-up and pull-down resistance values ​​of 2, the pull-up and pull-down resistance values ​​of the pull-up and pull-down resistors that support the charging function type and the camera function type are not supported. The resistance value is pull-up and pull-down resistance value 3, and the resistance value of the pull-up and pull-down resistors that do not support the charging function type and the camera function type is pull-up and pull-down resistance value 4. The preset second mapping relationship can refer to Table 2.

[0084] Pull-up and pull-down resistance Hardware version type Pull up and down resistance 1 Hardware version type 1 Pull up and down resistance 2 Hardware version type 2 Pull up and down resistance 3 Hardware version type 3 Pull up and down resistance 4 Hardware version type 4

[0085] Table 2

[0086] In this embodiment, the hardware version type of the core is determined based on the pull-up and pull-down resistance values ​​of the core board, and different hardware version types are distinguished by different pull-up and pull-down resistance values. This enables the present application to effectively and accurately obtain the hardware version type of each core board, thereby ensuring that the hardware version type of each core board automatically identifies and selects the correct upgrade data package, thereby ensuring that each core board completes the firmware upgrade based on the correct upgrade data package.

[0087] Embodiment 2

[0088] Based on the first embodiment of the present application, in another embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. On this basis, the firmware upgrade method of the present application also includes:

[0089] Step A10, after each of the core boards is turned on, obtaining status information of each of the core boards, wherein the status information includes the function type to which each of the core boards belongs, and the function type includes at least one of supporting charging function type, not supporting charging function type, supporting camera function type, and not supporting camera function type;

[0090] Wherein, this state information is the same as the state information in the above-described embodiment, and will not be repeated here, when the core board is turned on or started, the state information of the core board can be updated, further, it can also be the state information of the core board that is regularly updated, or it is also possible to preset the state information update condition for the core board for him, when the state information update condition of the core board is reached, the state information of the core board is updated, such as the cumulative number of failures in the core board firmware upgrade process is greater than the preset error number threshold, then the state information of the core board is updated. In addition, the state information update condition corresponding to each core board can be the same or different, and the present embodiment does not limit the state information update condition.

[0091] Step A20: based on the first mapping relationship between the state information and the hardware version type, update the hardware version type corresponding to each state information, and use each hardware version type as the hardware version type of each core board.

[0092] The hardware version type of each core board is distinguished by the status information of each core board. Wherein, the preset first mapping relationship is the same as the first mapping relationship of the above embodiment 1, and will not be described in detail here.

[0093] In this embodiment, each time the core board is turned on or started, the hardware version type of the core is updated based on the status information of the core board, so that different hardware version types are distinguished by different status information, so that the present application can effectively and accurately obtain the hardware version type of each core board when updating, thereby ensuring that the hardware version type of each core board automatically identifies and selects the correct upgrade data package, thereby ensuring that each core board completes the firmware upgrade according to the correct upgrade data package.

[0094] Embodiment 3

[0095] Based on the first embodiment of the present application, in another embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. On this basis, after the step of determining the target upgrade data packet corresponding to the first hardware version type according to each of the upgrade data packets, the method further includes:

[0096] Step B10, determining the upgrade package storage area corresponding to the first core board, and writing the target upgrade data packet into the upgrade package storage area;

[0097] In the present embodiment, the upgrade package storage area is a storage area for storing upgrade data packets. It may belong to a sub-partition of an independent partition of the first core board, wherein the independent partition is a public use partition of the core board, and the data of the independent partition needs to be loaded when the core board is powered on, and the data of the independent partition will not cause data loss due to restart.

[0098] In addition, if the first core board has AB partitions, that is, the first core board includes the first static partition and the second static partition, that is to say, the first static partition is one of the partitions of A partition and B partition, and the second static partition is another partition of A partition and B partition. The upgrade package storage area may belong to the sub-partition in the first static partition or the sub-partition of the second static partition. Of course, the upgrade package storage area may also belong to the sub-partition of the independent partition independent of the first static partition and the second static partition, wherein the independent partition is the public use partition of the core board, that is, when the core board is powered on, whether it is the data of the first static partition or the second static partition, it is also necessary to load the data of the independent partition, and the data of the independent partition will not cause data loss due to restarting.

[0099] Step B20: setting the attribute value of the upgrade identification status bit of the first core board to a first preset attribute value to identify that the first core board is to be upgraded in firmware.

[0100] In the present embodiment, the upgrade identification status bit of the core board can be used to indicate whether the current core board needs to perform a firmware version upgrade. It should be noted that when the attribute value of the upgrade identification status bit of the core board is set to the first preset attribute value, the core board can be triggered to retrieve the target upgrade data packet from the upgrade package storage area to perform a firmware upgrade of the firmware version of the core board, and the firmware version of the core board is upgraded to the target firmware. Wherein, the first preset attribute value, those skilled in the art can set it according to actual conditions, and the present embodiment is not specifically limited. In an example, the first preset attribute value can be 1.

[0101] Furthermore, it is also possible to detect whether the target upgrade data packet is successfully written to the upgrade package storage area. If the target upgrade data packet is successfully written to the upgrade package storage area, the attribute value of the upgrade identification status bit of the first core board is set to a first preset attribute value. Otherwise, a request to re-acquire the target upgrade data packet can be sent to resend the target upgrade data packet and write it to the upgrade package storage area until the target upgrade data packet is successfully written to the upgrade package storage area. If the cumulative number of write failures to write the target upgrade data packet is greater than the preset maximum number of write errors, an alarm prompt message can also be output.

[0102] In addition, if the first core board has AB partitions, during a fastboot upgrade of the first core board, the two partitions of the first core board can be upgraded synchronously to keep the software and firmware versions of the two partitions of the core board consistent, thereby improving the efficiency of the firmware upgrade and avoiding the situation in which a working partition of the core board crashes and cannot be booted after the fastboot upgrade due to inconsistent software and firmware versions of the AB partitions, and the server with the backup partition enabled is incompatible with the client system of the user device and causes a conflict. This ensures that after the fastboot upgrade, the server using AB partitions (i.e., the core board of the server has AB partitions) is compatible with the client system of the user device.

[0103] This embodiment first writes the target upgrade data packet to the upgrade package storage area of ​​the core board, and after the target upgrade data packet is completely written, sets the attribute value of the upgrade identification status bit of the core board to the first preset attribute value, wherein the upgrade identification status bit set to the first preset attribute is used to trigger the core board to retrieve the upgrade data packet from the upgrade package storage area to upgrade the firmware version, thereby avoiding the problem of the core board upgrading failing due to the phenomenon of packet loss (abnormal transmission of the upgrade data packet due to network instability and other reasons) caused by the firmware version upgrade of the core board being transmitted (i.e., transmitting the upgrade data packet to the core board) while upgrading (i.e., upgrading the firmware version of the core board), thereby enabling the embodiment of the present application to efficiently and stably upgrade the firmware version of the core board to the target firmware version.

[0104] In a possible implementation manner, after the step of setting the attribute value of the upgrade identification status bit of the target core board to the first preset attribute value, the method further includes:

[0105] Step C10, when the attribute value is a first preset attribute value, determining the working state of the first core board;

[0106] Step C20, when the working state of the first core board is an idle state, creating an upgrade thread corresponding to the first core board, or, when the working state of the first core board is running, interrupting the operation of the first core board and creating an upgrade thread corresponding to the first core board;

[0107] Step C30, based on the upgrade thread corresponding to the first core board, controlling the first core board to retrieve the target upgrade data packet from the upgrade package storage area to perform firmware upgrade.

[0108] As an example, the working state includes an idle state and an occupied state. The idle state refers to the state of the core board when there is no running task in the core board. At this time, if there is a running task in the first core board, the working state of the first core board is an occupied state; if there is no running task in the first core board, the working state of the first core board is an idle state.

[0109] As another example, a task tag can be inserted into the core board, which is used to record whether the core board is occupied, so that the idle state refers to the core board state when the task tag of the core board is not occupied. At this time, if the task tag in the first core board is occupied, the working state of the first core board is occupied; if the task tag in the first core board is not occupied, the working state of the first core board is idle. This example does not limit this.

[0110] It should be noted that the upgrade thread is used to control the core board to perform firmware upgrade.

[0111] When the working state of the first core board is occupied, if the first core board feedback can interrupt the operation, interrupt the operation of the first core board to create an upgrade thread corresponding to the first core board, based on the upgrade thread corresponding to the first core board, control the first core board to retrieve the target upgrade data packet from the upgrade package storage area for firmware upgrade, if the first core board feedback cannot interrupt the operation, wait for the working state of the first core board to be idle.

[0112] In this embodiment, before the upgrade firmware data is retrieved from the storage area of ​​the core board upgrade package for firmware upgrade, it is ensured that the core board to be upgraded is in an idle state, and an upgrade process is created for it, so as to prevent the process of firmware upgrade from being affected by the running tasks in the core board, or the process of firmware upgrade from causing the current running tasks of the core board to be interrupted, so as to avoid process conflicts during the firmware upgrade process and improve the stability of the firmware upgrade.

[0113] In one possible implementation, refer to Figure 3 After the step of triggering the first core board to retrieve the target upgrade data packet from the upgrade package storage area for firmware upgrade, the method further includes:

[0114] Step D10, detecting whether the firmware upgrade of the first core board is successful;

[0115] Step D20, if the firmware upgrade of the first core board is successful, setting the attribute value of the upgrade identification status bit of the first core board to a second preset attribute value to indicate that the first core board has completed the firmware upgrade;

[0116] In the present embodiment, the upgrade identification status bit of the core board can be used to indicate whether the current core board needs to perform a firmware version upgrade. If the current firmware upgrade of the first core board is successful, the attribute value of the upgrade identification status bit of the first core board is set to the second preset attribute value, it should be noted that when the attribute value of the upgrade identification status bit of the core board is set to the second preset attribute value, it is explained that the core board does not need to perform a firmware upgrade. Wherein, the second preset attribute value, those skilled in the art can set it according to actual conditions, and the present embodiment is not specifically limited. In an example, the second preset attribute value can be 0.

[0117] Step D30, if the current firmware upgrade of the first core board fails, the cumulative number of upgrade failures of the first core board is increased by one;

[0118] Step D40: if the accumulated number of times is less than a preset error number threshold, re-execute the step of performing firmware upgrade on the first core board according to the target upgrade data packet.

[0119] In this embodiment, the preset error number threshold value can be set by those skilled in the art according to actual conditions, and this embodiment does not make specific limitations. In one example, the preset error number threshold value is 3. If the firmware upgrade to the first core board fails this time, the cumulative number of upgrade failures of the first core board is increased by one, and the cumulative number is less than the preset error number threshold value, the firmware of the first core board can be upgraded again. If the firmware upgrade to the first core board is successful this time, the attribute value of the upgrade identification status bit of the first core board is set to the second preset attribute value, and the cumulative number of upgrade failures of the first core board is cleared.

[0120] Furthermore, if the cumulative number of upgrade failures of the first core board is greater than or equal to a preset error number threshold, that is, the first core board fails to upgrade for multiple consecutive times, it is judged as an upgrade abnormality, and then warning information of firmware upgrade failure can be reported.

[0121] This embodiment increases the cumulative number of upgrade failures of the first core board by one after determining that the current firmware upgrade of the first core board has failed, and resets the cumulative number of upgrade failures of the first core board to zero after determining that the second firmware version has been upgraded successfully. If it is identified that the statistical number is less than the preset error number threshold, the firmware upgrade is re-performed; if it is identified that the statistical number is greater than or equal to the preset error number threshold, a warning message of firmware upgrade failure is output, thereby avoiding repeated requests for re-upgrade of the first core board due to problems with the upgrade data packet itself, abnormalities in the core board itself, or network instability, and promptly reminding the staff that the first core board cannot be successfully upgraded, thereby further improving the robustness of the firmware upgrade method.

[0122] Embodiment 4

[0123] The present invention also provides a firmware upgrade device, see Figure 4 , the firmware upgrade device is applied to a server, the server includes a plurality of core boards, and the device includes:

[0124] An acquisition module 10 is used to acquire an upgrade firmware file based on the fastboot technology, wherein the upgrade firmware file includes a plurality of upgrade data packets;

[0125] A determination module 20 is used to traverse each of the core boards in sequence after receiving a start upgrade signal, take the traversed core board as a first core board, and determine a first hardware version type of the first core board;

[0126] The upgrade module 30 is used to determine the target upgrade data packet corresponding to the first hardware version type based on each of the upgrade data packets, and perform firmware upgrade on the first core board based on the target upgrade data packet, wherein the upgrade data packets corresponding to different hardware version types of each of the core boards are different.

[0127] Optionally, the determining module 20 is further configured to:

[0128] Acquire status information of the first core board, wherein the status information includes a function type to which the first core board belongs, and the function type includes at least one of a charging support function type, a charging non-support function type, a camera support function type, and a camera non-support function type;

[0129] Based on a first mapping relationship between the state information and the hardware version type, the hardware version type corresponding to the state information is determined, and the hardware version type is used as the first hardware version type of the first core board.

[0130] Optionally, the determining module 20 is further configured to:

[0131] Obtain the pull-up and pull-down resistance values ​​of the pull-up and pull-down resistors, wherein the pull-up and pull-down resistance values ​​corresponding to different hardware version types of the core boards are different;

[0132] Based on a second mapping relationship between the pull-up and pull-down resistance values ​​and the hardware version type, the hardware version type corresponding to the pull-up and pull-down resistance values ​​is determined, and the hardware version type is used as the first hardware version type of the first core board.

[0133] Optionally, the firmware upgrade device further includes a status update module, wherein the status update module is used to:

[0134] After each of the core boards is powered on, the status information of each of the core boards is obtained, wherein the status information includes the function type to which each of the core boards belongs, and the function type includes at least one of a charging support function type, a charging non-support function type, a camera support function type, and a camera non-support function type;

[0135] Based on the first mapping relationship between the state information and the hardware version type, the hardware version type corresponding to each state information is updated, and each hardware version type is used as the hardware version type of each core board.

[0136] Optionally, the device further comprises a writing module, wherein the writing module is configured to:

[0137] Determine the upgrade package storage area corresponding to the first core board, and write the target upgrade data packet into the upgrade package storage area;

[0138] The attribute value of the upgrade identification state bit of the first core board is set to a first preset attribute value to identify that the first core board is to be upgraded in firmware.

[0139] Optionally, the device further comprises a creation module, wherein the creation module is configured to:

[0140] When the attribute value is a first preset attribute value, determining the working state of the first core board;

[0141] When the working state of the first core board is an idle state, creating an upgrade thread corresponding to the first core board, or, when the working state of the first core board is running, interrupting the operation of the first core board and creating an upgrade thread corresponding to the first core board;

[0142] Based on the upgrade thread corresponding to the first core board, the first core board is controlled to retrieve the target upgrade data packet from the upgrade package storage area to perform firmware upgrade.

[0143] Optionally, the device further comprises a detection module, wherein the detection module is configured to:

[0144] Detect whether the firmware upgrade of the first core board is successful;

[0145] If the firmware upgrade of the first core board is successful, the attribute value of the upgrade identification status bit of the first core board is set to a second preset attribute value to indicate that the first core board has completed the firmware upgrade;

[0146] If the current firmware upgrade of the first core board fails, the cumulative number of upgrade failures of the first core board is increased by one;

[0147] If the accumulated number of times is less than a preset error number threshold, the step of performing firmware upgrade on the first core board according to the target upgrade data packet is re-executed.

[0148] The firmware upgrade device provided by the present invention adopts the firmware upgrade method in the above-mentioned embodiment 1, embodiment 2 or embodiment 3, and can solve the technical problem of how to upgrade the firmware of a server including different types of hardware devices. Compared with the prior art, the beneficial effects of the firmware upgrade device provided by the embodiment of the present invention are the same as the beneficial effects of the firmware upgrade method provided by the above-mentioned embodiment, and other technical features in the firmware upgrade device are the same as the features disclosed in the above-mentioned embodiment method, which will not be repeated here.

[0149] Embodiment 5

[0150] An embodiment of the present invention provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the firmware upgrade method in the above-mentioned embodiment 1.

[0151] Reference below Figure 5 , which shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiment of the present disclosure. The electronic device in the embodiment of the present disclosure may be a BMC (Baseboard Management Controller) or the like. Figure 5 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0152] like Figure 5 As shown, the electronic device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM 1002) or a program loaded from a storage device into a random access memory (RAM 1004). In RAM 1004, various programs and data required for the operation of the electronic device are also stored. The processing device 1001, ROM 1002, and RAM 1004 are connected to each other via a bus 1005. An input / output (I / O) interface is also connected to the bus 1005.

[0153] Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows an electronic device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have alternatively.

[0154] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0155] The electronic device provided by the present invention adopts the firmware upgrade method in the above embodiment to solve the technical problem of how to upgrade the firmware of a server including different types of hardware devices. Compared with the prior art, the beneficial effects of the electronic device provided by the embodiment of the present invention are the same as the beneficial effects of the firmware upgrade method provided by the above embodiment, and other technical features in the electronic device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0156] It should be understood that the various parts of the present disclosure can be implemented with hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0157] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art who is familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

[0158] Embodiment 6

[0159] An embodiment of the present invention provides a computer-readable storage medium having computer-readable program instructions stored thereon, and the computer-readable program instructions are used to execute the firmware upgrade method in the above-mentioned embodiment 1.

[0160] The computer-readable storage medium provided in the embodiment of the present invention may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.

[0161] The computer-readable storage medium may be included in the electronic device, or may exist independently without being installed in the electronic device.

[0162] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by an electronic device, the electronic device: obtains an upgrade firmware file, wherein the upgrade firmware file includes multiple upgrade data packets; traverses each of the core boards in turn, takes the traversed core board as the first core board, and determines the first hardware version type of the first core board; determines a target upgrade data packet corresponding to the first hardware version type, and performs a firmware upgrade on the first core board according to the target upgrade data packet, wherein different hardware version types of the core boards correspond to different upgrade data packets.

[0163] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0164] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0165] The modules involved in the embodiments described in the present disclosure may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0166] The readable storage medium provided by the present invention is a computer-readable storage medium, which stores computer-readable program instructions for executing the above-mentioned firmware upgrade method, and can solve the technical problem that after the fastboot upgrade, the server using AB partitions is easily incompatible with the client system of the user device. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in the embodiment of the present invention are the same as the beneficial effects of the firmware upgrade method provided in the above-mentioned embodiment 1 or embodiment 2, and will not be repeated here.

[0167] Embodiment 7

[0168] An embodiment of the present invention further provides a computer program product, including a computer program, wherein when the computer program is executed by a processor, the steps of the firmware upgrade method as described above are implemented.

[0169] The computer program product provided by the present application can solve the technical problem of low firmware upgrade efficiency when there are differences between the hardware version types of multiple core boards on the server. Compared with the prior art, the beneficial effects of the computer program product provided by the embodiment of the present invention are the same as the beneficial effects of the firmware upgrade method provided by the above-mentioned embodiment 1 or embodiment 2, and will not be repeated here.

[0170] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent processing scope of the present application.

Claims

1. A firmware upgrade method, characterized in that: The firmware upgrade method is applied to a server, the server includes multiple core boards, and the firmware upgrade method includes: Obtaining an upgrade firmware file based on fastboot technology, wherein the upgrade firmware file includes multiple upgrade data packets; After receiving the upgrade start signal, traverse each of the core boards in turn, take the traversed core board as the first core board, and determine the first hardware version type of the first core board; A target upgrade data packet corresponding to the first hardware version type is determined according to each of the upgrade data packets, and the target upgrade data packet is burned into the first core board, wherein different hardware version types of each of the core boards correspond to different upgrade data packets.

2. The firmware upgrade method according to claim 1, characterized in that: The step of determining the first hardware version type of the first core board includes: Acquire status information of the first core board, wherein the status information includes a function type to which the first core board belongs, and the function type includes at least one of a charging support function type, a charging non-support function type, a camera support function type, and a camera non-support function type; Based on a first mapping relationship between the state information and the hardware version type, the hardware version type corresponding to the state information is determined, and the hardware version type is used as the first hardware version type of the first core board.

3. The firmware upgrade method according to claim 1, characterized in that: The first core board includes: pull-up and pull-down resistors, and the step of determining the first hardware version type of the first core board includes: Obtain the pull-up and pull-down resistance values ​​of the pull-up and pull-down resistors, wherein the pull-up and pull-down resistance values ​​corresponding to different hardware version types of the core boards are different; Based on a second mapping relationship between the pull-up and pull-down resistance values ​​and the hardware version type, the hardware version type corresponding to the pull-up and pull-down resistance values ​​is determined, and the hardware version type is used as the first hardware version type of the first core board.

4. The firmware upgrade method according to claim 1, characterized in that: The method further comprises: After each of the core boards is powered on, the status information of each of the core boards is obtained, wherein the status information includes the function type to which each of the core boards belongs, and the function type includes at least one of a charging support function type, a charging non-support function type, a camera support function type, and a camera non-support function type; Based on the first mapping relationship between the state information and the hardware version type, the hardware version type corresponding to each state information is updated, and each hardware version type is used as the hardware version type of each core board.

5. The firmware upgrade method according to claim 1, wherein: After the step of determining the target upgrade data packet corresponding to the first hardware version type according to each of the upgrade data packets, the method further includes: Determine an upgrade preservation storage area corresponding to the first core board, and write the target upgrade data packet into the upgrade preservation storage area; The attribute value of the upgrade identification state bit of the first core board is set to a first preset attribute value to identify that the first core board is to be upgraded in firmware.

6. The firmware upgrade method according to claim 5, characterized in that: After the step of setting the attribute value of the upgrade identification status bit of the target core board to the first preset attribute value, the method further includes: When the attribute value is a first preset attribute value, determining the working state of the first core board; When the working state of the first core board is an idle state, creating an upgrade thread corresponding to the first core board, or, when the working state of the first core board is running, interrupting the operation of the first core board and creating an upgrade thread corresponding to the first core board; Based on the upgrade thread corresponding to the first core board, the first core board is controlled to retrieve the target upgrade data packet from the upgrade storage area to perform firmware upgrade.

7. The firmware upgrade method according to claim 6, characterized in that: After the step of controlling the first core board to retrieve the target upgrade data packet from the upgrade storage area to perform firmware upgrade, the method further includes: Detect whether the firmware upgrade of the first core board is successful; If the firmware upgrade of the first core board is successful, the attribute value of the upgrade identification status bit of the first core board is set to a second preset attribute value to indicate that the first core board has completed the firmware upgrade; If the current firmware upgrade of the first core board fails, the cumulative number of upgrade failures of the first core board is increased by one; If the accumulated number of times is less than a preset error number threshold, the step of burning the target upgrade data package into the first core board is re-executed.

8. A firmware upgrade device, characterized in that: The firmware upgrade device is applied to a server, the server includes a plurality of core boards, and the firmware upgrade device includes: An acquisition module, used for acquiring an upgrade firmware file based on the fastboot technology, wherein the upgrade firmware file includes a plurality of upgrade data packets; A determination module, configured to, after receiving a start upgrade signal, sequentially traverse each of the core boards, take the traversed core board as a first core board, and determine a first hardware version type of the first core board; An upgrade module is used to determine a target upgrade data packet corresponding to the first hardware version type based on each of the upgrade data packets, and burn the target upgrade data packet into the first core board, wherein the upgrade data packets corresponding to different hardware version types of each of the core boards are different.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the steps of the firmware upgrade method according to any one of claims 1 to 7.

10. A readable storage medium, characterized in that: The readable storage medium is a computer-readable storage medium, on which is stored a program for implementing a firmware upgrade method, and the program for implementing a firmware upgrade method is executed by a processor to implement the steps of the firmware upgrade method as described in any one of claims 1 to 7.

Images