Configuration data management method, device and equipment and readable storage medium

Abstract

The invention provides a configuration data management method and device, equipment and a readable storage medium, and the method comprises the steps: obtaining a to-be-flashed firmware package, and separating firmware data to be written into the firmware package from a configuration database; writing firmware data into the first storage unit, and writing a configuration database into the second storage unit; and calling the matched configuration data in the configuration database written in the second storage unit. According to the technical scheme, the firmware data and the multi-model configuration database are separated, the configuration data are stored in the large-capacity eMMC unit, and the Flash storage space bottleneck is solved. Not only is the pressure of the rootfs partition released, the use of a low-cost Flash chip is supported, but also the loading of configuration data as required is realized; meanwhile, multi-model compatibility is kept, the starting delay problem caused by a compression scheme is avoided, and sufficient elastic space is reserved for function extension.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of communication, and in particular, to a configuration data management method and device, equipment and a readable storage medium. BACKGROUND

[0002] The start of the BMC (baseboard management controller) of the server needs to occupy a certain Flash space, and usually this value is defined as 128MB, and an additional 4GB eMMC is equipped for data storage. This configuration selection is mainly based on cost consideration, because if the Flash space is expanded to 256MB, the cost will increase significantly, which is not cost-effective for manufacturers. However, as customers' demand for primary and backup BMC functions increases, the 128MB of Flash space has to be divided, that is, each BMC version can only use 64MB of space. With the continuous increase and complexity of software functions, especially on G7 generation devices, the existing Flash space has become insufficient and cannot meet the addition of new functions.

[0003] In order to reduce maintenance costs and improve efficiency, manufacturers tend to adapt all products in a unified BMC version branch instead of maintaining a BMC version branch for each product. This means that a BMC version must include adaptation files for multiple products, such as product appearance diagrams, configuration information, etc., resulting in a large storage requirement. However, when these BMC versions are actually deployed to specific models, only one product's adaptation file is actually used, and the rest becomes redundant data. Since the division of Flash partitions is determined at the BMC version compilation stage, even if it is known that only a small number of adaptation files will be used, all adaptation files still need to be compiled into the corresponding partitions at the time of compilation, which causes a great waste of space and may even cause compilation failure.

[0004] One technical solution is to improve the file system compression rate of the rootfs partition. The file system types that can be used by the rootfs partition, such as cramfs and squashfs, are compressed file systems, and a certain amount of space can be released by adjusting the compression parameters. Although this method is relatively simple to execute and does not require code modification, it can only provide limited space saving effect, and higher compression rate will cause the system to start slower, and cannot fundamentally solve the problem. SUMMARY

[0005] Therefore, the present specification provides a configuration data management method, device, equipment and readable storage medium to improve the problem of insufficient BMC hanging Flash capacity.

[0006] The specific technical solutions are as follows:

[0007] The present specification provides a configuration data management method, applied to a BMC device of a server, wherein the BMC device is mounted with a first storage unit and a second storage unit, and the method comprises the following steps: obtaining a to-be-written firmware package, wherein the to-be-written firmware package comprises firmware data and a configuration database; separating the firmware data and the configuration database of the to-be-written firmware package; writing the firmware data into the first storage unit and writing the configuration database into the second storage unit; and calling matched configuration data in the configuration database written into the second storage unit according to a product type of the server recorded by the local BMC device.

[0008] As a technical solution, the step of calling the matched configuration data in the configuration database written into the second storage unit according to the product type of the server recorded by the local BMC device comprises the following steps: reading the matched configuration data in the configuration database written into the second storage unit, and writing the matched configuration data into the first storage unit.

[0009] As a technical solution, the firmware data comprises startup necessary data and other data; the startup necessary data and the other data of the firmware data are separated; the startup necessary data is written into the first storage unit and the other data is written into the second storage unit; and in a started state, associated data is called in the other data written into the second storage unit according to a specific instruction.

[0010] As a technical solution, the step of obtaining the to-be-written firmware package, wherein the to-be-written firmware package comprises firmware data and a configuration database, and separating the firmware data and the configuration database of the to-be-written firmware package comprises the following steps: decompressing the to-be-written firmware package in the second storage unit; and the steps of writing the firmware data into the first storage unit and writing the configuration database into the second storage unit comprise the following step: migrating and writing the firmware data of the to-be-written firmware package to the first storage unit.

