Firmware upgrade method, electronic device, storage medium and program product

Abstract

This application discloses a firmware upgrade method, electronic device, storage medium, and program product, relating to the field of computer hardware management technology. The method includes arranging multiple target files in the read-only partition of the original firmware upgrade file of the baseboard management controller in ascending order of change weight to obtain a target firmware upgrade file, thereby reducing the difference between the target firmware upgrade image and the target firmware runtime image, and thus reducing the size of the incremental firmware upgrade image; generating a target firmware upgrade image based on the target firmware upgrade file; comparing the target firmware upgrade image with the target firmware runtime image to obtain an incremental firmware upgrade image; and uploading the incremental firmware upgrade image to the baseboard management controller so that the baseboard management controller performs a firmware upgrade based on the incremental firmware upgrade image. This solves the technical problem of long firmware upgrade times in related technologies, achieving the technical effect of improving firmware upgrade speed and shortening firmware upgrade time.

Description

Technical Field

[0001] This application relates to the field of computer hardware management technology, and in particular to firmware upgrade methods, electronic devices, storage media, and program products. Background Technology

[0002] The Baseboard Management Controller (BMC) is a core component of server management, responsible for remote management and control of the server, as well as hardware status monitoring and alarms. During the server product development and commercialization phases, BMC firmware upgrades are a critical step, used for feature debugging, security fixes, and support for new hardware.

[0003] The BMC firmware upgrade method in related technologies requires uploading a full firmware upgrade image, which results in a long firmware upgrade time for BMC. Summary of the Invention

[0004] This application provides a firmware upgrade method, electronic device, storage medium, and program product to at least solve the problem of long firmware upgrade time for BMC in related technologies.

[0005] This application provides a firmware upgrade method, including:

[0006] Obtain the original firmware upgrade file for the baseboard management controller;

[0007] Multiple target files in the read-only partition of the original firmware upgrade file are arranged in ascending order of change weight to obtain the target firmware upgrade file. The larger the change weight of the target file, the higher the probability that it has been modified.

[0008] Based on the target firmware upgrade file, a target firmware upgrade image is generated, in which a read-only partition image is generated by compressing a read-only file system;

[0009] The target firmware upgrade image is compared with the target firmware running image of the baseboard management controller to obtain the incremental firmware upgrade image;

[0010] The incremental firmware upgrade image is uploaded to the baseboard management controller so that the baseboard management controller can perform firmware upgrades based on the incremental firmware upgrade image.

[0011] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above firmware upgrade methods.

[0012] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described firmware upgrade methods.

[0013] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described firmware upgrade methods.

[0014] This application addresses the issue of long firmware upgrade times for BMCs by obtaining the original firmware upgrade file of the baseboard management controller (BMC). Multiple target files within the read-only partition of the original firmware upgrade file are arranged in ascending order of change weight to obtain the target firmware upgrade file. The higher the change weight of a target file, the higher the probability of it being modified, thus reducing the difference between the target firmware upgrade image and the target firmware runtime image, thereby reducing the size of the incremental firmware upgrade image. Based on the target firmware upgrade file, a target firmware upgrade image is generated, using a compressed read-only file system to create an image with a read-only partition. The target firmware upgrade image is compared with the target firmware runtime image of the baseboard management controller to obtain the incremental firmware upgrade image. The incremental firmware upgrade image is then uploaded to the baseboard management controller, enabling the BMC to perform firmware upgrades based on it. By uploading the incremental firmware upgrade image for firmware upgrades and reducing the size of the incremental firmware upgrade image, the technical problem of long firmware upgrade times in related technologies can be solved, achieving the technical effect of improving firmware upgrade speed and shortening firmware upgrade time. Attached Figure Description

[0015] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a firmware upgrade method provided in an embodiment of this application;

[0017] Figure 2 A schematic diagram showing the arrangement of the BMC firmware image in a 64M Nor Flash memory according to an embodiment of this application;

[0018] Figure 3 This is a schematic diagram illustrating the file arrangement within a read-only partition in related technologies;

[0019] Figure 4 A schematic diagram of the target file arrangement in the read-only partition of the target firmware upgrade file provided in this embodiment of the application;

[0020] Figure 5 This is a schematic diagram of a read-only partition image created by updating the first file in a read-only partition, where the files in the read-only partition are arranged in alphabetical order by their file names, in a related technology.

[0021] Figure 6 This is a schematic diagram of a read-only partition image created after updating the first file in the read-only partition, where the target files in the read-only partition are arranged in ascending order of change weights. This is provided as an embodiment of the present application.

[0022] Figure 7 A flowchart illustrating yet another firmware upgrade method provided in an embodiment of this application;

[0023] Figure 8 A flowchart illustrating the process of determining the erasure method of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block, as provided in the embodiments of this application.

[0024] Figure 9 This is a schematic diagram of the structure of the target firmware upgrade image provided in the embodiments of this application;

[0025] Figure 10 This is a schematic diagram of the structure of the incremental firmware upgrade image provided in the embodiments of this application;

[0026] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] The technical solutions of 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 of ordinary skill in the art without creative effort are within the protection scope of this application.

[0028] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0029] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] As a core component of server management, the Server Management Console (BMC) is primarily used for remote server management and control, hardware status monitoring, and alarm functions. BMC firmware upgrades are crucial during both the server product development and commercialization phases. Specifically, during development, BMC firmware upgrades are used to debug new features; during commercialization, they are typically used to patch known security vulnerabilities and support new hardware. Therefore, the speed of BMC firmware upgrades directly impacts product development speed and user experience.

[0031] The BMC firmware upgrade process in related technologies is as follows: First, a 64-megabyte (M) BMC firmware upgrade image is compiled. Then, the BMC firmware upgrade image is uploaded to the BMC runtime environment. After the 64M BMC firmware upgrade image is completely uploaded to the BMC runtime environment, the data in the non-volatile flash memory (Nor Flash) storing the original BMC runtime image is updated. Specifically, the BMC reads the original firmware runtime image and compares it block by block with the firmware upgrade image. The data block size is typically fixed at 64 kilobytes (K). If the current data block in the firmware upgrade image matches the corresponding data block in the original firmware runtime image, the current data block is skipped, and the comparison continues to the next data block. If there are discrepancies between the current data block in the firmware upgrade image and the corresponding data block in the original firmware runtime image, the corresponding data block in the original firmware runtime image is erased from the Nor Flash, and the current data block in the firmware upgrade image is written to the erase location. After processing 1024 data blocks, the image update is complete, which also completes the BMC firmware upgrade. Restarting the BMC makes the upgraded firmware effective, thus making the updated image effective.

