Firmware upgrading method and system, server, equipment, medium and product

Abstract

The invention discloses a firmware upgrading method and system, a server, equipment, a medium and a product, relates to the technical field of servers, and does not enter a memory of a management controller so as to wait in at least one network equipment buffer area as long as there is no response of an input instruction. When the incoming instruction is responded, at least one data block with the preset size is intercepted from at least one waiting data packet, verification processing is carried out in the form of the data block, the whole firmware mirror image file does not need to be verified, and the granularity of a verification object is reduced so as to save memory resources of the management controller. The method comprises the following steps of: checking and comparing target data blocks obtained by segmenting a second mirror image file stored in a flash memory, abandoning the data blocks when the checking results are identical, and writing the data blocks into the flash memory when the checking results are different, so that repeated writing in the flash memory is avoided, the storage space occupation of the flash memory is reduced, and the storage efficiency of the flash memory is improved. And the memory space utilization rate of the management controller is improved.

Description

Technical Field

[0001] This application relates to the technical field of servers, and particularly to a firmware upgrade method, system, server, device, medium, and product. Background Art

[0002] During the process of firmware upgrade using an operating system, the user uploads the entire firmware image file remotely or through other interfaces. After the transmission is completed, the entire firmware image file is uploaded to the memory of the management controller to perform an integrity check on the image file to ensure that the entire firmware image file has not been tampered with. Since the memory requirement of the entire firmware image file is large, it occupies a relatively large amount of memory space of the management controller.

[0003] Therefore, how to reduce the memory space occupied by the firmware image file in the management controller is a technical problem that those skilled in the art urgently need to solve. Summary of the Invention

[0004] This application provides a firmware upgrade method, system, server, device, medium, and product to at least solve the technical problems in the related art that the serial port burning without relying on the operating system in manual operation increases the firmware upgrade maintenance difficulty and upgrade speed.

[0005] This application provides a firmware upgrade method, including: Receiving a firmware upgrade instruction, obtaining a first image file to be upgraded, splitting the first image file into at least one data packet, and transmitting the at least one data packet to at least one network device buffer of a target link to wait for an incoming instruction; Responding to the incoming instruction, intercepting at least one data block of a preset size from the at least one waiting data packet, and storing the at least one data block in the memory of the management controller; Obtaining a target data block corresponding to the at least one data block, and performing a verification process on the at least one data block and the target data block to obtain a verification result; wherein, the target data block is split from a second image file, and the second image file is stored in the flash memory; When the verification result is the same, the data block is discarded; When the verification result is different, the data block is written into the flash memory.

[0006] This application also provides a dual operating system, which includes a first operating system and a second operating system; wherein, the memory access resource of the first operating system is greater than that of the second operating system; In the case where the first operating system fails to start the management controller, the second operating system is started to execute the steps of the above-mentioned firmware upgrade method to complete the firmware upgrade of the management controller.

[0007] The present application also provides a server, including a dual operating system.

[0008] The present application also provides an electronic device, including: a memory for storing a computer program; a processor for implementing the steps of any of the above firmware upgrade methods when executing the computer program.

[0009] The present application also provides a computer-readable storage medium, in which a computer program is stored, and the computer program implements the steps of any of the above firmware upgrade methods when executed by a processor.

[0010] The present application also provides a computer program product, including a computer program, and the computer program implements the steps of any of the above firmware upgrade methods when executed by a processor.

[0011] With this application, since the entire firmware image file is uploaded to the memory of the management controller during the conventional firmware upgrade process and the entire firmware image file is also verified during the verification process, it causes more memory occupancy of the management controller. Considering the resource-constrained characteristic that the accessible memory resources of the RTOS system are relatively few, usually the memory occupied by storing the entire firmware image file is greater than the accessible memory of the RTOS system. Therefore, first, before uploading to the memory of the management controller, receive a firmware upgrade instruction, obtain a first image file to be upgraded, split the first image file into at least one data packet, and transmit it to at least one network device buffer of the target link to wait for an incoming instruction. That is to say, during this transmission process, as long as there is no response to the incoming instruction, it will not enter the memory of the management controller and will wait in at least one network device buffer. When responding to the incoming instruction, intercept at least one data block of a preset size from at least one of the waiting data packets, realizing the mobility of the first image file to be retrieved at any time in the form of data blocks, rather than receiving the entire image file at once, and also realizing the interception control of the first image file at the flow control level in response to the incoming instruction. Intercept at least one data block and store it in the memory of the management controller, reducing the file storage granularity to the data block granularity. Compared with the conventional method of storing the entire firmware image file in the memory of the management controller, intercepting at least one data block according to the preset size reduces the memory occupancy space of the management controller under the RTOS system. Secondly, obtain target data blocks corresponding to at least one data block, and perform a verification process on at least one data block and the target data blocks to obtain a verification result. Compared with the situation where a large amount of memory of the management controller is occupied when verifying the entire firmware image file conventionally, this application performs the verification process in the form of data blocks, without verifying the entire firmware image file, reducing the granularity of the verification object to save the memory resources of the management controller. Finally, compared with the conventional integrity verification of the entire firmware image file corresponding to itself, this application needs to perform a verification comparison with the target data blocks obtained by splitting the second image file stored in the flash memory. When the verification result is the same, the data block is discarded. When the verification result is different, the data block is written into the flash memory, avoiding repeated writing in the flash memory, reducing the memory occupancy space of the management controller, and also reducing the storage space occupancy of the flash memory, improving the utilization rate of the memory space of the management controller. Avoid writing all firmware files into the flash memory, reducing the amount of written data, and improving the writing speed to a certain extent and reducing the write wear of the flash memory.

[0012] Therefore, it is possible to solve the technical problem that the firmware image file occupies a relatively large amount of memory space in the management controller, achieving the effect of splitting the image file to be upgraded when the management controller receives it, intercepting at least one data block of a preset size from at least one waiting data packet, storing it in a flowing manner in the form of data blocks, reducing the storage granularity, and during the verification process, performing the verification process in the form of data blocks, discarding the data blocks that are the same as the target data block among at least one data block, and actually writing to the flash memory only the data blocks that are different from the target data block, saving the memory resources of the management controller, reducing the memory occupied space of the management controller, and also avoiding repeated writing to the flash memory. Brief Description of the Drawings

[0013] To more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0014] Figure 1 It is a flowchart of a firmware upgrade method provided by an embodiment of the present application; Figure 2 It is a schematic structural diagram of a double-ring buffer area provided by an embodiment of the present application; Figure 3 It is a partial verification schematic diagram of splitting data blocks based on the first data block size provided by an embodiment of the present application; Figure 4 It is a schematic diagram of head-to-tail recursive search verification provided by an embodiment of the present application; Figure 5 It is a schematic diagram of a firmware upgrade method based on the RTOS operating system provided by an embodiment of the present application; Figure 6 It is a flowchart of a head-to-tail recursive search method provided by an embodiment of the present application; Figure 7 It is a schematic structural diagram of a firmware upgrade device provided by an embodiment of the present application. Detailed Embodiments

[0015] The following will clearly and completely describe the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, rather than all embodiments. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present application.

[0016] It should be noted that in the description of this application, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in this application are used to distinguish similar objects, rather than to describe a specific order or sequence.

[0017] To enable those skilled in the art of this technology to better understand the solution of this application, the following further detailed description of this application will be given in conjunction with the accompanying drawings and specific embodiments.

[0018] In combination with the specific application environment architecture or specific hardware architecture on which the execution of the firmware upgrade method depends, the specific application environment architecture or specific hardware architecture will be described herein.

[0019] The management controller (such as the Baseboard Management Controller (BMC)) is an important management component in a server, undertaking multiple key tasks such as monitoring of hardware status, system power management, various management services, user remote control, remote fault diagnosis and maintenance. As a control unit independent of the main system operation, the BMC usually runs an embedded operating system to provide more flexible remote management capabilities, such as remote power control, hardware health monitoring, logging and firmware update through the Intelligent Platform Management Interface (IPMI) protocol.