[0011] The present specification also provides a configuration data management device, applied to a BMC device of a server, wherein the BMC device is mounted with a first storage unit and a second storage unit, and the device comprises the following modules: a first module, configured to obtain a to-be-written firmware package, wherein the to-be-written firmware package comprises firmware data and a configuration database, and separate the firmware data and the configuration database of the to-be-written firmware package; a second module, configured to write the firmware data into the first storage unit and write the configuration database into the second storage unit; and a third module, configured to call matched configuration data in the configuration database written into the second storage unit according to a product type of the server recorded by the local BMC device.

[0012] As a technical solution, the matched configuration data is called in the configuration database written in the second storage unit according to the server product model recorded by the local BMC device, including reading the matched configuration data in the configuration database written in the second storage unit, and writing the matched configuration data into the first storage unit.

[0013] As a technical solution, the firmware data includes startup necessary data and other data; the startup necessary data and the other data of the firmware data are separated; the startup necessary data is written in the first storage unit, and the other data is written in the second storage unit; in the started state, according to a specific instruction, the associated data is called in the other data written in the second storage unit.

[0014] As a technical solution, the firmware package to be written is obtained, the firmware package to be written includes firmware data and a configuration database, and the firmware data and the configuration database of the firmware package to be written are separated, including: decompressing the firmware package to be written in the second storage unit; the firmware data is written in the first storage unit, and the configuration database is written in the second storage unit, including: migrating and writing the firmware data of the firmware package to be written to the first storage unit.

[0015] The specification also provides an electronic device, including a processor and a readable storage medium, the readable storage medium stores machine executable instructions capable of being executed by the processor, and the processor executes the machine executable instructions to realize the configuration data management method.

[0016] The specification also provides a readable storage medium, the readable storage medium stores machine executable instructions, and the machine executable instructions make the processor realize the configuration data management method when the machine executable instructions are called and executed by the processor.

[0017] The above technical solutions provided by the specification at least bring the following beneficial effects:

[0018] Separating the firmware data and the multi-model configuration database, storing the configuration data to the large capacity eMMC unit, solving the Flash storage space bottleneck. Both releasing the rootfs partition pressure and supporting the use of low-cost Flash chips, and realizing the on-demand loading of configuration data; at the same time, maintaining the multi-model compatibility, avoiding the startup delay problem caused by the compression scheme, and reserving sufficient flexible space for function expansion. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present specification or the prior art, the following will briefly introduce the drawings needed to be used in the description of the embodiments of the present specification and the prior art. Obviously, the drawings in the following description are only some embodiments described in the present specification, and other drawings can also be obtained by those skilled in the art according to these drawings of the embodiments of the present specification.

[0020] Figure 1 is a flow chart of a configuration data management method in an embodiment of the present specification;

[0021] Figure 2 is a structural diagram of a configuration data management device in an embodiment of the present specification;

[0022] Figure 3 is a hardware structural diagram of an electronic device in an embodiment of the present specification.

[0023] Reference signs: first module 21, second module 22, third module 23. DETAILED DESCRIPTION

[0024] The terms used in the embodiments of the present specification are only for the purpose of describing specific embodiments and are not intended to limit the present specification. The singular forms "a", "an" and "the" used in the present specification and claims are intended to include plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to any or all possible combinations of one or more associated listed items.

[0025] It should be understood that although the terms first, second, third, etc. can be used in the embodiments of the present specification to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information can also be referred to as the second information, and similarly, the second information can also be referred to as the first information, without departing from the scope of the present specification. In addition, the word "if" used can be interpreted as "when" or "upon" or "in response to determining" depending on the context.

[0026] Therefore, the present specification provides a configuration data management method, device, equipment and readable storage medium to at least improve one of the above technical problems.

[0027] The specific technical solutions are described as follows.

