Method for in-band flashing of firmware, and electronic device, storage medium and program product

Abstract

The present application relates to the technical field of computer firmware update. Disclosed are a method for in-band flashing of firmware, and an electronic device, a storage medium and a program product. The method comprises: acquiring a firmware layout type of firmware to be flashed and a reference layout table of the firmware to be flashed; and in a cache of a current firmware, performing, on the basis of the reference layout table, in-band flashing on the firmware to be flashed, wherein the current firmware and the firmware to be flashed are heterogeneous firmware. By means of adding a reference layout table for distinguishing heterogeneous firmware, mutual in-band flashing of the heterogeneous firmware is realized, thereby solving the technical problem in the related art of an in-band flashing interrupt handler being only capable of flashing firmware having the same layout, and achieving the technical effects of supporting in-band flashing of the heterogeneous firmware and also supporting flashing of different firmware by means of simply modifying the structure of the reference layout table.

Description

Firmware in-band flashing methods, electronic devices, storage media and program products

[0001] Cross-reference to related applications

[0002] This application claims priority to Chinese Patent Application No. 202510368837X, filed on March 26, 2025, entitled "In-band firmware refresh method, electronic device, storage medium and program product", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of computer firmware update technology, and in particular to a firmware in-band refresh method, electronic device, storage medium and program product. Background Technology

[0004] In the current server firmware field, UEFI (Unified Extensible Firmware Interface) and BIOS (Basic Input Output System) systems are the mainstream technologies. However, due to their closed-source nature and relatively high development threshold, they have gradually become factors limiting their flexibility and response speed. As a result, Coreboot, as an open-source firmware solution, has begun to attract attention. Compared to the traditional UEFI boot method, Coreboot is more open and flexible, and can adapt to the needs of specific business scenarios more quickly.

[0005] However, for the specific application scenario of in-band BIOS updates, UEFI BIOS, by default, only supports in-band updates for BIOS of the same type (i.e., UEFI layout type, which usually refers to the physical or logical arrangement of components, modules, or data structures), and cannot directly support in-band updates for Coreboot BIOS. When it is necessary to update different types of BIOS firmware, it is usually only possible to rely on out-of-band BMC (Baseboard Management Controller) updates or manual flashing, which greatly affects maintenance efficiency and increases operational complexity. Summary of the Invention

[0006] This application provides a firmware in-band refresh method, electronic device, storage medium, and program product to at least solve the problem in the related art that in-band refresh interrupt handlers can only refresh firmware with the same layout.

[0007] This application provides a firmware in-band refresh method, including: identifying the firmware layout type of the firmware to be refreshed; determining a reference layout table of the firmware to be refreshed based on the firmware layout type; and performing in-band refresh of the firmware to be refreshed based on the reference layout table in the cache of the current firmware, wherein the current firmware and the firmware to be refreshed are heterogeneous firmware.

[0008] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described firmware in-band refresh methods when executing the computer program.

[0009] This application also provides a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described firmware in-band refresh methods.

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

[0011] This application determines the reference layout table of the firmware to be refreshed based on the firmware layout type of the firmware to be refreshed. Based on the reference layout table, the firmware to be refreshed is refreshed in the cache of the current firmware. In this way, even if the current firmware and the firmware to be refreshed are heterogeneous firmware, in-band firmware refresh can still be achieved. Thus, by introducing the reference layout table, in-band refresh of heterogeneous firmware is realized, solving the technical problem that in-band refresh interrupt handlers in related technologies can only refresh firmware with the same layout. This achieves the technical effect of supporting in-band refresh of heterogeneous firmware, improving operation and maintenance efficiency, and reducing the operational complexity of in-band refresh of heterogeneous firmware. Attached Figure Description

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

[0013] Figure 1 is a flowchart illustrating a method for flashing the BIOS at the application layer of a Linux system in related technologies;

[0014] Figure 2 is a flowchart illustrating an in-band firmware refresh method provided in an embodiment of this application;

[0015] Figure 3 is a flowchart illustrating a method for in-band flashing of heterogeneous BIOS firmware according to an embodiment of this application;

[0016] Figure 4 is a schematic diagram of the layout provided in an embodiment of this application;

[0017] Figure 5 is a schematic diagram of a firmware in-band refresh device provided in an embodiment of this application;

[0018] Figure 6 is a schematic diagram of the structure of the electronic device provided in an embodiment of this application.

[0019] Explanation of reference numerals in the attached drawings: 10 - Firmware in-band refresh device; 301 - Identification module; 302 - Determination module; 303 - Refresh module; 401 - Memory; 402 - Processor. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

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

[0022] Figure 1 is a flowchart of a method for refreshing the BIOS at the application layer of a Linux system in the related art. This method sends an SMI (System Management Interrupt) interrupt instruction through the processor's out instruction, causing the CPU (Central Processing Unit) to enter SMM (System Management Mode). In SMM mode, the BIOS gains control, updates its own regions, and refreshes the BIOS.

