Updating method for baseboard management controller and electronic device

Abstract

The application provides an updating method for a substrate management controller and an electronic device, which can be applied to the technical field of computers. The method comprises the following steps: initializing an updating task, writing a state identifier of the updating task into a nonvolatile memory, the updating task being used for updating a version of the substrate management controller, the updating task comprising a plurality of updating stages arranged in an execution order, and the state identifier indicating a to-be-updated stage in the plurality of updating stages; in the execution process of the to-be-updated stage, acquiring the state identifier from the nonvolatile memory in the case that a device loaded with the substrate management controller is powered off and restarted; according to the to-be-updated stage indicated by the state identifier, performing a recovery operation for the to-be-updated stage, updating the state identifier in the case that the execution of the to-be-updated stage is completed, and executing a next to-be-updated stage in the execution order until the updating task is completed, and updating the state identifier to a completed state.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a method for updating a baseboard management controller and an electronic device. Background Technology

[0002] The Baseboard Management Controller (BMC) is a dedicated embedded device on the server motherboard. It is responsible for functions such as monitoring server hardware status, fault diagnosis, and remote management. It is a key component to ensure the reliability and maintainability of the server.

[0003] Currently, in server BMC firmware upgrades and daily operation, to ensure the normal operation of the server, the BMC storage medium needs to be divided into a primary partition and a backup partition. When updating the BMC version, operations are only performed on the backup partition to avoid interference with the operation on the primary partition. However, dual-partition storage not only increases update resources, but also reduces update efficiency and intelligence if a power outage occurs during the update process and power is restored, requiring the update process to be restarted from the primary partition according to instructions. Summary of the Invention

[0004] In view of the above problems, the present invention provides a method and electronic device for updating a baseboard management controller to improve storage resource utilization, upgrade efficiency and intelligence.

[0005] One aspect of the present invention provides an update method for a substrate management controller, comprising: initializing an update task; writing a status identifier of the update task to a non-volatile memory; the update task being used to update a version of the substrate management controller; the update task including multiple update stages arranged in execution order; the status identifier indicating a pending update stage among the multiple update stages; during the execution of a pending update stage, if the device carrying the substrate management controller is powered off and restarted, retrieving the status identifier from the non-volatile memory; performing a recovery operation for the pending update stage according to the pending update stage indicated by the status identifier; and, upon completion of the pending update stage, updating the status identifier and executing the next pending update stage in execution order until the update task is completed, and updating the status identifier to a completed state.

[0006] Another aspect of the present invention provides an electronic device, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the above-described method.

[0007] According to an embodiment of the present invention, by initializing the update task, the status identifier of the update task is written to a non-volatile memory. During the execution of the update phase, in response to a power outage and restart of the device, the status identifier is retrieved from the non-volatile memory. Based on the update phase indicated by the status identifier, a corresponding recovery operation is performed, and the next update phase is executed according to the execution order until the update task is completed, at which point the status identifier is updated to a completed state. Because non-volatile memory is used in the update process of the baseboard management controller, the partitioned storage of update resources caused by using traditional storage media is avoided, improving the utilization rate of update resources. Furthermore, by storing the status identifier in non-volatile memory, in the event of a power outage and restart of the device, the update phase in which the update task was interrupted can be determined based on the identifier, and the update can continue from that update phase without restarting the update process, thus improving the efficiency and intelligence of the update. Attached Figure Description

[0008] The above-described features, other objects, and advantages of the present invention will become clearer from the following description of embodiments of the invention with reference to the accompanying drawings, in which:

[0009] Figure 1 An application scenario diagram of an update method for a baseboard management controller according to an embodiment of the present invention is shown.

[0010] Figure 2 A flowchart of an update method for a substrate management controller according to an embodiment of the present invention is shown.

[0011] Figure 3 A flowchart of the data writing stage according to an embodiment of the present invention is shown.

[0012] Figure 4 A flowchart of an update method for a substrate management controller according to another embodiment of the present invention is shown.

[0013] Figure 5 A structural block diagram of an update apparatus for a substrate management controller according to an embodiment of the present invention is shown.

[0014] Figure 6 A block diagram of an electronic device suitable for implementing an update method for a substrate management controller according to an embodiment of the present invention is shown. Detailed Implementation

[0015] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the invention. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the invention for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0016] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0017] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0018] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0019] As an offline management unit independent of the Central Processing Unit (CPU) and operating system, the Server Hardware Management System (BMC) is responsible for server hardware status monitoring, fault diagnosis, and remote management, and is a key component for ensuring server reliability and maintainability. During server BMC firmware upgrades and daily operation, traditional storage media (such as electrically erasable programmable read-only memory (EEPROM) and flash memory) face the risk of configuration loss in extreme scenarios, such as data bit flipping caused by strong electromagnetic interference, damage to storage units caused by hardware impacts, and data loss due to write interruptions during power outages.

[0020] The BMC storage medium (such as Serial Peripheral Interface NOR Flash Memory, SPI NOR Flash) is divided into two symmetrical partitions: an active partition and an inactive partition. Each partition contains a complete kernel, device tree, and root file system. Updates only operate on the inactive partition to avoid interference with the active partition. In the event of a power outage during the update process, the system will boot from the other active partition after power is restored, preventing the server from failing to operate normally.