[0020] During the server startup process, the startup image of the BMC is generally stored in the Serial Peripheral Interface (SPI) NOR Flash on the BMC board to ensure the reliability and stability of the system. When the server is powered on, the BMC initializes the SPI controller through the BootROM and reads the startup program from the SPI Flash through this controller. Usually, the bootloader is U-Boot, which is responsible for initializing the hardware and loading the necessary driver programs. Subsequently, U-Boot boots the loading process of the Linux kernel, and the Linux kernel initializes various services of the BMC, such as network management, system logging, temperature monitoring, hardware diagnosis, etc., to ensure that the BMC can communicate and interact effectively with the server host system and the remote management platform.

[0021] In one or more operating systems in a server, various failure conditions can cause the BMC image to be damaged. Specifically, since the BMC firmware is stored in the SPI flash memory, and the flash memory has a service life and accidental damage factors, the basic principle of its failure is similar to that of a Solid State Drive (SSD). For example: if bad blocks appear due to long-term high-load operation or manufacturing defects, it may cause the loss of key data in the image file; sudden power outages during firmware updates or image writing (such as power failures in the computer room or poor contact caused by vibration) may result in incomplete image file writing or verification failures; in addition, incorrect erasure or overwriting caused by software problems may also lead to image damage; some environmental problems can also cause image damage. For example, too high a temperature in the computer room may cause abnormal operation of the flash memory (such as increased charge leakage in NAND flash memory at high temperatures), resulting in bit flipping of the image data and verification failures. Usually, this situation requires on-site manual operations, such as restoring or upgrading the image through the serial port method, which not only increases the maintenance difficulty but also prolongs the fault recovery time and affects the availability and stability of the system.

[0022] In the dual-system architecture (System A and System B) of the server, System A is responsible for complex application programs and services, and System B is responsible for tasks with high real-time requirements to ensure the real-time response of the system, forming a redundancy mechanism to ensure that the system will not crash. During the startup process of the management controller (such as BMC), usually, the image is started in System A. Fault conditions in the server (such as the service life or damage of the flash memory storing the firmware) will then damage the image file of the management controller, resulting in abnormal startup. Even if System B takes over the restart, due to the damaged image, it will cause the paralysis of the management controller. The firmware upgrade method provided in this application can solve the above technical problems.

[0023] Figure 1 The flowchart of a firmware upgrade method provided by an embodiment of this application is as Figure 1 shown. The method includes: S11: Receive a firmware upgrade instruction, obtain a first image file to be upgraded, split the first image file into at least one data packet, and transmit the at least one data packet to at least one network device buffer of the target link to wait for an incoming instruction; S12: Respond to the incoming instruction, intercept at least one data block of a preset size from the at least one waiting data packet, and store the at least one data block in the memory of the management controller; S13: Obtain target data blocks corresponding to the at least one data block, and perform verification processing on the at least one data block and the target data blocks to obtain a verification result; wherein, the target data blocks are split from a second image file, and the second image file is stored in the flash memory; S14: Determine whether the verification results are the same. If they are the same, proceed to step S15; if they are different, proceed to step S16; S15: Discard the data block; S16: Write the data block to the flash memory.

[0024] Specifically, the acquisition of the first image file can be directly issued by the user, or remotely issued by the user, or directly obtained by the user through IPMI commands, etc., which is not limited here. Regarding the acquisition method of the first image file, it can be directly from the file uploaded by the user, or it can be the file pre-stored in the buffer area after the user uploads the file, etc., which is not limited here.

[0025] Taking the remote issuance command as an example, with multiple interfaces and commands, the firmware upgrade operation can be remotely executed: 1) IPMI command. The user initiates a remote upgrade instruction through IPMI, and the operating system receives and responds. 2) Execute relevant commands after logging in through the Secure Shell (SSH). The operating system receives the instruction and starts the upgrade process. 3) Upload the image through the Hyper Text Transfer Protocol (HTTP) / Hyper Text Transfer Protocol Secure (HTTPS). The user accesses the web interface provided by the BMC Real-Time Operating System (RTOS) through a browser or management tool, selects and submits the image file. The operating system receives the data through the built-in HTTP / HTTPS server and starts the upgrade. 4) Transfer the image through the Trivial File Transfer Protocol (TFTP). The user uploads the image file to the BMC using a TFTP client, and the operating system receives the file and starts the upgrade operation, etc.

[0026] Regarding the method by which the above user communicates with the operating system, it is not limited here, nor is it restricted which interface the operating system implements to dock with the remote upgrade.

[0027] Regardless of which of the above methods is used to obtain it, a firmware upgrade instruction is received, and the first image file is stored in the memory of the user device. The memory of the user device is the memory resource allocated to the user device (such as a computer, mobile phone, etc.) and is used to store user data. In response to the firmware upgrade instruction, the first image file to be upgraded is obtained from the memory of the user device. For network transmission, the first image file needs to be split into at least one data packet for subsequent transmission. The at least one data packet is transmitted to at least one network device buffer of the target link, considering that there needs to be the same target link between the transmission object and the source object during the transmission process. In a target link, multiple network devices (such as switches, routers) will be passed through. These devices usually have their own buffers for temporarily storing data packets until they are forwarded to the next node. When forwarding to the next node, an incoming instruction needs to be waited for to transmit the at least one data packet to the memory of the management controller.

[0028] There is data that needs firmware upgrade in the memory of the management controller. This data is intercepted from the at least one waiting data packet. Similar to valve control, the amount of data required for upgrade is intercepted from the network device buffer. Instead of the conventional technical solution of transmitting the entire image file to the memory of the management controller and then performing the firmware upgrade operation. This application takes into account that the operating system for firmware upgrade is the RTOS system. If the standard firmware upgrade process of the Linux system is adopted, the image file is stored in the memory after uploading, and a large amount of memory resources are also required during the checksum writing process. However, the size of the memory resources accessible by RTOS is only 256KB, which is much smaller than the 64MB required to store the complete image, not to mention the memory occupation caused by other operations such as verification; 2) Verifying the complete 64MB image after transmission takes a relatively long time, increasing the user's waiting time and actually reducing the user experience; 3) The writing speed of SPI Flash is usually slower than the reading speed, and overall overwriting the image is likely to become the bottleneck of the entire firmware upgrade process, and the user may need to wait for dozens of minutes.

[0029] In the conventional technology, for the firmware upgrade of BMC in the Linux system, in the conventional firmware upgrade of the Linux system, the user uploads the local BMC firmware image file through a remote management tool or other interfaces. The size of this image file is usually 64MB, and the specific size may vary due to function expansion or customization requirements. The upload process is handled by a network protocol (such as HTTP, File Transfer Protocol (FTP), or a dedicated protocol), and after the data transmission is completed, it is stored in the memory of the BMC.

[0030] This application adopts the method of intercepting data blocks as needed. The data block granularity is smaller than the mirror file granularity. When this application responds to an incoming instruction, it will intercept at least one data block of a preset size and store it in the memory of the management controller to facilitate subsequent firmware upgrade operations.

[0031] It should be noted that for this application to intercept at least one data block of a preset size, the interception here is block by block, that is, the block-by-block interception method. For example, if this application needs to receive 1 4K data block and 1 8K data block, only one data block can be intercepted at the same time during this process. The data block of the preset size can be a conventional fixed-value data block or an unconventional non-fixed-value data block set that gradually increases or decreases.

[0032] Regarding the operating system, it can be an operating system of the server, such as the Linux system, or it can be a dual operating system of the server, such as the Linux system and the RTOS system, etc. It is not limited here and can be set according to the actual situation.