[0023] Specifically, as shown in Figure 1, the process begins by launching the BIOS flashing tool, selecting a BIOS file, and verifying it. If verification succeeds, the process continues; otherwise, it returns to select and verify the BIOS file again. Upon successful verification, I / O privileges are granted, a 4K buffer is allocated, and the buffer is converted to a physical address. Then, 4K of data from the file is read into the data buffer, and an SMI interrupt is requested to enter SMM mode. In SMM mode, the BIOS processor parses and processes the data, then writes the data to the BIOS, exits SMM mode, and checks if the write operation was successful. If successful, it checks if the end of the file has been reached; if not, the process repeats until the entire file is written. If the write operation fails or the end of the file is reached, the process ends. This method first triggers a BIOS firmware flashing request at the Linux system's application layer through a specific interface, initiating the entire flashing process. It uses the processor's `out` instruction to send an SMI interrupt, causing the CPU to temporarily suspend its current task and switch to SMM mode. SMM is a special CPU operating mode that allows low-level hardware management and maintenance tasks to be performed without interfering with the normal operation of the operating system or other applications. Once the CPU enters SMM mode, the BIOS takes over control. In this protected environment, the BIOS can safely perform low-level hardware management and update operations, including its own firmware updates.

[0024] However, this method focuses on refreshing the execution process of the BIOS interrupt handler, but does not take into account the situation where the layout of the BIOS to be refreshed is different from that of the currently running BIOS. Therefore, it cannot support in-band refresh between heterogeneous BIOSes with different layouts.

[0025] To address the shortcomings of the aforementioned related technologies, this application proposes an in-band firmware refresh method, electronic device, storage medium, and program product to solve the technical problem that in-band refresh interrupt handling programs can only refresh firmware with the same layout. At the same time, it achieves the technical effect of supporting in-band refresh of heterogeneous firmware and allowing different firmware to support refresh by only changing the structure of the reference layout table. The specific method will be described in detail below.

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

[0027] Figure 2 is a flowchart illustrating an in-band firmware refresh method provided in an embodiment of this application. As shown in Figure 2, the method specifically includes the following steps:

[0028] In step S101, the firmware layout type of the firmware to be refreshed is identified.

[0029] The firmware layout type to be flashed can be UEFI, Coreboot, etc., without specific limitations. UEFI firmware adopts a modular design, is easy to expand and maintain, and supports functional expansion through drivers and application programming interfaces. It provides secure boot functionality, ensuring that only signed firmware and operating system code can run, enhancing system security. It is widely used in modern computers, servers, and personal devices, especially in environments requiring high security and high performance. Coreboot firmware is lightweight and efficient, focusing on minimizing boot time and reducing unnecessary complexity. It is suitable for application scenarios that require fast boot, such as embedded systems and servers. It is also completely open source, allowing developers to customize firmware functions according to specific needs, providing great flexibility and running on various hardware platforms.

[0030] It is understood that the embodiments of this application first need to identify the firmware layout type of the firmware to be refreshed, so as to determine whether the firmware layout type of the firmware to be refreshed matches the format supported by the current server.

[0031] In this embodiment of the application, identifying the firmware layout type of the firmware to be refreshed includes: extracting the firmware identifier of the firmware to be refreshed; and determining the firmware layout type of the firmware to be refreshed based on the firmware identifier.

[0032] The firmware identifier is the layout type identifier of the firmware to be updated. This identifier can be used to identify the layout type of the firmware, thereby revealing the internal data structure and organization of the firmware.

[0033] In this embodiment of the application, determining the firmware layout type of the firmware to be refreshed based on the firmware identifier includes: obtaining a first correspondence table between firmware identifiers and firmware layout types; and querying the first correspondence table using the firmware identifier as an index to determine the firmware layout type of the firmware to be refreshed.

[0034] The first correspondence table is a mapping table that records the association between different firmware layout types and their corresponding firmware identifiers. It can be understood as a lookup table, where the corresponding firmware layout type can be found by using the firmware identifier.

[0035] It is understood that, in this embodiment of the application, the firmware identifier is used as an index to query the first correspondence table, and the firmware layout type confirmation information of the firmware to be refreshed is obtained from the information in the first correspondence table, thereby determining the firmware layout type of the firmware to be refreshed.

[0036] In this embodiment of the application, before identifying the firmware layout type of the firmware to be updated, the method further includes: obtaining a request for in-band firmware update issued by the server; responding to the request for in-band firmware update and triggering the interrupt routine of the current firmware; and determining the firmware layout type of the firmware to be updated in the interrupt routine of the current firmware.

[0037] The server-sent in-band firmware update request typically includes the location and version information of the firmware file to be updated. The interrupt handler sends an SMI interrupt instruction to temporarily suspend the current task and switch to SMM mode to run a dedicated interrupt handler. SMM mode provides a highly isolated and protected environment that allows sensitive operations to be performed without interfering with the operating system or other applications. This isolation ensures that even if there are vulnerabilities in the operating system or applications, ongoing system management tasks will not be affected, thus safely executing the firmware update operations.