[0021] While the current solution avoids the risk of server downtime due to power outages during the update process, it has several drawbacks: First, it requires two symmetrical partitions to store the complete kernel, device tree, and root file system, doubling the storage space requirement and potentially creating a bottleneck for small BMC devices with limited storage resources. Second, the system requires additional mechanisms to manage partition states (such as version validity management and boot record management mechanisms), ensure the atomicity and consistency of update and switching operations, and may also involve address remapping requirements, significantly increasing the complexity and cost of software design, implementation, and maintenance. Furthermore, its protection scope is limited, making it difficult to cope with firmware image corruption or global physical damage to the storage medium. Third, frequent write operations to the dual partitions will accelerate the wear and tear of the Flash storage medium, shortening its lifespan.

[0022] In view of this, and in response to the problems of high storage resource consumption, complex software design, limited protection scope, rapid wear and tear of storage media, and low update efficiency in the current BMC update process, this invention uses non-volatile memory (NVM) to replace traditional storage such as Flash and EEPROM, and overcomes the shortcomings of traditional storage (such as Flash and EEPROM) in terms of speed, lifespan, and power consumption, thus solving the problems of high storage resource consumption, complex software design, limited protection scope, rapid wear and tear of storage media, and low update efficiency.

[0023] Figure 1 An application scenario diagram of an update method for a baseboard management controller according to an embodiment of the present invention is shown.

[0024] like Figure 1 As shown, application scenario 100 according to this embodiment may include server 101, which may include BMC 1011 and non-volatile memory 1012 connected to BMC 1011.

[0025] When an update task is triggered, BMC1011 can write the status flag of the update task to non-volatile memory 1012 through the interface. During the execution of the pending update stage, if the server is powered off and restarted, the status flag can be retrieved from non-volatile memory 1012. According to the pending update stage indicated by the status flag, the corresponding update operation can continue to be executed to complete the version update of BMC1011. When the update is completed, the status flag is updated to the completed state.

[0026] It should be understood that Figure 1 The number of servers 101, BMC 1011, and non-volatile memory 1012 shown is merely illustrative. Depending on implementation requirements, any number of servers 101, BMC 1011, and non-volatile memory 1012 may be used.

[0027] The following will be based on Figure 1 The described scene, through Figures 2-4 The update method for a baseboard management controller according to an embodiment of the present invention will be described in detail.

[0028] Figure 2 A flowchart of an update method for a substrate management controller according to an embodiment of the present invention is shown.

[0029] like Figure 2 As shown, the update method for the baseboard management controller in this embodiment may include operations S210 to S230.

[0030] In operation S210, the update task is initialized and the status flag of the update task is written to the non-volatile memory. The update task is used to update the version of the board management controller. The update task includes multiple update stages arranged in execution order. The status flag indicates the stage to be updated among the multiple update stages.

[0031] During operation S220, in the execution of the pending update phase, if the device carrying the board management controller is powered off and restarted, the status flag is retrieved from the non-volatile memory.

[0032] In operation S230, according to the pending update stage indicated by the status flag, a recovery operation is performed for the pending update stage. If the pending update stage is completed, the status flag is updated and the next pending update stage is executed in the execution order until the update task is completed, and the status flag is updated to the completed state.

[0033] In some embodiments, the non-volatile memory can be resistive random access memory (ReRAM). Compared to Flash memory, ReRAM has faster read and write speeds; ReRAM can be written directly via electrical signals without separate erasure, achieving byte-level addressing, while Flash memory requires erasure in blocks before writing, using block addressing and preventing direct modification of individual bytes. ReRAM also has a longer lifespan than Flash memory. The following description uses ReRAM in non-volatile memory as an example to illustrate the update method for a substrate management controller according to an embodiment of the present invention.

[0034] An update task can be used to update the version of the BMC, such as upgrading or downgrading the BMC version. An update task can include multiple update stages, such as a data write stage (writing version update data to ReRAM), a verification stage (validating the version update data written to ReRAM), and an information write stage (writing metadata of the update task to ReRAM). Upon completion of each update stage and entry into the next update stage, the status flag can be updated. For example, upon entering the data write stage, the status flag is updated to data write status; upon entering the verification stage, the status flag is updated to verification status; and upon entering the information write stage, the status flag is updated to information write status.

[0035] During the execution of the pending update phase, if the device carrying the BMC is powered off and restarted, the status flag can be obtained from ReRAM, and a recovery operation for the pending update phase can be performed according to the pending update phase indicated by the status flag to complete the pending update phase. The next pending update phase is then executed in the execution order until all pending update phases of the update task are completed, and the status flag is updated to the completed state.

[0036] In some embodiments, if the status identifier obtained after the device is powered off and restarted is in the data write state, it indicates that the data write phase is not complete. In this case, the version update data needs to be rewritten to ReRAM. If the status identifier obtained after the device is powered off and restarted is in the verification state, it indicates that the verification phase is not complete. In this case, the version data written to ReRAM needs to be verified again, without performing the operation of rewriting the version update data to ReRAM.

[0037] According to an embodiment of the present invention, by initializing the update task, the status identifier of the update task is written to ReRAM. During the execution of the update phase, in response to a power outage and restart of the device, the status identifier is retrieved from ReRAM. Based on the update phase indicated by the status identifier, a corresponding recovery operation is performed, and the next update phase is executed according to the execution order until the update task is completed, at which point the status identifier is updated to a completed state. Because ReRAM is used during the update process of the baseboard management controller, the partitioned storage of update resources caused by using traditional storage media is avoided, improving the utilization rate of update resources. Furthermore, by storing the status identifier in ReRAM, in the event of a power outage and restart of the device, the update phase in which the update task was interrupted can be determined based on the identifier, and the update can continue from that phase without restarting the update process, thus improving the efficiency and intelligence of the update.