[0032] Understandably, the BMC firmware upgrade method in related technologies requires uploading a full 64MB BMC firmware upgrade image every time a BMC firmware upgrade is performed. Even if only minor modifications are made, and the comparison process between the original running image and the firmware upgrade image is performed on the BMC runtime environment, these factors result in a long BMC firmware upgrade time. In the server product development stage, this reduces the product development speed, and in the server product commercialization stage, it reduces the user experience.

[0033] To address the aforementioned issues, this application provides a firmware upgrade method, an electronic device, a storage medium, and a program product. The method includes: obtaining an original firmware upgrade file of a baseboard management controller; arranging multiple target files in the read-only partition of the original firmware upgrade file in ascending order of change weight to obtain a target firmware upgrade file, wherein the higher the change weight of a target file, the higher the probability of it being modified; generating a target firmware upgrade image based on the target firmware upgrade file, wherein the image of the read-only partition is generated using a compressed read-only file system; comparing the target firmware upgrade image with the target firmware running image of the baseboard management controller to obtain an incremental firmware upgrade image; and uploading the incremental firmware upgrade image to the baseboard management controller so that the baseboard management controller performs a firmware upgrade based on the incremental firmware upgrade image. The method provided by the above solution reduces the difference between the target firmware upgrade image and the target firmware running image by arranging multiple target files in the read-only partition of the original firmware upgrade file in ascending order of change weight. This reduces the size of the incremental firmware upgrade image. The incremental firmware upgrade image is then uploaded to the BMC for firmware upgrade, and its size is reduced. Furthermore, the process of comparing the target firmware upgrade image with the target firmware running image runs in a non-BMC environment. Therefore, it can solve the technical problem of long firmware upgrade time in related technologies, thereby improving firmware upgrade speed and shortening firmware upgrade time.

[0034] Embodiments of this application provide a firmware upgrade method applied to a server. Figure 1 This is a flowchart illustrating the firmware upgrade method provided in an embodiment of this application, as shown below. Figure 1 As shown, the firmware upgrade method includes the following steps:

[0035] Step S101: Obtain the original firmware upgrade file of the baseboard management controller.

[0036] The original firmware upgrade file is used for BMC firmware upgrades. It includes a universal bootloader partition (uboot partition), a kernel partition, a read-only partition, and a read-write partition. The uboot partition primarily stores the BMC boot code, the kernel partition primarily stores kernel files, the read-only partition primarily stores executable program files and configuration files, and the read-write partition is mainly used for dynamically writing data during BMC runtime; it is generally initialized when compiling an image with the read-write partition.

[0037] Figure 2 This is a schematic diagram showing the arrangement of the BMC firmware image in a 64M Nor Flash memory according to an embodiment of this application. Figure 2As shown, the firmware image includes a generic bootloader partition image, a kernel partition image, a read-only partition image, and a read-write partition image. The uboot partition image occupies 1MB of space, the kernel partition image occupies 10MB, the read-only partition image occupies 43MB, and the read-write partition image occupies 10MB. The uboot partition image is a binary file generated based on the BMC boot code, the kernel partition image is a kernel image file compiled from the Linux open-source operating system, and the read-only partition image is an image generated using a compressed read-only file system (SquashFS) based on files stored in the read-only partition. The firmware image includes target firmware upgrade images, target firmware runtime images, and original firmware runtime images.

[0038] Step S102: Arrange multiple target files in the read-only partition of the original firmware upgrade file in ascending order of change weight to obtain the target firmware upgrade file. The larger the change weight of the target file, the higher the probability of it being modified.

[0039] The read-only partition stores executable program files and configuration files; that is, multiple object files can be executable program files and configuration files stored in the read-only partition. Some of the executable program files are basic functional executable program files generated by compiling open-source code, while others are executable program files generated from business code written by developers to meet specific business needs. Figure 3 This is a diagram illustrating the file arrangement in a read-only partition in related technologies, such as... Figure 3 As shown, in related technologies, the executable program files and configuration files in the read-only partition are arranged in alphabetical order of their file names, such as A, B, C, D, E, F, G, ... and stored in a directory. When using the mksquashfs command in SquashFS to create an image of the read-only partition, a series of processes are performed according to the order of these executable program files and configuration files, and finally a complete SquashFS file system image, i.e., an image of the read-only partition, is generated.

[0040] This method of arranging files alphabetically by their names can lead to significant binary differences between the modified read-only partition image created using the `mksquashfs` command in SquashFS and the original read-only partition image, especially when only a few executable files or configuration files in the read-only partition have been modified. This is because the `mksquashfs` command in SquashFS divides the files in the read-only partition into fixed-size data blocks and processes these blocks sequentially according to their file order. When the size of some executable files or configuration files in the directory changes, it causes significant shifting in the generated modified read-only partition image. Since binary comparisons only confirm the consistency of content at the same location, this results in a large difference between the generated modified read-only partition image and the original image.

[0041] Understandably, the way files are arranged in the read-only partition in the relevant technology can lead to a significant difference between the image of the read-only partition after the firmware upgrade and the image of the read-only partition before the firmware upgrade. When performing a firmware upgrade, a lot of modifications need to be made to the image of the read-only partition before the firmware upgrade, which reduces the firmware upgrade speed.

[0042] To improve firmware upgrade speed, this embodiment arranges multiple target files in the read-only partition of the original firmware upgrade file in ascending order of change weight, thereby reducing the difference between the target firmware upgrade image and the target firmware running image and improving firmware upgrade speed.

[0043] Figure 4 This is a schematic diagram of the arrangement of target files in the read-only partition of the target firmware upgrade file provided in the embodiments of this application, as shown below. Figure 4 As shown, after arranging the target files in the read-only partition in ascending order of change weight, the order of the target files in the read-only partition is: target file starting with the letter B, target file starting with the letter F, target file starting with the letter C, target file starting with the letter G, target file starting with the letter A, target file starting with the letter E, and target file starting with the letter D.

[0044] Figure 5 This is a schematic diagram of a read-only partition image created after updating the first file in the read-only partition, where the files in the read-only partition are arranged in alphabetical order by file name. The grid part represents the difference between the read-only partition image created after the update and the read-only partition image created before the update. Figure 6This embodiment of the application illustrates a read-only partition image created after updating the first file in the read-only partition, where target files in the read-only partition are arranged in ascending order of change weight. The grid portion represents the difference between the updated and unupdated read-only partition images. It is evident that arranging the target files in the read-only partition in ascending order of change weight, compared to arranging them alphabetically by file name, significantly reduces the difference between the updated and unupdated read-only partition images. Furthermore, the differences are concentrated at the end of the read-only partition image, thus improving firmware upgrade speed.