[0038] It is understood that when the embodiments of this application receive a request from the server to update the firmware in-band, the CPU responds to the request by sending an SMI interrupt instruction, causing the CPU to temporarily suspend the current task and switch to SMM mode to run the interrupt routine of the current firmware. The firmware layout information of the firmware to be updated is extracted from the interrupt routine of the current firmware, and the firmware layout type is determined according to the firmware layout information.

[0039] In step S102, the reference layout table of the firmware to be refreshed is determined according to the firmware layout type.

[0040] The reference layout table is a preset layout table stored in SMRAM (System Management Random Access Memory). It contains reference firmware layout information and provides a standard template that can be used to verify and parse whether the layout of the firmware to be flashed conforms to the expected format.

[0041] It is understood that the embodiments of this application determine the target in-band refresh action of the firmware to be refreshed by using a reference layout table of firmware layout types. This can ensure that the correct target in-band refresh action is taken according to the specific firmware layout type of the firmware to be refreshed, thereby achieving efficient and secure firmware updates.

[0042] In this embodiment of the application, determining the reference layout table of the firmware to be refreshed based on the firmware layout type includes: reading a second correspondence table between firmware layout types and reference layout tables in the database; and querying the second correspondence table using the firmware layout type as an index to obtain the reference layout table.

[0043] The second correspondence table is a mapping table that records the association between different firmware layout types and their corresponding reference layout tables. It can be understood as a lookup table, which allows you to find the corresponding reference layout table by firmware layout type.

[0044] It is understood that, in order to obtain the reference layout table of firmware layout types in this embodiment of the application, a second correspondence table needs to be found in the database that stores the data relationship between firmware layout types and reference layout tables. The specific firmware layout type of the firmware to be refreshed is used as an index to query and extract the corresponding reference layout table in the second correspondence table.

[0045] In this embodiment of the application, before determining the reference layout table of the firmware to be refreshed according to the firmware layout type, the method further includes: reading the reference layout table stored in the database; obtaining the first layout structure of the firmware when the reference layout table is established; identifying the second layout structure of the firmware to be refreshed; comparing the first layout structure with the second layout structure; if the first layout structure and the second layout structure are inconsistent, updating the reference layout table and the second correspondence table in the database according to the second layout structure.

[0046] It is understood that, before obtaining the reference layout table for the firmware layout type in this embodiment, it is first necessary to read the reference layout table stored in the database and obtain the first layout structure recorded during the establishment phase of the reference layout table, i.e., the original or standard firmware layout. Then, the second layout structure of the firmware to be updated, i.e., the actual firmware layout information, is identified. The first layout structure and the second layout structure are compared. If the first layout structure and the second layout structure are inconsistent, it indicates that the current firmware layout has changed or been updated. In this case, it is necessary to update the reference layout table and the second correspondence table in the database according to the second layout structure to ensure that the two reflect the latest firmware layout information, thereby ensuring that subsequent firmware update operations can be performed based on the latest and most accurate layout information and avoiding problems caused by layout mismatch.

[0047] In step S103, the firmware to be refreshed is refreshed in-band based on the reference layout table in the cache of the current firmware, wherein the current firmware and the firmware to be refreshed are heterogeneous firmware.

[0048] Heterogeneous firmware refers to different types of firmware with different hardware layouts and structures. For example, UEFI firmware and Coreboot firmware have significant differences in their internal organization, so they are heterogeneous firmware. The current firmware is the firmware of the current server, and by default, in-band refresh of heterogeneous firmware is not supported. The cache of the current firmware is the SMRAM memory area, which is used to store and run code and data in SMM mode.

[0049] It is understood that, in the embodiments of this application, when the firmware to be refreshed is executed in the cache of the current firmware, the current firmware and the firmware to be refreshed are allowed to be heterogeneous firmware. Even if the current firmware and the firmware to be refreshed are of different types, they can be processed correctly. The firmware to be refreshed is refreshed in the band based on the reference layout table. This enables the current firmware, which does not support in-band refresh of heterogeneous firmware by default, to support in-band refresh of heterogeneous firmware. This solves the problem in related technologies that the in-band refresh interrupt handler can only refresh firmware with the same reference layout. For heterogeneous firmware, it can only be completed by relying on out-of-band BMC refresh or manual burning, which results in low operation and maintenance efficiency, high operation complexity and high risk.

[0050] In this embodiment of the application, the intra-band refresh of the firmware to be refreshed based on the reference layout table includes: extracting reference layout information from the reference layout table; reading multiple blocks of the firmware to be refreshed based on the reference layout information; identifying the target block order of the multiple blocks; and refreshing the firmware to be refreshed intra-band according to the target block order.

[0051] The reference layout information refers to the preset reference layout information in the reference layout table; multiple areas, namely FV_BB (Firmware Volume Boot Block), FV_MAIN (Main Firmware Volume), and NVRAM (Non-Volatile Random Access Memory) in UEFI BIOS, or Romstage (Read-Only Memory stage), Ramstage (Random Access Memory stage), and Payload in Coreboot BIOS; the order of the target blocks is usually defined by the reference layout table to ensure that each block is correctly placed in its proper position.