[0033] Regarding obtaining the target data block corresponding to at least one data block in step S13, it should be noted that in this embodiment, if it is one data block, the data block and the corresponding target data block are subjected to verification processing. If there are multiple data blocks, multiple data blocks and their respective corresponding target data blocks need to be subjected to verification processing. It should be noted that the mirror formats of the data block and the target data block are the same, that is, the corresponding data block sizes are the same. The target data block is obtained through the segmentation processing of the second mirror file, and the second mirror file is stored in the flash memory. It should be noted that in this embodiment, for the target data block corresponding to the at least one data block mentioned above, the size of the corresponding segmented data block is the same as the specification of the interception size of the at least one data block.

[0034] The flash memory stores the firmware image. Usually, it is a non-volatile firmware image memory, so that the data does not change when the power is turned off or on during each firmware upgrade.

[0035] Regarding the verification processing in step S13, different from the conventional firmware upgrade of BMC in the Linux system, the conventional firmware upgrade of the Linux system includes the following steps: The Linux system on the BMC will read the complete mirror file from the memory and prepare for subsequent processing. At this stage, the mirror is temporarily stored in the memory, and the memory requirement is usually large, which puts certain requirements on the hardware resources of the BMC; Before overwriting the firmware storage device (usually SPI Flash), the Linux system performs an integrity check on the uploaded image. Common check methods include checksums (Checksum), hash checks (such as MD5, SHA256), etc. The purpose of the check is to ensure that the uploaded image data has not been tampered with or damaged during transmission. Once the check fails, the system will refuse to continue the upgrade and prompt the user to re-upload the image; After the check is completed, the Linux system writes the complete image file to the firmware storage device through the SPI driver. This process requires overwriting the existing firmware content. Since the Flash write speed is relatively slow, the entire operation may take several minutes, depending on the performance of the storage device and the size of the image; When the image writing is completed, the system updates the operation status and prompts the user that the firmware update has been successful. The user can then choose to reboot the system to load the new firmware version.

[0036] The purpose of the check processing in this embodiment is to find the data of at least one data block that is different from the target data block for subsequent writing to the image flash. This embodiment takes into account that the speed of data transmitted over the network is often greater than the writing speed to the image flash. Therefore, if all at least one data packet is written to the image flash, it cannot keep up with the speed of data transmitted over the network and also occupies more memory space. Frequent writing to the image flash will increase the write loss. Here, in this embodiment, the data of at least one data block that is different from the target data block is found and written to the flash. Compared with the data volume of the first image file, the amount of write data to the flash is reduced, which speeds up the writing speed and reduces the write loss to a certain extent. At the same time, it also speeds up the firmware upgrade speed.

[0037] The verification process here needs to consider the data in at least one data block and the target data block. There are two cases: one is data alignment, and the other is data misalignment. In either case, it is necessary to perform a comparison and verification on at least one data block and the corresponding target data block. The verification process of this embodiment is different from the conventional integrity verification process for a mirror file. The integrity verification process takes a relatively long time and can be a comparison block by block. Considering the problems of a large amount of data and accurate comparison, if the verification values of the entire first mirror file and the entire second mirror file are determined and compared, there are a large number of data corresponding to a mirror file, resulting in a large amount of computing resources occupied by the entire data comparison. In addition, there will be a situation where although some data are different, the subsequent data are normal, resulting in a normal verification value, thereby missing the data where at least one data block intercepted from the first mirror file is different from the corresponding target data block segmented from the second mirror file, making the comparison inaccurate. Therefore, in the embodiment of the present application, the entire mirror file is processed in the form of data blocks, and the data in each data block is compared. Here, the comparison can be a data comparison or a comparison of the verification values in each data block, which is not limited here.

[0038] The verification process of this embodiment is based on a cyclic comparison method of the data blocks corresponding to the flash memory and the mirror file issued by the user. Here, the cyclic comparison can set the cache area as a circular cache area. After verifying a data block and obtaining a verification result, the position of this data block is left blank to provide space for the next data block read from the flash memory. When the verification results are the same, the data block is discarded. When the verification results are different, the data block needs to be written to the flash memory.

[0039] With this application, during the conventional firmware upgrade process, uploading the entire firmware image file to the memory of the management controller and performing verification processing on the entire firmware image file during verification processing result in a relatively large memory occupation of the management controller. Considering the resource-constrained characteristic that the accessible memory resources in the RTOS system are relatively few, usually the memory occupied by storing the entire firmware image file is greater than the accessible memory of the RTOS system. Therefore, first, before uploading to the memory of the management controller, receive a firmware upgrade instruction, obtain a first image file to be upgraded, split the first image file into at least one data packet, and transmit it to at least one network device buffer of the target link to wait for an incoming instruction. That is to say, during this transmission process, as long as there is no response to the incoming instruction, it will not enter the memory of the management controller and will wait in at least one network device buffer. When responding to the incoming instruction, intercept at least one data block of a preset size from at least one of the waiting data packets, realizing the fluidity of the first image file that can be accessed at any time in the form of data blocks, rather than receiving the entire image file at once, and also realizing the interception control of the first image file at the flow control level in response to the incoming instruction. Intercept at least one data block and store it in the memory of the management controller, reducing the file storage granularity to the data block granularity. Compared with the conventional method of storing the entire firmware image file in the memory of the management controller, intercepting at least one data block according to the preset size reduces the memory occupation space of the management controller under the RTOS system. Secondly, obtain target data blocks corresponding to at least one data block, and perform verification processing on at least one data block and the target data blocks to obtain a verification result. Compared with the situation where a large amount of memory of the management controller is occupied when verifying the entire firmware image file conventionally, this application performs verification processing in the form of data blocks, without verifying the entire firmware image file, reducing the granularity of the verification object to save the memory resources of the management controller. Finally, compared with the conventional integrity verification of the entire firmware image file corresponding to itself, this application needs to perform verification and comparison with the target data blocks obtained by splitting the second image file stored in the flash. When the verification result is the same, the data blocks are discarded. When the verification result is different, the data blocks are written into the flash, avoiding repeated writing in the flash, reducing the memory occupation space of the management controller, and also reducing the storage space occupation of the flash, improving the utilization rate of the memory space of the management controller. Avoid writing all firmware files into the flash, reducing the amount of written data, improving the writing speed to a certain extent, and reducing the write wear of the flash.

[0040] Therefore, the technical problem that the firmware image file occupies a large amount of memory space in the management controller can be solved, and the image file to be upgraded is split when the management controller receives it, and at least one data block of a preset size is intercepted from at least one waiting data packet, and stored in the form of data blocks, thereby reducing the storage granularity. In the verification process, the verification process is performed in the form of data blocks, and at least one data block that is the same as the target data block is discarded. What is actually written to the flash memory is a data block that is different from the target data block. This saves the memory resources of the management controller, reduces the memory space occupied by the management controller, and also avoids the technical effect of repeated writing to the flash memory.

[0041] In some embodiments, performing verification processing on at least one data block and a target data block to obtain a verification result includes: forming at least one data block stored in the memory of the management controller into a data packet to be detected; The target data block corresponding to the at least one acquired data block forms a target data packet; the data block to be checked at the same data block position corresponding to the data packet to be checked and the target data packet is acquired; The data blocks to be checked of the data packet to be detected and the target data packet are checked one by one in a preset order to obtain a check result.

[0042] Specifically, when storing in the memory of the management controller, it will be processed in a circular buffer manner. Here, during the first comparison process, the data block positions in the storage structure corresponding to the circular buffer method need to be filled with data blocks, thus forming a circular buffer area corresponding to a data packet. In the present application, two circular buffer areas are required, one circular buffer area stores a data packet to be detected formed by at least one data block intercepted from at least one data packet transmitted from the network device buffer, and the other circular buffer area stores a target data packet formed by a target data block divided from the second mirror file in the flash memory.

[0043] It should be noted that the data packet to be detected and the target data packet in this embodiment are distinguished from at least one data packet stored in the buffer of the network device, and have different sources.