[0038] In some embodiments, the initialization process for an update task may include the following operations: packaging a status identifier, the target version information of the update task, and a baseline check value obtained based on the version update data to be written to ReRAM into a first data structure in a predetermined format; and writing the first data structure into ReRAM through an integrated circuit bus interface.

[0039] In some embodiments, during the initialization process of the BMC update, after the update task is triggered, the BMC interacts with commands via the Inter-Integrated Circuit (I²C) interface to perform a write operation to a pre-defined dedicated BMC version update data storage area in the ReRAM. This write operation combines status identifiers (e.g., data write status) with the target firmware version number for this upgrade, benchmark verification values ​​(e.g., Cyclic Redundancy Check (CRC) value, Secure Hash Algorithm (SHA) verification value), and other information into a fixed-format, fixed-length data structure, which is then written to the ReRAM. This structured write method is concise, has no redundant steps, and the write operation is completed once the data transmission is finished. On the other hand, since the ReRAM is a non-volatile memory, its data storage relies on the resistance changes of the resistive switching layer, such as switching between high-resistance state (HRS) and low-resistance state (LRS), rather than the charge storage of traditional memory. All data written to ReRAM is directly solidified into resistors at the end of the write cycle, requiring no additional save or refresh operations. This ensures data is stably saved immediately after being written. Therefore, this initialization operation guarantees that the data structure is saved immediately after being written. If an unexpected power outage occurs during the execution of the update phase, the BMC, upon power-on startup, can determine the existence of an interrupted, incomplete update phase by reading the status flags in ReRAM. It can then initiate the recovery process from that phase, rather than canceling the update task and continuing with a non-upgraded partition for normal boot.

[0040] According to embodiments of the present invention, by pre-storing update status identifiers, a starting point for status traceability is provided for the entire process, enabling intelligent recovery after power failure. By pre-calculating and storing benchmark verification values, a unique and objective comparison basis is provided for subsequent verification stages, fundamentally ensuring the accuracy of version update data. By recording target version information, the accuracy and auditability of the update process are ensured. By packaging these data into a single structure and writing them into ReRAM, inconsistencies in data during power failure are avoided, further enhancing the robustness of the solution.

[0041] Figure 3 A flowchart of the data writing stage according to an embodiment of the present invention is shown.

[0042] like Figure 3As shown, once initialization is complete, the data writing phase can begin. The data writing phase may include the BMC control domain 301, the ReRAM operation domain 302, and the status monitoring domain 303.

[0043] In some embodiments, during the data writing phase, the recovery operation performed may be as follows: when the update phase is the data writing phase, the firmware data block is parsed to obtain the data bytes to be written and the target storage address for storing the data bytes; the data bytes are mapped to the storage unit indicated by the target storage address, the storage unit including multiple ReRAM units; and a voltage is applied to the ReRAM unit according to the target resistance required to store the data bytes and the current resistance of the ReRAM unit to achieve in-situ writing of the data bytes.

[0044] In some embodiments, version update data can be divided into multiple fixed-length firmware data blocks. During the data writing phase, in the BMC control domain 301, the BMC can read the firmware data blocks via the I²C interface, that is, read firmware data blocks from the firmware data in units of data blocks, and parse out key configuration parameters, such as the firmware version number, the firmware generation date, and some BMC configuration information such as heat dissipation configuration, sensor configuration, etc. It may also include the data bytes to be written, and the target storage address for storing the data bytes. The target storage address can be the logical physical address used by the BMC to locate the hardware device and storage area receiving the data when interacting with ReRAM. This target storage address can essentially be a communication addressing identifier, designed based on underlying bus protocols such as I²C and Intelligent Platform Management Bus (IPMB), to clearly identify the device to which the current data is to be sent, and the area of ​​the device, in a hardware environment where multiple devices coexist, thus avoiding data transmission chaos.

[0045] In some embodiments, data bytes can be mapped to memory cells indicated by a target memory address, and these memory cells may include multiple ReRAM cells. Because ReRAM has byte-addressing capabilities, it can directly read or write individual bytes within a memory cell, unlike traditional storage methods that operate on the entire data block. When in-situ replacement of a single byte in ReRAM is required, the BMC can apply an appropriate voltage signal to the corresponding ReRAM cell based on the target memory address. For example, a voltage can be applied to the ReRAM cell based on the target resistance required to store the data byte and the current resistance of the ReRAM cell to achieve in-situ writing of the data byte.

[0046] In some embodiments, the ReRAM cell may include a first electrode, a second electrode, and a resistive switching layer spaced apart from the first electrode and the second electrode; the process of applying a voltage to the ReRAM cell according to the target resistance required to store the data byte and the current resistance of the ReRAM cell to achieve in-situ writing of the data byte may include the following operations: when the target resistance is greater than the current resistance, applying a first voltage to the ReRAM cell to disconnect the conductive channel from the first electrode to the second electrode; when the target resistance is less than or equal to the current resistance, applying a second voltage to the ReRAM cell to turn on the conductive channel to achieve in-situ writing of the data byte.

[0047] In some embodiments, the ReRAM operation field 302 can determine the type of write operation based on a comparison between the target resistance and the current resistance, and apply a voltage accordingly to complete the in-situ writing of the byte. For example, if the target resistance is greater than the current resistance (e.g., the target resistance is HRS and the current resistance is LRS), i.e., writing the number 0, a first voltage (e.g., a RESET voltage less than 0V) is applied to dissolve and disconnect the conductive path from the first electrode to the second electrode. If the target resistance is less than or equal to the current resistance (e.g., the target resistance is LRS and the current resistance is HRS), i.e., writing the number 1, a second voltage (e.g., a SET voltage greater than 0V) is applied to allow the resistive switching layer to form a conductive path.