[0045] Step S103: Based on the target firmware upgrade file, generate the target firmware upgrade image, wherein the image of the read-only partition is generated by using a compressed read-only file system.

[0046] Step S104: Compare the target firmware upgrade image with the target firmware running image of the baseboard management controller to obtain the incremental firmware upgrade image.

[0047] It is understandable that since the image is generally in binary form, the target firmware upgrade image is compared with the target firmware running image of the baseboard management controller in binary form.

[0048] The target firmware runtime image for the baseboard management controller is generated based on the target firmware runtime file. Multiple target files in the read-only partition of the original firmware runtime file corresponding to the baseboard management controller's original firmware runtime image are arranged in ascending order of change weight to obtain the target firmware runtime file. The original firmware runtime image is the firmware image currently running on the baseboard management controller. It should be noted that the change weights of the target files are continuously updated with each firmware upgrade.

[0049] It is understandable that the incremental firmware upgrade image includes the content in the target firmware upgrade image that differs from the target firmware runtime image of the baseboard management controller.

[0050] Step S105: Upload the incremental firmware upgrade image to the baseboard management controller so that the baseboard management controller can perform firmware upgrade based on the incremental firmware upgrade image.

[0051] As can be seen, the process of comparing the target firmware upgrade image with the target firmware running image is run in a non-BMC environment. After the incremental firmware upgrade image is determined, it is then uploaded to the BMC, which performs the firmware upgrade based on the incremental firmware upgrade image.

[0052] The firmware upgrade method provided in this application involves: obtaining the original firmware upgrade file of the baseboard management controller; arranging multiple target files in the read-only partition of the original firmware upgrade file in ascending order of change weight to obtain the target firmware upgrade file, wherein the larger the change weight of the target file, the higher the probability of it being modified, thereby reducing the difference between the target firmware upgrade image and the target firmware running image, and thus reducing the size of the incremental firmware upgrade image; generating a target firmware upgrade image based on the target firmware upgrade file, and generating an image of the read-only partition using a compressed read-only file system; comparing the target firmware upgrade image with the target firmware running image of the baseboard management controller to obtain the incremental firmware upgrade image; and uploading the incremental firmware upgrade image to the baseboard management controller so that the baseboard management controller can perform firmware upgrades based on the incremental firmware upgrade image. By uploading the incremental firmware upgrade image for firmware upgrades and reducing the size of the incremental firmware upgrade image, the technical problem of long firmware upgrade time for BMCs in related technologies can be solved, achieving the technical effect of improving firmware upgrade speed and shortening firmware upgrade time.

[0053] Embodiments of this application provide a firmware upgrade method applied to a server. Figure 7 This is a flowchart illustrating the firmware upgrade method provided in an embodiment of this application, as shown below. Figure 7 As shown, the firmware upgrade method includes the following steps:

[0054] Step S701: Obtain the original firmware upgrade file for the baseboard management controller. For details, please refer to [link to relevant documentation]. Figure 1 Step S101 of the illustrated embodiment will not be described again here.

[0055] Step S702: Arrange multiple target files in the read-only partition of the original firmware upgrade file in ascending order of change weight to obtain the target firmware upgrade file. The larger the change weight of the target file, the higher the probability of it being modified.

[0056] Specifically, step S702 includes:

[0057] Step S7021: Based on multiple historical firmware upgrade files of the baseboard management controller, determine the change weight of each target file in multiple target files in the read-only partition of the original firmware upgrade file.

[0058] Each release of BMC means that customers need to upgrade the BMC firmware image. Therefore, the firmware upgrade files of each historical release are obtained to determine the change weight of each target file in the read-only partition of the original firmware upgrade file.

[0059] Step S7022: Based on the change weight of each target file in the read-only partition, arrange the multiple target files in the read-only partition of the original firmware upgrade file in ascending order of change weight to obtain the target firmware upgrade file.

[0060] Step S703: Based on the target firmware upgrade file, generate the target firmware upgrade image, wherein an image of a read-only partition is generated using a compressed read-only file system. For details, please refer to [link to relevant documentation]. Figure 1 Step S103 of the illustrated embodiment will not be described again here.

[0061] Step S704: Compare the target firmware upgrade image with the target firmware running image of the baseboard management controller to obtain the incremental firmware upgrade image.

[0062] Specifically, step S704 above includes:

[0063] Step S7041: Based on the first partition size, the target firmware upgrade image is divided into multiple target firmware upgrade image blocks, and the target firmware runtime image is divided into multiple target firmware runtime image blocks, wherein the target firmware upgrade image blocks and the target firmware runtime image blocks correspond one-to-one.

[0064] BMC firmware images are typically stored in Nor Flash. Nor Flash is characterized by the requirement that data must be erased before being written each time it is updated. Erasure must be done in fixed lengths such as 4K, 32K, or 64K, while writing is done in 256-byte units. The erasure time varies depending on the erase length. Table 1, for example, shows a performance specification table for Nor Flash.

[0065] Table 1

[0066]

[0067] As shown in Table 1, erasing one unit takes 43ms when erasing in 4K units; 190ms when erasing in 32K units; 340ms when erasing in 64K units; 120s when using the 64M full erase method; and 0.6ms when writing 256 bytes per page when programming in 256-byte pages.

[0068] Table 2 is a comparison of the time taken to erase the entire 64M Nor Flash using different erase lengths.

[0069] Table 2

[0070]

[0071] As shown in Table 2, the time taken to erase 64M in 4K units was 704s; the time taken to erase 64M in 32K units was 389s; the time taken to erase 64M in 64K units was 348s; and the time taken to erase 64M in 64M units was 120s.

[0072] It can be seen that the time consumed by different erasure lengths varies greatly. As mentioned above, when upgrading BMC firmware in related technologies, the content in Nor Flash is updated by erasing data blocks of a fixed size (64K). This method is relatively moderate, neither fast nor slow, and is the result of comprehensive consideration.

[0073] To improve the erasure speed and thus reduce the time for BMC firmware upgrades, this application selects the most suitable erasure method based on the differences between the target firmware upgrade image and the target firmware runtime image. Specifically, by comparing the target firmware upgrade image and the target firmware runtime image from a binary perspective, a more suitable erasure method is selected to create an incremental firmware upgrade image.

[0074] First, the 64M image is divided into 1024 blocks, each 64K in size, that is, the first partition is 64K in size.

[0075] Step S7042: For any target firmware upgrade image block, based on the second partition size, the target firmware upgrade image block is divided into a first part and a second part, and the target firmware running image block corresponding to the target firmware upgrade image block is divided into a third part and a fourth part, wherein the first part corresponds to the third part, the second part corresponds to the fourth part, and the second partition size is smaller than the first partition size.