[0028] In an embodiment, the present specification provides a configuration data management method applied to a BMC device of a server, wherein the BMC device is mounted with a first storage unit and a second storage unit, and the method comprises: obtaining a to-be-written firmware package, wherein the to-be-written firmware package comprises firmware data and a configuration database; separating the firmware data and the configuration database of the to-be-written firmware package; writing the firmware data in the first storage unit and writing the configuration database in the second storage unit; and calling matched configuration data in the configuration database written in the second storage unit according to a product type of the server recorded by the local BMC device.

[0029] Specifically, as Figure 1 comprises the following steps:

[0030] Step S11, obtaining a to-be-written firmware package, wherein the to-be-written firmware package comprises firmware data and a configuration database, and the firmware data and the configuration database of the to-be-written firmware package are separated.

[0031] The to-be-written firmware package contains firmware data and a configuration database. The firmware data is program code and core data required for the operation of the BMC system, and the configuration database stores adaptation files of various product types, including product appearance diagrams, configuration information, etc. For example, assuming that a server manufacturer produces three types of servers A, B and C, the configuration database in the BMC firmware package of the server manufacturer contains configuration files corresponding to the A, B and C types respectively.

[0032] The firmware data and the configuration database are separated from the to-be-written firmware package through a specific packaging and unpackaging mechanism. For example, a custom file system structure or compression format can be used, so that the firmware package can identify and distinguish the firmware data and the configuration database part after being obtained by the BMC device. This separation operation can be performed in the startup phase or the firmware update phase of the BMC, depending on the design architecture of the system.

[0033] Step S12, writing the firmware data in the first storage unit and writing the configuration database in the second storage unit.

[0034] The separated firmware data is written into the first storage unit (Flash chip), and the configuration database is written into the second storage unit (eMMC chip). For example, assuming that the capacity of the Flash chip is 128 MB, and originally the firmware data and all product type configuration files need to be stored, now only the firmware data is stored through the separation operation, thereby saving a large amount of space. The eMMC chip has a large storage capacity (such as 4 GB) and is suitable for storing the configuration database containing configuration information of multiple product types.

[0035] Step S13, according to the server product model recorded by the local BMC device, the matching configuration data in the configuration database written in the second storage unit is called.

[0036] The BMC device calls the matching configuration data in the configuration database stored in the second storage unit (eMMC chip) according to the server product model recorded locally. For example, when the BMC starts, it reads the product model information (such as Model A) stored locally, then extracts the configuration file corresponding to Model A from the configuration database in the eMMC chip, and loads it into the memory for use.

[0037] In an embodiment, after obtaining the firmware package to be written, the system first parses it to separate the firmware data and the configuration database. This process can be implemented with the help of specific file system tools or compression / decompression algorithms. For example, the firmware package can adopt a special tarball format, which contains two main parts: one is the directory structure of the firmware data, and the other is the independent file of the configuration database. When running the unpacking script on the BMC device, the two parts can be identified and processed separately.

[0038] The separated firmware data is written into the first storage unit, i.e. the Flash chip. Since the redundant configuration file is removed, the size of the rootfs partition is significantly reduced. For example, the rootfs that originally needs to occupy 64MB of Flash space may only need 32MB after separating the configuration database, thus releasing half of the storage space. This saved space can be used to store more firmware function modules, or reduce the requirement for the capacity of the Flash chip, thereby reducing the hardware cost.

[0039] At the same time, the configuration database is completely written into the second storage unit, i.e. the eMMC chip. The eMMC chip has a large storage capacity and can easily accommodate a database containing configuration information of multiple product models. For example, a 4GB eMMC chip can easily store configuration files of dozens or even hundreds of server models without running out of space. During the writing process, the system can index the configuration database or establish a fast query mechanism so that subsequent specific model configuration data can be quickly located.

[0040] The BMC device starts and reads the locally recorded product model information. This information is usually stored in the non-volatile storage area of the BMC, such as EEPROM or a specific Flash partition. Then, the BMC looks up and calls the matching configuration data in the configuration database in the eMMC chip according to the model information. For example, assuming that the server where the current BMC is located is model X, the system extracts the configuration file corresponding to model X from the configuration database and loads it into a specified location in memory. These configuration files may include device startup parameters, network configurations, hardware monitoring settings, etc., and are essential for the normal operation of the BMC.