[0048] In this way, the resistance of the ReRAM cell can be changed directly in-situ to update and replace data. Therefore, utilizing this characteristic of ReRAM, the parsed version update data can be written directly to the target memory address more efficiently and securely. Furthermore, unlike operating the Flash memory of a BMC device, the BMC does not need to perform a block erase operation first; it can directly overwrite specified bytes or blocks of ReRAM, further improving firmware upgrade efficiency. All data written to ReRAM is immediately stored non-volatilely at the end of its write cycle, possessing real-time persistence characteristics. A write cycle refers to the duration required for the BMC to write a set of target data (e.g., a single byte, multiple consecutive bytes, or a data block) to ReRAM. For the same type of ReRAM, the write cycle time for a single byte or a fixed-length data block can be constant. This in-situ write mechanism ensures that even if an unexpected power outage occurs while writing a specific data block, only the currently being written block will be corrupted, without affecting other successfully written data blocks or the entire memory partition, thus strictly limiting the potential data corruption caused by a single power outage to a minimum.

[0049] According to embodiments of the present invention, by implementing byte-level in-situ writing, time-consuming erase operations and block data migration are eliminated, enabling direct and rapid overwriting of the target byte and shortening the update time. Furthermore, redundant dual partitions can be eliminated from the need for secure updates; reliable updates can be completed within a single storage partition, saving storage space. Moreover, wear is evenly distributed across each byte, extending the lifespan of the ReRAM and improving update reliability.

[0050] Continue to refer to Figure 3 Once the data bytes have been written in place, the resistance of the ReRAM cell can be verified using status monitoring 303; and if the resistance is verified, the storage status of the storage cell can be verified.

[0051] In some embodiments, verifying the resistor can involve verifying whether the resistor is an HRS or LRS resistor. Resistors can be classified as HRS or LRS. HRS corresponds to logic 0, and the resistance is in the high range (MΩ to GΩ level). At this time, the conductivity of the memory cell is weak, and the current is extremely small. LRS corresponds to logic 1, and the resistance value is in the low range (kΩ to MΩ level). At this time, the memory cell forms a conductive channel, and the current is relatively large.

[0052] Verification of memory cells can be performed to determine whether they are functioning normally or abnormally. Memory cell states can be categorized as normal or abnormal. A normal state indicates that the cell responds to voltage signals, switches stably between HRS and LRS, has resistance values ​​within the corresponding range, and exhibits no physical damage (e.g., intact resistive switching layer, normal electrode contact). An abnormal state indicates that the memory cell has malfunctioned, fails to respond to voltage signals (e.g., remains at HRS after applying a SET voltage), has resistance values ​​drifting outside the normal range, or exhibits physical damage (e.g., resistive switching layer breakdown, permanent blockage of conductive channels, etc.).

[0053] In some embodiments, the process of verifying the resistance of a ReRAM cell may include the following operations: applying a first test voltage to the ReRAM cell, the first test voltage not changing the open or closed state of the conductive channel; and verifying the resistance of the ReRAM cell based on a comparison between the first test resistance of the ReRAM cell and a target resistance.

[0054] In some embodiments, the resistor directly corresponds to binary data 0 or 1. The purpose of BMC verification is to confirm that the resistor of the ReRAM memory cell has been accurately switched to the state corresponding to the target resistor (i.e., HRS or LRS), ensuring that the data has been written normally. The process is as follows:

[0055] When the SET or RESET voltage is applied to the ReRAM operation field (after writing version update data), the BMC sends a read command to the ReRAM via the I²C interface, which includes the address of the target storage unit (such as the address of the 8 storage units corresponding to the bytes in the firmware partition) and specifies the object to be verified for writing.

[0056] After receiving a read command, ReRAM applies a first test voltage to the ReRAM cell of the target memory cell. The first test voltage can be a low-amplitude read voltage (the voltage value is much lower than the SET and RESET operation voltages, such as 0.5V, to ensure that the current resistance is not changed and the open and closed state of the conductive channel is not changed).