[0052] It is understood that, through the obtained reference layout table, the required reference layout information is identified, and the target block order of multiple predefined blocks of the firmware to be refreshed is obtained. The specific in-band refresh action of the firmware to be refreshed can be performed through this target block order, which will be described in detail below.

[0053] In this embodiment of the application, the in-band refresh of the firmware to be refreshed according to the target block order includes: refreshing multiple blocks to the cache of the current firmware in blocks according to the target block order.

[0054] The method involves refreshing multiple blocks to the current firmware cache in blocks, by refreshing the corresponding blocks of the firmware to be refreshed to the corresponding offset of the current firmware according to the target block order.

[0055] It is understood that, in the embodiments of this application, when the firmware to be refreshed performs the target in-band refresh action in the cache of the current firmware, the target block order is obtained by parsing the parameter layout table, and the corresponding blocks of the firmware to be refreshed are refreshed to the corresponding offset of the current firmware according to the target block order, thereby enabling the current firmware, which by default does not support in-band refresh of heterogeneous firmware, to support in-band refresh of heterogeneous firmware.

[0056] In this embodiment of the application, before performing an in-band refresh of the firmware to be refreshed based on the reference layout table, the process includes: identifying the actual layout information of the firmware to be refreshed; extracting the reference layout information from the reference layout table; comparing the actual layout information and the reference layout information; and determining the execution of the in-band refresh action of the firmware to be refreshed based on the comparison result.

[0057] The actual layout information is extracted from the actual firmware file to be updated, including the data structure and organization of the firmware, as well as detailed information such as the location, size and function of each block; the reference firmware layout information is extracted from the reference layout table, including a detailed description of the location, size and function of each part of the preset firmware to be updated.

[0058] Understandably, before performing an in-band refresh of the firmware to be refreshed based on the reference layout table, it is necessary to identify the reference firmware layout information in the reference layout table to obtain detailed data on the internal structure of the specific type of firmware, such as the position and size of each part. Then, the actual layout information of the firmware is extracted from the firmware file to be refreshed. This information reflects the actual data structure and organization of the firmware to be refreshed. The extracted firmware layout information of the firmware to be refreshed is compared with the reference firmware layout information to confirm whether the two are consistent. Based on the comparison results, the target in-band refresh action of the firmware to be refreshed is determined, thereby avoiding problems caused by incompatible layouts between the current firmware and the firmware to be refreshed.

[0059] In this embodiment of the application, comparing the actual layout information and the reference layout information includes: comparing the actual layout information and the reference layout information one by one; if the information is consistent at all the same positions, the comparison result is a layout consistent result; if the information is consistent at any position, the comparison result is a layout inconsistent result.

[0060] It is understood that the embodiments of this application compare the reference firmware layout information and the actual layout information of the firmware to be updated one by one. Specifically, each part of the actual layout information of the firmware to be updated is compared in detail with the corresponding predefined reference firmware layout information part in the reference layout table to check whether the information in the same position is consistent. If the information in the same position of all compared parts is completely consistent, the result of layout consistency is obtained, indicating that the firmware to be updated conforms to the expected layout format; otherwise, if the information in any position is inconsistent, the result of layout inconsistency is obtained, indicating that the layout of the firmware to be updated does not match the reference layout table.

[0061] In this embodiment of the application, if the comparison result is a layout consistency result, then the in-band refresh action of the firmware to be refreshed is performed.

[0062] It is understood that in this embodiment of the application, the reference firmware layout information and the actual layout information of the firmware to be refreshed are compared one by one. If the comparison result is a layout consistency result, that is, the actual layout information of the firmware to be refreshed completely matches the standard information in the reference layout table, then the in-band refresh action of the firmware to be refreshed is performed.

[0063] In this embodiment of the application, if the comparison result is a layout inconsistency, the interrupt procedure of the current firmware is exited.

[0064] It is understood that in this embodiment of the application, the reference firmware layout information and the actual layout information of the firmware to be refreshed are compared one by one. If the comparison result is that the layout is inconsistent, that is, there is a difference between the actual layout information of the firmware to be refreshed and the layout information of the reference firmware, the interruption program of the current firmware needs to be exited immediately. Specifically, when any part of the layout information is detected to be mismatched, in order to avoid system instability or other potential problems caused by forced refresh, further operations need to be stopped and the interruption program in SMM mode needs to be exited.

[0065] In this embodiment of the application, before in-band refreshing of the firmware to be refreshed based on the reference layout table, the method further includes: identifying the firmware layout type of the current firmware; if the firmware layout type of the current firmware is inconsistent with the firmware layout type of the firmware to be refreshed, then it is determined that the current firmware and the firmware to be refreshed are heterogeneous firmware.

[0066] It is understood that, before performing an in-band update of the firmware to be updated based on the reference layout table, this application embodiment needs to identify the firmware layout type of the current firmware and compare the firmware layout type of the current firmware with that of the firmware to be updated. If the two are inconsistent, it is determined that the current firmware and the firmware to be updated are heterogeneous firmware, meaning that they belong to different types and have different hardware layouts and structures. Special handling is required to ensure that the new firmware can be correctly written to the cache. In this way, it can be ensured that the firmware update operation can be successfully completed even when there are different types of firmware, thus improving the flexibility and adaptability of the system.