[0044] The positions corresponding to the data blocks in the two ring buffer areas are the same, and the data blocks to be checked in the same data block positions corresponding to the data packets to be detected and the target data packets are compared after one data block position is compared, and the next data block position is compared. In short, the two data packets compare the same data block position. The preset order here can be clockwise or counterclockwise, that is, starting from the first data block position or the last data block position, and in short, the data blocks to be checked in the same data block position are checked one by one in a certain cyclic order.

[0045] In this embodiment, the data blocks to be verified at the same data block positions of the data packet to be detected and the target data packet are verified one by one in a preset order to obtain a verification result, so as to ensure the orderliness and cyclicity of verification and avoid repeated writing to the flash memory.

[0046] In some embodiments, before verifying at least one data block and the target data block to obtain a verification result, it further includes: Pre-establish a first buffer area and a second buffer area; wherein, the first buffer area and the second buffer area adopt a circular structure; Store the data blocks to be verified of the data packet to be detected in the first buffer area; Store the data blocks to be verified of the target data packet in the second buffer area.

[0047] Specifically, considering other operating systems, such as the RTOS system, after the mirror file is uploaded, it is stored in the memory. The checksum writing process also requires a large amount of memory resources. However, the size of the memory resources accessible by RTOS is only 256KB, which is much smaller than the 64MB required to store the complete mirror, not to mention the memory occupation brought by other operations such as verification; verifying the complete 64MB mirror after transmission takes a long time, increasing the user's waiting time and actually reducing the user experience; the writing speed of the SPI Flash is usually slower than the reading speed, and the overall overwriting of the mirror is likely to become the bottleneck of the entire firmware upgrade process, and the user may need to wait for dozens of minutes.

[0048] Therefore, before actual writing, a first buffer area and a second buffer area are pre-established first. The two buffer areas adopt a circular structure. Here, the circular structure is considered because the memory resources for the RTOS to process the complete mirror file are relatively tight. The circular structure is composed of the positions of multiple data blocks, and each position corresponds to a data block. Through the caching method of data blocks, caching of the entire mirror file is avoided. At the same time, the circularity corresponds to flow. After the data blocks at the corresponding data block positions in the first buffer area and the second buffer area are compared, the data block position is vacated for the data block of the next mirror file to be added, forming a cyclic usage method.

[0049] In this embodiment, considering that the acquisition channels of the two mirror files are different, the second mirror file is read from the flash memory, and the first mirror file is transmitted from an external device. Therefore, it is necessary to divide them into two different buffer areas. The first buffer area is used for writing and storing at least one data block intercepted from the first mirror file, and the second buffer area is used for reading and storing the target data block obtained by splitting the second mirror file.

[0050] The present embodiment provides for pre - establishing a first buffer area and a second buffer area, which respectively store at least one data block intercepted from a first mirror file and a target data block obtained by splitting and processing a second mirror file, saving the memory resources and computing resources of the operating system, and facilitating the management of the verification processing procedures for the two types of data blocks.

[0051] In some embodiments, when the data blocks to be verified of the data packet to be detected and the data packet to be verified of the target data packet are aligned, the first buffer area and the second buffer area form a double - ring buffer area.

[0052] Specifically, in the case of comparison under a conventional mirror format, the mirror file will not be offset or misaligned, that is, the data of at least one data block and the target data block are aligned, that is, the data blocks to be verified of the data packet to be detected and the data packet to be verified of the target data packet are aligned, thus avoiding the occurrence of consistency problems caused by data offset. Here, the first buffer area and the second buffer area appear in a group form to form a double - ring buffer area.

[0053] The present embodiment provides that when the data blocks to be verified of the data packet to be detected and the data packet to be verified of the target data packet are aligned, adopting a double - ring buffer area can effectively avoid the situation where a small - scale modification of the firmware mirror causes the entire larger - scale flash memory upgrade to be completely overwritten.

[0054] In some embodiments, verifying the data blocks to be verified of the data packet to be detected and the target data packet respectively one by one in a preset order to obtain a verification result, including: Obtaining the position of the first data block in the double - ring buffer area; Verifying the data blocks to be verified of the data packet to be detected and the target data packet respectively stored in the first buffer area and the second buffer area one by one starting from the data at the position of the first data block to obtain a verification result.

[0055] Specifically, the preset order of the present embodiment starts from the position of the first data block, and verifies the data blocks to be verified at the same data block positions of the data packet to be detected and the target data packet one by one to obtain a verification result. In fact, it is an operation that cycles from the position of the first data block to the position of the last data block. In the present embodiment, it is not aimed at the first data block, but considering the cyclic verification of data blocks in the double - shaped buffer area, which has fluidity and follows the order of data block positions.

[0056] The present embodiment provides a method of starting from the position of the first data block and verifying the data blocks to be verified at the same data block positions of the data packet to be detected and the target data packet one by one, making the comparison of the data blocks for verification have orderliness and fluidity.

[0057] In some other embodiments, when there is a displacement in the data boundaries of the data packet to be detected and the target data packet, the first buffer region and the second buffer region form a plurality of double-ring buffer regions.

[0058] Since the first image file for user upgrade is an iterative version of the original image on the image flash, in this case, the modified part of the first image file may cause the boundary of the data block to shift, resulting in the failure of the original block checksum. For example, for a 100M data, if a few bytes are modified or added. At this time, if the checksum is performed with a size of 100M, it will fail. However, if the checksum is performed with a size of 1M, the content before the modified part will pass the checksum, while the content after the modified part will all fail the checksum due to the offset caused by the modification.

[0059] According to the statistics and observations of the mirror iteration process, the hierarchical structure in the BMC mirror is more detailed, the modularity is clear, and the changes are usually local and concentrated, while most of the mirror content remains unchanged. In addition, since the mirror may contain some compilation-related information after compilation, such as the compilation time, etc., this header content often changes dynamically. Therefore, this part of the data needs to be excluded during the checksum to avoid affecting the result of the consistency comparison.

[0060] Based on the above considerations, usually, a dynamic window or a rolling hash algorithm is used to find the consistency. However, the computational complexity behind it is relatively high, and it is also unrealistic for some operating system resource issues. Therefore, in order to quickly locate the continuously consistent data blocks before and after the first image file, thereby skipping the parts that do not need to be transmitted, reducing the data transmission volume to improve the upgrade speed. In this embodiment, a plurality of ring buffer regions are constructed for the first buffer region and the second buffer region. That is to say, the first buffer region and the second buffer region of a double-ring buffer region compare the header data blocks of the data packet to be detected and the target data packet, and the first buffer region and the second buffer region of another double-ring buffer region compare the tail data blocks of the data packet to be detected and the target data packet. Other first buffer regions and second buffer regions of double-ring buffer regions can also be added to compare the data blocks at the middle positions of the data packet to be detected and the target data packet, etc., which are not limited here, but at least two double-ring buffer regions are guaranteed to perform recursive search at the head and tail, accelerating the comparison and improving the checksum accuracy at the same time.

[0061] The setting of the plurality of double-ring buffer regions provided in this embodiment facilitates subsequent rapid positioning of different regions of the data block, improves the efficiency of the checksum process, reduces the data transmission volume, and also improves the firmware upgrade speed.

[0062] In some embodiments, the number of double-ring buffer regions is two, and the data blocks to be verified of the data packet to be detected and the target data packet are verified one by one in a preset order, including: Obtain the position of the first data block and the position of the last data block of the double-ring buffer region; For the data blocks to be verified of the data packet to be detected and the target data packet respectively stored in the first buffer region and the second buffer region of the first double-ring buffer region, verification processing is performed one by one starting from the data at the position of the first data block; For the data blocks to be verified of the data packet to be detected and the target data packet respectively stored in the first buffer region and the second buffer region of the second double-ring buffer region, verification processing is performed one by one starting from the data at the position of the last data block.