[0057] The resistance value of the storage cell determines the magnitude of the current flowing through it (using Ohm's law: I=U / R). ReRAM detects the current signal through a built-in current sensor and converts it into resistance value data, which is then fed back to the BMC.

[0058] The BMC presets resistance thresholds for HRS and LRS (e.g., HRS ≥ 1MΩ, LRS ≤ 100kΩ), and compares the feedback test resistance value with the resistance threshold: if the test resistance value is ≥ the resistance threshold of HRS, it is determined to be HRS, corresponding to logic 0; if the test resistance value is ≤ the resistance threshold of LRS, it is determined to be LRS, corresponding to logic 1.

[0059] Compare the judgment result with the target resistance of the data being written (e.g., if 1 is written, the target resistance is LRS). If the judgment result matches the target resistance, the resistance verification is successful and the data writing is valid. If the judgment result does not match the target resistance, the verification fails and the BMC triggers a retry mechanism (e.g., reapplying the SET voltage or RESET voltage).

[0060] In some embodiments, the process of verifying the storage state of a memory cell may include the following operations: applying a second test voltage to the ReRAM cell and obtaining a resistance verification result based on a comparison between a second test resistance of the ReRAM cell under the second test voltage and a target resistance, wherein the second test voltage is used to switch the open or closed state of the conductive channel; applying a critical voltage to the ReRAM cell and detecting the resistance and current of the ReRAM cell under the critical voltage, wherein the critical voltage includes at least one of a critical effective voltage of a first voltage and a critical effective voltage of a second voltage; and verifying the storage state of the memory cell based on the resistance verification result and the resistance and current under the critical voltage.

[0061] In some embodiments, the core of BMC's verification of the storage unit status is to confirm whether the hardware is working properly, that is, to verify whether the unit can stably respond to operations and is free from physical damage. The process is as follows:

[0062] Multi-round state switching tests can be performed. The BMC sends repeated switching commands to the target cell (e.g., first apply a SET voltage to the LRS, then apply a Reset voltage to the HRS, repeating 2-3 times). After each round of switching, the switching accuracy is checked through the resistance verification process described above, and the response time and resistance value fluctuation range are recorded. For example, a second test voltage is applied to the ReRAM cell, and the resistance verification result is obtained based on the comparison between the second test resistance of the ReRAM cell under the second test voltage and the target resistance. The second test voltage is used to switch the open or closed state of the conductive channel.

[0063] Boundary condition verification can be performed, controlling the application of critical voltages to the ReRAM (such as the minimum effective voltage of the SET voltage and the maximum safe voltage of the RESET voltage) to detect whether the unit can switch normally under boundary conditions; at the same time, abnormal signals of resistance and current are monitored through the I²C interface. If there is no current feedback, the current is far beyond the normal range, or the resistance value fluctuates beyond the limit, it is determined to be a hardware failure or performance instability.

[0064] Based on multiple rounds of state switching tests and boundary condition verification, a comprehensive judgment can be made. If the resistor verification of multiple rounds of switching is accurate, the boundary condition response is normal, and there are no abnormal signals, the memory cell is judged to be normal (usable). If the resistor verification of multiple rounds of switching is inaccurate, the boundary condition response is abnormal, or there is at least one of the abnormal signals, it is judged to be faulty (unusable). The BMC will mark the address of the faulty memory cell and avoid or enable the backup area during subsequent writes.

[0065] According to embodiments of the present invention, by verifying the resistor and memory cell status, the validity of data writing can be ensured. ReRAM uses binary numbers corresponding to resistors (HRS=0, LRS=1). Resistor verification can confirm whether the write operation successfully switched the cell to the target resistor, avoiding data errors caused by sending commands but the resistance not changing. Hardware faults in the memory cell can be investigated. Memory cell status verification targets the physical layer and can detect whether the cell is damaged (such as failure of the resistive switching layer, inability to conduct or disconnection of conductive channels), preventing faulty cells from affecting the integrity of the overall upgrade data. It can prepare for subsequent operations. If verification fails, a retry (such as reapplying voltage) or an abnormal update process can be triggered, ensuring the safety and stability of the BMC upgrade process.

[0066] In some embodiments, when all version data has been written to ReRAM, a verification phase can be initiated to verify the version update data written to ReRAM. Specifically, the operations in this verification phase may include: invoking the hardware verification engine integrated within the baseboard management controller; using the hardware verification engine, reading the version update data written to ReRAM via direct memory access; determining an update verification value based on the version update data written to ReRAM; and verifying the version update data written to ReRAM based on the update verification value and the baseline verification value.

[0067] In some embodiments, the verification process can be led by the BMC's recovery firmware. It efficiently reads the version update data written to ReRAM using Direct Memory Access (DMA) by calling the hardware verification engine (such as CRC or SHA) integrated within the BMC device, and calculates the checksum of the version update data in real time to obtain the update checksum. Subsequently, this calculated update checksum is compared with the baseline checksum pre-stored in the first data structure and stored in ReRAM during the initialization phase. Only when the baseline checksum and update checksum completely match, confirming that all version update data is complete and error-free, is the write operation considered successful, paving the way for the next version switch. If the baseline checksum and update checksum do not completely match or do not match at all, an exception handling process is triggered, the version switch is aborted, and recovery is attempted.

[0068] In some embodiments, the verification process can also confirm the accuracy of data block writing by comparing the resistance verification results of each data block (obtained based on the resistance verification structure of multiple storage units) with preset standard states (such as the HRS / LRS sequence corresponding to the original binary data of the version update data). On the other hand, the stability of data block storage can also be judged by combining data such as resistance value fluctuation range and response time. Finally, based on the verification results of all data blocks, the integrity of the entire version update data is verified to ensure that the firmware used for the upgrade is not damaged due to write errors or storage unit abnormalities.

[0069] According to embodiments of the present invention, the verification operation during the verification phase can ensure that the data written to ReRAM is complete and correct, thereby improving the accuracy and reliability of the update task.

[0070] In some embodiments, if the verification in the verification phase passes, an information writing phase can be executed to update the metadata of the task and write it to ReRAM. The metadata is used to guide the baseboard management controller to load the updated version when the baseboard management controller is started.

[0071] In some embodiments, the following operations may be performed during the information writing phase: when the update phase is the information writing phase, a second data structure for interaction between the baseboard management controller and the ReRAM is constructed based on metadata, the metadata including at least one of the following: update data validity identifier, benchmark check value, timestamp of update task, update status of update task, pointer to the version updated by update task, reserved field of update task, and capacity of the version updated by update task; the second data structure is written to the ReRAM through an atomic write operation.

[0072] In some embodiments, the BMC may contain a second data structure that interacts with the ReRAM. This second data structure can be used to record metadata of the update task, such as update data validity identifier, baseline check value, sum of baseline check values, timestamp of update task, update status of update task, pointer to the version updated by update task, reserved fields of update task, and capacity, reserved fields, status identifier of the version updated by update task, etc.

[0073] The update data validity identifier (such as the magic number identifier) ​​can be a predefined fixed binary sequence (or characteristic string). By embedding the update data validity identifier at the beginning of the second data structure, when the BMC reads data, it checks the identifier to confirm that the currently read data block is valid and that the data block has not been misaligned or truncated, and writes it to ReRAM to avoid data parsing errors caused by address offsets.

[0074] The sum of the baseline check values ​​can refer to a fixed-length value calculated using the CRC algorithm on the complete binary version update data of the updated version.

[0075] The pointer to the version updated by the update task can be a binary flag (e.g., 0 for the first partition, 1 for the second partition, used to instruct the BMC to select the version in the partition pointed to by the pointer for startup). In some embodiments, since ReRAM is used, partitioning is not required, so the pointer to the version updated by the update task may not need to be set.

[0076] Reserved fields only reserve a portion of the write space, and the content of the parameters passed by the second data structure can be supplemented as needed.

[0077] The second data structure obtained from the above operations can be written into the dedicated metadata area of ​​ReRAM through a single indivisible atomic write operation.

[0078] An indivisible atomic write operation refers to a write operation to the ReRAM metadata area that either succeeds completely or fails completely, without partial writes or intermediate states. This atomic write operation ensures that the pointer update is completed instantaneously, without any intermediate states of partial writes. This pointer switching behavior is logically defined as the final sign that the entire update task has successfully completed, and it explicitly specifies the firmware version to be loaded at the next boot.

[0079] According to an embodiment of the present invention, through atomic write operations, the system has a single, clear source of version status under any circumstances (including the immediate power failure that follows). In the event of an unexpected power failure or other failure, after the system restarts, it only needs to read this fixed metadata area to clearly know which firmware partition should be loaded. This avoids the contradictory state that may occur in the dual-partition scheme, where both partitions believe that they are valid versions. This avoids the version status confusion or update failure problems that may be caused by power failure in dual partitions or other complex storage structures.

[0080] In some embodiments, the present invention can combine intelligent algorithms to predict electrical risks and back up critical data before power failure, or extend to upgrade protection scenarios for other server components (such as BIOS). It can also study the redundancy design of multiple ReRAM cells to further enhance data reliability and explore the application potential of the above update method in a wider range of hardware management fields.

[0081] For example, unstable indicators of the equipment, such as voltage ripple, current, and capacitor health, can be monitored in real time. This data can be input into an intelligent risk prediction model. The intelligent risk prediction model can determine the power outage risk value based on the relationship between the power supply voltage drop rate, ripple coefficient, volatility, capacitor health, and their respective predetermined thresholds. If the power outage risk value exceeds the predetermined power outage risk value, the currently executing update task will be suspended. The update task data will be atomically backed up to a dedicated non-volatile storage area.

[0082] According to embodiments of the present invention, by predicting power risks and backing up critical data before a power outage, data structure damage caused by power outages during write operations can be avoided, ensuring data integrity. At the same time, recovery time can be shortened, recovery complexity reduced, and update efficiency and reliability improved.

[0083] Figure 4 A flowchart of an update method for a substrate management controller according to another embodiment of the present invention is shown.

[0084] like Figure 4 As shown, the update method of this embodiment may include operations S401 to S414.

[0085] When operating S401, the BMC update task is triggered.

[0086] In operation S402, the status identifier and target version information are written to ReRAM.

[0087] When operating S403, the data writing phase begins.

[0088] In operation S404, determine whether a power outage has occurred. If a power outage has occurred, execute operation S405; otherwise, execute operation S409.

[0089] When operating S405, restart.

[0090] In operation S406, the status flag is read from ReRAM.

[0091] During operation S407, the status indicator indicates that the data is being written.

[0092] During operation S408, the recovery process enters the data writing stage and rewrites the version update data, which means that the process starts from operation S404.

[0093] During operation S409, ensure that all version update data is written to ReRAM.

[0094] When operating S410, the verification phase begins.

[0095] In operation S411, determine whether the verification passes. If the verification fails, execute operation S412; if the verification passes, execute operation S413.

[0096] During operation of S412, an exception handling process is triggered, the update process is aborted, and an attempt is made to recover.

[0097] When operating S413, the information writing stage begins.

[0098] After operating S414 and completing the upgrade, update the status indicator to "completed".

[0099] This invention employs ReRAM instead of traditional storage media. During initialization, the status identifier and target version information are written to a dedicated ReRAM area via the I²C interface. The ReRAM byte addressing feature enables in-situ overwrite of version update data (without block erasure). Hardware verification engine (CRC / SHA) and DMA are used to complete the integrity verification of the new firmware. The current valid version pointer in the metadata area of ​​the ReRAM is updated through atomic write operations to clarify the boot version. The invention also covers the complete logic of triggering the recovery process by reading the ReRAM status after power failure.

[0100] This invention, by using ReRAM to replace traditional storage media, employs a phased approach in BMC upgrades: writing to the first data structure, updating data in byte-level in-situ, verifying data integrity with hardware, and writing to the second data structure. This approach reduces storage resource consumption, simplifies software design and maintenance costs, improves security by limiting the scope of data corruption during power outages and covering more fault scenarios, and reduces storage media wear and extends its lifespan by eliminating the need for block erase operations. This significantly addresses the pain points of existing upgrade solutions.

[0101] Based on the above-described updating method for a substrate management controller, the present invention also provides an updating apparatus for a substrate management controller. The following will be combined with... Figure 5 The device is described in detail.

[0102] Figure 5 A structural block diagram of an update apparatus for a substrate management controller according to an embodiment of the present invention is shown.

[0103] like Figure 5 As shown, the update device 500 for the substrate management controller in this embodiment includes a first writing module 510, an acquisition module 520, and an update module 530.

[0104] The first writing module 510 is used to initialize the update task and write the status identifier of the update task to the non-volatile memory. The update task is used to update the version of the baseboard management controller. The update task includes multiple update stages arranged in execution order. The status identifier indicates the stage to be updated among the multiple update stages.

[0105] The acquisition module 520 is used to acquire a status identifier from a non-volatile memory during the execution of the update phase, in the event that the device carrying the baseboard management controller is powered off and restarted.

[0106] The update module 530 is used to perform a recovery operation for the stage to be updated according to the stage to be updated indicated by the status identifier, and update the status identifier when the stage to be updated is completed, and execute the next stage to be updated in the execution order until the update task is completed, and update the status identifier to the completed state.

[0107] In some embodiments, the update module 530 may include a parsing unit, a mapping unit, and a first application unit.

[0108] The parsing unit is used to parse firmware data blocks when the update phase is a data writing phase, to obtain the data bytes to be written and the target storage address for storing the data bytes.

[0109] A mapping unit is used to map data bytes to a storage unit indicated by a target storage address. The storage unit includes multiple non-volatile memory units.

[0110] The first application unit is used to apply voltage to the non-volatile memory cell according to the target resistance required to store the data byte and the current resistance of the non-volatile memory cell, so as to realize the in-situ writing of the data byte.

[0111] In some embodiments, the first application unit may include a first application subunit and a second application subunit.

[0112] The first application subunit is configured to apply a first voltage to a non-volatile memory cell when the target resistance is greater than the current resistance, thereby disconnecting the conductive path from the first electrode to the second electrode.

[0113] The second application subunit is used to apply a second voltage to the non-volatile memory cell when the target resistance is less than or equal to the current resistance, so as to conduct the conductive channel and realize the in-situ writing of data bytes.

[0114] In some embodiments, the updating device for the substrate management controller may further include a first verification module and a second verification module.

[0115] The first verification module is used to verify the resistance of the non-volatile memory cell after the in-situ writing of data bytes is completed.

[0116] The second verification module is used to verify the storage status of the storage cell if the resistor passes the verification.

[0117] In some embodiments, the first verification module may include a second application unit and a first verification unit.

[0118] The second application unit is used to apply a first test voltage to the non-volatile memory cell, wherein the first test voltage does not change the open or closed state of the conductive channel.

[0119] The first verification unit is used to verify the resistance of the non-volatile memory cell based on the comparison result between the first test resistance and the target resistance of the non-volatile memory cell.

[0120] In some embodiments, the second verification module may include a third application unit, a fourth application unit, and a second verification unit.

[0121] The third application unit is used to apply a second test voltage to the non-volatile memory cell and obtain a resistance verification result based on the comparison result between the second test resistance of the non-volatile memory cell under the second test voltage and the target resistance. The second test voltage is used to switch the open or closed state of the conductive channel.

[0122] The fourth application unit is used to apply a critical voltage to the non-volatile memory cell and detect the resistance and current of the non-volatile memory cell at the critical voltage. The critical voltage includes at least one of the critical effective voltage of the first voltage and the critical effective voltage of the second voltage.

[0123] The second verification unit is used to verify the storage status of the storage unit based on the resistance verification results and the resistance and current under the critical voltage.

[0124] In some embodiments, the updating device for the substrate management controller may further include a packaging module and a second writing module.

[0125] The packaging module is used to package the status identifier, the target version information of the update task, and the baseline check value obtained based on the version update data to be written to non-volatile memory into a first data structure in a predetermined format.

[0126] The second write module is used to write the first data structure to non-volatile memory via the integrated circuit bus interface.

[0127] In some embodiments, the update module 530 may further include a calling unit, a reading unit, a determining unit, and a verification unit.

[0128] The calling unit is used to invoke the hardware verification engine integrated within the baseboard management controller.

[0129] The read unit is used to read version update data that has been written to non-volatile memory via direct memory access using a hardware verification engine.

[0130] The determination unit is used to determine the update check value based on the version update data written to the non-volatile memory.

[0131] The verification unit is used to verify the version update data written to the non-volatile memory based on the update verification value and the baseline verification value.

[0132] In some embodiments, the update module 530 may further include a building unit and a third writing unit.

[0133] The construction unit is used to construct a second data structure for interaction between the baseboard management controller and the non-volatile memory based on metadata when the update stage is an information writing stage. The metadata includes at least one of the following: update data validity identifier, benchmark check value, timestamp of update task, update status of update task, pointer to the version updated by update task, reserved field of update task, and capacity of the version updated by update task.

[0134] The third write unit is used to write the second data structure into non-volatile memory through an atomic write operation.

[0135] According to embodiments of the present invention, any plurality of modules among the first write module 510, the acquire module 520, and the update module 530 may be combined into one module, or any one of these modules may be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules may be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of the present invention, at least one of the first write module 510, the acquire module 520, and the update module 530 may be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the first write module 510, the acquire module 520, and the update module 530 may be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0136] Figure 6 A block diagram of an electronic device suitable for implementing an update method for a substrate management controller according to an embodiment of the present invention is shown.