[0067] It should be noted that the heterogeneous firmware in this application is not limited to UEFI type BIOS firmware and Coreboot type. For other types of heterogeneous BIOS firmware, such as TianoCore EDK II type, Open Firmware, etc., only the structure of the reference layout table needs to be changed, and the flashing of in-band heterogeneous firmware is also supported.

[0068] According to the firmware in-band refresh method of this application embodiment, a reference layout table of the firmware to be refreshed is determined by the firmware layout type of the firmware to be refreshed. Based on the reference layout table, the firmware to be refreshed is refreshed in the cache of the current firmware. In this way, even if the current firmware and the firmware to be refreshed are heterogeneous firmware, firmware in-band refresh can still be achieved. Thus, the introduction of the reference layout table realizes the in-band refresh of heterogeneous firmware, which solves the technical problem that the in-band refresh interrupt handling program of related technologies can only refresh firmware with the same layout, improves operation and maintenance efficiency, and reduces the operational complexity of in-band refresh of heterogeneous firmware.

[0069] The firmware in-band refresh method is further described below through a specific embodiment.

[0070] Figure 3 is a flowchart of a method for in-band flashing of heterogeneous firmware provided in this embodiment. In this embodiment, heterogeneous BIOS firmware of UEFI type and Coreboot type is selected for in-band flashing. As shown in Figure 3, the method specifically includes the following steps:

[0071] Step S201: Assuming the current server BIOS firmware is of UEFI type, the server OS (Server Operating System) initiates a request to update the BIOS firmware in-band.

[0072] Initiating the firmware update process by requesting an in-band BIOS firmware update from the server OS ensures that the system can run the latest BIOS version to obtain performance improvements, security patches, or other enhancements.

[0073] Step S202: The UEFI BIOS triggers the SMI interrupt handler, and the type of BIOS firmware to be flashed is determined in the interrupt handler.

[0074] Determine the actual type of firmware to be flashed (UEFI type or Coreboot type) so that the correct processing steps can be taken subsequently.

[0075] Step S203: Determine whether the BIOS firmware to be flashed belongs to the Coreboot type. If yes, proceed to step S204; otherwise, proceed to step S208.

[0076] If the current server BIOS firmware is assumed to be of the Coreboot type, then it is necessary to determine whether the BIOS firmware to be flashed is of the UEFI type. In this way, the appropriate processing method can be selected according to the firmware type to ensure that subsequent steps are performed on the correct BIOS firmware type to be flashed.

[0077] Step S204: The UEFI BIOS interrupt handler continues to parse the layout of the BIOS firmware to be flashed.

[0078] Read and analyze the layout information in the firmware file to be flashed, extract its hardware layout details, and provide the necessary data foundation for the next step of verification and flashing operations.

[0079] Step S205: Compare the layout of the BIOS firmware to be flashed with the preset Coreboot layout reference table in SMRAM. If they match, proceed to step S206; otherwise, proceed to step S207.

[0080] Using a pre-set Coreboot layout reference table as a reference, each part of the firmware to be flashed is compared one by one to confirm whether the firmware to be flashed conforms to the Coreboot standard format, thus ensuring the safety and accuracy of the flashing process.

[0081] In step S206, the UEFI BIOS interrupt handler continues to read each block of the Coreboot BIOS firmware to be refreshed according to the Coreboot layout reference layout table, refreshes it to the current Flash memory in blocks, and ends the process.

[0082] Following the guidance of the Coreboot layout reference table, different blocks of the firmware are read and written sequentially into the Flash memory to complete the firmware update operation and ensure that the new firmware is correctly installed and takes effect.

[0083] Step S207: The layout of the BIOS firmware to be flashed does not conform to the expected Coreboot layout reference layout. Exit the flash interrupt program and end the process.

[0084] Due to firmware layout mismatch, the interrupt handler terminates the update operation and returns an error status to prevent potential problems caused by firmware incompatibility and ensure system stability and security. At the same time, it can be selected to update the expected Coreboot layout reference layout in the database according to the layout of the BIOS firmware to be updated, so as to ensure that both reflect the latest firmware layout information. This ensures that subsequent firmware update operations can be based on the latest and most accurate layout information, avoiding problems caused by layout mismatch.

[0085] Step S208: The UEFI BIOS interrupt handler continues to parse the layout of the BIOS firmware to be flashed.

[0086] Read and analyze the layout information in the firmware file to be flashed, extract its hardware layout details, and provide the necessary data foundation for the next step of verification and flashing operations.

[0087] Step S209: Compare the layout of the BIOS firmware to be flashed with the preset UEFI layout reference table in SMRAM. If they match, proceed to step S210; otherwise, proceed to step S211.