[0076] The second partition size is 32K.

[0077] Step S7043: Compare the first part and the third part to obtain the first comparison result.

[0078] Step S7044: Compare the second part and the fourth part to obtain the second comparison result.

[0079] Step S7045: Based on the first comparison result and the second comparison result, determine the erasure method of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block.

[0080] Step S7046: Determine the incremental firmware upgrade image based on the erasure method of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block.

[0081] Step S705: Upload the incremental firmware upgrade image to the baseboard management controller so that the baseboard management controller can perform a firmware upgrade based on the incremental firmware upgrade image. For details, please refer to [link to relevant documentation]. Figure 1 Step S105 of the illustrated embodiment will not be described again here.

[0082] The firmware upgrade method provided in this application divides the image into coarse-grained blocks using a first partition size, and then further subdivides each block into two parts using a second partition size, achieving a two-level comparison of coarse and fine division. This approach can accurately locate the minimum range of differences: if only a certain part within a block is different, it is not necessary to include the entire coarse-grained block in the incremental data; only the differing part needs to be included. Compared to comparing blocks based on a single granularity, this reduces the transmission and processing of invalid data, thereby improving firmware upgrade efficiency.

[0083] In some optional implementations, step S7021 above includes:

[0084] Step a1: Based on multiple historical firmware upgrade files of the baseboard management controller, determine the historical change rate of each historical target file in the read-only partition of each historical firmware upgrade file.

[0085] For any given historical firmware upgrade file, determine which historical target files in the read-only partition of that file have changed. Compare each changed historical target file sequentially, and based on the comparison results, determine the historical change rate of the changed historical target files. It is understood that the historical change rate ranges from 0% to 100%. The historical change rate of each historical target file in the read-only partition of the given historical firmware upgrade file can be calculated, and consequently, the historical change rate of each historical target file in the read-only partition of each historical firmware upgrade file can be calculated.

[0086] Step a2: For any historical target file, add up the multiple historical change rates corresponding to that historical target file to obtain the sum of the historical change rates of that historical target file, so as to obtain the sum of the historical change rates of each historical target file.

[0087] Step a3: Determine the change weight of each historical target file based on the sum of the historical change rates of each historical target file.

[0088] For any historical target file, the sum of the historical change rates of that historical target file is used as the change weight of that historical target file.

[0089] Understandably, a list of historical target file change weights can be generated based on the change weights of each historical target file and each historical target file. The change weights in this list reflect the probability that different historical target files will be modified. The larger the change weight, the higher the probability that the historical target file will be modified in the future.

[0090] Step a4: Based on the change weight of each historical target file, determine the change weight of each target file in the read-only partition of the original firmware upgrade file.

[0091] Specifically, after obtaining the change weight of each historical target file, for any target file in the read-only partition of the original firmware upgrade file, the change weight of the historical target file corresponding to that target file is used as the change weight of that target file. This can be understood as the historical target file corresponding to the target file being a historical target file with the same name as the target file.

[0092] The firmware upgrade method provided in this application greatly reduces the difference between the target firmware upgrade image and the target firmware running image by sorting the target files according to the change weight, thereby reducing the size of the incremental firmware upgrade image and improving the speed of firmware upgrade.

[0093] In some optional implementations, step S7045 above includes:

[0094] Step b1: If the first comparison result shows that the first part and the third part are different, and the second comparison result shows that the second part and the fourth part are different, then the target firmware upgrade image block is determined to be an incremental firmware upgrade image block, and the target firmware running image block corresponding to the target firmware upgrade image block is the incremental firmware running image block corresponding to the incremental firmware upgrade image block. The erasure method of the target firmware running image block corresponding to the target firmware upgrade image block is determined to be erasure in units of the first erasure size.

[0095] The first erase size is 64KB. Understandably, comparing the first and third parts, and the second and fourth parts, will result in four possible outcomes: 1. Both the first and third parts differ; both the second and fourth parts differ; 2. The first and third parts are the same; both the second and fourth parts differ; 3. The first and third parts differ; both the second and fourth parts are the same; 4. The first and third parts are the same; both the second and fourth parts are the same. It's clear that "difference" means even a single byte difference is considered a difference.

[0096] If the comparison result is the fourth case, it indicates that the target firmware upgrade image block is not an incremental firmware upgrade image block and does not need to be included in the incremental firmware upgrade image for firmware upgrade.

[0097] If the comparison result is the first case, it means that both the front and back parts of the target firmware upgrade image block are different from the corresponding target firmware runtime image block. In this case, the target firmware upgrade image block is determined to be an incremental firmware upgrade image block, and the erasure method of the target firmware runtime image block corresponding to the target firmware upgrade image block is determined to be erasure in 64K units.

[0098] The firmware upgrade method provided in this application improves firmware upgrade efficiency by comparing and determining the most efficient erasure method.

[0099] In some optional implementations, step S7045 above includes:

[0100] Step c1: If the first comparison result shows that the first part and the third part are different, and the second comparison result shows that the second part and the fourth part are the same, then based on the third division size, the first part is divided into multiple fifth parts, and the third part is divided into multiple sixth parts, wherein the fifth part and the sixth part correspond one-to-one, and the third division size is smaller than the second division size.

[0101] The third partition is 4K in size. If the comparison result is the third case, it indicates that the second part of the target firmware upgrade image block is not an incremental firmware upgrade image block and does not need to be included in the incremental upgrade image for firmware upgrades. The first part of the target firmware image block and the third part of the corresponding target firmware runtime image block are then further partitioned, dividing the 32K block into eight 4K parts.

[0102] Step c2: For any fifth part, compare the fifth part with the corresponding sixth part to obtain the third comparison result.

[0103] Step c3: Based on the third comparison result, determine the erasure method of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block.

[0104] The firmware upgrade method provided in this application improves firmware upgrade efficiency by comparing and determining the most efficient erasure method.

[0105] In some alternative implementations, step c3 above includes:

[0106] Step c31: If the number of target fifth parts that are different from the corresponding sixth part in the first part of the third comparison result characterization exceeds a preset number threshold, the first part is determined to be an incremental firmware upgrade image block, and the third part corresponding to the first part is the incremental firmware running image block corresponding to the incremental firmware upgrade image block. The erasure method of the third part corresponding to the first part is determined to be erasure in units of the second erasure size, wherein the second erasure size is smaller than the first erasure size.

[0107] The second erase size is 32KB. It's understandable that if the number of different target fifth parts (different from the corresponding sixth part) in the first part exceeds a preset threshold, erasing in 32KB units will be faster. That is, the first part will be used as the incremental firmware upgrade image block.