[0041] The above embodiment significantly reduces the size of the rootfs partition by separating the configuration database from the Flash chip, thereby alleviating the problem of insufficient Flash space. For example, in actual tests of a certain server manufacturer, after adopting the present scheme, the size of the rootfs partition is reduced from the original 60MB to 30MB, releasing half of the space. As the capacity requirement of the Flash chip is reduced, the manufacturer can choose a smaller capacity and lower cost Flash chip. For example, a 64MB Flash chip may be sufficient now, which directly reduces the hardware cost and improves the market competitiveness of the product. The released Flash space can be used to store more firmware function modules, so that the BMC system can support more rich functions without worrying about the limitation of storage space.

[0042] The above embodiment ensures compatibility between new and old versions during firmware updates, whether online upgrade or burning update. For example, when upgrading from an old version to a new version, the new version can normally recognize and use the configuration database stored in the eMMC; and if downgrading from the new version to the old version, the old version will not have the problem of missing configuration data because its rootfs is full.

[0043] The configuration database is centrally stored in the eMMC chip, which is convenient for unified management and update. For example, when a new configuration item needs to be added for a certain product model, only the configuration database in the eMMC needs to be updated, without the need to recompile and burn the entire firmware package.

[0044] In a specific scenario, a server manufacturer produces three models of servers, A, B, and C, each with its unique hardware configuration and appearance design. In traditional BMC firmware development, the development team needs to adapt to the three models in one BMC version branch, resulting in the rootfs partition containing all configuration files of models A, B, and C. As the functions continue to increase, the size of the rootfs gradually approaches the upper limit of the capacity of the Flash chip (assuming 64MB), causing the development of new functions to be limited.

[0045] When generating the firmware package, the firmware data and the configuration database are effectively distinguished. The firmware data mainly includes the kernel, drivers, basic services, etc. of the BMC system, while the configuration database contains detailed configuration files of the A, B, and C models. In the firmware flashing process, the firmware data is written into the Flash chip, and the configuration database is written into the eMMC chip.

[0046] When the BMC device starts, it first reads the product model information from the local storage (assuming it is model B), then extracts the configuration file of model B from the configuration database in the eMMC chip and loads it into the memory. In this way, the BMC system only uses the configuration data matching the current server model during runtime, without the need to store configuration files of all models in the Flash chip.

[0047] In the above scenario, the size of the rootfs partition is reduced from the original 60MB to 30MB, successfully solving the problem of insufficient Flash space. At the same time, since the read and write speed of the eMMC chip is relatively slower than that of the Flash chip, but the loading process of the configuration data does not have a significant impact on the system startup time, because the extraction and loading of the configuration data can be performed asynchronously in the background or cached in advance when the system is idle.

[0048] In an embodiment, the configuration data matching the product model of the server where the local BMC device is located is called from the configuration database written in the second storage unit, including: reading the matching configuration data from the configuration database written in the second storage unit, and writing the matching configuration data into the first storage unit.

[0049] In an embodiment, the firmware data includes startup necessary data and other data; the startup necessary data and the other data of the firmware data are separated; the startup necessary data is written into the first storage unit, and the other data is written into the second storage unit; in the started state, according to a specific instruction, the associated data in the other data written in the second storage unit is called.

[0050] In an embodiment, the firmware package to be flashed is obtained, the firmware package to be flashed includes firmware data and a configuration database, and the firmware data and the configuration database of the firmware package to be written are separated, including: decompressing the firmware package to be flashed in the second storage unit; the firmware data is written into the first storage unit, and the configuration database is written into the second storage unit, including: migrating and flashing the firmware data of the firmware package to be flashed to the first storage unit.

[0051] In an embodiment, the first step is to obtain the firmware package to be written, if there is a new firmware version to be deployed on multiple different server product models, in order to meet the specific needs of these different products, the firmware package not only contains the core firmware data, but also contains the configuration file corresponding to each product model. These configuration files may include but are not limited to network settings, BIOS parameter adjustment, hardware monitoring configuration, etc.