[0063] Specifically, considering that during the firmware upgrade process of the image file, the changes to the image file are usually local and concentrated, and considering the resource limitation problems of some operating systems, in this embodiment, combined with the structure of the above double-ring buffer region, the head-tail recursive method is adopted. Considering the characteristics of quick positioning, two double-ring buffer regions are used. One double-ring buffer region is used to verify the header data blocks of the two image files, and the other double-ring buffer region is used to verify the tail data blocks of the two image files, so as to perform verification processing with a head-on and tail synchronization. For the data blocks to be verified of the data packet to be detected and the target data packet respectively stored in the first buffer region and the second buffer region of the first double-ring buffer region, verification processing is performed one by one starting from the data at the position of the first data block; for the data blocks to be verified of the data packet to be detected and the target data packet respectively stored in the first buffer region and the second buffer region of the second double-ring buffer region, verification processing is performed one by one starting from the data at the position of the last data block. The two groups of double-ring buffer regions are used for a two-sided attack.

[0064] It should be noted that in this embodiment, considering the problem of operating system limitation, the setting of the buffer region is designed to occupy as little memory resource as possible. Therefore, the number of groups of the double-ring buffer region can be set according to the actual usage situation and is not limited here.

[0065] The head-tail synchronization verification processing provided in this embodiment can quickly locate the target image data, save the memory resources of the operating system, and improve the efficiency of the verification processing, thereby improving the firmware upgrade speed.

[0066] In some embodiments, intercepting at least one data block of a preset size from at least one waiting data packet includes: Pre-obtain the preset data block size of the first buffer region and the second buffer region; Use the preset data block size as the preset size for intercepting the data block for interception; Obtaining a target data block corresponding to at least one data block includes: Performing a splitting process on the second mirror file according to a preset data block size to obtain corresponding target data blocks.

[0067] Specifically, the preset data block size is a regulation for setting the data block position size when based on the circular buffer structure of the first buffer area and the second buffer area. The preset data block size can be used as the preset size for intercepting data blocks to intercept at least one data block. At the same time, perform a splitting process on the second mirror file according to the preset data block size to obtain corresponding target data blocks.

[0068] It should be noted that the specific values of the preset data block size here can be the same or different, which are not limited herein. Store the data blocks after interception and splitting process into the data block positions of the corresponding circular structure. It is worth noting that for the case where the data of the two mirror files is offset, the subsequent storage is also performed in the same operation, which will not be elaborated herein. Finally, the actual verification process is to compare the data block positions under the circular structure. The comparison here is to perform a verification process on the data blocks at the same data block position. The verification here can be the data of the data block or the verification value of the data block, etc., which are not limited herein.

[0069] In this embodiment, intercepting at least one data block according to the preset data block size and performing a splitting process on the second mirror file to store the values in the data block positions of the corresponding circular buffer area, so as to perform a verification process on the data blocks at the same data block position, facilitating the consistent operation of data verification and improving the verification processing efficiency.

[0070] In some embodiments, the preset data block size is a fixed data block size; intercept at least one data block with a fixed data block size from at least one waiting data packet; Correspondingly, split the second mirror file according to the fixed data block size to obtain corresponding target data blocks.

[0071] Specifically, if the preset data block size is a fixed data block size, the specifications of the intercepted and split data blocks are the same, and subsequent comparisons are made according to the data blocks of this specification to ensure the consistency comparison of the data verification process.

[0072] In some embodiments, performing a verification process on the data blocks to be verified of the data packet to be detected and the target data packet respectively according to a preset order to obtain a verification result includes: Obtaining the current data block position; Comparing the data blocks to be verified at the current data block positions corresponding to the first buffer area and the second buffer area; If they are the same, it is determined that the data blocks to be verified at the current data block position are the same. The data blocks to be verified at the next data block position corresponding to the current data block position in the first buffer area and the second buffer area are used as the new current data block position, and the process returns to the step of comparing the data blocks to be verified at the current data block position corresponding to the first buffer area and the second buffer area; If they are different, it is determined that the data blocks to be verified at the current data block position are different, and the process returns to the step of comparing the data blocks to be verified at the current data block position corresponding to the first buffer area and the second buffer area until all the data blocks to be verified in the first buffer area and the second buffer area are completely compared.

[0073] Figure 2 This is a schematic structural diagram of a double-ring buffer area provided by an embodiment of the present application. As Figure 2 shown, obtain the current data block position, and compare the data blocks to be verified at the current data block position corresponding to the first buffer area and the second buffer area. If they are the same, continue to compare the next one. If they are the same at this time, directly delete them, indicating that the data of the data block to be verified at the current data block position has been stored in the flash memory. If they are different, retain the data of the data block to be verified at the current data block position in the first buffer area, indicating that the data of the data block to be verified at the current data block position has not been stored in the flash memory. Continue with subsequent data comparison and reading. Figure 2 The rings in can rotate in the same rotation direction. The verified data blocks can be written with new data until all the first mirror files to be upgraded given by the user are completely compared.

[0074] In this embodiment, comparing multiple data blocks of the same specification in different buffer areas effectively avoids the entire overwriting of the firmware upgrade due to small-scale modifications of the data packets to be detected. For the different data blocks, they are written into the flash memory subsequently, improving the subsequent firmware upgrade speed and reducing the write loss of the flash memory.

[0075] In some other embodiments, the preset data block size is a non-fixed data block size; multiple preset data block sizes increase step by step, and there is an integer multiple relationship between the multiple preset data block sizes; at least one data block is intercepted from at least one waiting data packet in the order of multiple non-fixed data block sizes that increase step by step; Correspondingly, the second mirror file is segmented in the order of multiple non-fixed data block sizes that increase step by step to obtain corresponding target data blocks.

[0076] Specifically, considering that there may be data comparison differences within a certain range during the data comparison process, while the rest of the large-scale comparisons are the same. Therefore, the specifications of the data blocks corresponding to the circular structure of the buffer area can be different for quick positioning and searching. So, in the embodiments of the present application, the length of the preset data block size is set to a non-fixed value and increases step by step. For example, starting from a 4K data block, data blocks of different sizes such as 4K, 8K, 16K, 32K, 64K, etc. are used in sequence. At the same time, considering that during the comparison of data blocks of different specifications, if there are differences in the data corresponding to the position of the 64K specification data block, in order to reduce the amount of data written subsequently, precise positioning is performed here, and the 64K specification data is locally verified again and split step by step from 32K, 16K to the subsequent 4K to find the differences in the data corresponding to the smallest specification. Therefore, in the embodiments of the present application, there is an integer multiple relationship between multiple preset data block sizes to facilitate subsequent splitting and simplifying calculations.

[0077] In this embodiment, at least one data block is intercepted in the order of multiple preset data block sizes that increase step by step, and the second mirror file is divided into multiple data blocks, which saves the verification time and improves the firmware upgrade speed.

[0078] In some embodiments, the verification process is performed on the data blocks to be verified of the data packet to be detected and the target data packet respectively in a preset order to obtain verification results, including: Obtain the current data block position; Compare the data blocks to be verified at the current data block positions corresponding to the first buffer area and the second buffer area; If they are the same, it is determined that the data blocks to be verified at the current data block position are the same, and the data blocks to be verified at the next data block position corresponding to the first buffer area and the second buffer area are used as the new current data block position, and return to the step of comparing the data blocks to be verified at the current data block positions corresponding to the first buffer area and the second buffer area; If they are different, it is determined that the data blocks to be verified at the current data block position are different, and the data blocks to be verified at the current data block position are used as the initial verification data blocks and the first data block size is obtained; wherein, the length of the first data block size is a non-fixed value, multiple first data block sizes decrease step by step, and there is an integer multiple relationship between multiple first data block sizes; Split from the initial verification data blocks in the order of multiple non-fixed data block sizes that decrease step by step to determine multiple current first data blocks; Obtain the current first data block position according to the data block position order of multiple current first data blocks; wherein, the current first data block position starts to compare from the first position of the data block positions of multiple first data blocks; Compare the data at the current first data block positions corresponding to the first buffer area and the second buffer area; If they are the same, determine that the initial check data blocks at the current first data block positions are the same, take the next first data block position corresponding to the current first data block positions in the first buffer area and the second buffer area as the new current first data block position, and return to the step of comparing the data at the current first data block positions corresponding to the first buffer area and the second buffer area; If they are different, determine that the initial check data blocks at the current first data block positions are the same, take the next first data block position corresponding to the current first data block positions in the first buffer area and the second buffer area as the new current first data block position, and return to the step of comparing the data at the current first data block positions corresponding to the first buffer area and the second buffer area until all the data in the first buffer area and the second buffer area are compared.