[0108] The firmware upgrade method provided in this application improves firmware upgrade efficiency by comparing and determining the most efficient erasure method.

[0109] In some optional implementations, the above firmware upgrade method further includes:

[0110] Step d1: If the number of target fifth parts that differ from the corresponding sixth part in the first part of the third comparison result does not exceed the preset number threshold, the target fifth part is determined to be an incremental firmware upgrade image block, and the sixth part corresponding to the target fifth part is the incremental firmware running image block corresponding to the incremental firmware upgrade image block. The erasure method of the sixth part corresponding to the target fifth part is determined to be erasure in units of the third erasure size, wherein the third erasure size is smaller than the second erasure size.

[0111] The third erase size is 4K. It's understandable that if the number of target fifth parts that differ from the corresponding sixth part in the first part does not exceed a preset threshold, erasing in 4K units will be faster. That is, the target fifth part is used as an incremental firmware run image block.

[0112] It should be noted that if the first comparison result is that the first part and the third part are the same, and the second comparison result is that the second part and the fourth part are different, that is, in the case of the second comparison result, the process of determining the erasure method of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block is similar to the process of determining the erasure method of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block in the case of the third comparison result. Please refer to the relevant descriptions of steps c1 to c3 and step d1 above, which will not be repeated here.

[0113] To make the process of determining the erase method of the incremental firmware upgrade image block and the corresponding incremental firmware runtime image block clearer, combined with Figure 8 Describe, Figure 8 This is a flowchart illustrating the process of determining the erasure method of the incremental firmware upgrade image block and the corresponding incremental firmware runtime image block, as provided in an embodiment of this application. Figure 8 As shown, the process includes:

[0114] The 64M target firmware upgrade image is divided into 1024 blocks of 64K each, and the 64K data blocks are processed one by one.

[0115] The current 64K data block is divided into two 32K data blocks for processing. It is then determined whether the data content of both 32K data blocks is consistent with the corresponding data block in the target firmware runtime image.

[0116] If both 32K data blocks have the same data content as the corresponding data block in the target firmware runtime image, then it is determined that the 64K data block is not an incremental firmware upgrade image block, and the process continues to traverse the next 64K data block.

[0117] If the data content of both 32K data blocks is inconsistent with the corresponding data block in the target firmware runtime image, then the current 64K data block is determined to be the incremental firmware upgrade image block. The erasure method of the corresponding 64K data block in the target firmware runtime image is to erase in units of 64K.

[0118] If one of the two 32K data blocks has a different data content from the corresponding data block in the target firmware runtime image, then the target 32K data block with the different data content from the corresponding data block in the target firmware runtime image will be divided into eight 4K data blocks for separate processing.

[0119] Determine if the number of target 4K data blocks whose data content differs from the corresponding data block in the target firmware runtime image is greater than N.

[0120] If the number of target 4K data blocks whose data content differs from the corresponding data block in the target firmware runtime image is greater than N, then the target 32K data block is determined as the incremental firmware upgrade image block. The corresponding 32K data block in the target firmware runtime image is erased in units of 32K.

[0121] If the number of target 4K data blocks whose data content differs from the corresponding data block in the target firmware runtime image is no greater than N, then the target 4K data blocks whose data content differs from the corresponding data block in the target firmware runtime image are determined as incremental firmware upgrade image blocks. The erasure method of the corresponding 4K data block in the target firmware runtime image is to erase in units of 4K.

[0122] The firmware upgrade method provided in this application improves firmware upgrade efficiency by comparing and determining the most efficient erasure method.

[0123] In some optional implementations, the above firmware upgrade method further includes:

[0124] Step e1: Obtain the first erase time and the first write time for the data of the second erase size.

[0125] Step e2: Obtain the second erase time and the second write time for the data of the third erase size.

[0126] Based on the different physical characteristics of different Nor Flash models, the time TS1 for erasing 4K data and the programming time (which is also the writing time) TS2 are determined; the time TB1 for erasing 32K data and the programming time (which is also the writing time) TB2 are determined, thereby dynamically calculating the preset quantity threshold.

[0127] Step e3: Based on the first erase time, the first write time, the second erase time, and the second write time, determine the preset quantity threshold using the following formula:

[0128] N = (TB1 + TB2) / (TS1 + TS2)

[0129] Where N is a preset quantity threshold, TB1 is the first erase time, TB2 is the first write time, TS1 is the second erase time, and TS2 is the second write time.

[0130] Under the physical characteristics of a sample Nor Flash model, erasing 32K data takes 190ms, and writing 32K data takes 76.8ms, for a total erasing and writing time of 266.8ms. Erasing 4K data takes 43ms, and writing 4K data takes 9.6ms, for a total erasing and writing time of 52.6ms. Using the formula above, N is calculated to be 5. This means that when the number of target fifth parts that differ from the corresponding sixth part in the first part is greater than 5, erasing the Nor Flash using the 32K erasing method will be faster. When the number of target fifth parts is no greater than 5, erasing the Nor Flash using the 4K erasing method will be faster.

[0131] In some optional implementations, step S7046 above includes:

[0132] Step f1: Determine the offset address of the incremental firmware running image block corresponding to the incremental firmware upgrade image block in the target storage module of the original firmware running image of the storage substrate management controller.

[0133] The target storage module is the target Nor Flash.

[0134] Step f2: Based on the offset address of the incremental firmware running image block corresponding to the incremental firmware upgrade image block in the target storage module of the original firmware running image of the storage substrate management controller and the erasure method of the incremental firmware running image block corresponding to the incremental firmware upgrade image block, determine the data header of the incremental firmware upgrade image block.

[0135] The incremental firmware upgrade image includes an incremental firmware upgrade image block and a data header for the incremental firmware upgrade image block. The data header of the incremental firmware upgrade image block is used to indicate the offset address of the incremental firmware running image block corresponding to the incremental firmware upgrade image block in the target storage module of the original firmware running image of the storage substrate management controller, the data block size of the incremental firmware upgrade image block, and the erasure method of the incremental firmware running image block corresponding to the incremental firmware upgrade image block.

[0136] For example, the structure of the data header can be as follows:

[0137] struct data_head {

[0138] int magic; / / 0x1234abcd

[0139] int erase_type; / / 4K, 32K, 64K

[0140] int data_len; / / Data block size

[0141] int data_addr; / / Starting offset of the data

[0142] };