[0052] Separate the firmware data from the configuration database, identify which data is common to all servers, that is, the firmware data part, and which is specific to certain server product models, that is, the configuration database part. A batch of servers, although sharing the same underlying firmware, differ in the number of network interfaces, hard disk types, etc. Therefore, the common firmware code is extracted as firmware data, and the network configuration, hard disk management strategy, etc. Information specific to each server model is packaged separately into the configuration database. This not only simplifies the maintenance process of the firmware, but also makes subsequent adjustments for specific server models easier.

[0053] After separating the firmware data and the configuration database, the two parts of data are written into the corresponding storage units. The first storage unit here is usually Flash, which has fast reading speed but relatively small capacity, suitable for storing firmware data; while the second storage unit is eMMC, which is characterized by large capacity and low cost, and is very suitable for storing a large amount of configuration data.

[0054] Based on the server product model recorded by the local BMC device, the matching configuration data is found and called in the second storage unit. When the BMC device starts, it automatically identifies the server model it is in, and loads the corresponding configuration data from the eMMC accordingly.

[0055] In an embodiment, as Figure 2 The present specification also provides a configuration data management apparatus applied to a BMC device of a server, wherein the BMC device is mounted with a first storage unit and a second storage unit, and the apparatus comprises: a first module for obtaining a firmware package to be written, wherein the firmware package to be written comprises firmware data and a configuration database; a second module for separating the firmware data and the configuration database of the firmware package to be written; a third module for writing the firmware data in the first storage unit and writing the configuration database in the second storage unit; and a fourth module for calling matching configuration data in the configuration database written in the second storage unit according to the server product model recorded by the local BMC device.

[0056] In an embodiment, the calling of the matched configuration data in the configuration database written in the second storage unit according to the server product model recorded by the local BMC device comprises: reading the matched configuration data in the configuration database written in the second storage unit, and writing the matched configuration data into the first storage unit.

[0057] In an embodiment, the firmware data comprises boot necessary data and other data; the boot necessary data and the other data of the firmware data are separated; the boot necessary data is written in the first storage unit, and the other data is written in the second storage unit; in the started state, the associated data is called in the other data written in the second storage unit according to the specific instruction.

[0058] In an embodiment, the obtaining of the firmware package to be written comprises firmware data and a configuration database; the firmware data and the configuration database of the firmware package to be written are separated, comprising: decompressing the firmware package to be written in the second storage unit; the writing of the firmware data in the first storage unit and the writing of the configuration database in the second storage unit comprises: migrating and writing the firmware data of the firmware package to be written to the first storage unit.

[0059] In an embodiment, the configuration data management method first needs to establish a hardware environment basis: the BMC device deployed on the server motherboard is connected with the first storage unit (i.e. a NOR Flash chip with a capacity of 128 MB) through an SPI bus, and is connected with the second storage unit (i.e. an eMMC chip with a capacity of 4 GB) through an SDIO interface.

[0060] The Flash chip is divided into uboot_spl (64 KB), uboot (960 KB), overlay_conf (2.5 MB), pfr (4 MB), kernel (7 MB), rootfs (50 MB) and sectiontable (4 KB) fixed partitions according to a pre-compiled partition table; and the eMMC chip is pre-formatted into an EXT4 file system, and a special partition (with a mounting path of / mnt / emmc / aux_rootfs / ) with a capacity of 1 GB is reserved for storing a dynamic configuration database.

[0061] Taking the online upgrade scenario as an example, when the administrator uploads the upgrade file through the IPMI protocol, the firmware management service of the BMC temporarily stores it in the / tmp partition of the eMMC. The compressed package uses a structured storage design inside, including a manifest.json metadata file, a rootfs.squashfs core firmware image, and a newly introduced aux_rootfs.cpio configuration database package. The key to the separation operation lies in the file routing mechanism during the decompression process: the decompression thread first parses the "content_type" field in manifest.json, and when the "aux_rootfs" label is detected, it redirects the corresponding aux_rootfs.cpio package to the eMMC target path, rather than merging it into the rootfs image as in the traditional way.

