CN113867739A - Firmware loading method, system, equipment and medium for BMC - Google Patents
Firmware loading method, system, equipment and medium for BMC Download PDFInfo
- Publication number
- CN113867739A CN113867739A CN202110964218.9A CN202110964218A CN113867739A CN 113867739 A CN113867739 A CN 113867739A CN 202110964218 A CN202110964218 A CN 202110964218A CN 113867739 A CN113867739 A CN 113867739A
- Authority
- CN
- China
- Prior art keywords
- firmware
- partition
- bmc
- version
- partitions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 238000011068 loading method Methods 0.000 title claims abstract description 27
- 238000005192 partition Methods 0.000 claims abstract description 292
- 230000004044 response Effects 0.000 claims abstract description 29
- 230000005856 abnormality Effects 0.000 claims description 10
- 238000000034 method Methods 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 8
- 206010033799 Paralysis Diseases 0.000 abstract description 6
- 125000004122 cyclic group Chemical group 0.000 description 12
- 230000006870 function Effects 0.000 description 10
- 230000007246 mechanism Effects 0.000 description 10
- 108010028984 3-isopropylmalate dehydratase Proteins 0.000 description 8
- 238000010586 diagram Methods 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 239000000758 substrate Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a firmware loading method of BMC, which comprises the following steps: dividing the Flash into two partitions and respectively burning firmware in the two partitions; responding to BMC starting, and acquiring starting parameters; determining a corresponding partition according to the address information in the starting parameter, and loading firmware from the corresponding partition; in response to detecting the BMC failure, the BMC is restarted and elected to load firmware from another partition. The invention also discloses a system, a computer device and a readable storage medium. According to the scheme provided by the invention, one Flash is partitioned and the firmware is respectively stored, so that when a firmware version of one partition fails, the firmware version of the other partition can be switched to, the normal operation of a system is ensured, and the loss caused by instability and even paralysis of the system is reduced.
Description
Technical Field
The invention relates to the field of BMC, in particular to a firmware loading method, a firmware loading system, firmware loading equipment and a storage medium of BMC.
Background
With continuous high-speed updating and iteration of the technology, whether the running state of the server can be efficiently monitored and the running log of the server can be recorded becomes an important factor for selecting services by a client. The BMC (Baseboard management Controller) is the most important firmware for realizing efficient monitoring in the server and recording the running state of the server, so that whether the firmware version of the BMC can run stably or not is the most important option for a client.
The current storage device generally has only one BMC for one controller and only one BMC firmware version for one BMC, and when the BMC firmware version fails, the whole node cannot normally operate.
Disclosure of Invention
In view of the above, in order to overcome at least one aspect of the above problem, an embodiment of the present invention provides a firmware loading method for a BMC, including the following steps:
dividing the Flash into two partitions and respectively burning firmware in the two partitions;
responding to BMC starting, and acquiring starting parameters;
determining a corresponding partition according to the address information in the starting parameter, and loading firmware from the corresponding partition;
in response to detecting the BMC failure, the BMC is restarted and elected to load firmware from another partition.
In some embodiments, burning firmware in the two partitions respectively further includes:
burning a first version of firmware into a first partition of the two partitions;
burning a second version of firmware to a second partition of the two partitions, wherein the first version is higher than the second version.
In some embodiments, in response to BMC boot, obtaining boot parameters further comprises:
detecting whether firmware stored in the first partition is normal;
responding to the abnormality of the firmware stored in the first partition, and judging whether the firmware stored in the second partition is normal or not;
and in response to that the firmware stored in the second partition is normal, updating the address corresponding to the second partition to a starting parameter.
In some embodiments, further comprising:
and updating the firmware in the first partition and the firmware in the second partition in turn.
Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a firmware loading system for a BMC, including:
the burning module is configured to divide the Flash into two partitions and burn firmware in the two partitions respectively;
the acquisition module is configured to respond to BMC starting and acquire starting parameters;
the loading module is configured to determine a corresponding partition according to the address information in the starting parameter and load firmware from the corresponding partition;
a reboot module configured to reboot the BMC and select to load firmware from another partition in response to detecting the BMC failure.
In some embodiments, the burning module is further configured to:
burning a first version of firmware into a first partition of the two partitions;
burning a second version of firmware to a second partition of the two partitions, wherein the first version is higher than the second version.
In some embodiments, the acquisition module is further configured to:
detecting whether firmware stored in the first partition is normal;
responding to the abnormality of the firmware stored in the first partition, and judging whether the firmware stored in the second partition is normal or not;
and in response to that the firmware stored in the second partition is normal, updating the address corresponding to the second partition to a starting parameter.
In some embodiments, further comprising an update module configured to:
and updating the firmware in the first partition and the firmware in the second partition in turn.
Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a computer apparatus, including:
at least one processor; and
a memory storing a computer program operable on the processor, wherein the processor executes the program to perform the steps of:
dividing the Flash into two partitions and respectively burning firmware in the two partitions;
responding to BMC starting, and acquiring starting parameters;
determining a corresponding partition according to the address information in the starting parameter, and loading firmware from the corresponding partition;
in response to detecting the BMC failure, the BMC is restarted and elected to load firmware from another partition.
In some embodiments, burning firmware in the two partitions respectively further includes:
burning a first version of firmware into a first partition of the two partitions;
burning a second version of firmware to a second partition of the two partitions, wherein the first version is higher than the second version.
In some embodiments, in response to BMC boot, obtaining boot parameters further comprises:
detecting whether firmware stored in the first partition is normal;
responding to the abnormality of the firmware stored in the first partition, and judging whether the firmware stored in the second partition is normal or not;
and in response to that the firmware stored in the second partition is normal, updating the address corresponding to the second partition to a starting parameter.
In some embodiments, further comprising:
and updating the firmware in the first partition and the firmware in the second partition in turn.
Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a computer-readable storage medium storing a computer program which, when executed by a processor, performs the steps of:
dividing the Flash into two partitions and respectively burning firmware in the two partitions;
responding to BMC starting, and acquiring starting parameters;
determining a corresponding partition according to the address information in the starting parameter, and loading firmware from the corresponding partition;
in response to detecting the BMC failure, the BMC is restarted and elected to load firmware from another partition.
In some embodiments, burning firmware in the two partitions respectively further includes:
burning a first version of firmware into a first partition of the two partitions;
burning a second version of firmware to a second partition of the two partitions, wherein the first version is higher than the second version.
In some embodiments, in response to BMC boot, obtaining boot parameters further comprises:
detecting whether firmware stored in the first partition is normal;
responding to the abnormality of the firmware stored in the first partition, and judging whether the firmware stored in the second partition is normal or not;
and in response to that the firmware stored in the second partition is normal, updating the address corresponding to the second partition to a starting parameter.
In some embodiments, further comprising:
and updating the firmware in the first partition and the firmware in the second partition in turn.
The invention has one of the following beneficial technical effects: according to the scheme provided by the invention, one Flash is partitioned and the firmware is respectively stored, so that when a firmware version of one partition fails, the firmware version of the other partition can be switched to, the normal operation of a system is ensured, and the loss caused by instability and even paralysis of the system is reduced.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other embodiments can be obtained by using the drawings without creative efforts.
Fig. 1 is a flowchart illustrating a firmware loading method of a BMC according to an embodiment of the present invention;
FIG. 2 is a schematic structural diagram of a firmware loading system of a BMC according to an embodiment of the invention;
FIG. 3 is a schematic structural diagram of a computer device provided in an embodiment of the present invention;
fig. 4 is a schematic structural diagram of a computer-readable storage medium according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the following embodiments of the present invention are described in further detail with reference to the accompanying drawings.
It should be noted that all expressions using "first" and "second" in the embodiments of the present invention are used for distinguishing two entities with the same name but different names or different parameters, and it should be noted that "first" and "second" are merely for convenience of description and should not be construed as limitations of the embodiments of the present invention, and they are not described in any more detail in the following embodiments.
In the embodiment of the present invention, the BMC is a substrate controller, the BMC is an independent System, and is independent of other hardware on the System, a Basic Input Output System (BIOS), an Operating System (OS), and the like, but may interact with the BIOS and the OS, so as to perform a better platform management function, and generally, the BMC has the following functions: 1. access is performed through a serial port of the system; 2. fault logging and SNMP (simple network management protocol) alarm sending; 3. accessing system event logs and sensor conditions; 4. the control comprises starting up and shutting down; 5. support independent of system power or operating state; 6. text console redirection for system setup, text utility and operating system console based.
In the embodiment of the present invention, the firmware refers to a program written in the memory, and also refers to a device "driver" stored inside the device, through which the operating system can install a standard device driver to implement the operation of a specific machine, for example, the optical disc drive, the recorder, etc. all have internal firmware. Firmware is software that acts as the most basic and bottom layer of a system. In a hardware device, the firmware is the soul of the hardware device, and because some hardware devices do not have other software components except the firmware, the firmware determines the functions and performances of the hardware device.
According to an aspect of the present invention, an embodiment of the present invention provides a firmware loading method for a BMC, which may include, as shown in fig. 1, the steps of:
s1, dividing the Flash into two partitions and respectively burning firmware in the two partitions;
s2, responding to the BMC start, and acquiring start parameters;
s3, determining the corresponding partition according to the address information in the starting parameter, and loading the firmware from the corresponding partition;
s4, in response to detecting the BMC failure, restarting the BMC and selecting to load firmware from another partition.
According to the scheme provided by the invention, one Flash is partitioned and the firmware is respectively stored, so that when a firmware version of one partition fails, the firmware version of the other partition can be switched to, the normal operation of a system is ensured, and the loss caused by instability and even paralysis of the system is reduced.
In some embodiments, burning firmware in the two partitions respectively further includes:
burning a first version of firmware into a first partition of the two partitions;
burning a second version of firmware to a second partition of the two partitions, wherein the first version is higher than the second version.
In some embodiments, in response to BMC boot, obtaining boot parameters further comprises:
detecting whether firmware stored in the first partition is normal;
responding to the abnormality of the firmware stored in the first partition, and judging whether the firmware stored in the second partition is normal or not;
and in response to that the firmware stored in the second partition is normal, updating the address corresponding to the second partition to a starting parameter.
Specifically, a cyclic redundancy check CRC check mechanism may be used to verify whether the firmware stored in the first partition and the second partition is normal firmware. Cyclic Redundancy Check (CRC) is a hash function that generates a short fixed bit Check code from data such as network packets or computer files, and is mainly used to detect or Check errors that may occur after data transmission or storage. It uses the principle of division and remainder to detect the error.
Specifically, verifying whether the read firmware is a normal firmware by using a cyclic redundancy check CRC mechanism may include: and calculating a numerical value by using the head FW head of the firmware and the data contained in the ELF File in the File format File through a CRC (cyclic redundancy check) mechanism, comparing the numerical value with a stored numerical value stored in the tail part of the firmware, if the numerical value is consistent, the read firmware is proved to be normal firmware, and if the numerical value is inconsistent, the read firmware is proved not to be normal firmware.
It should be noted that, when the firmware is written and read, the firmware may have bit errors, so it is necessary to verify whether the read firmware is normal firmware.
In some embodiments, after verifying that the read firmware is normal firmware, a cyclic redundancy check CRC checking mechanism may be used to verify whether a flag bit in the FW head is a preset flag bit, and if the flag bit is the preset flag bit, further verify that the read firmware is normal firmware, and if the flag bit is not the preset flag bit, the read firmware is not normal firmware. Therefore, whether the read firmware is normal firmware or not is verified by adopting a CRC (Cyclic redundancy check) mechanism, so that the loaded firmware can be ensured to be normal firmware, the use safety and stability of the firmware are ensured, and the solid state disk can be safely started.
In some embodiments, further comprising:
and updating the firmware in the first partition and the firmware in the second partition in turn.
Specifically, the step of updating the firmware in the first partition and the firmware in the second partition in turn means that the firmware stored in the first partition can be updated for the first time, the firmware stored in the second partition can be updated for the second time, and the step of updating the firmware stored in the first partition and the firmware stored in the second partition in turn is used for simultaneously storing two versions of the firmware in the first partition and the firmware in the second partition.
It should be noted that when the firmware itself has a problem or a high-version firmware occurs, the firmware needs to be updated. The firmware updating is a user behavior, and the firmware is updated only when the user updates the firmware, that is, the firmware is not automatically updated.
In some embodiments, the BMC firmware may be upgraded using a Yafuflash tool (other tool implementations are possible), and the BMC run partition and standby partition version number may be queried using an IPMITOOL tool. And the BMC accesses the hardware Flash through the SPI interface, the Flash capacity can be larger than 128M, otherwise, the dual-partition upgrading requirement cannot be met. Meanwhile, a software partition dividing mode is adopted to realize a double-partition function, a single Flash is divided into two partitions, and the physical numbers are partition 1 and partition 2 respectively. And after the BMC is powered on and started, the partition firmware is loaded according to the boot parameters, the partition which is loaded and operated is called as an operation partition, and the non-operation partition is called as a standby partition. The BMC provides an IPMI interface for inquiring firmware version numbers of the running partition and the standby partition, and the system can use an ipmitool tool for inquiry. The BMC provides an IPMI interface for inquiring the physical number of the current running partition, and the system can use an ipmitool tool to inquire the current running partition as a partition 1 or a partition 2. When the BMC needs to be upgraded, upgrading the spare partition firmware is adopted by the BMC in a default mode, the BMC automatically starts partition switching after the firmware is upgraded, the spare partition which is upgraded is started, and the BMC is restarted to finish partition switching.
It should be particularly noted that, the steps in the above embodiments of the firmware loading method for the BMC may be intersected, replaced, added, or deleted, and therefore, these reasonable permutations and combinations should also fall within the scope of the present invention, and should not limit the scope of the present invention to the embodiments.
Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a firmware loading system 400 of a BMC, as shown in fig. 2, including:
the burning module 401 is configured to divide the Flash into two partitions and burn the firmware in the two partitions respectively;
an obtaining module 402 configured to obtain a start parameter in response to BMC start;
a loading module 403, configured to determine a corresponding partition according to the address information in the boot parameters, and load firmware from the corresponding partition;
a restart module 404 configured to restart the BMC and select to load firmware from another partition in response to detecting the BMC failure.
In some embodiments, the burning module 401 is further configured to:
burning a first version of firmware into a first partition of the two partitions;
burning a second version of firmware to a second partition of the two partitions, wherein the first version is higher than the second version.
In some embodiments, the acquisition module 402 is further configured to:
detecting whether firmware stored in the first partition is normal;
responding to the abnormality of the firmware stored in the first partition, and judging whether the firmware stored in the second partition is normal or not;
and in response to that the firmware stored in the second partition is normal, updating the address corresponding to the second partition to a starting parameter.
Specifically, a cyclic redundancy check CRC check mechanism may be used to verify whether the firmware stored in the first partition and the second partition is normal firmware. Cyclic Redundancy Check (CRC) is a hash function that generates a short fixed bit Check code from data such as network packets or computer files, and is mainly used to detect or Check errors that may occur after data transmission or storage. It uses the principle of division and remainder to detect the error.
Specifically, verifying whether the read firmware is a normal firmware by using a cyclic redundancy check CRC mechanism may include: and calculating a numerical value by using the head FW head of the firmware and the data contained in the ELF File in the File format File through a CRC (cyclic redundancy check) mechanism, comparing the numerical value with a stored numerical value stored in the tail part of the firmware, if the numerical value is consistent, the read firmware is proved to be normal firmware, and if the numerical value is inconsistent, the read firmware is proved not to be normal firmware.
It should be noted that, when the firmware is written and read, the firmware may have bit errors, so it is necessary to verify whether the read firmware is normal firmware.
In some embodiments, after verifying that the read firmware is normal firmware, a cyclic redundancy check CRC checking mechanism may be used to verify whether a flag bit in the FW head is a preset flag bit, and if the flag bit is the preset flag bit, further verify that the read firmware is normal firmware, and if the flag bit is not the preset flag bit, the read firmware is not normal firmware. Therefore, whether the read firmware is normal firmware or not is verified by adopting a CRC (Cyclic redundancy check) mechanism, so that the loaded firmware can be ensured to be normal firmware, the use safety and stability of the firmware are ensured, and the solid state disk can be safely started.
In some embodiments, further comprising an update module configured to:
and updating the firmware in the first partition and the firmware in the second partition in turn.
Specifically, the step of updating the firmware in the first partition and the firmware in the second partition in turn means that the firmware stored in the first partition can be updated for the first time, the firmware stored in the second partition can be updated for the second time, and the step of updating the firmware stored in the first partition and the firmware stored in the second partition in turn is used for simultaneously storing two versions of the firmware in the first partition and the firmware in the second partition.
It should be noted that when the firmware itself has a problem or a high-version firmware occurs, the firmware needs to be updated. The firmware updating is a user behavior, and the firmware is updated only when the user updates the firmware, that is, the firmware is not automatically updated.
In some embodiments, the BMC firmware may be upgraded using a Yafuflash tool (other tool implementations are possible), and the BMC run partition and standby partition version number may be queried using an IPMITOOL tool. And the BMC accesses the hardware Flash through the SPI interface, the Flash capacity can be larger than 128M, otherwise, the dual-partition upgrading requirement cannot be met. Meanwhile, a software partition dividing mode is adopted to realize a double-partition function, a single Flash is divided into two partitions, and the physical numbers are partition 1 and partition 2 respectively. And after the BMC is powered on and started, the partition firmware is loaded according to the boot parameters, the partition which is loaded and operated is called as an operation partition, and the non-operation partition is called as a standby partition. The BMC provides an IPMI interface for inquiring firmware version numbers of the running partition and the standby partition, and the system can use an ipmitool tool for inquiry. The BMC provides an IPMI interface for inquiring the physical number of the current running partition, and the system can use an ipmitool tool to inquire the current running partition as a partition 1 or a partition 2. When the BMC needs to be upgraded, upgrading the spare partition firmware is adopted by the BMC in a default mode, the BMC automatically starts partition switching after the firmware is upgraded, the spare partition which is upgraded is started, and the BMC is restarted to finish partition switching.
It should be particularly noted that, the steps in the above embodiments of the firmware loading method for the BMC may be intersected, replaced, added, or deleted, and therefore, these reasonable permutations and combinations should also fall within the scope of the present invention, and should not limit the scope of the present invention to the embodiments.
According to the scheme provided by the invention, one Flash is partitioned and the firmware is respectively stored, so that when a firmware version of one partition fails, the firmware version of the other partition can be switched to, the normal operation of a system is ensured, and the loss caused by instability and even paralysis of the system is reduced.
Based on the same inventive concept, according to another aspect of the present invention, as shown in fig. 3, an embodiment of the present invention further provides a computer apparatus 501, comprising:
at least one processor 520; and
a memory 510, the memory 510 storing a computer program 511 executable on the processor, the processor 520 executing the program to perform the steps of:
s1, dividing the Flash into two partitions and respectively burning firmware in the two partitions;
s2, responding to the BMC start, and acquiring start parameters;
s3, determining the corresponding partition according to the address information in the starting parameter, and loading the firmware from the corresponding partition;
s4, in response to detecting the BMC failure, restarting the BMC and selecting to load firmware from another partition.
In some embodiments, burning firmware in the two partitions respectively further includes:
burning a first version of firmware into a first partition of the two partitions;
burning a second version of firmware to a second partition of the two partitions, wherein the first version is higher than the second version.
In some embodiments, in response to BMC boot, obtaining boot parameters further comprises:
detecting whether firmware stored in the first partition is normal;
responding to the abnormality of the firmware stored in the first partition, and judging whether the firmware stored in the second partition is normal or not;
and in response to that the firmware stored in the second partition is normal, updating the address corresponding to the second partition to a starting parameter.
In some embodiments, further comprising:
and updating the firmware in the first partition and the firmware in the second partition in turn.
In some embodiments, the BMC firmware may be upgraded using a Yafuflash tool (other tool implementations are possible), and the BMC run partition and standby partition version number may be queried using an IPMITOOL tool. And the BMC accesses the hardware Flash through the SPI interface, the Flash capacity can be larger than 128M, otherwise, the dual-partition upgrading requirement cannot be met. Meanwhile, a software partition dividing mode is adopted to realize a double-partition function, a single Flash is divided into two partitions, and the physical numbers are partition 1 and partition 2 respectively. And after the BMC is powered on and started, the partition firmware is loaded according to the boot parameters, the partition which is loaded and operated is called as an operation partition, and the non-operation partition is called as a standby partition. The BMC provides an IPMI interface for inquiring firmware version numbers of the running partition and the standby partition, and the system can use an ipmitool tool for inquiry. The BMC provides an IPMI interface for inquiring the physical number of the current running partition, and the system can use an ipmitool tool to inquire the current running partition as a partition 1 or a partition 2. When the BMC needs to be upgraded, upgrading the spare partition firmware is adopted by the BMC in a default mode, the BMC automatically starts partition switching after the firmware is upgraded, the spare partition which is upgraded is started, and the BMC is restarted to finish partition switching.
According to the scheme provided by the invention, one Flash is partitioned and the firmware is respectively stored, so that when a firmware version of one partition fails, the firmware version of the other partition can be switched to, the normal operation of a system is ensured, and the loss caused by instability and even paralysis of the system is reduced.
Based on the same inventive concept, according to another aspect of the present invention, as shown in fig. 4, an embodiment of the present invention further provides a computer-readable storage medium 601, where the computer-readable storage medium 601 stores computer program instructions 610, and the computer program instructions 610, when executed by a processor, perform the following steps:
s1, dividing the Flash into two partitions and respectively burning firmware in the two partitions;
s2, responding to the BMC start, and acquiring start parameters;
s3, determining the corresponding partition according to the address information in the starting parameter, and loading the firmware from the corresponding partition;
s4, in response to detecting the BMC failure, restarting the BMC and selecting to load firmware from another partition.
In some embodiments, burning firmware in the two partitions respectively further includes:
burning a first version of firmware into a first partition of the two partitions;
burning a second version of firmware to a second partition of the two partitions, wherein the first version is higher than the second version.
In some embodiments, in response to BMC boot, obtaining boot parameters further comprises:
detecting whether firmware stored in the first partition is normal;
responding to the abnormality of the firmware stored in the first partition, and judging whether the firmware stored in the second partition is normal or not;
and in response to that the firmware stored in the second partition is normal, updating the address corresponding to the second partition to a starting parameter.
In some embodiments, further comprising:
and updating the firmware in the first partition and the firmware in the second partition in turn.
In some embodiments, the BMC firmware may be upgraded using a Yafuflash tool (other tool implementations are possible), and the BMC run partition and standby partition version number may be queried using an IPMITOOL tool. And the BMC accesses the hardware Flash through the SPI interface, the Flash capacity can be larger than 128M, otherwise, the dual-partition upgrading requirement cannot be met. Meanwhile, a software partition dividing mode is adopted to realize a double-partition function, a single Flash is divided into two partitions, and the physical numbers are partition 1 and partition 2 respectively. And after the BMC is powered on and started, the partition firmware is loaded according to the boot parameters, the partition which is loaded and operated is called as an operation partition, and the non-operation partition is called as a standby partition. The BMC provides an IPMI interface for inquiring firmware version numbers of the running partition and the standby partition, and the system can use an ipmitool tool for inquiry. The BMC provides an IPMI interface for inquiring the physical number of the current running partition, and the system can use an ipmitool tool to inquire the current running partition as a partition 1 or a partition 2. When the BMC needs to be upgraded, upgrading the spare partition firmware is adopted by the BMC in a default mode, the BMC automatically starts partition switching after the firmware is upgraded, the spare partition which is upgraded is started, and the BMC is restarted to finish partition switching.
According to the scheme provided by the invention, one Flash is partitioned and the firmware is respectively stored, so that when a firmware version of one partition fails, the firmware version of the other partition can be switched to, the normal operation of a system is ensured, and the loss caused by instability and even paralysis of the system is reduced.
Finally, it should be noted that, as will be understood by those skilled in the art, all or part of the processes of the methods of the above embodiments may be implemented by a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the embodiments of the methods described above.
Further, it should be appreciated that the computer-readable storage media (e.g., memory) herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory.
Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as software or hardware depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosed embodiments of the present invention.
The foregoing is an exemplary embodiment of the present disclosure, but it should be noted that various changes and modifications could be made herein without departing from the scope of the present disclosure as defined by the appended claims. The functions, steps and/or actions of the method claims in accordance with the disclosed embodiments described herein need not be performed in any particular order. Furthermore, although elements of the disclosed embodiments of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.
It should be understood that, as used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly supports the exception. It should also be understood that "and/or" as used herein is meant to include any and all possible combinations of one or more of the associated listed items.
The numbers of the embodiments disclosed in the embodiments of the present invention are merely for description, and do not represent the merits of the embodiments.
It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.
Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, of embodiments of the invention is limited to these examples; within the idea of an embodiment of the invention, also technical features in the above embodiment or in different embodiments may be combined and there are many other variations of the different aspects of the embodiments of the invention as described above, which are not provided in detail for the sake of brevity. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of the embodiments of the present invention are intended to be included within the scope of the embodiments of the present invention.
Claims (10)
1. A firmware loading method of BMC is characterized by comprising the following steps:
dividing the Flash into two partitions and respectively burning firmware in the two partitions;
responding to BMC starting, and acquiring starting parameters;
determining a corresponding partition according to the address information in the starting parameter, and loading firmware from the corresponding partition;
in response to detecting the BMC failure, the BMC is restarted and elected to load firmware from another partition.
2. The method of claim 1, wherein burning firmware in the two partitions respectively, further comprises:
burning a first version of firmware into a first partition of the two partitions;
burning a second version of firmware to a second partition of the two partitions, wherein the first version is higher than the second version.
3. The method of claim 2, wherein the obtaining boot parameters in response to the BMC boot further comprises:
detecting whether firmware stored in the first partition is normal;
responding to the abnormality of the firmware stored in the first partition, and judging whether the firmware stored in the second partition is normal or not;
and in response to that the firmware stored in the second partition is normal, updating the address corresponding to the second partition to a starting parameter.
4. The method of claim 2, further comprising:
and updating the firmware in the first partition and the firmware in the second partition in turn.
5. A firmware loading system for a BMC, comprising:
the burning module is configured to divide the Flash into two partitions and burn firmware in the two partitions respectively;
the acquisition module is configured to respond to BMC starting and acquire starting parameters;
the loading module is configured to determine a corresponding partition according to the address information in the starting parameter and load firmware from the corresponding partition;
a reboot module configured to reboot the BMC and select to load firmware from another partition in response to detecting the BMC failure.
6. The system of claim 5, wherein the burn module is further configured to:
burning a first version of firmware into a first partition of the two partitions;
burning a second version of firmware to a second partition of the two partitions, wherein the first version is higher than the second version.
7. The system of claim 6, wherein the acquisition module is further configured to:
detecting whether firmware stored in the first partition is normal;
responding to the abnormality of the firmware stored in the first partition, and judging whether the firmware stored in the second partition is normal or not;
and in response to that the firmware stored in the second partition is normal, updating the address corresponding to the second partition to a starting parameter.
8. The system of claim 6, further comprising an update module configured to:
and updating the firmware in the first partition and the firmware in the second partition in turn.
9. A computer device, comprising:
at least one processor; and
memory storing a computer program operable on the processor, characterized in that the processor executes the program to perform the steps of the method according to any of claims 1-4.
10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, is adapted to carry out the steps of the method according to any one of claims 1-4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110964218.9A CN113867739A (en) | 2021-08-21 | 2021-08-21 | Firmware loading method, system, equipment and medium for BMC |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110964218.9A CN113867739A (en) | 2021-08-21 | 2021-08-21 | Firmware loading method, system, equipment and medium for BMC |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113867739A true CN113867739A (en) | 2021-12-31 |
Family
ID=78988088
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110964218.9A Withdrawn CN113867739A (en) | 2021-08-21 | 2021-08-21 | Firmware loading method, system, equipment and medium for BMC |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113867739A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115543488A (en) * | 2022-11-29 | 2022-12-30 | 苏州浪潮智能科技有限公司 | Multi-core SoC firmware starting method and related device |
-
2021
- 2021-08-21 CN CN202110964218.9A patent/CN113867739A/en not_active Withdrawn
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115543488A (en) * | 2022-11-29 | 2022-12-30 | 苏州浪潮智能科技有限公司 | Multi-core SoC firmware starting method and related device |
| CN115543488B (en) * | 2022-11-29 | 2023-08-25 | 苏州浪潮智能科技有限公司 | Firmware starting method and related device of multi-core SoC |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4594750B2 (en) | Method and system for recovering from failure of a blade service processor flash in a server chassis | |
| US9081639B2 (en) | System and method for remotely re-imaging a computer system | |
| TWI571800B (en) | Booting method and computer system | |
| US8935509B2 (en) | Method for controlling BMC having customized SDR | |
| WO2010098019A4 (en) | Program update device, program update method, and information processing device | |
| CN107315616B (en) | Firmware loading method and device and electronic equipment | |
| CN112003917B (en) | File storage management method, system, device and medium | |
| CN108959045B (en) | Method and system for testing fault switching performance of NAS cluster | |
| EP2382545B1 (en) | Component configuration mechanism for rebooting | |
| CN107980119B (en) | Server management method and server | |
| KR20170040734A (en) | Electronic system with update control mechanism and method of operation thereof | |
| CN108932249B (en) | Method and device for managing file system | |
| WO2021057795A1 (en) | System starting method and apparatus, node device and computer-readable storage medium | |
| US7818557B2 (en) | Method for re-imaging a computer system | |
| US7499987B2 (en) | Deterministically electing an active node | |
| CN113867739A (en) | Firmware loading method, system, equipment and medium for BMC | |
| CN116028094A (en) | BMC upgrading method and device | |
| JP2003099146A (en) | System for controlling start of computer system | |
| US20170364368A1 (en) | Setting method of accessing system parameters and server using the same | |
| CN115129345A (en) | Firmware upgrading method, device, equipment and storage medium | |
| JP2002049509A (en) | Data processing system | |
| CN112131043A (en) | Method and device for detecting and recovering abnormity of basic input and output system | |
| CN111045710A (en) | Method, equipment and medium for upgrading SAS-Expander firmware based on IPMI command | |
| CN116431291B (en) | Deployment method, system, equipment and storage medium of virtualization management platform | |
| WO2024000535A1 (en) | Partition table update method and apparatus, and electronic device and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WW01 | Invention patent application withdrawn after publication | ||
| WW01 | Invention patent application withdrawn after publication |
Application publication date: 20211231 |