A server firmware upgrading method and an electronic device

Abstract

The application discloses a server firmware upgrading method and electronic equipment, and relates to the technical field of server upgrading, which comprises writing a to-be-upgraded firmware image into an external memory, wherein the memory is a nonvolatile storage carrier belonging to a server host mainboard, and the server cost is reduced by multiplexing the existing storage resource of the server host; the firmware upgrading depends on the external memory, the density of hardware circuit wiring and the interference risk are also reduced, and the hardware design efficiency and stability are improved; in terms of capacity expansion, a large-capacity external memory can be selected to flexibly expand the capacity, and when the firmware image is increased, it is written into a target partition, thereby avoiding the redesign of the mainboard caused by the fixed capacity. Through storage multiplexing, design simplification and flexible capacity expansion, the defects of the traditional scheme in terms of cost, complexity and capacity are solved, and the comprehensive performance of the server is improved.

Description

Technical Field

[0001] This application relates to the field of server upgrade technology, and in particular to a method for upgrading server firmware and an electronic device. Background Technology

[0002] With the rapid development of IoT technology in the information age, the requirements for server performance, data processing, and storage capabilities are constantly increasing. High-performance computing servers, as the core of information systems, are particularly critical for technological iteration. Among these, the Baseboard Management Controller (BMC), as a core component for out-of-band server management, requires dedicated flash memory to store boot code and firmware images. This design constrains server cost control and hardware design.

[0003] When the BMC starts up, it accesses the dedicated Flash memory via the Serial Peripheral Interface (SPI) bus to read the boot code and complete initialization. During upgrades, the firmware image is first temporarily stored in Dynamic Random Access Memory (DRAM), then written to the Flash memory, and the system restarts. However, this approach has significant drawbacks: First, each BMC requires an independent Flash memory, which leads to an increase in server hardware costs as the scale expands. Second, it increases the complexity of motherboard circuit routing and the risk of signal interference, affecting design stability. Third, the Flash memory capacity is fixed, making it difficult to meet the needs of BMC firmware iteration. Upgrades require replacing components and resetting the circuit, limiting upgrade flexibility and timeliness. Summary of the Invention

[0004] This application provides a method for upgrading server firmware and an electronic device to at least solve the problems of high material costs, high hardware design complexity, and fixed Flash storage capacity that cannot be flexibly expanded in the related technologies.

[0005] This application provides a method for upgrading server firmware, comprising: obtaining a firmware image to be upgraded from a baseboard management controller; performing security preprocessing on the firmware image to be upgraded, the security preprocessing including verification and decryption; writing the security preprocessed firmware image to be upgraded into a target partition of an external storage device; the external storage device is a non-volatile storage medium independent of the internal storage of the baseboard management controller and belonging to the server host motherboard; restarting the baseboard management controller and initializing the hardware components required for the operation of the baseboard management controller; reading the firmware image to be upgraded from the target partition and loading the firmware image to be upgraded into a temporary cache area to upgrade the server firmware according to the firmware image to be upgraded.

[0006] This application also provides a server firmware upgrade device, comprising:

[0007] The acquisition module is used to acquire the firmware image to be upgraded from the baseboard management controller;

[0008] The preprocessing module is used to perform security preprocessing on the firmware image to be upgraded. Security preprocessing includes verification and decryption.

[0009] The write module is used to write the security-preprocessed firmware image to be upgraded to the target partition of the external storage; the external storage is a non-volatile storage medium that is independent of the internal storage of the baseboard management controller and belongs to the server host motherboard.

[0010] The restart module is used to restart the baseboard management controller and initialize the hardware components required for the baseboard management controller to run.

[0011] The read module is used to read the firmware image to be upgraded from the target partition and load the firmware image to be upgraded into a temporary cache area so as to upgrade the server firmware according to the firmware image to be upgraded.

[0012] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of the above-described server firmware upgrade method when executing the computer program.

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

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

[0015] This application writes the firmware image to be upgraded into external storage, which is a non-volatile storage medium belonging to the server host motherboard, rather than a dedicated Flash memory for the BMC. By reusing the existing storage resources of the server host, server costs are reduced. Since firmware upgrades rely on external storage on the host side, the motherboard does not need to plan the installation, wiring, and power supply of a dedicated Flash memory for the BMC, reducing components and signal links, lowering the density of hardware circuit wiring and the risk of interference, and improving hardware design efficiency and stability. In terms of capacity expansion, a large-capacity external storage can be selected, allowing for flexible capacity expansion. When the firmware image increases in size, it only needs to be written to the target partition, avoiding the need for motherboard redesign due to fixed capacity. This method, through storage reuse, simplified design, and flexible capacity expansion, solves the shortcomings of traditional solutions in terms of cost, complexity, and capacity, thereby improving the overall performance of the server. Attached Figure Description

[0016] 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.

[0017] Figure 1 A schematic diagram of the specific hardware architecture on which the execution of a server firmware upgrade method provided in this application depends;

[0018] Figure 2 A schematic flowchart illustrating a server firmware upgrade method provided in an embodiment of this application;

[0019] Figure 3 A schematic diagram of the process of upgrading server firmware during the BMC firmware startup phase, as provided in an embodiment of this application;

[0020] Figure 4 A schematic diagram illustrating the process of a server firmware upgrade method during the BMC firmware upgrade stage, as provided in an embodiment of this application.

[0021] Figure 5 A flowchart illustrating another server firmware upgrade method provided in this application embodiment;

[0022] Figure 6 A schematic diagram of a server firmware upgrade device provided in an embodiment of this application;

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

[0024] 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.

[0025] 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.

[0026] To more clearly illustrate the embodiments of this application, the technical terms used in the embodiments will be briefly introduced below:

[0027] The Baseboard Management Controller (BMC) is a dedicated microcontroller embedded in the server motherboard. It operates independently of the server's main central processing unit (CPU), memory, and operating system, and is a core component of the server's "out-of-band management".

[0028] Out-of-band management differs from in-band management (which requires management through the server's main operating system or network interface) in that it is a remote management method. Out-of-band management is achieved through a dedicated channel (such as a BMC dedicated network interface) that is independent of the server's main hardware and system.

[0029] Flash memory is a non-volatile semiconductor storage device (data is not lost after power is turned off). It uses flash memory chips to realize data storage and has the characteristics of fast read and write speed, low power consumption and small size.

[0030] The Serial Peripheral Interface (SPI) is a high-speed synchronous serial communication bus that uses a "master-slave mode" to realize data transmission between devices. Typically, the master device (such as BMC) initiates communication, and the slave device (such as Flash memory) responds. Data interaction can be completed with only 4 signal lines (clock line SCLK, master output line MOSI, master input line MISO, and slave select line CS).

[0031] Dynamic Random Access Memory (DRAM) is a volatile semiconductor storage device (data is lost when power is off). It records data by storing charge in capacitors and requires periodic refreshing of the capacitor charge to maintain the data. It features fast read and write speeds and large storage capacity, and is a core component of server main memory.

[0032] Firmware is specialized software embedded in hardware devices, used to control the basic functions of the hardware devices (such as the monitoring and control logic of the BMC). When the server is powered on or the BMC is triggered to reset, the firmware image becomes the file carrier of the firmware. It is a binary file that packages the firmware code, configuration files, boot program, etc., and can be written to hardware storage devices (such as flash memory) using a burning tool.

[0033] Non-volatile memory based on the serial peripheral interface bus (BIOS SPI Flash) is mainly used to store critical boot code such as the server's Basic Input / Output System (BIOS) program and BMC firmware. It communicates with the BMC and host CPU via the SPI bus and has a write protection mechanism to ensure data security.

[0034] The Non-Volatile Memory Host Controller Interface Specification (NVMe SSD) defines solid-state drives as high-speed storage devices based on the PCIe bus, featuring extremely low latency, ultra-high read and write speeds, and a large command queue.

[0035] The Enhanced Serial Peripheral Interface (eSPI) is a standardized bus interface based on serial communication principles. It enables short-range data transmission between master devices (such as BMC and CPU) and slave devices (such as BIOS SPI Flash and Super I / O chips) using a small number of signal lines (usually 4-6).

[0036] Peripheral Component Interconnect Express (PCIe) is the mainstream high-performance serial bus interface in the current server and computer field, used to connect hardware components with high bandwidth requirements.

[0037] Internal Static Random Access Memory (InternalSRAM) is a high-speed temporary storage unit integrated inside the BMC chip. Its physical structure is tightly coupled with the core computing unit of the BMC (such as the processor). It implements data storage based on static storage technology and is mainly used for the rapid storage of temporary data and program code that are frequently accessed during the startup and operation of the BMC. It is a high-speed data exchange buffer inside the BMC chip.

[0038] In the information age, the Internet of Things (IoT) technology continues to develop and mature, leading to an ever-growing demand for high-speed data processing, efficient data handling, and secure data storage. This directly drives increasingly stringent requirements for server technology. High-performance computing servers, as core devices supporting the operation of information systems, play an indispensable role in data processing and storage systems. In current server architectures, the Baseboard Management Controller (BMC) is the core component for out-of-band server management, and each BMC requires a dedicated Flash memory. The core function of this Flash memory is to store the BMC's boot code and complete firmware image, providing basic data support for the BMC's normal startup and operation. Based on this design, each server needs to be configured with at least one dedicated Flash memory corresponding to the BMC. This situation not only significantly increases the hardware material cost of server equipment but also increases the difficulty of motherboard wiring, constraining server cost control and hardware design efficiency.

[0039] From the startup and upgrade process of BMC, its operating mechanism follows a fixed path: During the startup phase, BMC directly connects to and accesses the dedicated Flash memory via the SPI bus, reads the device startup code from it, and then executes the code to complete the device startup and initialization, thus entering the normal working state; During the upgrade phase, the externally received firmware image is first temporarily stored in the BMC's dedicated dynamic random access memory (DRAM). After all the firmware images have been received, the Flash memory burning process is started to write the firmware image temporarily stored in DRAM into the dedicated Flash memory. Finally, a reboot command is sent to BMC to enable it to boot from the newly written firmware, completing the entire upgrade process.

[0040] However, the aforementioned mainstream BMC startup and upgrade solutions have significant shortcomings in practical applications, specifically in the following three aspects:

[0041] (1) High material costs: Since each BMC needs to be equipped with a dedicated Flash memory, as the number of servers and the configuration requirements of BMC increase, the proportion of Flash memory procurement costs in the total cost of server hardware continues to rise, increasing the overall production cost of the server.

[0042] (2) High hardware design complexity: In the process of server motherboard hardware design, each additional dedicated Flash memory requires additional design of corresponding circuit links and wiring space, which not only increases the complexity of hardware circuit wiring, but may also increase the risk of signal interference due to increased wiring density, reducing the stability and manufacturability of motherboard design.

[0043] (3) Storage capacity bottleneck: The capacity of the Flash memory is fixed during the server motherboard hardware design stage and cannot be flexibly expanded according to the upgrade requirements of the BMC firmware. When the BMC firmware image is expanded to a larger capacity due to functional iteration, if the existing Flash memory capacity cannot meet the requirements, it is necessary to replace it with a larger capacity Flash memory and redesign the motherboard circuit, which not only increases the upgrade cost, but also seriously restricts the flexibility and timeliness of server firmware upgrades.

[0044] To address all or part of the aforementioned technical problems, this application provides a method for upgrading server firmware, including writing the firmware image to be upgraded into an external storage device. This storage device is a non-volatile storage medium belonging to the server host motherboard, rather than a dedicated Flash memory for the BMC. This design completely abandons the traditional model where each BMC must be paired with a dedicated Flash memory. By reusing the existing storage resources of the server host, it eliminates the separate procurement cost of dedicated Flash memory for the BMC, directly reducing the overall server cost from the hardware material level. Since the firmware upgrade relies on the external storage device on the host side, rather than a dedicated Flash memory for the BMC, the motherboard hardware design does not need to plan the Flash memory installation location, wiring links, and power supply circuits for the BMC. This reduces the number of components and signal links on the motherboard, lowers the density of hardware circuit wiring and the risk of interference, simplifies the motherboard layout design process, improves hardware design efficiency and stability, and solves the wiring complexity problem caused by an additional dedicated Flash memory in traditional solutions. The external storage device used has a capacity potential far exceeding that of traditional dedicated Flash memory and can be flexibly selected according to the overall storage needs of the server host (e.g., expanding from GB to TB levels). When the BMC firmware image increases in size due to functional iterations, there is no need to replace the BMC-related hardware or redesign the motherboard. The large-capacity image can simply be written to the target partition of the external storage through the upgrade process. Through the universality and scalability of the storage medium, the firmware capacity can be flexibly adapted, avoiding the motherboard redesign problem caused by the fixed Flash capacity in traditional solutions.

[0045] In summary, this method addresses the shortcomings of traditional BMC-dedicated Flash solutions in terms of cost, design complexity, and capacity expansion by reusing host-side external memory, simplifying the hardware design process, and leveraging the capacity scalability of general-purpose storage. This improves the server's cost control capabilities, design efficiency, and firmware upgrade flexibility.

[0046] 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.

[0047] The specific application environment architecture or specific hardware architecture on which the server firmware upgrade method depends is described here.

[0048] like Figure 1 The diagram illustrates the specific hardware architecture upon which the server firmware upgrade method relies. This specific hardware architecture includes the core control module, external storage architecture, communication interfaces and channels, security mechanism support, and power and reset control.

[0049] The core control module includes the Baseboard Management Controller (BMC) and internal storage. The BMC, a dedicated microcontroller independent of the server CPU, is responsible for coordinating the entire upgrade process, including image acquisition, verification, writing, restart control, and hardware initialization. The BMC needs sufficient processing power and memory (such as built-in SRAM / DRAM) to support secure preprocessing (verification / decryption) and temporary data caching.

[0050] Internal storage includes non-volatile storage and volatile storage. Non-volatile storage (such as Internal ROM) stores the basic boot loader, used to start the BMC and initialize hardware components. Volatile storage (such as Internal SRAM / DRAM) serves as a temporary buffer, used to store the upgrade image, verification results, decrypted program code, etc.

[0051] External storage architecture includes external memory. External memory must be a non-volatile storage medium independent of the BMC's internal storage and belonging to the server host motherboard. Examples include BIOS SPI Flash connected to the BMC via the SPI bus, typically with capacities ranging from a few MB to tens of MB, suitable for storing small to medium-sized firmware images. NVMe SSDs connect via PCIe channels, offering higher read / write speeds and larger storage capacity, suitable for large firmware or scenarios requiring frequent upgrades. External memory must support partition management (such as creating target and backup partitions) and have write protection mechanisms to prevent unauthorized writes.

[0052] Communication interfaces and channels include data transmission channels and hardware control interfaces. Data transmission channels include internal high-speed serial communication channels within the server and remote management interfaces. Internal high-speed serial communication channels, such as eSPI or PCIe, are used for high-speed data transmission between the BMC and external memory, ensuring efficient image writing and reading. Remote management interfaces, such as the Intelligent Platform Management Interface (IPMI), Redfish protocol, or Secure Shell (SSH) protocol, are used by administrators to remotely upload firmware images to be upgraded, trigger the upgrade process, and monitor the upgrade status.

[0053] The hardware control interface requires the BMC to communicate with other hardware components on the server motherboard (such as CPU, memory, fan, power supply) via dedicated pins or buses to initialize these components after a reboot and ensure that the BMC operates normally.

[0054] The security mechanism supports encryption and decryption modules and verification algorithms. For the encryption and decryption modules, BMC must have a hardware or software-level encryption / decryption engine, such as Advanced Encryption Standard (AES) or Rivest-Shamir-Adleman (RSA), to support the decryption of the encrypted image to be upgraded, while ensuring data security during the upgrade process. It supports hash algorithms such as Message-Digest Algorithm 5 (MD5) and Secure Hash Algorithm 256-bit (SHA-256) to verify the integrity of the image to be upgraded, preventing tampering or damage.

[0055] Power and reset control includes a power management unit and a hardware reset interface. The power management unit ensures a stable power supply to the BMC during upgrades (especially during reboots) to prevent upgrade failures or firmware corruption due to power outages. Regarding the hardware reset interface, the BMC must be able to trigger its own hardware reset (e.g., via a watchdog timer or an external reset signal) to reboot and load the new firmware.

[0056] The embodiments of this application provide a method for upgrading server firmware. The method is described in detail below in conjunction with the execution flow of the server firmware upgrade method.

[0057] like Figure 2 As shown, the method includes the following steps:

[0058] S201. Obtain the firmware image to be upgraded from the baseboard management controller.

[0059] In some embodiments, the firmware image to be upgraded is transferred to a temporary buffer (such as dynamic random access memory DRAM) of the baseboard management controller via a remote management interface or local tools. DRAM is chosen as the temporary buffer because it has high-speed read / write characteristics, enabling it to quickly receive and temporarily store new images, avoiding speed bottlenecks caused by directly writing to external memory. It also reserves operational space for subsequent image verification, ensuring that the firmware image to be upgraded can smoothly enter the processing chain of the baseboard management controller.

[0060] Among them, remote management nodes can be such as the Redfish protocol interface, while local tools can be dedicated upgrade software.

[0061] S202. Perform security preprocessing on the firmware image to be upgraded.

[0062] The security preprocessing includes verification and decryption. This application performs dual verification on the firmware image to be upgraded, temporarily stored in DRAM. First, a first hash value of the firmware image to be upgraded is calculated. This first hash value is compared with a pre-provided second hash value. If the first hash value and the second hash value are the same, it can be confirmed that the firmware image to be upgraded has not been tampered with, damaged, or lost during transmission. Then, the firmware image to be upgraded is decrypted. To prevent unauthorized tampering or theft, the firmware image to be upgraded is encrypted. After the image verification is passed, the baseboard management controller decrypts it to convert the encrypted firmware image into an executable binary file, preparing it for subsequent writing to external storage.

[0063] S203. Write the security-preprocessed firmware image to be upgraded to the target partition of the external storage.

[0064] External storage is a non-volatile storage medium independent of the motherboard's main memory and belonging to the server host motherboard. Examples include BIOS SPI Flash (a non-volatile memory based on the Serial Peripheral Interface bus) or NVMe SSDs (non-volatile memory host controller interface standard solid-state drives). External storage is normally write-protected to prevent accidental operation.

[0065] In some embodiments, the baseboard management controller first unlocks the write protection mechanism of the external memory through the upgrade service module in the firmware, and then writes the securely pre-processed firmware image to be upgraded to the target partition of the external memory through a high-speed serial communication channel inside the server (such as Enhanced Serial Peripheral Interface eSPI or High-Speed ​​Peripheral Component Interconnect PCIe). After the writing is completed, the write protection mechanism of the external memory is re-locked to restore the secure state of the external memory and prevent the firmware image to be upgraded from being accidentally modified.

[0066] The above embodiments temporarily unlock the write protection mechanism during upgrades, satisfying the need for writing new images while minimizing the window of external storage exposure to write risks, thus preventing unauthorized modifications at the hardware access level. Relying on the server's internal high-speed serial communication channel for image transmission enables rapid firmware image writing, reducing upgrade time and ensuring the integrity of the firmware image during transmission. This prevents write interruptions or data corruption due to signal interference, ensuring the continuity of the upgrade process. The write protection mechanism is immediately re-locked after writing, ensuring that the external storage quickly returns to a safe state after the upgrade, improving the reliability of the entire firmware upgrade process.

[0067] In some embodiments, the target partition of the external storage includes a target primary partition (SLOT_A) and a target backup partition (SLOT_B). The target primary partition and the target backup partition are completely independent and functionally equivalent, both capable of storing a complete BMC firmware image. Through redundant storage and intelligent switching design, the risk of BMC failure due to upgrade failure in traditional single-partition booting is mitigated, while ensuring continuity of booting and upgrades. The target primary partition is the default boot partition.

[0068] When performing step S203 based on the above embodiment, the write protection mechanism of the external memory is first unlocked, and then the pre-processed firmware image to be upgraded is written to the target spare partition through the high-speed serial communication channel inside the server (such as eSPI or PCIe), without overwriting the firmware image already written to the target main partition. Then the write protection mechanism of the external memory is re-locked, and the boot partition pointer is jumped from the target main partition to the target spare partition.

[0069] The core purpose of the aforementioned redundant partition design is to provide dual backup boot sources for the BMC, avoiding the problem of having no usable firmware to boot from if the image is damaged or write fails during the upgrade process in the traditional single-partition scenario. By backing up the two partitions, a backup is provided for booting and upgrading.

[0070] S204. Restart the baseboard management controller and initialize the hardware components required for the baseboard management controller to run.

[0071] In some embodiments, a hardware reset of the baseboard management controller (BMC) is first triggered to restart the BMC. This hardware reset, unlike a software restart, completely clears the temporary state of the BMC. This step interrupts the current operating state of the BMC, forcing it into the boot process of the new firmware, creating conditions for loading the firmware image to be upgraded. It's equivalent to pressing the confirmation button for the upgrade process, marking the official end of the old firmware's mission.

[0072] Then, the internal storage of the baseboard management controller is activated, causing the internal storage to read the basic bootloader and execute it to initialize the hardware components required for the baseboard management controller to run.

[0073] The hardware components required for the baseboard management controller to operate include: PCIe lanes, BIOSFlash memory, main control chip, DRAM, etc.

[0074] Specifically, the baseboard management controller first activates the internal memory (Internal ROM) to determine the storage location of the basic boot loader code and reads the boot loader into the internal static random access memory (Internal SRAM) to prepare for subsequent hardware initialization. Then, it executes the basic boot loader stored in the Internal SRAM to initialize the hardware components required for the baseboard management controller to run, eliminating differences in the initial hardware state and preparing the hardware environment and storage space for subsequent loading of the firmware image.

[0075] The above embodiments can prevent the abnormal state of the old firmware from affecting the loading of the new firmware through hardware-level reset, so as to ensure that the new firmware can be executed from scratch; after hardware reset, the internal storage is activated first and the basic bootloader is read, which can ensure the stable execution of the BMC boot process.

[0076] S205. Read the firmware image to be upgraded from the target partition and load the firmware image to be upgraded into the temporary cache area to upgrade the server firmware according to the firmware image to be upgraded.

[0077] The temporary buffer can be dynamic random access memory (DRAM). DRAM has high-speed read and write characteristics and can quickly receive and temporarily store firmware images to be upgraded.

[0078] In some embodiments, after hardware initialization is complete, a dedicated bootloader for the firmware image to be upgraded is read from the target partition by the basic bootloader. The dedicated bootloader is then loaded into a temporary cache that has been initialized. The dedicated bootloader is then executed to read the firmware image to be upgraded from the target partition and load it into the temporary cache, thereby upgrading the server firmware based on the firmware image.

[0079] Among them, the dedicated boot loader (Universal Boot Loader, uboot) of the firmware image to be upgraded is adapted to the reading requirements of the firmware image to be upgraded, which can effectively reduce the error rate in the image reading process and ensure the integrity of the image data.

[0080] After hardware initialization is complete, the basic bootloader reads the u-boot of the firmware image to be upgraded from the target partition of external storage. Once verified, it is loaded into the pre-initialized DRAM. After u-boot is loaded, the Boot Loader actively relinquishes system control and no longer participates in subsequent processes. At this point, boot control of the BMC is officially transferred to the firmware image u-boot. The firmware image u-boot, having gained control, locates and reads the complete firmware image to be upgraded from the target partition of external storage, and then loads the entire firmware image into the BMC's DRAM. The high read / write speed of DRAM provides efficient support for the subsequent main firmware operation, ensuring that the main firmware, which includes critical functions such as server hardware monitoring and remote control, can be successfully invoked.

[0081] The above embodiments optimize firmware image reading through a dedicated bootloader, enabling precise location of core programs required for the upgrade, avoiding interference from irrelevant data, and improving the targeting and accuracy of the upgrade process. The dedicated bootloader, after being loaded into the initialized temporary cache, can be quickly invoked and executed. The firmware image, loaded into the temporary cache, provides low-latency data support for subsequent upgrade operations, preventing upgrade process interruptions due to data reading delays and improving overall upgrade efficiency.

[0082] In some embodiments, after the firmware image to be upgraded is loaded in the temporary cache, the program execution pointer jumps to the entry address of the firmware image to be upgraded, and then the firmware image to be upgraded is loaded according to the entry address. If the firmware image to be upgraded is loaded successfully and the baseboard management controller functions normally, then the server firmware upgrade is determined to be successful.

[0083] Once the complete BMC firmware image is loaded into DRAM, the program execution pointer (PC, the "instruction address pointer" that controls the program execution order) will jump to the entry address of the BMC firmware image. Execution of the main firmware code will then begin, enabling the baseboard management controller to have full functionality, allowing it to monitor server hardware status and respond to remote management commands. If the firmware image to be upgraded loads successfully and the BMC functions normally, the upgrade is successful. If loading fails (e.g., uboot cannot recognize the new image), the problem must be investigated regarding the writing process or the image itself.

[0084] In the above embodiments, the program execution pointer jumps directly to the entry address of the firmware image to be upgraded, avoiding deviations in the program execution path. This ensures that the baseboard management controller can accurately locate and start the new firmware, eliminating upgrade failures caused by incorrect execution paths and allowing the upgrade operation to focus on the effective operation of the target firmware. Successful firmware image loading and normal baseboard management controller function are used as dual criteria for successful upgrades. Successful firmware image loading ensures the data integrity of the new firmware, eliminating data loss or corruption during loading. Normal baseboard management controller function verifies the compatibility and reliability of the new firmware, confirming that it meets the operational requirements of the server hardware and improving the reliability of the upgrade effect.

[0085] During step S205, the firmware image to be upgraded can be read from the target spare partition. If reading the firmware image from the target spare partition fails, the boot partition pointer is redirected to the target main partition, and the written firmware image is read from the target main partition to restart the baseboard management controller. Afterward, the written firmware image is copied to the target spare partition, overwriting the firmware image to be upgraded in the target spare partition.

[0086] The firmware image written to the main partition is a stable version that has been verified through long-term operation.

[0087] If the target backup partition fails to read, the boot partition pointer is immediately switched back to the target primary partition. A verified and usable existing firmware image is read from the target primary partition. The primary partition acts as a fallback, minimizing the impact of the upgrade failure and ensuring the baseboard management controller (BMD) will not fail to boot due to an abnormal image on the target backup partition. Quickly rolling back to the primary partition and restarting the BMD after an image read failure minimizes system downtime. Based on the firmware image already written to the target primary partition, the BMD can quickly restore normal functionality after restarting, ensuring the continuity of server operations. After restarting, a usable firmware image from the target primary partition is copied to the target backup partition, overwriting the faulty image. This achieves self-healing of the target backup partition, restoring it to a redundant dual-partition architecture. This allows subsequent upgrades to continue in dual-partition mode, preventing the system from losing redundancy due to the target backup partition remaining in an abnormal state for an extended period.

[0088] In summary, this application provides a server firmware upgrade method. Through a dual-partition redundancy design, it avoids the risk of system failure due to upgrade failure; it performs image verification and decryption to ensure the integrity and authenticity of the firmware image to be upgraded; during transmission, it utilizes the server's internal high-speed serial communication channel for rapid image transfer, improving upgrade efficiency; during the writing process, it dynamically controls the write protection mechanism of the external memory, temporarily unlocking it during writing and locking it immediately upon completion, satisfying both upgrade requirements and ensuring storage security. The post-upgrade boot process clears the residual state of the old firmware through hardware reset, activates the basic bootloader based on internal storage, and loads the dedicated bootloader and the new firmware image; simultaneously, in the event of a backup partition image read failure or a boot failure, the boot partition pointer is rolled back to the target primary partition, and the function of the baseboard management controller is quickly restored based on the verified stable firmware image, achieving security, efficiency, and reliability in firmware upgrades.

[0089] This application provides a server firmware upgrade method comprising a BMC firmware startup phase and a BMC upgrade phase. The following will describe the server firmware upgrade method in stages:

[0090] like Figure 3 As shown, during the BMC firmware startup phase, when the BMC powers on or triggers a reset, the BMC chip prioritizes activating its internal memory (Internal ROM) to automatically execute code. As the first program to run after the BMC powers on, the Internal ROM determines the storage location of the basic boot loader code according to preset logic and reads this boot loader code into the BMC's internal static random access memory (Internal SRAM), preparing for subsequent hardware initialization. This step ensures that the startup process can transition from internal chip storage to external memory resources.

[0091] Next, the Boot Loader, stored in Internal SRAM, begins execution. As a preparatory program before the main application runs, the Boot Loader initializes key hardware components required for BMC operation, including PCIe channels, BIOSFlash memory, the main control chip, and DRAM. It initializes the PCIe channels to ensure data transfer between devices, initializes the BIOSFlash memory to confirm the availability of external storage, initializes the main control chip to activate the BMC core control unit, and initializes DRAM to reserve space for the subsequent bootloader. The core objective of this step is to eliminate initial state differences at the hardware level by initializing the necessary hardware, and to prepare the hardware environment and storage space for loading the firmware image later.

[0092] After hardware initialization is complete, the BootLoader will further execute the program loading task. It will read the dedicated boot loader (Universal Boot Loader, uboot) of the firmware image from a pre-specified external memory (such as BIOS SPI Flash or NVMe SSD) and load it into the initialized DRAM. After uboot is loaded, the BootLoader will actively transfer system control and no longer participate in subsequent processes. At this time, the boot control of BMC is officially transferred to the firmware image uboot. This step realizes the transition from the basic boot loader to the dedicated boot loader, providing more professional support for loading the complete BMC firmware image. As a general and feature-rich BootLoader implementation, uboot can more flexibly adapt to the BMC firmware loading requirements.

[0093] Next, u-boot, having gained control, will undertake the core task of loading the main firmware. It will locate and read the complete BMC firmware image (containing the code and configuration of the BMC main management functions) from external storage and load it completely into the BMC's DRAM. The high read and write speed of the DRAM provides efficient support for the subsequent operation of the main firmware. This step is the core loading of the BMC boot process, ensuring that the main firmware, which includes critical functions such as server hardware monitoring and remote control, can be successfully invoked.

[0094] Once the complete BMC firmware image is loaded into DRAM, the system jumps the program execution pointer (PC, the instruction address pointer that controls the program execution order) to the entry address of the BMC firmware image. At this point, the BMC officially leaves the boot loading stage and enters the main firmware execution stage. The main firmware code begins execution, and the BMC then possesses full functionality, capable of monitoring server hardware status and responding to remote management commands, marking the completion of the entire BMC boot process.

[0095] Overall, the BMC boot process, from the direction guided by the internal ROM inside the chip, to the hardware foundation built by the BootLoader, to the core firmware loaded by uboot, and finally to the operation of the main firmware, is based on the previous step. The roles of various technical components (Internal ROM, BootLoader, uboot, DRAM, etc.) are matched with each other to jointly ensure the stability and integrity of BMC boot.

[0096] like Figure 4As shown, during the BMC firmware upgrade phase, there is no need for physical contact with the server. The new BMC firmware image can be transferred to the BMC's DRAM via a remote management interface or local tools. DRAM is chosen as the temporary storage medium because it has high-speed read / write capabilities, enabling it to quickly receive and temporarily store the new image, avoiding the speed bottleneck caused by directly writing to external memory. It also reserves operational space for subsequent image verification. This step is the data foundation of the entire upgrade process, ensuring that the new image can smoothly enter the BMC's processing chain.

[0097] Next, the BMC performs dual verification on the new firmware image temporarily stored in DRAM. On one hand, it calculates the MD5 hash value of the received firmware image and compares it with the MD5 value of the firmware image to be upgraded provided by the administrator to confirm that the image has not been tampered with, damaged, or lost data during transmission, thus preventing upgrade failure due to invalid images. On the other hand, if the new image is in an encrypted format, the BMC will decrypt it after verification, converting the encrypted image into an executable binary firmware image, preparing it for subsequent writing to external storage.

[0098] Subsequently, the BMC will temporarily unlock the write protection mechanism of the external memory through the upgrade service module in the firmware, removing write permission restrictions. Then, it will completely write the decrypted new image from DRAM to the target partition of the external memory via eSPI or PCIe channel. After the write operation is completed, the BMC will immediately relock the write protection mechanism, restoring the external memory to a safe state and preventing the new image from being accidentally modified. After the new image is written, the upgrade process will actively trigger a hardware reset of the BMC, causing the BMC to enter the reboot process.

[0099] Finally, after the BMC resets, it will re-execute the previous complete boot process. First, basic initialization is completed via InternalROM, reading and executing the firmware image uboot from external storage. Then, uboot completes advanced hardware initialization, reading the newly written BMC firmware image from the target partition of external storage. After verification, it is loaded into DRAM, and finally, control is transferred to the new image, enabling the BMC to boot based on the new firmware and execute core management functions. This step is the final verification of the upgrade result. If the new image loads normally and the BMC functions normally, the upgrade is successful; if loading fails, problems with the writing process or the image itself need to be investigated.

[0100] Overall, the BMC firmware upgrade process achieves a smooth transition from old firmware to new firmware through steps of transmission, verification, writing, rebooting, and loading. Each step is deeply related to BMC's hardware architecture, technical components (such as uboot and upgrade service module), and boot process, jointly ensuring the success of the upgrade operation and the stability of BMC's subsequent operation.

[0101] like Figure 5 As shown in the embodiments of this application, a method for upgrading server firmware is also provided, the method including the following:

[0102] First, two independent partitions of identical size are created in the external storage: a target primary partition (SLOT_A) and a target backup partition (SLOT_B). Both partitions are functionally equivalent, capable of storing a complete BMC firmware image. The core purpose of this redundant partition design is to provide dual backup boot sources for the BMC: avoiding the problem of having no usable firmware to boot from if the image is corrupted or write fails during the upgrade process, as is common in traditional single-partition scenarios. The mutual backup between the two partitions provides a safety net for booting and upgrading.

[0103] Next, after the BMC powers on or resets, its internal BootROM will, according to preset rules, prioritize reading the core program required for booting from SLOT_A. First, the BootLoader code in SLOT_A is read into Internal SRAM. Then, the BootLoader completes hardware initialization, loads uboot from SLOT_A, and finally, uboot loads the complete BMC firmware image from SLOT_A into DRAM and executes it. The entire regular boot process is consistent with the previous single-partition boot logic, only explicitly designating external storage as the default partition SLOT_A to ensure the stability and compatibility of the boot process.

[0104] Next is the upgrade process. This solution's upgrade logic revolves around not affecting the default partition. After the firmware image to be upgraded is transferred to the BMC's DRAM via a remote management interface or local tools, the BMC first completes image verification and decryption. Then, the upgrade service module temporarily unlocks the write protection mechanism of the external storage, but instead of overwriting the default SLOT_A, it completely writes the new image to the spare partition SLOT_B. After writing, the write protection mechanism is immediately re-locked to prevent accidental modification of the new image. This design of writing the upgrade to the spare partition ensures that the old image in SLOT_A remains intact throughout the upgrade process. Even if the new image writing fails or has problems, the BMC can still boot normally through SLOT_A, completely eliminating the risk of bricking the device during the upgrade.

[0105] Once the new image is written to SLOT_B and verified to be correct, the BMC updates its internal boot partition pointer, switching the default boot partition from SLOT_A to SLOT_B. Subsequently, when the BMC powers on or reboots, the BootROM will read the boot program from SLOT_B first, following the updated pointer, repeating the normal boot process, and ultimately running the new firmware based on SLOT_B. This step achieves a smooth transition to the new firmware without manual intervention, ensuring the new firmware takes effect stably after the upgrade.

[0106] If, upon first booting from SLOT_B after an upgrade, several boot failures occur consecutively, the BMC will automatically revert the boot partition pointer back to the original default partition SLOT_A. It will then reset and restart the BMC. At this point, the BootROM will restart from SLOT_A, ensuring the BMC can quickly resume normal operation. More importantly, after reverting to SLOT_A, the BMC will completely copy the intact old image from SLOT_A to SLOT_B, overwriting any damaged or problematic new image in SLOT_B. This restores SLOT_B to a usable backup partition consistent with SLOT_A. This not only quickly resolves boot failures but also automatically repairs the backup partition, ensuring that subsequent boots and upgrades still have dual-partition fallback capabilities.

[0107] Overall, this dual-partition scheme retains the stability of the original process while improving the reliability and security of BMC startup and upgrade through partition redundancy and intelligent switching.

[0108] 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.

[0109] like Figure 6 As shown, embodiments of this application also provide a server firmware upgrade apparatus, the apparatus comprising:

[0110] The acquisition module 601 is used to acquire the firmware image to be upgraded from the baseboard management controller;

[0111] Preprocessing module 602 is used to perform security preprocessing on the firmware image to be upgraded. Security preprocessing includes verification and decryption.

[0112] The write module 603 is used to write the security-preprocessed firmware image to be upgraded to the target partition of the external storage; the external storage is a non-volatile storage medium that is independent of the internal storage of the baseboard management controller and belongs to the server host motherboard.

[0113] Restart module 604 is used to restart the baseboard management controller and initialize the hardware components required for the baseboard management controller to run;

[0114] The read module 605 is used to read the firmware image to be upgraded from the target partition and load the firmware image to be upgraded into a temporary cache area to upgrade the server firmware according to the firmware image to be upgraded.

[0115] As an optional implementation provided in this application, the acquisition module 601 is used to: acquire the firmware image to be upgraded through a remote management interface or local tools, and transfer the firmware image to be upgraded to a temporary cache area.

[0116] As an optional implementation provided in this application, the preprocessing module 602 is specifically used for: calculating a first hash value of the firmware image to be upgraded; comparing the first hash value with a pre-provided second hash value; and decrypting the firmware image to be upgraded if the first hash value and the second hash value are the same.

[0117] As an optional implementation provided in this application, the write module 603 is specifically used for: unlocking the write protection mechanism of the external memory; writing the securely preprocessed firmware image to be upgraded to the target partition through the high-speed serial communication channel inside the server; and relocking the write protection mechanism of the external memory.

[0118] As an optional implementation provided in this application, the restart module 604 is specifically used to: trigger the hardware reset of the baseboard management controller to restart the baseboard management controller; activate the internal storage of the baseboard management controller to read the basic bootloader; and execute the basic bootloader to initialize the hardware components required for the operation of the baseboard management controller.

[0119] As an optional implementation provided in this application, the read module 605 is specifically used for: reading a dedicated bootloader of the firmware image to be upgraded from the target partition through the basic bootloader; loading the dedicated bootloader into the initialized temporary cache area; executing the dedicated bootloader to read the firmware image to be upgraded from the target partition; and loading the firmware image to be upgraded into the temporary cache area to upgrade the server firmware according to the firmware image to be upgraded.

[0120] As an optional implementation provided in this application, the device further includes a loading module, configured to: after the firmware image to be upgraded is loaded in the temporary cache, jump the program execution pointer to the entry address of the firmware image to be upgraded; load the firmware image to be upgraded according to the entry address of the firmware image to be upgraded; if the firmware image to be upgraded is successfully loaded and the baseboard management controller functions normally, then determine that the server firmware upgrade is successful.

[0121] As an optional implementation provided in this application, the target partition includes a target primary partition and a target backup partition; the write module 603 is specifically used for: unlocking the write protection mechanism of the external storage; writing the security-preprocessed firmware image to be upgraded to the target backup partition without overwriting the firmware image already written in the target primary partition; relocking the write protection mechanism of the external storage; and jumping the boot partition pointer from the target primary partition to the target backup partition.

[0122] As an optional implementation provided in this application, the device further includes a repair module, configured to: when reading the firmware image to be upgraded from the target spare partition fails, redirect the boot partition pointer back to the target main partition; read the written firmware image from the target main partition and restart the baseboard management controller; and copy the written firmware image to the target spare partition, overwriting the firmware image to be upgraded in the target spare partition.

[0123] For a description of the features in the embodiment corresponding to the server firmware upgrade device, please refer to the relevant description in the embodiment corresponding to the server firmware upgrade method, which will not be repeated here.

[0124] like Figure 7 As shown, embodiments of this application also provide an electronic device, including a memory 701 and a processor 702. The memory 701 stores a computer program, and the processor 702 is configured to run the computer program to perform the steps in any of the above-described server firmware upgrade method embodiments.

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

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

[0127] 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 server firmware upgrade method embodiments.

[0128] 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 above-described server firmware upgrade method embodiments.

[0129] 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.

[0130] The above provides a detailed description of a server firmware upgrade method and electronic device 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 only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for upgrading server firmware, the method comprising: The method comprises the following steps: obtaining a firmware image to be upgraded of a baseboard management controller; performing security preprocessing on the firmware image to be upgraded, the security preprocessing comprising checksum calculation and decryption; writing the security preprocessed firmware image to be upgraded into a target partition of an external storage, the external storage being independent of the internal storage of the baseboard management controller and belonging to a non-volatile storage carrier of a server host motherboard; restarting the baseboard management controller and initializing hardware components required for the baseboard management controller to operate; reading the firmware image to be upgraded from the target partition and loading the firmware image to be upgraded into a temporary buffer area to upgrade server firmware according to the firmware image to be upgraded; wherein the security preprocessing on the firmware image to be upgraded comprises calculating a first hash value of the firmware image to be upgraded, comparing the first hash value with a second hash value provided in advance, and if the first hash value is identical to the second hash value, decrypting the firmware image to be upgraded to convert the encrypted firmware image to be upgraded into an executable binary file.

2. The method of claim 1, wherein, The step of obtaining the firmware image to be upgraded of the baseboard management controller comprises: obtaining the firmware image to be upgraded through a remote management interface or a local tool and transmitting the firmware image to be upgraded to the temporary buffer area.

3. The method of claim 1, wherein, The step of writing the security preprocessed firmware image to be upgraded into the target partition of the external storage comprises: unlocking a write protection mechanism of the external storage; writing the security preprocessed firmware image to be upgraded into the target partition through a high-speed serial communication channel inside the server; and relocking the write protection mechanism of the external storage.

4. The method of claim 1, wherein, The step of restarting the baseboard management controller and initializing hardware components required for the baseboard management controller to operate comprises: triggering a hardware reset of the baseboard management controller to restart the baseboard management controller; activating the internal storage of the baseboard management controller to read a basic bootloader; executing the basic bootloader to initialize the hardware components required for the baseboard management controller to operate.

5. The method of claim 4, wherein, The step of reading the firmware image to be upgraded from the target partition and loading the firmware image to be upgraded into the temporary buffer area to upgrade server firmware according to the firmware image to be upgraded comprises: reading a special bootloader of the firmware image to be upgraded from the target partition through the basic bootloader; loading the special bootloader into the initialized temporary buffer area; executing the special bootloader to read the firmware image to be upgraded from the target partition; loading the firmware image to be upgraded into the temporary buffer area to upgrade server firmware according to the firmware image to be upgraded.

6. The method of claim 1, wherein, The method further comprises: jumping a program execution pointer to an entry address of the firmware image to be upgraded when the firmware image to be upgraded is loaded into the temporary buffer area; loading the firmware image to be upgraded according to the entry address of the firmware image to be upgraded. If the to-be-upgraded firmware image is loaded successfully and the function of the baseboard management controller is normal, it is determined that the server firmware upgrade is successful.

7. The method of claim 1, wherein, The target partition includes a target primary partition and a target backup partition. The writing of the security-pretreated to-be-upgraded firmware image into the target partition of the external storage includes: Unlocking the write protection mechanism of the external storage; Writing the security-pretreated to-be-upgraded firmware image into the target backup partition without covering the written firmware image in the target primary partition; Re-locking the write protection mechanism of the external storage; Jumping the boot partition pointer from the target primary partition to the target backup partition.

8. The method of claim 7, wherein, The method further includes: When the reading of the to-be-upgraded firmware image from the target backup partition fails, pointing the boot partition pointer back to the target primary partition; Reading the written firmware image from the target primary partition and restarting the baseboard management controller; Copying the written firmware image to the target backup partition to cover the to-be-upgraded firmware image in the target backup partition.

9. An electronic device, comprising: It includes: A memory for storing a computer program; A processor for implementing the steps of the server firmware upgrade method according to any one of claims 1 to 8 when executing the computer program.

Images