[0062] At this time, the aux_rootfs.cpio package contains configuration sets for multiple product models, and each directory contains product-specific FRU information files, LCD display icons, sensor calibration parameters, and other non-core data, with a total size of up to 35 MB. These data will be directly packaged into rootfs.squashfs in the traditional scheme, occupying valuable Flash space, while in the present embodiment, they are completely retained in the / mnt / emmc / aux_rootfs / directory of the eMMC.

[0063] The process of writing firmware data to the first storage unit follows a strict partition verification mechanism: the decompressed rootfs.squashfs image is directly burned to the rootfs partition of the Flash through the SPI driver. During this process, the upgrade service calls the mmc_utils tool to verify the remaining space of the rootfs partition. Since the configuration database has been stripped, the size of the rootfs image has been reduced from the original 45 MB to 12 MB, which is far below the 50 MB partition upper limit, thus ensuring successful writing.

[0064] The writing of the configuration database to the second storage unit is performed in an asynchronous manner: a dedicated thread is created to decompress aux_rootfs.cpio to the persistent storage area of the eMMC, and the decompression command is executed in the background, so that even in the event of an unexpected interruption, the transaction log can be recovered.

[0065] To ensure data integrity, the implementation process includes two levels of verification: first, the aux_rootfs.cpio package is verified by SHA256 digest, and after decompression, the key configuration files are verified again. This double protection mechanism ensures the reliability of large-capacity configuration data in eMMC storage, and completely avoids the risk of upgrade failure due to insufficient rootfs space in the traditional scheme.

[0066] When the system finishes upgrading and restarts, the BMC enters the configuration data dynamic loading stage. In the S35 stage of the init.d startup script, the system first reads the product model code preprogrammed in the motherboard CPLD through the I2C bus, and then scans the configuration database in the eMMC with the code as the index.

[0067] The on-demand copy strategy is adopted during loading, only the key startup configuration files (such as fru.bin and bmc_network.cfg) are copied into the tmpfs, and the large-size resources (such as the LCD icon set) are directly pointed to the eMMC source file through the symbolic link.

[0068] The strategy makes the system only need to load about 2MB of key data during startup (the traditional scheme needs to load all 35MB of configuration sets), which significantly speeds up the startup process.

[0069] For runtime dynamic requests (such as Web interface requests for LCD icons), the BMC HTTP service will redirect the file reading path, and when receiving the request, the rewrite rule in the Nginx configuration will actually point the request to the corresponding file in the eMMC. This on-demand access mechanism not only guarantees the completeness of the function, but also avoids the impact on the memory caused by loading all configuration data at once.

[0070] In an embodiment, the present specification provides an electronic device, comprising a processor and a readable storage medium, the readable storage medium stores machine executable instructions capable of being executed by the processor, and the processor executes the machine executable instructions to implement the foregoing configuration data management method. From the hardware architecture, the hardware architecture schematic diagram can be seen in Figure 3 .

[0071] In an embodiment, the present specification provides a readable storage medium, the readable storage medium stores machine executable instructions, and when the machine executable instructions are called and executed by a processor, the machine executable instructions cause the processor to implement the foregoing configuration data management method.

[0072] Here, the readable storage medium can be any electronic, magnetic, optical or other physical storage device, and can contain or store information such as executable instructions, data, etc. For example, the readable storage medium can be: RAM (Radom Access Memory, Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard drive), solid state disk, any type of storage disk (such as optical disk, dvd, etc.), or similar storage medium, or combination thereof.

[0073] The systems, apparatuses, modules, or units disclosed in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, and the specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an e-mail device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0074] For the sake of description, the above apparatuses are described in various units by functions for description. Of course, the functions of the units can be implemented in one or more software and / or hardware in implementing the present specification.

[0075] Those skilled in the art will understand that the embodiments of the present specification can be provided as a method, a system, or a computer program product. Therefore, the present specification can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of the present specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0076] The present specification is described with reference to flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present specification. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and combinations of flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a device implemented in accordance with the flowcharts and / or block diagrams. Figure 1 The functions specified in a flow or multiple flows and / or blocks Figure 1 The functions specified in a flow or multiple flows and / or blocks