[0079] In this embodiment, the process of determining the difference and sameness of the data blocks to be checked at the current data block positions is the same as the loop comparison process in the above embodiment, which will not be elaborated here. In this embodiment, after the difference of the data blocks to be checked at the current data block positions, directly obtain the first data block size. Both the first data block size and the preset data block size here are non-fixed values and decrease step by step. The step-by-step decrease here has the same span as the step-by-step increase of the preset data block size in the above embodiment, which will not be elaborated here.

[0080] Divide the initial check data block in the order of multiple non-fixed data block sizes that decrease step by step to determine multiple current first data blocks. It should be noted that local checks on the data blocks to be checked need to be performed at any time until all comparisons are completed. During the local check process, since it is split into multiple first data blocks, there may be cases where the data at the current first data block positions are the same first. Since the data blocks to be checked show different situations, it is still necessary to continue to find the next current first data block position and continue the comparison until all the data are compared.

[0081] It should be noted that in this embodiment, in the order of the first data block size decreasing step by step, here it can be, for example, first according to a first data block size, such as dividing the original 64K into 32K data. At this time, it is split into two data blocks, and these two data blocks are used as the current first data blocks for the subsequent data block comparison, and all the data blocks in the current iteration are compared. At the same time, continue to compare the 32K data. At this time, it is used as the current first data block in another iteration, and the comparison of this iteration is completed until the data block with the smallest unit specification is found for positioning. For example, Figure 3 is a schematic diagram of local check for dividing data blocks based on the first data block size provided by an embodiment of the present application, asFigure 3 As shown, when comparing 32K data blocks, if it is found that their Hash values are inconsistent, the system will restart local verification from 4K in the latter 16K part of the 32K data block until a consistent verification value is found. The final boundary is an integer multiple of 4K, for example, it may be 36K.

[0082] The local verification process based on data block segmentation of the first data block size provided in this embodiment can quickly locate and find the final verification result while saving verification time, improving the positioning efficiency.

[0083] In some embodiments, verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result, including: Marking the positions of the data blocks with different verification results in the first double-ring buffer area to obtain the first marked positions; Marking the positions of the data blocks with different verification results in the second double-ring buffer area to obtain the second marked positions; Writing the data blocks corresponding to the first marked positions to the second marked positions in the double-ring buffer area into the flash memory.

[0084] Figure 4 It is a schematic diagram of a head-tail recursive search verification provided by an embodiment of the present application. As Figure 4 shown, the system will attack from both the head and the tail of the data packet to be detected, Figure 4 determining the longest continuous consistent data blocks at the head and tail. The data blocks in this part do not need to be transmitted, and directly reduce it to the data in the local area for subsequent writing into the flash memory.

[0085] Specifically, in this embodiment, considering that there may be multiple different data blocks during the head-tail attack, there is no need to care about the different data blocks in the middle. Only care about the position of the first different data block among the positions of the data blocks with different verification results in the first double-ring buffer area, and mark it as the first marked position. The position of the first different data block among the positions of the data blocks with different verification results in the second double-ring buffer area is marked as the second marked position. Here, the data blocks corresponding to the first marked position to the second marked position are written into the flash memory.

[0086] In the head-tail recursive search process provided in this embodiment, a local concentrated area is determined corresponding to the case of different data blocks, improving the verification processing efficiency.

[0087] In some embodiments, verifying the data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result, including: Obtain the first target data of the data block to be verified in the data packet to be detected and the second target data of the data block to be verified in the target data packet; Determine the verification value according to the first target data; Determine the hash value according to the second target data; Judge whether the verification value and the hash value are the same; If they are different, determine that the verification results are different; If they are the same, determine that the verification results are the same.

[0088] Specifically, the verification processing process in this embodiment corresponds to the comparison of verification values inside the data block. The verification value can quickly check whether the data in the data block has errors during transmission or storage by calculating the verification value of the data block. The hash value is used to detect minor changes in the data.

[0089] The process of determining the verification value and the hash value in this embodiment can be the same as or different from the conventional processing method, which is not limited here and can be set according to the actual situation.

[0090] The comparison of the verification value and the hash value of the data in the data block provided in this embodiment adopts a dual-verification mechanism, which can effectively ensure the integrity and reliability of the data in the data block.

[0091] Figure 5 It is a schematic diagram of a firmware upgrade method based on the RTOS operating system provided by an embodiment of the present application. As Figure 5 shown, this embodiment takes into account the fault tolerance ability of the RTOS operating system, fully considers resource limitations, optimizes the efficiency and reliability of the upgrade process. The RTOS operating system runs normally and the network protocol stack works properly. The user establishes communication with the RTOS operating system through the network. Figure 5 Each module, the RTOS network stack and the SPI driver in are implemented by software design within the RTOS operating system. When the remote user uses a remote command to perform a BMC remote upgrade task on the RTOS operating system, the RTOS operating system is constructed and initialized in the memory.

[0092] The network protocol stack on the RTOS operating system provides the RTOS operating system with streamlined network capabilities, supports the Transmission Control Protocol (TCP) / User Datagram Protocol (UDP), receives data blocks transmitted by the remote user, and is controlled by the streaming transmission management module. In the process of remotely upgrading the BMC firmware image proposed in this patent, the TCP protocol is adopted.

[0093] In Figure 5There are two ways to obtain the data packets to be detected corresponding to at least one data block. One way is to send them to the streaming management module through the RTOS network stack, process them, and then send them to the verification module for verification processing. The other way is to send them to the verification module through the writing module for verification processing.

[0094] Regarding the streaming management module, it transmits and processes data in the form of a continuous stream. Its streaming transmission allows data to be gradually processed during transmission. At the same time, for applications with high real-time requirements, it can transmit data with low latency to ensure smooth and natural interaction.

[0095] In some embodiments, before storing at least one data block in the memory of the management controller, it further includes: Establishing index marks for at least one data block; Determining a first check value according to the data of at least one data block; Saving the first check value and the index mark and storing them in the memory of the management controller together with at least one data block.

[0096] Specifically, receive at least one data block (such as 4K in size), establish an index mark (Identity, ID) for the data block, and at the same time calculate the first check value for the data block using a hashing algorithm. The streaming management module undertakes the verification work of receiving network data blocks to improve parallelism and avoid delays caused by centralized calculation. Subsequently, write the data block into the circular Buffer in the writing module, and synchronously send the index mark and the first check value to the verification module. The module controls the transmission speed at the TCP protocol flow control level according to the Buffer status feedback by the writing module.

[0097] Storing the index mark and the first check value in the memory of the management controller together with the data block provided in this embodiment, to a certain extent, considering the effective memory resources of the RTOS operating system, the content can be used without downloading the complete image file, reducing the storage requirements.

[0098] Combined Figure 5 Viewed together, the acquisition method in this embodiment is based on obtaining from the first buffer area. The specific process of establishing the index mark and the first check value is the same as that of the above embodiment and will not be elaborated here.

[0099] The acquisition method of at least one data packet provided in this embodiment saves the memory resources of the operating system while improving the accuracy and integrity of subsequent data block verification processing and also improving the data verification processing efficiency.