[0137] like Figure 6 As shown, an electronic device 600 according to an embodiment of the present invention includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present invention.

[0138] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 executes various operations of the method flow according to embodiments of the present invention by executing programs in ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also execute various operations of the method flow according to embodiments of the present invention by executing programs stored in said one or more memories.

[0139] According to an embodiment of the present invention, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0140] The present invention also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of the present invention.

[0141] According to embodiments of the present invention, a computer-readable storage medium may be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of the present invention, a computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0142] Embodiments of the present invention also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of the present invention.

[0143] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this invention. According to embodiments of the invention, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0144] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0145] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this embodiment of the invention. According to embodiments of the invention, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0146] According to embodiments of the present invention, program code for executing the computer programs provided in the embodiments of the present invention can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0147] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0148] Those skilled in the art will understand that the features described in the various embodiments of the present invention can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in the present invention. In particular, the features described in the various embodiments of the present invention can be combined and / or combined in various ways without departing from the spirit and teachings of the present invention. All such combinations and / or combinations fall within the scope of the present invention.

[0149] The embodiments of the present invention have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of the invention. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of the invention, and all such substitutions and modifications should fall within the scope of the invention.

Claims

1. A method for updating a baseboard management controller, characterized in that, The method includes: The update task is initialized by writing the status identifier of the update task to a non-volatile memory. The update task is used to update the version of the baseboard management controller. The update task includes multiple update stages arranged in execution order. The status identifier indicates the stage to be updated among the multiple update stages. During the execution of the pending update phase, if the device carrying the baseboard management controller is powered off and restarted, the status identifier is retrieved from the non-volatile memory; According to the pending update stage indicated by the status identifier, perform a recovery operation for the pending update stage, and when the pending update stage is completed, update the status identifier and execute the next pending update stage according to the execution order until the update task is completed, and update the status identifier to the completed state. The version update data is divided into multiple firmware data blocks. The update stage includes a data writing stage for writing the version update data into the non-volatile memory and a verification stage for verifying the version update data written into the non-volatile memory. Based on the pending update stage indicated by the status identifier, perform a recovery operation for the pending update stage, including: When the update-to-be-updated stage is the data writing stage, the firmware data block is parsed to obtain the data bytes to be written and the target storage address for storing the data bytes; the data bytes are mapped to the storage unit indicated by the target storage address, the storage unit including multiple non-volatile memory units; according to the target resistance required to store the data bytes and the current resistance of the non-volatile memory unit, a voltage is applied to the non-volatile memory unit to realize the in-situ writing of the data bytes; When the update-to-be-updated stage is a verification stage, the hardware verification engine integrated within the baseboard management controller is invoked; using the hardware verification engine, the version update data already written to the non-volatile memory is read via direct memory access; based on the version update data written to the non-volatile memory, an update verification value is determined; and the version update data written to the non-volatile memory is verified according to the update verification value and the baseline verification value.