[0088] Using a pre-set UEFI layout reference table as a reference, each part of the firmware to be flashed is compared one by one to confirm whether the firmware to be flashed conforms to the UEFI standard format, thus ensuring the security and accuracy of the flashing process.

[0089] In step S210, the UEFI BIOS interrupt handler continues to read each block of the UEFI BIOS to be refreshed according to the UEFI layout reference table, refreshes it to the current Flash memory in blocks, and ends the process.

[0090] Following the guidance of the UEFI layout reference table, different blocks of the firmware are read and written sequentially into the Flash memory to complete the firmware update operation and ensure that the new firmware is correctly installed and takes effect.

[0091] Step S211: The layout of the BIOS firmware to be flashed does not conform to the expected UEFI layout reference table. Exit the flash interrupt program and end the process.

[0092] Due to firmware layout mismatch, the interrupt handler terminates the update operation and returns an error status to prevent potential problems caused by firmware incompatibility and ensure system stability and security. At the same time, it can be selected to update the expected UEFI layout reference table in the database according to the layout of the BIOS firmware to be updated, so as to ensure that both reflect the latest firmware layout information. This ensures that subsequent firmware update operations can be based on the latest and most accurate layout information, avoiding problems caused by layout mismatch.

[0093] The UEFI BIOS layout reference table and CorebootBIOS layout reference table pre-installed in SMRAM are shown in Figure 4, as detailed below:

[0094] The UEFI BIOS layout table defines the location, size, and function of each part of the firmware file. The following are the main components of the UEFI BIOS layout table:

[0095] FV_BB contains the bootloader and other initialization code. It is the first part executed during system startup and its function is to provide basic hardware initialization and boot services. It usually contains some immutable basic instruction sets.

[0096] FV_MAIN is the main firmware volume, containing most of the BIOS code and data. It is responsible for system initialization and configuration management, including device drivers, platform-specific initialization code, etc.

[0097] NVRAM stands for Non-volatile Random Access Memory, used to store configuration parameters and other persistent data, such as user settings, BIOS configuration options, and other data that needs to be stored for a long time.

[0098] The Coreboot BIOS layout table defines a different firmware file structure, primarily used in lightweight and highly customizable firmware environments. The following are the main components of the Coreboot BIOS layout table:

[0099] Romstage: Responsible for initializing the most basic hardware components, such as the CPU and chipset, providing the basic environment for subsequent stages of operation and ensuring that the system can continue to run more complex initialization steps.

[0100] Ramstage: Executed after memory is initialized, it loads more device drivers and prepares the system to load payloads, further initializes the hardware, loads necessary drivers and services, and prepares for the operating system or other payloads.

[0101] Payload: A user-specified program, which can be a bootloader (such as GRUB), operating system kernel, etc., used to perform specific tasks or boot into the operating system, providing great flexibility and customization.

[0102] The reference layout table provides a standard firmware layout information template. By comparing the firmware layout information of the firmware to be flashed with the firmware layout information in the reference layout table, the accuracy and consistency of the firmware flashing operation can be ensured.

[0103] In summary, this embodiment assumes that the current server BIOS firmware is of UEFI type. When the server OS initiates an in-band update request for the BIOS firmware, the UEFI BIOS triggers the SMI interrupt handler. In the interrupt handler, the type of the BIOS firmware to be updated is determined. If it is of Coreboot type, the UEFI BIOS interrupt handler continues to parse the layout of the BIOS firmware to be updated and compares it with the preset Coreboot layout reference layout table in SMRAM. If they match, the various blocks of the Coreboot BIOS firmware to be updated are read and updated to the current Flash memory in blocks. If they do not match, it means that the layout of the BIOS firmware to be updated does not conform to the expected Coreboot layout reference layout, and the update interrupt handler exits. Similarly, if the refresh interrupt handler initially determines that the BIOS firmware to be refreshed is of type UEFI, the UEFI BIOS interrupt handler continues to parse the layout of the BIOS firmware to be refreshed and compare it with the preset UEFI layout reference table in SMRAM. If they match, the UEFI BIOS interrupt handler continues to read each block of the UEFI BIOS firmware to be refreshed according to the UEFI layout reference table and refreshes it to the current Flash memory in blocks. If they do not match, it means that the layout of the BIOS firmware to be refreshed does not conform to the expected UEFI layout reference layout, and the refresh interrupt handler exits.

[0104] In this way, an innovative layout reference table is added to the SMRAM area to distinguish heterogeneous BIOSes. UEFI BIOS firmware corresponds to one layout table, and Coreboot BIOS firmware corresponds to another layout table. The refresh interrupt handler obtains the name and offset of each block by parsing the layout table, and then refreshes the corresponding block of the BIOS firmware file to be refreshed to the corresponding offset of the current BIOS Flash memory. This supports in-band refresh of heterogeneous BIOS firmware and solves the problem that traditional in-band refresh interrupt handlers can only refresh BIOS firmware with the same layout.

[0105] It should be noted that the heterogeneous BIOS firmware in this embodiment is not limited to UEFI type BIOS firmware and Coreboot type BIOS firmware. For other types of heterogeneous BIOS firmware, it is also possible to refresh it by simply changing the structure of the layout reference table.

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