[0143] Among them, the magic field is used to indicate that this is the starting point of the data header; the erase_type field indicates the erasure method of the incremental firmware running image block corresponding to the incremental firmware upgrade image block; data_len indicates the data block size of the incremental firmware upgrade image block; int data_addr indicates the offset address of the incremental firmware running image block corresponding to the incremental firmware upgrade image block in the target storage module of the original firmware running image of the storage substrate management controller, and the value range is 0 to 64M.

[0144] It is understandable that by traversing 1024 target firmware upgrade image blocks, the erasure method of the incremental firmware running image block corresponding to each incremental firmware upgrade image block is obtained, as well as the offset address of the incremental firmware running image block corresponding to each incremental firmware upgrade image block in the target storage module of the original firmware running image of the storage substrate management controller. In this way, the data header of each incremental firmware upgrade image block can be determined to create the entire incremental firmware upgrade image.

[0145] Step f3: Determine the incremental firmware upgrade image based on the incremental firmware upgrade image block and the data header of the incremental firmware upgrade image block.

[0146] For example, Figure 9 This is a schematic diagram of the structure of the target firmware upgrade image provided in the embodiments of this application, as shown below. Figure 9 As shown, the grid section represents incremental firmware upgrade image blocks, where the size of different incremental firmware upgrade image blocks can be 4K, 64K, or 32K. Figure 10 This is a schematic diagram of the structure of the incremental firmware upgrade image provided in the embodiments of this application, as shown below. Figure 10 As shown, the incremental firmware upgrade image includes multiple data headers and multiple incremental firmware upgrade image blocks corresponding to the multiple data headers. In the incremental firmware upgrade image, they are arranged in the order of data header, incremental firmware upgrade image block corresponding to the data header, data header, and incremental firmware upgrade image block corresponding to the data header. The grid part is the incremental firmware upgrade image block.

[0147] The firmware upgrade method provided in this application embodiment ensures that the storage area that needs to be erased and written can be accurately located when performing a BMC firmware upgrade, thereby improving the accuracy of the BMC firmware upgrade.

[0148] In some optional implementations, step S705 above includes:

[0149] Step g1: Based on the local network speed, determine the first upload time of the incremental firmware upgrade image to the baseboard management controller and the second upload time of the target firmware upgrade image to the baseboard management controller.

[0150] Step g2: Obtain the first upgrade time required for the baseboard management controller to perform a firmware upgrade using the incremental firmware upgrade image.

[0151] It is understandable that by obtaining the number of incremental firmware upgrade image blocks in the target firmware upgrade image and the erase / write method of the incremental firmware runtime image block corresponding to each incremental firmware upgrade image block through the aforementioned method, the first upgrade time required for firmware upgrade using the incremental firmware upgrade image can be calculated. The calculation formula is as follows:

[0152] T = T0 × N0 + T1 × N1 + T2 × N2

[0153] Where T is the first upgrade time, T0 is the time taken to erase and write a single 4K data, T1 is the time taken to erase and write a single 32K data, T2 is the time taken to erase and write a single 64K data, N0 is the number of incremental firmware running image blocks erased in 4K units, N1 is the number of incremental firmware running image blocks erased in 32K units, and N2 is the number of incremental firmware running image blocks erased in 64K units.

[0154] For example, the number of incremental firmware run image blocks erased in 4K units is 202, the number of incremental firmware run image blocks erased in 32K units is 154, and the number of incremental firmware run image blocks erased in 64K units is 312. According to Table 1, the time taken to erase and write a single 4K data is 52.6ms, the time taken to erase and write a single 32K data is 266.8ms, and the time taken to erase and write a single 64K data is 493.6ms. Thus, the first upgrade time can be calculated to be 247.87s.

[0155] Step g3: Obtain the second upgrade time required for firmware upgrade using the target firmware upgrade image by employing a full erase method on the baseboard management controller.

[0156] For example, Table 1 shows that using a full erase method, the erase time required for firmware upgrade using the target firmware upgrade image is 120s, and the write time is 157.3s. Therefore, the total erase and write time for the second upgrade is 277.3s. A full erase, or 64MB full erase, is a method of erasing the entire original firmware running image at once.

[0157] Step g4: If the sum of the first upgrade time and the first upload time is not greater than the sum of the second upgrade time and the second upload time, the incremental firmware upgrade image is uploaded to the baseboard management controller so that the baseboard management controller can perform firmware upgrade based on the incremental firmware upgrade image.

[0158] The sum of the first upgrade time and the first upload time is the first total, and the sum of the second upgrade time and the second upload time is the second total. If the first total is not greater than the second total, the firmware upgrade is performed based on the incremental firmware upgrade image.

[0159] Step g5: If the sum of the first upgrade time and the first upload time is greater than the sum of the second upgrade time and the second upload time, the target firmware upgrade image is uploaded to the baseboard management controller so that the baseboard management controller can perform firmware upgrade based on the target firmware upgrade image.

[0160] If the first sum is greater than the second sum, a full erase method is used to upgrade the firmware based on the target firmware upgrade image.

[0161] The firmware upgrade methods in related technologies cannot predict the time required for the firmware upgrade. The firmware upgrade method provided in this application solves the deficiency of the related technologies in that they cannot predict the time required for the firmware upgrade, thereby improving the user experience. In the BMC firmware upgrade scenario, the first upload time and the second upload time are determined by combining the local network speed, and the first upgrade time and the second upgrade time are estimated. Based on the sum of the first and second upload times, a more efficient firmware upgrade method is dynamically selected, further improving the firmware upgrade speed.

[0162] In some optional implementations, the above firmware upgrade method further includes:

[0163] Step h1 involves simultaneously uploading the incremental firmware upgrade image to the baseboard management controller and writing data at the target offset address in the target storage module of the original firmware running image of the baseboard management controller based on the data header and incremental firmware upgrade image block in the uploaded incremental firmware upgrade image.

[0164] or,

[0165] While uploading the target firmware upgrade image to the baseboard management controller, the process simultaneously erases the data in the target storage module of the original firmware running image of the baseboard management controller and writes the uploaded target firmware upgrade image to the corresponding location in the target storage module.

[0166] In related technologies, when upgrading BMC firmware, uploading the BMC firmware upgrade image and updating the Nor Flash containing the original firmware running image are performed sequentially. This method results in a long firmware upgrade time and slow speed.

[0167] Since the total time spent erasing and writing Nor Flash is greater than the time spent uploading the image in most cases, this application embodiment improves the firmware upgrade speed by uploading the BMC firmware upgrade image and updating the Nor Flash that stores the original firmware running image in parallel.

[0168] When performing a firmware upgrade based on an incremental firmware upgrade image, the content at the corresponding position in the Nor Flash of the original firmware running image of the storage substrate management controller is erased and written simultaneously when the first data header and the corresponding incremental firmware upgrade image block of the first data header are uploaded.