[0077] Moreover, these computer program instructions can also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including instruction devices that implement the flowcharts and / or block diagrams. Figure 1 The functions specified in a flow or multiple flows and / or blocks Figure 1 The functions specified in a flow or multiple flows and / or blocks

[0078] These computer program instructions can also be loaded into computer or other programmable data processing devices, so that a series of operation steps are performed on the computer or other programmable data processing devices to generate computer-implemented processes, thus the instructions executed on the computer or other programmable data processing devices provide the function of the flow Figure 1 one or more flows and / or blocks Figure 1 one or more blocks or a plurality of blocks.

[0079] Those skilled in the art should understand that the embodiments of the present specification can be provided as a method, a system or a computer program product. Therefore, the present specification can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present specification can take the form of a computer program product implemented on one or more computer-usable storage media (which can include, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0080] The above only describes the embodiments of the present specification and is not intended to limit the present specification. The present specification can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present specification shall be included in the scope of claims of the present specification.

Claims

1. A configuration data management method, characterized in that: A BMC device applied to a server, wherein the BMC device is mounted with a first storage unit and a second storage unit, and the method includes: Obtain a firmware package to be flashed, the firmware package to be flashed including firmware data and a configuration database, and separate the firmware data and the configuration database of the firmware package to be written; Writing firmware data into the first storage unit and writing a configuration database into the second storage unit; According to the server product model recorded by the local BMC device, matching configuration data is called from the configuration database written into the second storage unit.

2. The method according to claim 1, characterized in that The calling of matching configuration data in the configuration database written into the second storage unit according to the server product model recorded by the local BMC device includes: The matching configuration data is read from the configuration database written into the second storage unit, and the matching configuration data is written into the first storage unit.

3. The method according to claim 1, characterized in that The firmware data includes data necessary for startup and other data; Separate the data necessary for startup and other data from the firmware data; Writing necessary startup data into the first storage unit and writing other data into the second storage unit; In the started state, the associated data is called from other data written into the second storage unit according to a specific instruction.

4. The method according to claim 1, wherein The step of obtaining a firmware package to be written, the firmware package to be written including firmware data and a configuration database, and separating the firmware data and the configuration database of the firmware package to be written includes: Decompress the firmware package to be flashed in the second storage unit; Writing firmware data into the first storage unit and writing a configuration database into the second storage unit includes: Migrate and flash the firmware data of the firmware package to be flashed to the first storage unit.

5. A configuration data management device, characterized in that: A BMC device applied to a server, wherein the BMC device is mounted with a first storage unit and a second storage unit, and the apparatus comprises: The first module is used to obtain a firmware package to be flashed, which includes firmware data and a configuration database, and separate the firmware data and the configuration database of the firmware package to be written; A second module is configured to write firmware data into the first storage unit and write a configuration database into the second storage unit; The third module is configured to call matching configuration data from the configuration database written into the second storage unit according to the server product model recorded by the local BMC device.

6. The device according to claim 5, characterized in that The calling of matching configuration data in the configuration database written into the second storage unit according to the server product model recorded by the local BMC device includes: The matching configuration data is read from the configuration database written into the second storage unit, and the matching configuration data is written into the first storage unit.

7. The device according to claim 5, characterized in that The firmware data includes data necessary for startup and other data; Separate the data necessary for startup and other data from the firmware data; Writing necessary startup data into the first storage unit and writing other data into the second storage unit; In the started state, the associated data is called from other data written into the second storage unit according to a specific instruction.

8. The device according to claim 5, characterized in that The step of obtaining a firmware package to be flashed, the firmware package to be flashed including firmware data and a configuration database, and separating the firmware data and the configuration database of the firmware package to be written includes: Decompress the firmware package to be flashed in the second storage unit; Writing firmware data into the first storage unit and writing a configuration database into the second storage unit includes: Migrate and flash the firmware data of the firmware package to be flashed to the first storage unit.

9. An electronic device, characterized in that: include: A processor and a readable storage medium, wherein the readable storage medium stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the method according to any one of claims 1 to 4.

10. A readable storage medium, characterized in that: The readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the method according to any one of claims 1 to 4.

Images