[0107] Figure 5 is a schematic diagram of the structure of an in-band firmware refresh device provided in an embodiment of this application. As shown in Figure 5, the in-band firmware refresh device 10 includes: an identification module 301, a determination module 302, and a refresh module 303.

[0108] The identification module 301 is used to identify the firmware layout type of the firmware to be refreshed; the determination module 302 is used to determine the reference layout table of the firmware to be refreshed according to the firmware layout type; the refresh module 303 refreshes the firmware to be refreshed in-band based on the reference layout table in the cache of the current firmware, wherein the current firmware and the firmware to be refreshed are heterogeneous firmware.

[0109] In this embodiment, the identification module 301 is further configured to: identify the firmware layout type of the firmware to be updated, extract the firmware identifier of the firmware to be updated, and determine the firmware layout type of the firmware to be updated based on the firmware identifier.

[0110] In this embodiment of the application, determining the firmware layout type of the firmware to be refreshed based on the firmware identifier includes: obtaining a first correspondence table between firmware identifiers and firmware layout types; and querying the first correspondence table using the firmware identifier as an index to determine the firmware layout type of the firmware to be refreshed.

[0111] In this embodiment of the application, a final interrupt module is also included, wherein the interrupt module is further configured to: obtain a request for in-band firmware update issued by the server before identifying the firmware layout type of the firmware to be updated; respond to the request for in-band firmware update and trigger the interrupt routine of the current firmware; and determine the firmware layout type of the firmware to be updated in the interrupt routine of the current firmware.

[0112] In this embodiment of the application, the determining module 302 is further configured to: determine a reference layout table for the firmware to be refreshed based on the firmware layout type, including: reading a second correspondence table between firmware layout types and reference layout tables in the database; and querying the second correspondence table using the firmware layout type as an index to obtain the reference layout table.

[0113] In this embodiment, the refresh module 303 is further configured to: refresh the firmware to be refreshed in-band based on the reference layout table, extract reference layout information from the reference layout table; read multiple blocks of the firmware to be refreshed based on the reference layout information; identify the target block order of the multiple blocks, and refresh the firmware to be refreshed in-band according to the target block order.

[0114] In this embodiment of the application, the in-band refresh of the firmware to be refreshed according to the target block order includes: refreshing multiple blocks to the cache of the current firmware in blocks according to the target block order.

[0115] In this embodiment of the application, a comparison module is also included, wherein the comparison module is further configured to: identify the actual layout information of the firmware to be refreshed before performing an in-band refresh of the firmware to be refreshed based on the reference layout table; extract the reference layout information from the reference layout table; compare the actual layout information and the reference layout information; and determine the execution of the in-band refresh action of the firmware to be refreshed based on the comparison result.

[0116] In this embodiment of the application, comparing the actual layout information and the reference layout information includes: comparing the actual layout information and the reference layout information one by one; if the information is consistent at all the same positions, the comparison result is a layout consistent result; if the information is consistent at any position, the comparison result is a layout inconsistent result.

[0117] In this embodiment of the application, if the comparison result is a layout consistency result, then the in-band refresh action of the firmware to be refreshed is performed.

[0118] In this embodiment of the application, if the comparison result is a layout inconsistency, the interrupt procedure of the current firmware is exited.

[0119] In this embodiment of the application, a judgment module is further included, wherein the judgment module is further configured to: before in-band refreshing the firmware to be refreshed based on the reference layout table, further include: identifying the firmware layout type of the current firmware; if the firmware layout type of the current firmware is inconsistent with the firmware layout type of the firmware to be refreshed, then determine that the current firmware and the firmware to be refreshed are heterogeneous firmware.

[0120] It should be noted that the descriptions of the features in the embodiments corresponding to the firmware in-band refresh device can be found in the relevant descriptions of the embodiments corresponding to the firmware in-band refresh method, and will not be repeated here.

[0121] According to the firmware in-band refresh device provided in the embodiments of this application, a reference layout table of the firmware to be refreshed is determined by the firmware layout type of the firmware to be refreshed. Based on the reference layout table, the firmware to be refreshed is refreshed in the cache of the current firmware. In this way, even if the current firmware and the firmware to be refreshed are heterogeneous firmware, firmware in-band refresh can still be achieved. Thus, the introduction of the reference layout table realizes the in-band refresh of heterogeneous firmware, which solves the technical problem that the in-band refresh interrupt handling program of related technologies can only refresh firmware with the same layout, improves operation and maintenance efficiency, and reduces the operational complexity of in-band refresh of heterogeneous firmware.

[0122] An embodiment of this application also provides an electronic device, as shown in FIG6, including a memory 401 and a processor 402. The memory 401 stores a computer program, and the processor 402 is configured to run the computer program to perform the steps in any of the firmware in-band refresh method embodiments described above.

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

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

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

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

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