[0169] When performing a firmware upgrade based on the target firmware upgrade image, upon uploading the first data block, a full erase command is immediately issued to the Nor Flash of the original firmware runtime image of the storage substrate management controller. This ensures that the full erase of the Nor Flash and the writing of the 64MB target firmware upgrade image content to the Nor Flash are performed simultaneously. This parallel processing method further improves the speed of BMC firmware upgrades.

[0170] For example, if the local network speed is 2M / s, and the firmware upgrade is performed based on the target firmware upgrade image, it can be calculated that the time to upload the target firmware upgrade image is 32s, the second upgrade time is 277.3s, and the total time for the non-parallel method is 309.3s. The parallel scheme proposed in this application embodiment can complete the entire upgrade in just 277.3s. Parallel processing alone can improve the upgrade speed by about 10%.

[0171] The firmware upgrade method provided in this application further reduces the time required for BMC firmware upgrades and improves the efficiency of BMC firmware upgrades by processing image uploading and image erasure / writing in parallel.

[0172] In some optional implementations, step S7021 above includes:

[0173] Step i1: Receive the user-uploaded custom change rates for each target file in the read-only partition.

[0174] Among them, users can be BMC firmware developers. Based on the high-frequency modification requests reported by BMC users, the developers determine the custom change rate of each target file in the read-only partition. For any target file, the higher the modification request for that target file, the higher the custom change rate of that target file.

[0175] Step i2: Based on the custom change rates of multiple historical firmware upgrade files of the baseboard management controller and the target files of each target file in the read-only partition uploaded by the user, determine the change weight of each target file in the multiple target files in the read-only partition of the original firmware upgrade file.

[0176] Specifically, based on multiple historical firmware upgrade files of the baseboard management controller, the historical change rate of each historical target file in the read-only partition of each historical firmware upgrade file is determined; for any historical target file, the multiple historical change rates corresponding to that historical target file are added together to obtain the sum of historical change rates of that historical target file, thus obtaining the sum of historical change rates of each historical target file; based on the sum of historical change rates of each historical target file, the change weight of each historical target file is determined; based on the change weight of each historical target file and the custom change rate of each target file in the read-only partition uploaded by the user, the change weight of each target file in the read-only partition of the original firmware upgrade file is determined.

[0177] Based on the change weight of each historical target file and the custom change rate of each target file in the read-only partition uploaded by the user, the change weight of each target file in the read-only partition of the original firmware upgrade file is determined, including:

[0178] For any target file, based on the name of the target file, filter out the change weights of historical target files with the same name as the target file from the change weights of historical target files, use the change weights of the historical target files as the initial change weights of the target file, and add the initial change weights of the target file to the custom change rate of the target file to obtain the change weight of the target file.

[0179] The firmware upgrade method provided in this application incorporates both historical change rate and custom change rate into the change weight. This avoids the problem that relying solely on historical change rate may overlook new requirements, or relying solely on subjective judgment may deviate from the actual upgrade pattern. This makes the change weight more closely match the real-world firmware upgrade scenario, further reducing the difference between the target firmware upgrade image and the target firmware running image, thereby further reducing the size of the incremental firmware upgrade image and improving the firmware upgrade speed.

[0180] The firmware upgrade method provided in this application reduces the difference between the target firmware upgrade image and the target firmware running image, dynamically selects a faster method for erasing incremental firmware running image blocks, and comprehensively selects the fastest firmware upgrade method based on the actual network conditions when uploading the image. It can also accurately estimate the time required for this firmware upgrade, thereby improving the firmware upgrade speed and prompting users to update the firmware upgrade time, thus improving the development efficiency of server products and the customer experience.

[0181] The firmware upgrade method provided in this application embodiment ensures that the slowest average firmware upgrade speed is achieved by using a full erase method. Compared to firmware upgrade methods in related technologies, the firmware upgrade speed is improved by approximately 10%. This application embodiment moves the image comparison operation, originally performed on the BMC runtime environment, to the image creation stage. Furthermore, it employs a binary comparison method, concentrating differences and updating only the differing data blocks. The smaller the incremental firmware upgrade image size, the more significant the improvement in firmware upgrade speed.

[0182] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0183] Embodiments of this application also provide an electronic device, such as... Figure 11 As shown, it includes a processor 1101 and a memory 1102, in which a computer program is stored. The processor 1101 is configured to run the computer program to perform the steps in any of the firmware upgrade method embodiments described above.

[0184] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the firmware upgrade method embodiments described above when running.

[0185] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0186] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the firmware upgrade method embodiments described above.

[0187] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the firmware upgrade method embodiments described above.

[0188] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0189] The firmware upgrade method, electronic device, storage medium, and program product provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A firmware upgrade method characterized by comprising: The method comprises the following steps: obtain an original firmware upgrade file of a baseboard management controller; arrange a plurality of target files in a read-only partition of the original firmware upgrade file in order of change weight from small to large to obtain a target firmware upgrade file, wherein the greater the change weight of a target file, the higher the probability of being modified; generate a target firmware upgrade image based on the target firmware upgrade file, wherein a compressed read-only file system is used to generate an image of the read-only partition; compare the target firmware upgrade image with a target firmware running image of the baseboard management controller to obtain an incremental firmware upgrade image; upload the incremental firmware upgrade image to the baseboard management controller to enable the baseboard management controller to perform firmware upgrade based on the incremental firmware upgrade image.

2. The method of claim 1, wherein, The arranging a plurality of target files in a read-only partition of the original firmware upgrade file in order of change weight from small to large to obtain a target firmware upgrade file comprises: determine a change weight of each target file in the plurality of target files in the read-only partition of the original firmware upgrade file based on a plurality of historical firmware upgrade files of the baseboard management controller; arrange the plurality of target files in the read-only partition of the original firmware upgrade file in order of the change weight from small to large based on the change weight of each target file in the plurality of target files in the read-only partition to obtain a target firmware upgrade file.

3. The method of claim 2, wherein, The determining a change weight of each target file in the plurality of target files in the read-only partition of the original firmware upgrade file based on a plurality of historical firmware upgrade files of the baseboard management controller comprises: determine a historical change rate of each historical target file in a plurality of historical target files in a read-only partition of each historical firmware upgrade file based on a plurality of historical firmware upgrade files of the baseboard management controller; for any historical target file, add a plurality of historical change rates corresponding to the historical target file to obtain a historical change rate sum of the historical target file to obtain a historical change rate sum of each historical target file; determine a change weight of each historical target file based on the historical change rate sum of each historical target file; determine a change weight of each target file in the plurality of target files in the read-only partition of the original firmware upgrade file based on the change weight of each historical target file.