2. The method according to claim 1, characterized in that, The non-volatile memory cell includes a first electrode, a second electrode, and a resistive switching layer disposed at a distance from the first electrode and the second electrode; The step of applying a voltage to the non-volatile memory cell based on the target resistance required to store the data byte and the current resistance of the non-volatile memory cell to achieve in-situ writing of the data byte includes: When the target resistance is greater than the current resistance, a first voltage is applied to the non-volatile memory cell to disconnect the conductive path from the first electrode to the second electrode; When the target resistance is less than or equal to the current resistance, a second voltage is applied to the non-volatile memory cell to turn on the conductive channel, thereby enabling the in-situ writing of the data byte.

3. The method according to claim 2, characterized in that, The method further includes: After the in-situ writing of the data byte is completed, the resistance of the non-volatile memory cell is verified. If the resistor passes verification, the storage state of the storage cell is verified.

4. The method according to claim 3, characterized in that, The verification of the resistance of the non-volatile memory cell includes: A first test voltage is applied to the non-volatile memory cell, wherein the first test voltage does not change the open or closed state of the conductive channel; The resistance of the non-volatile memory cell is verified based on the comparison result between the first test resistance of the non-volatile memory cell and the target resistance.

5. The method according to claim 3, characterized in that, The verification of the storage status of the storage unit includes: A second test voltage is applied to the non-volatile memory cell, and the resistance verification result is obtained based on the comparison between the second test resistance of the non-volatile memory cell under the second test voltage and the target resistance. The second test voltage is used to switch the open or closed state of the conductive channel; A critical voltage is applied to the non-volatile memory cell, and the resistance and current of the non-volatile memory cell under the critical voltage are detected. The critical voltage includes at least one of a first voltage critical effective voltage and a second voltage critical effective voltage. The storage state of the storage cell is verified based on the resistance verification results and the resistance and current at the critical voltage.

6. The method according to claim 1, characterized in that, The method further includes: The status identifier, the target version information of the update task, and the benchmark verification value obtained based on the version update data to be written to the non-volatile memory are packaged into a first data structure in a predetermined format. The first data structure is written to the non-volatile memory via the integrated circuit bus interface.

7. The method according to claim 1, characterized in that, The pending update stage includes an information writing stage in which the metadata of the update task is written to the non-volatile memory after the version update data written to the non-volatile memory passes verification. The metadata is used to guide the baseboard management controller to load the updated version when the baseboard management controller is started. Based on the pending update stage indicated by the status identifier, perform a recovery operation for the pending update stage, including: When the pending update stage is the information writing stage, a second data structure for interaction between the baseboard management controller and the non-volatile memory is constructed based on the metadata. The metadata includes at least one of the following: update data validity identifier, benchmark check value, timestamp of the update task, update status of the update task, pointer to the version updated by the update task, reserved field of the update task, and capacity of the version updated by the update task. The second data structure is written to the non-volatile memory through an atomic write operation.

8. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

Images