[0100] Such as Figure 5As shown, the write module and the read module are respectively responsible for operating the SPI driver to efficiently write and read the mirror data blocks to and from the Flash memory. To achieve the parallelism of data transmission and processing and optimize the utilization rate of system resources, a Double Ring Buffer architecture is designed. Each Buffer has a length of 64KB. In the write module, the received mirror data blocks are first stored in the write Buffer, which can cache up to 16 data blocks at most. According to the status and capacity of the buffer, the data blocks are written into the Flash one by one. The write operation adopts a block writing strategy to ensure the stable operation of the system under resource-constrained conditions. The read module extracts the mirror data blocks from the Flash into the circular read Buffer and provides support for subsequent verification. The read operation runs independently of the write operation, and the internal control module dynamically controls the input speed according to the output speed of the Buffer. The read operation runs independently of the write operation, and the internal control module dynamically controls the input speed according to the output speed of the Buffer.

[0101] The verification module extracts the data blocks stored in the Flash from the read buffer, calculates their hash values, and compares the results with the verification values of the remote data blocks received during the streaming transmission. Through this verification mechanism, the verification module can verify one by one whether the 16 data blocks in the buffer are consistent with the data transmitted remotely, so as to determine whether the received data needs to be written into the Flash storage.

[0102] Furthermore, the present application also provides a dual operating system, which includes a first operating system and a second operating system; wherein, the memory resources accessible by the first operating system are greater than those accessible by the second operating system; In the case where the startup of the management controller by the first operating system fails, the second operating system is started to execute the steps of the above firmware upgrade method to complete the firmware upgrade of the management controller.

[0103] Specifically, for dual operating systems such as the Linux operating system (the first operating system) and the RTOS system (the second operating system), in order to improve the server fan regulation speed, system startup efficiency, and fault handling ability after power-on, an RTOS dual-system architecture has currently been introduced in the BMC. This architecture runs the Linux operating system and the RTOS operating system on two cores of the BMC respectively. Among them, the RTOS and the Linux system start synchronously. Due to the high real-time and lightweight characteristics of the RTOS, it can usually be quickly started within a few seconds, control the server fan, and at the same time provide basic user management services. Specifically, after the system is powered on, the BMC first boots and loads the RTOS through U-Boot, and the RTOS immediately starts to execute key functions such as fan regulation and temperature monitoring. At the same time, the BMC also starts to provide basic remote management functions for users, such as system status monitoring and fault diagnosis. As Linux starts up, the RTOS gradually transfers control to the Linux system. At this time, the BMC enters the full Linux control mode, providing more rich service functions, such as log management, network configuration, firmware update, and more complex remote management operations, etc. At the same time, the RTOS enters the status monitoring mode, responsible for continuously monitoring the health status of Linux and taking over the system control right again when necessary. Through the dual-system architecture, the BMC can provide comprehensive and flexible management functions while ensuring fast response and efficient regulation, significantly improving the overall performance, reliability, and maintainability of the server.

[0104] However, due to the increasing complexity of the current BMC and the influence of various uncertain factors, the Linux system has a risk of crashing, which may cause problems such as downtime and freezing. At this time, the RTOS detects the situation of Linux downtime in a timely manner through real-time monitoring, takes over the system control right, and continues to provide network services and basic management functions, such as fan control, temperature monitoring, hardware status detection, and remote user management, etc. In this way, the RTOS or remote users can still remotely restart the BMC through the RTOS when the Linux system crashes, avoiding complete loss of control due to Linux crashes. It overcomes the challenge of limited RTOS memory resources during the firmware upgrade process, significantly improves the speed of remote image upgrade, solves the problem that the current BMC cannot start normally due to a damaged startup image, thereby improving the reliability and fault tolerance of the system and reducing the operation and maintenance costs.

[0105] The remote upgrade function can be implemented on the RTOS operating system of the management controller, making full use of the real-time performance and stability of RTOS. Even if both the Linux system and the firmware image are damaged, the RTOS operating system can still be relied on to complete the recovery and upgrade of the remote firmware, improving the fault tolerance of the management controller. It can achieve remote firmware upgrade in the case of BMC crash and damaged image, effectively shortening the system downtime and significantly improving the system maintainability and user experience. In addition, by designing a method to reduce the amount of data written, the service life of Flash is extended and the device maintenance cost is reduced.

[0106] Furthermore, the present application also provides a server, including the above-mentioned operating system.

[0107] For the description of the features in the corresponding embodiments of the server, reference can be made to the relevant descriptions in the corresponding embodiments of the firmware upgrade method, which will not be elaborated here one by one.

[0108] Figure 6 It is a flowchart of a head-tail recursive search method provided by an embodiment of the present application, as Figure 6 shown, including: S21: Establish communication between both parties; S22: In the current time, the second operating system calculates the hash value of the th data block in the firmware image of the mirror flash; S23: Send it to the remote end to synchronously compare the hash values; S24: Determine whether the hash values are the same; if so, return to step S22 to obtain the data block of the next time, if not, enter step S25; S25: Recursively search within the range from to ; S26: Determine whether the verification values are the same; if the same, return to step S25, if different, enter step S27; S27: Repeat from the tail; S28: Establish an index of data blocks in units of 4K and send the data blocks with different verification results to the flash.

[0109] An embodiment of the present application also provides a firmware upgrade device, Figure 7 It is a schematic structural diagram of a firmware upgrade device provided by an embodiment of the present application, as Figure 7 shown, and the device includes: A receiving module 11, configured to receive a firmware upgrade instruction, obtain a first mirror file to be upgraded, split the first mirror file into at least one data packet, and transmit the at least one data packet to at least one network device buffer of the target link to wait for an incoming instruction; A response module 12, configured to respond to an incoming instruction, intercept at least one data block of a preset size from at least one waiting data packet, and store the at least one data block in the memory of the management controller; A verification processing module 13, configured to obtain a target data block corresponding to the at least one data block, and perform verification processing on the at least one data block and the target data block to obtain a verification result; wherein, the target data block is obtained by splitting a second image file, and the second image file is stored in the flash memory; A discard module 14, configured to discard the data block when the verification result is the same; A writing module 15, configured to write the data block into the flash memory when the verification result is different.

[0110] For the description of the features in the corresponding embodiments of the firmware upgrade device, reference may be made to the relevant descriptions in the corresponding embodiments of the firmware upgrade method, which will not be elaborated here one by one.

[0111] An embodiment of the present application further provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned firmware upgrade method embodiments.

[0112] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above-mentioned firmware upgrade method embodiments when running.

[0113] In an exemplary embodiment, the above-mentioned computer-readable storage medium may include, but is not limited to: USB flash drive, read-only memory (ROM for short), random access memory (RAM for short), mobile hard disk, magnetic disk or optical disc, etc., various media that can store computer programs.

[0114] An embodiment of the present application further provides a computer program product. The above-mentioned computer program product includes a computer program, and the computer program implements the steps in any of the above-mentioned firmware upgrade method embodiments when executed by a processor.

[0115] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and the computer program implements the steps in any of the above-mentioned firmware upgrade method embodiments when executed by a processor.

[0116] Those skilled in the art may further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods for each specific application to implement the described functions, but such implementation should not be considered as exceeding the scope of this application.

[0117] The above has introduced in detail a firmware upgrade method, system, server, device, medium, and product provided by this application. Specific examples are used herein to elaborate on the principle and implementation manner of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A firmware upgrade method, characterized in that: include: receiving a firmware upgrade instruction, obtaining a first image file to be upgraded, splitting the first image file into at least one data packet, and transmitting the at least one data packet to at least one network device buffer of a target link to wait for an incoming instruction; In response to the incoming instruction, intercept at least one data block of a preset size from at least one waiting data packet, and store the at least one data block in a memory of the management controller; Obtaining a target data block corresponding to at least one data block, and performing verification processing on at least one data block and the target data block to obtain a verification result; wherein the target data block is obtained by segmenting a second image file, and the second image file is stored in a flash memory; When the verification results are the same, the data block is discarded; When the verification result is different, the data block is written to the flash memory.