4. The method of claim 1, wherein, The comparing the target firmware upgrade image with a target firmware running image of the baseboard management controller to obtain an incremental firmware upgrade image comprises: divide the target firmware upgrade image into a plurality of target firmware upgrade image blocks and divide the target firmware running image into a plurality of target firmware running image blocks based on a first division size, wherein the target firmware upgrade image blocks and the target firmware running image blocks correspond to each other one by one; For any target firmware upgrade image block, the target firmware upgrade image block is divided into a first part and a second part based on a second division size, and a target firmware running image block corresponding to the target firmware upgrade image block is divided into a third part and a fourth part, wherein the first part corresponds to the third part, and the second part corresponds to the fourth part, and the second division size is smaller than the first division size; comparing the first part and the third part to obtain a first comparison result; comparing the second part and the fourth part to obtain a second comparison result; based on the first comparison result and the second comparison result, determining the erasing mode of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block; based on the erasing mode of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block, determining the incremental firmware upgrade image.

5. The method of claim 4, wherein, The determination of the erasing mode of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block based on the first comparison result and the second comparison result comprises: if the first comparison result is that the first part and the third part are different, and the second comparison result is that the second part and the fourth part are different, it is determined that the target firmware upgrade image block is an incremental firmware upgrade image block, the target firmware running image block corresponding to the target firmware upgrade image block is the incremental firmware running image block corresponding to the incremental firmware upgrade image block, and the erasing mode of the target firmware running image block corresponding to the target firmware upgrade image block is erasing in units of the first erasing size.

6. The method of claim 4, wherein, The determination of the erasing mode of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block based on the first comparison result and the second comparison result comprises: if the first comparison result is that the first part and the third part are different, and the second comparison result is that the second part and the fourth part are the same, the first part is divided into a plurality of fifth parts based on a third division size, and the third part is divided into a plurality of sixth parts, wherein the fifth part and the sixth part correspond one by one, and the third division size is smaller than the second division size; for any fifth part, the fifth part and the corresponding sixth part are compared to obtain a third comparison result; based on the third comparison result, the erasing mode of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block is determined.

7. The method of claim 6, wherein, The determination of the erasing mode of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block based on the third comparison result comprises: In a case where the third comparison result represents that the number of different target fifth parts existing in the first part and the corresponding sixth part exceeds a preset number threshold, the first part is determined as an incremental firmware upgrade image block, the third part corresponding to the first part is an incremental firmware running image block corresponding to the incremental firmware upgrade image block, and the erasing manner of the third part corresponding to the first part is determined as erasing in a second erasing size, where the second erasing size is smaller than the first erasing size.

8. The method of claim 7, wherein, The method further comprises: In a case where the third comparison result represents that the number of different target fifth parts existing in the first part and the corresponding sixth part does not exceed the preset number threshold, the target fifth part is determined as an incremental firmware upgrade image block, the sixth part corresponding to the target fifth part is an incremental firmware running image block corresponding to the incremental firmware upgrade image block, and the erasing manner of the sixth part corresponding to the target fifth part is determined as erasing in a third erasing size, where the third erasing size is smaller than the second erasing size.

9. The method of claim 8, wherein, The method further comprises: obtaining a first erasing time consumption and a first writing time consumption of data in the second erasing size; obtaining a second erasing time consumption and a second writing time consumption of data in the third erasing size; determining the preset number threshold based on the first erasing time consumption, the first writing time consumption, the second erasing time consumption and the second writing time consumption by the following formula: N = (TB1 + TB2) / (TS1 + TS2) wherein N is the preset number threshold, TB1 is the first erasing time consumption, TB2 is the first writing time consumption, TS1 is the second erasing time consumption, and TS2 is the second writing time consumption.

10. The method of claim 4, wherein, The determination of the incremental firmware upgrade image based on the erasing manner of the incremental firmware upgrade image block and the incremental firmware running image block corresponding to the incremental firmware upgrade image block comprises: determining an offset address of the incremental firmware running image block corresponding to the incremental firmware upgrade image block in a target storage module storing an original firmware running image of the baseboard management controller; determining a data header of the incremental firmware upgrade image block based on the offset address of the incremental firmware running image block corresponding to the incremental firmware upgrade image block in the target storage module storing the original firmware running image of the baseboard management controller and the erasing manner of the incremental firmware running image block corresponding to the incremental firmware upgrade image block; determining the incremental firmware upgrade image based on the incremental firmware upgrade image block and the data header of the incremental firmware upgrade image block.

11. The method of claim 1, wherein, The uploading of the incremental firmware upgrade image to the baseboard management controller to enable the baseboard management controller to perform firmware upgrade based on the incremental firmware upgrade image comprises: determining a first uploading time of the incremental firmware upgrade image to the baseboard management controller and a second uploading time of the target firmware upgrade image to the baseboard management controller based on a local network speed; obtaining a first upgrade time required by the baseboard management controller to perform firmware upgrade by using the incremental firmware upgrade image; The second upgrade time required for the baseboard management controller to perform firmware upgrade by using the target firmware upgrade image in a full-erasing manner; In a case where the sum of the first upgrade time and the first upload time is not greater than the sum of the second upgrade time and the second upload time, uploading the incremental firmware upgrade image to the baseboard management controller to enable the baseboard management controller to perform firmware upgrade based on the incremental firmware upgrade image; In a case where the sum of the first upgrade time and the first upload time is greater than the sum of the second upgrade time and the second upload time, uploading the target firmware upgrade image to the baseboard management controller to enable the baseboard management controller to perform firmware upgrade based on the target firmware upgrade image.

12. The method of claim 11, wherein, The method further comprises: performing, in parallel with the uploading of the incremental firmware upgrade image to the baseboard management controller, a step of erasing and rewriting data at a target offset address in a target storage module storing a running image of the original firmware of the baseboard management controller based on a data header and an incremental firmware upgrade image block in the uploaded incremental firmware upgrade image; or performing, in parallel with the uploading of the target firmware upgrade image to the baseboard management controller, a step of erasing data in a target storage module storing a running image of the original firmware of the baseboard management controller and writing the uploaded target firmware upgrade image to a corresponding position in the target storage module.

13. An electronic device, comprising: comprises: a memory for storing a computer program; a processor for implementing the steps of the firmware upgrade method according to any one of claims 1 to 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that, The computer program stored in the computer readable storage medium implements the steps of the firmware upgrade method according to any one of claims 1 to 12 when executed by the processor.

15. A computer program product comprising a computer program, characterized in that, The computer program implements the steps of the firmware upgrade method according to any one of claims 1 to 12 when executed by the processor.

Images