[0128] The foregoing has provided a detailed description of the firmware in-band refresh method, electronic device, storage medium, and program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for firmware in-band refresh, the method comprising: include: Identify the firmware layout type of the firmware to be updated; The reference layout table of the firmware to be refreshed is determined according to the firmware layout type; In the current firmware cache, the firmware to be refreshed is refreshed in-band based on the reference layout table, wherein the current firmware and the firmware to be refreshed are heterogeneous firmware.

2. The firmware in-band refresh method of claim 1, wherein, The in-band refresh of the firmware to be refreshed based on the reference layout table includes: Extract the reference layout information from the reference layout table; Based on the reference layout information, multiple blocks of the firmware to be refreshed are read; Identify the target block order of the multiple blocks, and perform an in-band refresh of the firmware to be refreshed according to the target block order.

3. The firmware in-band refresh method of claim 2, wherein, The in-band flashing of the firmware to be flashed according to the target block sequence includes: According to the target block order, the multiple blocks are refreshed to the cache of the current firmware in blocks.

4. The firmware in-band refresh method of claim 1 or 2, wherein, Before performing an in-band update on the firmware to be updated based on the reference layout table, the process includes: Identify the actual layout information of the firmware to be refreshed; Extract the reference layout information from the reference layout table; Compare the actual layout information with the reference layout information; The execution of the in-band refresh action of the firmware to be refreshed is determined based on the comparison results.

5. The firmware in-band refresh method of claim 4, wherein, The comparison between the actual layout information and the reference layout information includes: Compare the actual layout information with the reference layout information one by one; If the information at all the same locations is consistent, then the comparison result is a layout consistency result; If the information is consistent at any location, then the comparison result is a layout inconsistency result.

6. The firmware in-band refresh method of claim 5, wherein, If the comparison result is consistent with the layout, then perform an in-band refresh of the firmware to be refreshed.

7. The firmware in-band refresh method of claim 5, wherein, If the comparison result is a layout inconsistency, then the interrupt procedure of the current firmware will be exited.

8. The firmware in-band refresh method of claim 1, wherein, The identification of the firmware layout type of the firmware to be updated includes: Extract the firmware identifier of the firmware to be updated; The firmware layout type of the firmware to be updated is determined based on the firmware identifier.

9. The firmware in-band refresh method of claim 8, wherein, The step of determining the firmware layout type of the firmware to be updated based on the firmware identifier includes: Obtain the first correspondence table between firmware identifiers and firmware layout types; Using the firmware identifier as an index, the firmware layout type of the firmware to be refreshed is determined by querying the first correspondence table.

10. The firmware in-band refresh method of claim 1, wherein, Before identifying the firmware layout type of the firmware to be flashed, the process also includes: Get the request from the server for in-band firmware update; In response to the request for in-band firmware update, the interrupt procedure of the current firmware is triggered; In the interrupt routine of the current firmware, the firmware layout type of the firmware to be updated is determined.

11. The firmware in-band refresh method of claim 1, wherein, The step of determining the reference layout table of the firmware to be refreshed based on the firmware layout type includes: Read the second correspondence table between firmware layout types and reference layout tables from the database; Using the firmware layout type as an index, the reference layout table is obtained by querying the second correspondence table.

12. The firmware in-band refresh method of claim 1, wherein, Before performing an in-band update of the firmware to be updated based on the reference layout table, the process also includes: Identify the firmware layout type of the current firmware; If the firmware layout type of the current firmware is inconsistent with the firmware layout type of the firmware to be refreshed, then the current firmware and the firmware to be refreshed are determined to be heterogeneous firmware.

13. The firmware in-band refresh method of claim 1, wherein, The firmware layout type of the firmware to be refreshed is any one of a UEFI type and a Coreboot type.

14. The firmware in-band refresh method of claim 9, wherein, The first correspondence table is a mapping relationship table recording the association between different firmware layout types and corresponding firmware identifiers.

15. The firmware in-band refresh method of claim 10, wherein, The request for updating the firmware in-band issued by the server contains location information and version information of the firmware file to be updated.

16. The firmware in-band refresh method of claim 10, wherein, The interrupt program is an SMI interrupt instruction sent to temporarily suspend the current task of the CPU and switch to an SMM mode to run a special interrupt processing program.

17. A firmware in-band refresh apparatus, comprising: The method comprises the steps of: The identification module is configured to identify the firmware layout type of the firmware to be refreshed. The determination module is configured to determine a reference layout table of the firmware to be refreshed according to the firmware layout type. The refreshing module is configured to refresh the firmware to be refreshed in-band in the cache of the current firmware based on the reference layout table, wherein the current firmware and the firmware to be refreshed are heterogeneous firmware.

18. An electronic device, comprising: The method comprises the steps of: The memory is used to store a computer program. The processor is used to execute the computer program to implement the steps of the firmware in-band refreshing method according to any one of claims 1 to 17.

19. A non-transitory computer readable storage medium, comprising: The non-volatile computer readable storage medium stores a computer program, wherein the computer program is executed by the processor to implement the steps of the firmware in-band refreshing method according to any one of claims 1 to 17.

20. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the firmware in-band refreshing method according to any one of claims 1 to 17.

Images