2. The firmware upgrade method according to claim 1, characterized in that: Performing verification processing on at least one data block and a target data block to obtain a verification result includes: forming at least one data block stored in the memory of the management controller into a data packet to be detected; Forming a target data packet with a target data block corresponding to the at least one acquired data block; Acquire the to-be-checked data blocks at the same data block positions corresponding to the to-be-checked data packet and the target data packet; The data blocks to be checked of the data packet to be detected and the target data packet are checked one by one in a preset order to obtain a check result.

3. The firmware upgrade method according to claim 2, characterized in that: Before verifying at least one data block and a target data block to obtain a verification result, the method further includes: Pre-establishing a first buffer area and a second buffer area; wherein the first buffer area and the second buffer area adopt a ring structure; storing the to-be-checked data blocks of the to-be-detected data packet in the first buffer area; The to-be-checked data block of the target data packet is stored in the second buffer area.

4. The firmware upgrade method according to claim 3, characterized in that: When the data block to be checked of the data packet to be detected is aligned with the data block to be checked of the target data packet, the first buffer area and the second buffer area form a double-ring buffer area.

5. The firmware upgrade method according to claim 4, characterized in that: The verification process is performed on the respective data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result, including: Get the first data block position of the double ring buffer area; The data blocks to be checked of the data packets to be detected and the target data packets correspondingly stored in the first buffer area and the second buffer area are checked one by one starting from the data at the first data block position to obtain the check result.

6. The firmware upgrade method according to claim 3, characterized in that: When the data boundary between the to-be-detected data packet and the target data packet is displaced, the first buffer area and the second buffer area form a plurality of double-ring buffer areas.

7. The firmware upgrade method according to claim 6, characterized in that: The number of the dual ring buffer areas is two, and the to-be-checked data blocks of the to-be-detected data packet and the target data packet are checked one by one in a preset order, including: Get the first data block position and the last data block position of the double ring buffer area; The data blocks to be checked of the data packet to be detected and the target data packet stored in the first buffer area and the second buffer area of ​​the first double-ring buffer area are checked one by one starting from the data at the first data block position; The data blocks to be checked of the data packet to be detected and the target data packet stored in the first buffer area and the second buffer area of ​​the second double-ring buffer area are checked one by one starting from the data at the last data block position.

8. The firmware upgrade method according to claim 5, characterized in that: The method includes intercepting at least one data block of a preset size from at least one waiting data packet, comprising: Pre-acquire preset data block sizes of the first buffer area and the second buffer area; Using the preset data block size as the preset size of the intercepted data block for interception; Obtaining a target data block corresponding to at least one data block includes: The second image file is segmented according to the preset data block size to obtain corresponding target data blocks.

9. The firmware upgrade method according to claim 8, characterized in that: The preset data block size is a fixed data block size; intercepting at least one data block of the fixed data block size from at least one waiting data packet; Correspondingly, the second image file is segmented according to the fixed data block size to obtain corresponding target data blocks.

10. The firmware upgrade method according to claim 9, characterized in that: The verification process is performed on the respective data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result, including: Get the current data block position; Compare the data blocks to be checked at the current data block positions corresponding to the first buffer area and the second buffer area; If they are the same, it is determined that the data blocks to be checked at the current data block position are the same, and the data blocks to be checked at the next data block position of the current data block position corresponding to the first buffer area and the second buffer area are used as the new current data block position, and the process returns to the step of comparing the data blocks to be checked at the current data block position corresponding to the first buffer area and the second buffer area; If they are different, it is determined that the data blocks to be checked at the current data block position are different, and the process returns to the step of comparing the data blocks to be checked at the current data block position corresponding to the first buffer area and the second buffer area until all the data blocks to be checked in the first buffer area and the second buffer area are compared.

11. The firmware upgrade method according to claim 8, characterized in that: The preset data block size is a non-fixed data block size; the multiple preset data block sizes increase step by step, and there is an integer multiple relationship between the multiple preset data block sizes; at least one data block is intercepted from at least one waiting data packet in the order of the multiple non-fixed data block sizes that increase step by step to obtain; Correspondingly, the second image file is segmented in the order of a plurality of non-fixed data block sizes that increase in a step-by-step manner to obtain corresponding target data blocks.

12. The firmware upgrade method according to claim 11, characterized in that: The verification process is performed on the respective data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result, including: Get the current data block position; Compare the data blocks to be checked at the current data block positions corresponding to the first buffer area and the second buffer area; If they are the same, it is determined that the data blocks to be checked at the current data block position are the same, and the data blocks to be checked at the next data block position of the current data block position corresponding to the first buffer area and the second buffer area are used as the new current data block position, and the process returns to the step of comparing the data blocks to be checked at the current data block position corresponding to the first buffer area and the second buffer area; If they are different, it is determined that the data block to be checked at the current data block position is different, and the data block to be checked at the current data block position is used as the initial check data block and a first data block size is obtained; wherein the length of the first data block size is a non-fixed value, multiple first data block sizes decrease step by step, and there is an integer multiple relationship between the multiple first data block sizes; Splitting the initial check data block in the order of a plurality of non-fixed data block sizes that decrease in a stepwise manner to determine a plurality of current first data blocks; Acquire the current first data block position according to the data block position sequence of the multiple current first data blocks; wherein the current first data block position is compared starting from the first position of the data block positions of the multiple first data blocks; Comparing the data of the current first data block position corresponding to the first buffer area and the second buffer area; If they are the same, it is determined that the initial check data blocks of the current first data block position are the same, and the first data block position next to the current first data block position corresponding to the first buffer area and the second buffer area is used as the new current first data block position, and the process returns to the step of comparing the data of the current first data block position corresponding to the first buffer area and the second buffer area; If they are different, it is determined that the initial check data blocks at the current first data block position are the same, and the next first data block position of the current first data block position corresponding to the first buffer area and the second buffer area is used as the new current first data block position, and the process returns to the step of comparing the data at the current first data block position corresponding to the first buffer area and the second buffer area until all the data in the first buffer area and the second buffer area are compared.

13. The firmware upgrade method according to claim 7, characterized in that: The verification process is performed on the respective data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result, including: Marking the data block positions with different verification results in the first double-ring buffer area to obtain a first marking position; Marking the data block positions with different verification results in the second dual-ring buffer area to obtain a second marking position; In the dual ring buffer area, data blocks corresponding to the first mark position to the second mark position are written into the flash memory.

14. The firmware upgrade method according to claim 2, characterized in that: The verification process is performed on the respective data blocks to be verified of the data packet to be detected and the target data packet one by one in a preset order to obtain a verification result, including: Acquire first target data of the data block to be checked of the data packet to be detected and second target data of the data block to be checked of the target data packet; Determine a check value according to the first target data; determining a hash value according to the second target data; Determining whether the check value and the hash value are the same; If they are different, it is determined that the verification results are different; If they are the same, it is determined that the verification results are the same.

15. The firmware upgrade method according to claim 1, characterized in that: Before storing the at least one data block in the memory of the management controller, the method further includes: Establishing an index mark corresponding to at least one data block; determining a first check value based on data of at least one data block; The first check value and the index mark are saved and stored in the memory of the management controller together with at least one data block.

16. A dual operating system, characterized in that: The dual operating system includes a first operating system and a second operating system; wherein the access memory resources of the first operating system are greater than the access memory resources of the second operating system; In the case where the first operating system fails to start the management controller, the second operating system is started to execute the steps of the firmware upgrade method according to any one of claims 1 to 15 to complete the firmware upgrade of the management controller.

17. A server, characterized in that: Includes the dual operating system as described in claim 16 above.

18. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the firmware upgrade method according to any one of claims 1 to 15 when executing the computer program.

19. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the firmware upgrade method according to any one of claims 1 to 15.

20. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the firmware upgrade method according to any one of claims 1 to 15 are implemented.

Images