A default value configuration method, device, apparatus and medium

Abstract

The application discloses a default value configuration method, device, equipment and medium. The method comprises the following steps: in response to a first start instruction of a target device, sending a default variable data request to a second firmware, so that the second firmware searches a target configuration file matched according to a target configuration identifier acquired in advance; acquiring the target configuration file from the second firmware; and updating the default values of various target configuration options in the target device according to the default variable data in the target configuration file. The application solves the problem that in the prior art, the BIOS code needs to be modified according to different dynamic modifications of some options and the newly added SKU package each time, resulting in low development efficiency, realizes that one configuration file is configured for each SKU, and different SKUs are independent and do not affect each other, improves the independence of the SKUs, and improves the development efficiency of the BIOS code.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a default value configuration method, apparatus, device, and medium. Background Technology

[0002] In the server industry, to fully meet customer needs, the same server model is usually shipped with different configurations. Each configuration is called a minimum stock keeping unit (SKU) or a package. For example, SKU1 requires a model A central processing unit (CPU), while SKU2 requires a model B CPU; or SKU1 requires a model C network interface card (NIC), while SKU2 requires a model D NIC.

[0003] Because each SKU corresponds to different CPUs, memory, peripherals, etc. on the motherboard, and their application scenarios also differ, the requirements for the default values ​​of the Basic Input Output System (BIOS) will also vary. For example, for SKUs with high-performance computing requirements, the corresponding power consumption parameters need to be increased to maximize performance advantages; while for SKUs with low real-time response performance requirements, it is necessary to maintain a low power consumption state to save energy. Alternatively, some SKUs require the hard drive as the first boot device, while others require the network card as the first boot device. Such requirements are not uncommon, so the BIOS needs to be able to switch different default values ​​according to different SKUs to meet customer requirements.

[0004] In the BIOS, the options in the Setup section are described using a Virtual Form Representation (VFR) language. The VFR file not only describes the options but also specifies the default values ​​for each option. Currently, the mainstream method used by various manufacturers is to include a single VFR file in the BIOS code, and the VFR compiler generates only one set of default values ​​after parsing the VFR file. Therefore, only one initial set of default values ​​is available at boot time. The current practice is to dynamically modify certain options during boot based on different SKUs. Each time a new SKU package is added, the BIOS code needs to be modified, resulting in low development efficiency. Summary of the Invention

[0005] This invention provides a default value configuration method, apparatus, device, and medium to solve the problem in related technologies that require dynamic modification of certain options based on different SKUs and modification of BIOS code for each new SKU package, resulting in low development efficiency.

[0006] According to one aspect of the present invention, a default value configuration method is provided, comprising:

[0007] In response to the first power-on command of the target device, a default variable data request is sent to the second firmware so that the second firmware can find the matching target configuration file according to the pre-acquired target configuration identifier;

[0008] Obtain the target configuration file from the second firmware;

[0009] Update the default values ​​of each target configuration option in the target device according to the default variable data in the target configuration file.

[0010] The technical solution of this invention allows the first firmware to automatically find a matching target configuration file based on the target configuration identifier corresponding to the target device through the second firmware, obtain the target configuration file from the second firmware, and update the default values ​​of each target configuration option in the target device according to the default variable data in the target configuration file. This eliminates the need to dynamically modify the default values ​​of the target configuration options according to different SKUs during the boot process, thus avoiding the problem of low development efficiency.

[0011] Optionally, the second firmware may obtain the target configuration identifier in the following ways:

[0012] When the default variable data request carries a target configuration identifier, the second firmware parses the default variable data request to obtain the corresponding target configuration identifier;

[0013] If the target configuration identifier is not included in the default variable data request, the second firmware directly obtains the target configuration identifier.

[0014] The technical solution of this invention can obtain the target configuration identifier corresponding to the target device through the first firmware and send the target configuration identifier to the second firmware; or the second firmware can automatically obtain the target configuration identifier after receiving the default variable data request, and then match the corresponding target configuration file according to the target configuration identifier. This realizes that a configuration file is configured for each SKU, and different SKUs are independent of each other and do not affect each other, thus improving the independence of SKUs.

[0015] Optionally, obtaining the target configuration file from the second firmware includes:

[0016] Receive the target configuration file fed back by the second firmware;

[0017] Alternatively, the system may receive the default variable access path from the second firmware and retrieve the corresponding target configuration file from the second firmware according to the default variable access path.

[0018] The technical solution of this invention can directly find the matching target configuration file according to the target configuration identifier through the second firmware and send the target configuration file directly to the first firmware; alternatively, the second firmware can send the default variable access path matching the target configuration identifier to the first firmware, and the first firmware can actively pull the matching target configuration file from the second firmware according to the default variable access path, thereby ensuring that there is a one-to-one correspondence between SKU, configuration identifier and configuration file, and that different SKUs are independent of each other and do not affect each other, thus improving the independence of SKU.

[0019] Optionally, the second firmware searches for a matching target configuration file according to a pre-acquired target configuration identifier, including:

[0020] The second firmware obtains the variable header corresponding to each pre-created configuration file; wherein, each variable header carries the configuration identifier of the corresponding configuration file; each configuration file contains a set of default variable data for each target configuration option;

[0021] The target configuration identifier is compared with the configuration identifier carried in each variable header;

[0022] The configuration file that matches the target configuration identifier is taken as the corresponding target configuration file.

[0023] The technical solution of this invention can pre-create configuration files corresponding to multiple SKUs in the second firmware, and include a corresponding configuration identifier in the variable header of each configuration file. The pre-obtained target configuration identifier is compared with the configuration identifier carried in each variable header, so that the configuration file that matches the target configuration identifier is used as the corresponding target configuration file. This realizes that a corresponding configuration file is created for each SKU, and the configuration files corresponding to different SKUs are independent of each other and do not affect each other, thus improving the independence of SKUs.

[0024] Optionally, the default value configuration method further includes:

[0025] In response to the adjustment of the default value, a new configuration file is added to the second firmware through the preset interface.

[0026] The technical solution of this invention allows for the direct addition of a new configuration file in the second firmware via a preset interface when the default value needs to be modified or added, without requiring modification of the BIOS code. This improves the scalability of SKUs and enhances development efficiency.

[0027] Optionally, updating the default values ​​of each target configuration option in the target device according to the default variable data in the target configuration file includes:

[0028] The target configuration file is parsed to obtain the corresponding default variable data;

[0029] The default variable data in the first storage block of the target device is updated using the default variable data of the target configuration file;

[0030] The updated default variable data is copied to the second storage block of the target device, and the default values ​​of each target configuration option in the target device are updated.

[0031] The technical solution of this invention can obtain the target configuration file through the first firmware, parse it to obtain the corresponding default variable data, then use the default variable data to update the default variable data in the first storage block of the target device, and copy the updated default variable data to the second storage block of the target device to update the default values ​​of each target configuration option in the target device, thereby improving the update efficiency of the default values.

[0032] Optionally, the target configuration file is a JSON file.

[0033] The technical solution of this invention can be achieved by setting the target configuration file as a JSON file, taking advantage of the readability of JSON files to facilitate understanding by developers.

[0034] According to another aspect of the present invention, a default value configuration device is provided, comprising:

[0035] The request sending module is configured to send a default variable data request to the second firmware in response to the first power-on command of the target device, so that the second firmware can find the matching target configuration file according to the pre-acquired target configuration identifier;

[0036] The file acquisition module is configured to acquire the target configuration file from the second firmware.

[0037] The default value update module is configured to update the default values ​​of each target configuration option in the target device according to the default variable data in the target configuration file.

[0038] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0039] At least one processor;

[0040] and a memory that is in communication with the at least one processor network;

[0041] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the default value configuration method according to any embodiment of the present invention.

[0042] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the default value configuration method described in any embodiment of the present invention.

[0043] The technical solution of this invention, after receiving the first power-on command of the target device, involves the first firmware sending a default variable data request to the second firmware, so that the second firmware can find a matching target configuration file according to the pre-acquired target configuration identifier; and obtaining the target configuration file from the second firmware, and updating the default values ​​of each target configuration option in the target device according to the default variable data in the target configuration file. This solves the problem in the prior art that it is necessary to dynamically modify certain options according to different SKUs and modify the BIOS code for each new SKU package, resulting in low development efficiency. It realizes that a configuration file is configured for each SKU, and different SKUs are independent of each other and do not affect each other, thereby improving the independence of SKUs and improving the development efficiency of BIOS code.

[0044] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0046] Figure 1 A schematic diagram illustrating the compilation of a VFR file for existing technology.

[0047] Figure 2 This is a schematic diagram illustrating the implementation of a first-time power-on scenario using existing technology.

[0048] Figure 3 This is a schematic diagram illustrating an implementation scenario where a user manually modifies options, based on existing technology.

[0049] Figure 4 This is a schematic diagram illustrating an implementation of a default value loading scenario provided by existing technology.

[0050] Figure 5 This is a flowchart of a default value configuration method provided in Embodiment 1 of the present invention.

[0051] Figure 6 This is a flowchart of a default value configuration method provided in Embodiment 2 of the present invention.

[0052] Figure 7 This is a flowchart of a default value configuration method provided in Embodiment 3 of the present invention.

[0053] Figure 8 This is a schematic diagram of the structural configuration of a server provided in Embodiment 4 of the present invention.

[0054] Figure 9 This is a schematic diagram illustrating the implementation of a first-time power-on scenario provided in Embodiment 4 of the present invention.

[0055] Figure 10 This is a schematic diagram illustrating the implementation of adding a new configuration file according to Embodiment 4 of the present invention.

[0056] Figure 11 This is a schematic diagram illustrating an implementation of parsing a JSON file provided in Embodiment 4 of the present invention.

[0057] Figure 12 This is a schematic diagram of a default value configuration device provided in Embodiment 5 of the present invention.

[0058] Figure 13 A schematic diagram of the structure of an electronic device for implementing the default value configuration method of this invention. Detailed Implementation

[0059] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0060] It should be noted that the terms "target," "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising," "including," and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0061] It should be noted that the existing BIOS architecture can include four scenarios: compilation scenario, first boot scenario, user manually modifying options scenario, and user loading default values ​​scenario.

[0062] 1) Compilation scenario

[0063] For ease of description, only the Setup.vfr file will be described here; the same applies to other VFR files. Figure 1 This is a compilation diagram of a VFR file provided for existing technology. For example... Figure 1 As shown, the VFR compiler parses the Setup.vfr file and generates a set of default variable data, which is stored in the FV_MAIN block. The default variable data contains multiple variables.

[0064] 2) First boot-up scenario

[0065] Figure 2 This is a schematic diagram illustrating an implementation of a first-time power-on scenario using existing technology. (Example:) Figure 2 As shown, during the first boot, the Variable area of ​​the NVRAM block is empty. During the first boot, the BIOS firmware copies the DefaultVariable data of FV_MAIN into the NVRAM. On subsequent boots, the BIOS will use the Variable data from the NVRAM.

[0066] 3) User manually modifies options scenario

[0067] Figure 3 This is a schematic diagram illustrating an implementation scenario where a user manually modifies options, based on existing technology. For example... Figure 3As shown, after entering the BIOS Setup interface, users can manually modify the options. After modifying the options, press the save button, and the BIOS will update the NVRAM Variable data. The FV_MAIN Default Variable data will never change.

[0068] 4) Loading default values ​​scenario

[0069] Figure 4 This is a schematic diagram illustrating an implementation of a default value loading scenario provided by existing technology. For example... Figure 4 As shown, when a user performs a Load default in the BIOS Setup interface or a Load default in the general Clear CMOS method, the BIOS will copy the Default Variable data of FV_MAIN to NVRAM, overwriting the original Variable data.

[0070] Example 1

[0071] Figure 5 This is a flowchart illustrating a default value configuration method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations where, during device startup, a matching configuration file is automatically located according to a configuration identifier, and the default values ​​of each target configuration option are automatically updated. This method can be executed by a default value configuration device, which can be implemented in hardware and / or software, and this default value configuration processing device can be configured within an electronic device. Exemplarily, the electronic device can include, but is not limited to, personal computers and servers. The default value configuration method in this embodiment is applied to a first firmware. It should be noted that the electronic device includes a first firmware and a second firmware, wherein the first firmware can be BIOS firmware, and the second firmware can be Baseboard Management Controller (BMC) firmware. Furthermore, the BMC firmware can be an independent embedded chip within the electronic device.

[0072] like Figure 5 As shown, the method includes:

[0073] S101. In response to the first power-on command of the target device, a default variable data request is sent to the second firmware so that the second firmware can find the matching target configuration file according to the pre-acquired target configuration identifier.

[0074] The target configuration file corresponds to an option configuration package, which can be a SKU package (or simply SKU). The first boot command refers to the first boot command of the target device. In actual operation, the second firmware can determine whether the electronic device is being powered on for the first time using a boot flag. The value of the boot flag differs depending on whether the electronic device is being powered on for the first time or not. For example, assuming the boot flag is FirstBoot Flag, its value is 1 when the electronic device is being powered on for the first time, and 0 when the electronic device is being powered on not for the first time.

[0075] Optionally, the default variable data request refers to a request to obtain default variable data; the target configuration identifier refers to the configuration identifier used by default by the target device. Optionally, the configuration identifier corresponds one-to-one with the configuration file, and one configuration file corresponds to one SKU. The configuration identifier is used to identify each SKU, and can also be used as the file name of each configuration file. Optionally, the configuration identifier can be used to name the file of each configuration file.

[0076] Optionally, the configuration identifier can be determined using a DIP switch configured on the electronic device's motherboard or a Field Replaceable Unit (FRU). For example, when using a DIP switch to determine the configuration identifier, each position of the DIP switch can be set to its corresponding value to determine the configuration identifier, i.e., the SKU identifier. For example, setting the 8th DIP switch to 1 represents SKU1, i.e., 00000001 represents SKU1. Since the first and second firmware can exchange data via the Intelligent Platform Management Interface (IPMI), the DIP switch can be connected to at least one of the first or second firmware to enable the first or second firmware to obtain the configuration identifier.

[0077] The motherboard of an electronic device contains an Electrically Erasable Programmable Read-Only Memory (EEPROM) chip, also known as an FRU chip. The FRU chip can be programmed with different data, such as the FRU string "SKU number: 1" as a configuration identifier. When the configuration identifier is determined using the FRU, the second firmware can retrieve the string corresponding to the configuration identifier from the FRU.

[0078] Both the DIP switch and the FRU chip are independent of the first and second firmware. In other words, the configuration identifier of the current motherboard of the electronic device can be changed simply by modifying the DIP switch or the FRU string without making any changes to the first or second firmware.

[0079] Optionally, the data exchange format for each configuration file can be JSON. This can be understood as each configuration file being a JSON file. Each configuration file contains a set of default variable data for each BIOS option. For example, assuming a target device's target configuration options are BIOS options, and the number of BIOS options is 1000, then a configuration file would contain the default values ​​for 1000 BIOS options.

[0080] Optionally, the target configuration file can be a JSON file. This allows developers to easily understand the file by leveraging the readability of JSON.

[0081] Optionally, the second firmware can be an embedded chip in the target device, which can use a Linux system.

[0082] When the target device is powered on for the first time, the variable area in the second storage block of the target device is empty. The first firmware can send a default variable data request to the second firmware so that the second firmware can find the matching target configuration file according to the pre-acquired target configuration identifier.

[0083] Optionally, the second firmware obtains the target configuration identifier in the following ways: if the target configuration identifier is carried in the default variable data request, the second firmware parses the default variable data request to obtain the corresponding target configuration identifier; if the target configuration identifier is not carried in the default variable data request, the second firmware directly obtains the target configuration identifier.

[0084] Therefore, the first firmware obtains the target configuration identifier corresponding to the target device and sends the target configuration identifier to the second firmware; alternatively, after the second firmware receives the default variable data request, the second firmware automatically obtains the target configuration identifier and then matches the corresponding target configuration file according to the target configuration identifier. This achieves the configuration of a configuration file for each SKU, and different SKUs are independent of each other and do not affect each other, thus improving the independence of SKUs.

[0085] Optionally, the default variable data request sent from the first firmware to the second firmware may or may not include a target configuration identifier. Optionally, if the default variable data request includes a target configuration identifier, it can be understood that the first firmware obtains the target device's target configuration identifier, then sends it to the second firmware via the default variable request, so that the second firmware can then find a matching target configuration file based on the target configuration identifier and send it back to the first firmware. Optionally, if the default variable data request does not include a target configuration identifier, it can be understood that the second firmware obtains the target device's target configuration identifier, then finds a matching target configuration file based on the target configuration identifier and sends it back to the first firmware.

[0086] Optionally, the second firmware searches for a matching target configuration file according to a pre-acquired target configuration identifier, including: the second firmware obtains a variable header corresponding to each pre-created configuration file; wherein each variable header carries a configuration identifier for the corresponding configuration file; each configuration file contains a set of default variable data for each target configuration option; the target configuration identifier is compared with the configuration identifier carried in each variable header; and the configuration file that matches the target configuration identifier is taken as the corresponding target configuration file.

[0087] Each configuration file corresponds to one SKU. Therefore, multiple configuration files for each SKU can be pre-created in the second firmware. Each configuration file includes a corresponding configuration identifier in its variable header. The pre-obtained target configuration identifier is compared with the configuration identifier carried in each variable header, and the configuration file matching the target configuration identifier is used as the corresponding target configuration file. This achieves the creation of a corresponding configuration file for each SKU, ensuring that the configuration files for different SKUs are independent and do not affect each other, thus improving the independence of SKUs.

[0088] Optionally, each configuration file is configured with a variable header that stores a configuration identifier, and this configuration identifier has a mapping relationship with the configuration file. Multiple configuration files are pre-created in the second firmware, and the configuration identifier, SKU, and default variable data of each configuration file are different. This can be understood as a one-to-one mapping relationship between the configuration file, configuration identifier, SKU, and default variable data.

[0089] Optionally, after the second firmware obtains the target configuration identifier of the target device, the second firmware traverses the variable headers of all configuration files and compares the configuration identifier in the variable header with its own target configuration identifier to find the configuration file that matches the target configuration identifier, and uses it as the corresponding target configuration file.

[0090] S102. Obtain the target configuration file from the second firmware.

[0091] Optionally, obtaining the target configuration file from the second firmware includes: receiving the target configuration file fed back by the second firmware; or, receiving the default variable access path fed back by the second firmware, and obtaining the corresponding target configuration file from the second firmware according to the default variable access path.

[0092] Therefore, the second firmware can directly find the matching target configuration file according to the target configuration identifier and send the target configuration file directly to the first firmware; alternatively, the second firmware can send the default variable access path matching the target configuration identifier to the first firmware, and the first firmware can actively pull the matching target configuration file from the second firmware according to the default variable access path. This ensures that there is a one-to-one correspondence between SKU, configuration identifier and configuration file, and that different SKUs are independent of each other and do not affect each other, thus improving the independence of SKU.

[0093] Optionally, the default variable access path is used to characterize the access and retrieval path for default variable data in each configuration file. The access and retrieval path for default variable data is unique in each configuration file, and the default variable access path is different for each configuration file.

[0094] Optionally, after the second firmware finds a matching target configuration file based on the target configuration identifier, it can directly send the target configuration file to the first firmware, so that the first firmware can obtain the target configuration file as quickly as possible, thereby speeding up the update efficiency of the default values ​​of various target configuration options in the first firmware. Optionally, after the second firmware finds a matching target configuration file based on the target configuration identifier, it can identify and obtain the default variable access path corresponding to the target configuration file, and only send the default variable access path corresponding to the target configuration file to the first firmware, so that the first firmware itself actively pulls the corresponding target configuration file from the second firmware.

[0095] S103. Update the default values ​​of each target configuration option in the target device according to the default variable data in the target configuration file.

[0096] Optionally, the default values ​​of each target configuration option in the target device are updated according to the default variable data in the target configuration file, including: parsing the target configuration file to obtain the corresponding default variable data; updating the default variable data in the first storage block of the target device with the default variable data in the target configuration file; copying the updated default variable data to the second storage block of the target device, and updating the default values ​​of each target configuration option in the target device.

[0097] Therefore, after obtaining the target configuration file through the first firmware, it can be parsed to obtain the corresponding default variable data; then the default variable data in the first storage block of the target device can be updated using the default variable data, and the updated default variable data can be copied to the second storage block of the target device to update the default values ​​of each target configuration option in the target device, thereby improving the efficiency of updating the default values.

[0098] Optionally, the first firmware in each electronic device includes memory, such as read-only memory (ROM), a non-volatile memory for storing the BIOS program. This memory can be divided into multiple storage blocks. Common storage blocks may include, but are not limited to, NVRAM, FV_MAIN, and FV_BB.

[0099] Optionally, the first storage block can be FV_MAIN or FV_BB; the second storage block can be NVRAM. After the first firmware obtains the target configuration file, it parses it to obtain the corresponding default variable data; then it updates the default variable data in the first storage block of the target device with the default variable data; then it copies the updated default variable data to the second storage block of the target device and updates the default values ​​of each target configuration option in the target device.

[0100] Optionally, after entering the target configuration option configuration interface, the user can manually modify the target configuration option and press the save button after the modification is completed. The first firmware will automatically update the variable data in the second storage block, but the default variable data in the first storage block will never change.

[0101] Optionally, the default value configuration method also includes: in response to the adjustment operation of the default value, adding a new configuration file in the second firmware through a preset interface.

[0102] The default interface can be a remote management and monitoring interface. For example, the default interface can be a Redfish interface. When using the Redfish interface to establish communication between the first and second firmware, the Redfish protocol can be used to implement data transmission between the two firmwares. Therefore, if the default values ​​need to be modified or added, a new configuration file can be added directly to the second firmware through the default interface without modifying the BIOS code, improving SKU scalability and development efficiency.

[0103] Optionally, Redfish is a management standard based on HTTPS services, utilizing a RESTful interface for device management. The first firmware and the second firmware can exchange data through a preset interface, with the default values ​​of the first firmware stored in the second firmware in JSON format.

[0104] Under the existing architecture, taking the first firmware as the BIOS firmware, the second firmware as the BMC firmware, the default interface as the Redfish interface, and the target configuration option as the BIOS option as an example, this article explains the default configuration process of the existing BIOS option. The BMC firmware includes three files describing the BIOS options:

[0105] Attribute.json: Used to describe the name, attributes, default values, and other information of BIOS options;

[0106] CurrentSetting.json: This describes the current values ​​of BIOS options. The BIOS updates CurrentSetting.json whenever BIOS settings change.

[0107] FeatureSetting.json: This file describes the modified values ​​of BIOS options. If a user needs to modify BIOS options via REDFISH, a new FeatureSetting.json file needs to be created. The BIOS will read FeatureSetting.json when it boots up and then modify the option values.

[0108] It should be noted that the Attribute.json, CurrentSetting.json, and FeatureSetting.json files are all part of the existing Redfish mechanism. Through these three files, users can view the descriptions of all options and their current values, and modify the current values ​​of the options.

[0109] The newly added DefaultSetting.json file in this invention has the same file format as the three JSON files mentioned above, and its function is to provide default values ​​to the BIOS firmware during the first boot.

[0110] In the Redfish interface, BIOS options are described using Mapping IDs. Each option has a unique Mapping ID. Combined with the concept of UEFI Variable, each Mapping ID corresponds to a member variable in a structure.

[0111] In this embodiment of the invention, a new configuration file is added to the BMC firmware to describe the default values ​​of BIOS options. For example, the configuration file can be a DefaultSetting_Sku_n.json file. Optionally, when adding a new SKU or modifying the default values ​​of BIOS options corresponding to an existing SKU, neither the BIOS firmware nor the BMC firmware code needs to be modified; only a new DefaultSetting_Sku_n.json file needs to be added through the Redfish interface.

[0112] The technical solution of this invention, after receiving the first power-on command of the target device, sends a default variable data request to the second firmware, so that the second firmware can find the matching target configuration file according to the pre-acquired target configuration identifier, obtain the target configuration file from the second firmware, and update the default values ​​of each target configuration option in the target device according to the default variable data in the target configuration file. This solves the problem of low development efficiency caused by the need to dynamically modify certain options according to different SKUs and modify the BIOS code for each new SKU package in the prior art. It realizes that a configuration file is configured for each SKU, and different SKUs are independent of each other and do not affect each other, which improves the independence of SKUs and improves the development efficiency of BIOS code.

[0113] Example 2

[0114] Figure 6 This is a flowchart illustrating a default value configuration method provided in Embodiment 2 of the present invention. This embodiment of the present invention can be combined with various optional solutions from one or more of the above embodiments. For example... Figure 6 As shown, the method includes:

[0115] S201. In response to the first power-on command of the target device, the first firmware sends a default variable data request to the second firmware.

[0116] S202, The second firmware obtains the variable header corresponding to each pre-created configuration file.

[0117] Each variable header carries a configuration identifier for the corresponding configuration file; each configuration file corresponds to an inventory unit (SKU), and each configuration file contains a set of default variable data for each target configuration option.

[0118] S203. The second firmware compares the target configuration identifier with the configuration identifier carried in each variable header.

[0119] S204. The second firmware will use the configuration file that matches the target configuration identifier as the corresponding target configuration file.

[0120] S205, The first firmware receives the target configuration file fed back by the second firmware.

[0121] S206. The first firmware parses the target configuration file to obtain the corresponding default variable data.

[0122] S207. The first firmware updates the default variable data in the first storage block of the target device using the default variable data of the target configuration file.

[0123] S208. The first firmware copies the updated default variable data to the second storage block of the target device and updates the default values ​​of each target configuration option in the target device.

[0124] The technical solution of this invention allows the first firmware to send a default variable data request to the second firmware upon receiving the initial power-on command. This enables the second firmware to compare the target configuration identifier with the configuration identifier carried in the variable header of each configuration file, and to select the configuration file matching the target configuration identifier as the corresponding target configuration file. The second firmware then sends the target configuration file to the first firmware via a preset interface. The first firmware parses the target configuration file to obtain the corresponding default variable data, updates the default variable data in the first storage block of the target device using the default variable data from the target configuration file, copies the updated default variable data to the second storage block of the target device, and updates the default values ​​of each target configuration option in the target device. This achieves the creation of a corresponding configuration file for each SKU, ensuring that different SKUs are independent and do not affect each other, thus improving the independence and scalability of SKUs.

[0125] Example 3

[0126] Figure 7 This is a flowchart illustrating a default value configuration method provided in Embodiment 3 of the present invention. Figure 7 As shown, the default value configuration method in this embodiment includes the following steps:

[0127] S301. In response to the first power-on command of the target device, the first firmware sends a default variable data request to the second firmware.

[0128] S302, The second firmware obtains the variable header corresponding to each pre-created configuration file.

[0129] Each variable header carries a configuration identifier for the corresponding configuration file; each configuration file corresponds to an inventory unit (SKU), and each configuration file contains a set of default variable data for each target configuration option.

[0130] S303, The second firmware compares the target configuration identifier with the configuration identifier carried in each variable header;

[0131] S304. The second firmware will use the configuration file that matches the target configuration identifier as the corresponding target configuration file.

[0132] S305. The first firmware receives the default variable access path fed back by the second firmware, and obtains the corresponding target configuration file from the second firmware according to the default variable access path.

[0133] S306. The first firmware parses the target configuration file to obtain the corresponding default variable data.

[0134] S307. The first firmware updates the default variable data in the first storage block of the target device using the default variable data of the target configuration file.

[0135] S308. The first firmware copies the updated default variable data to the second storage block of the target device and updates the default values ​​of each target configuration option in the target device.

[0136] S309. In response to the adjustment operation of the default value, a new configuration file is added in the second firmware through the preset interface.

[0137] The technical solution of this invention allows for the addition of a new configuration file in the second firmware via a preset interface when adding a new SKU or modifying the default value of the target configuration option corresponding to an existing SKU. This eliminates the need to modify the BIOS and BMC code, significantly reducing the development workload of the first and second firmware and improving the development efficiency of developers.

[0138] Example 4

[0139] Figure 8 This is a schematic diagram of the structural configuration of a server provided in Embodiment 4 of the present invention. In this embodiment, an electronic device is used as the server, the first firmware is BIOS firmware, the second firmware is BMC firmware, and the preset interface is a REDFISH interface, to illustrate the server's structural configuration. Figure 8 As shown, the server in this embodiment includes: an operating system (OS), BIOS firmware, and BMC firmware. The BIOS firmware establishes a communication connection with the BMC firmware via a REDFISH interface.

[0140] Figure 9 This is a schematic diagram illustrating the implementation of a first-boot scenario according to Embodiment 4 of the present invention. In this embodiment, the implementation process of the first-boot scenario is described using BIOS firmware as the first firmware and BMC firmware as the second firmware as examples. During the first boot, the Variable region of the NVRAM block is empty. For example... Figure 9As shown, the implementation process of the first power-on scenario in this embodiment includes three steps:

[0141] Step 1: The BIOS firmware sends a default variable data request to the BMC firmware. After receiving the default variable data request, the BMC firmware first obtains the SKU ID of the current server, then iterates through the headers of all DefaultSetting.json files (the headers contain configuration identifiers), finds the corresponding DefaultSetting.json file, and finally sends the matching DefaultSetting.json file to the BIOS.

[0142] Step 2: After the BIOS firmware obtains the DefaultSetting.json data, it parses it and then updates the Default Variable data in the FV_MAIN block.

[0143] Step 3: As with existing solutions, the BIOS firmware copies the Default Variable data of FV_MAIN into NVRAM.

[0144] It should be noted that the compilation scenario, the user manually modifying option scenario, and the loading default value scenario in the embodiments of the present invention are the same as those in the existing solutions, and will not be described again here.

[0145] Figure 10 This is a schematic diagram illustrating the implementation of adding a new configuration file according to Embodiment 4 of the present invention. In this embodiment, taking the first firmware as BIOS firmware, the second firmware as BMC firmware, and the preset interface as the Redfish interface as an example, the implementation process of adjusting default values ​​is explained. In this embodiment, Redfish protocol data can be transmitted between the debugging host and the BMC firmware via a LAN network; maintenance personnel can perform operations such as adding, deleting, modifying, and querying configuration files in the BMC firmware by operating on the debugging host. Figure 10 As shown, this describes a scenario where maintenance personnel add a configuration file for a new SKU by debugging the host. When adding a configuration file, there is no need to modify the BIOS firmware and BMC firmware. The configuration file can be added directly in the BMC firmware through the debugging host, thus realizing the addition of configuration files conveniently and quickly.

[0146] Figure 11 This is a schematic diagram illustrating the implementation of parsing a JSON file according to Embodiment 4 of the present invention. In this embodiment, taking the first firmware as BIOS firmware and the second firmware as BMC firmware as examples, the implementation process of parseting a JSON file using BIOS firmware is explained. Figure 11As shown, after the BIOS firmware obtains the JSON file from the BMC firmware, it needs to parse the JSON file. The JSON file describes the value of each option in string form, making it a highly readable language. Variable data is stored in binary form, typically with each storage unit containing the value of one option (though some options may occupy multiple storage units). The BIOS firmware needs to parse the JSON file. For example, if the BIOS firmware parses the option value of Setup001 as 1, it will find storage unit 1 and write its value as 1; if it parses the option value of Setup002 as 1, it will find storage unit 2 and write its value as 1, and so on. One storage unit refers to one byte, which contains 8 bits.

[0147] Example 5

[0148] Figure 12 This is a schematic diagram of a default value configuration device provided in Embodiment 5 of the present invention. The default value configuration device can be configured in an electronic device and applied to the first firmware. For example... Figure 12 As shown, the default value configuration device includes: a request sending module 401, a file acquisition module 402, and a default value update module 403.

[0149] The request sending module 401 is configured to send a default variable data request to the second firmware in response to the first power-on command of the target device, so that the second firmware can find the matching target configuration file according to the pre-acquired target configuration identifier.

[0150] The file acquisition module 402 is configured to acquire the target configuration file from the second firmware.

[0151] The default value update module 403 is configured to update the default values ​​of each target configuration option in the target device according to the default variable data in the target configuration file.

[0152] The technical solution of this invention, after receiving the first power-on command of the target device, sends a default variable data request to the second firmware, so that the second firmware can find the matching target configuration file according to the pre-acquired target configuration identifier, obtain the target configuration file from the second firmware, and update the default values ​​of each target configuration option in the target device according to the default variable data in the target configuration file. This solves the problem of low development efficiency caused by the need to dynamically modify certain options according to different SKUs and modify the BIOS code for each new SKU package in the prior art. It realizes that a configuration file is configured for each SKU, and different SKUs are independent of each other and do not affect each other, which improves the independence of SKUs and improves the development efficiency of BIOS code.

[0153] In an optional embodiment of the present invention, the method by which the second firmware obtains the target configuration identifier may specifically include: if the target configuration identifier is carried in the default variable data request, the second firmware parses the default variable data request to obtain the corresponding target configuration identifier; if the target configuration identifier is not carried in the default variable data request, the second firmware directly obtains the target configuration identifier.

[0154] In an optional embodiment of the present invention, the target configuration file may be obtained from the second firmware, specifically by: receiving the target configuration file fed back by the second firmware; or, receiving the default variable access path fed back by the second firmware, and obtaining the corresponding target configuration file from the second firmware according to the default variable access path.

[0155] In an optional embodiment of the present invention, when the second firmware searches for a matching target configuration file according to a pre-acquired target configuration identifier, it is specifically configured to: obtain a variable header corresponding to each pre-created configuration file; wherein each variable header carries a configuration identifier for the corresponding configuration file; each configuration file corresponds to a stock unit (SKU), and each configuration file contains a set of default variable data for each target configuration option; compare the target configuration identifier with the configuration identifier carried in each variable header; and take the configuration file that matches the target configuration identifier as the corresponding target configuration file.

[0156] In an optional embodiment of the present invention, the default value configuration device may further include: a configuration file addition module, used to add a new configuration file in the second firmware through a preset interface in response to the adjustment operation of the default value.

[0157] In an optional embodiment of the present invention, the default value update module 403 is optionally used to: parse the target configuration file to obtain the corresponding default variable data; update the default variable data in the first storage block of the target device using the default variable data of the target configuration file; copy the updated default variable data to the second storage block of the target device, and update the default values ​​of each target configuration option in the target device.

[0158] In one optional embodiment of the present invention, the target configuration file may be a JSON file.

[0159] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0160] The above-described default value configuration device can execute the default value configuration method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the default value configuration method.

[0161] Example 6

[0162] Figure 13 A schematic diagram of the structure of an electronic device 10 that can be used to implement the default value configuration method of embodiments of the present invention is shown. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the invention described and / or claimed herein.

[0163] like Figure 13 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 and a random access memory (RAM) 13, which are network-communicated with the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer programs stored in the ROM 12 or constructed from storage units 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0164] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0165] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the default configuration method.

[0166] In some embodiments, the default value configuration method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is built into RAM 13 and executed by processor 11, one or more steps of the default value configuration method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the default value configuration method by any other suitable means (e.g., by means of firmware).

[0167] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0168] Computer programs used to implement the default value configuration method of the present invention can be written in any combination of one or more programming languages. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0169] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0170] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0171] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0172] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0173] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and no limitation is imposed herein.

[0174] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method of configuring default values, characterized by, The application is applied to the first firmware, comprising: In response to the first boot instruction of the target device, a default variable data request is sent to the second firmware to make the second firmware search for a matching target configuration file according to a target configuration identifier obtained in advance; wherein the target configuration identifier is obtained by one of the following hardware methods: the physical dialing state of the dialer on the mainboard of the target device is determined, and the dialer is independent of the first firmware and the second firmware; the string burned on the FRU chip on the mainboard of the target device is determined, and the second firmware directly reads the FRU chip data; Wherein, the second firmware searches for a matching target configuration file according to a target configuration identifier obtained in advance, comprising: The second firmware obtains a variable header corresponding to each configuration file created in advance; wherein each variable header carries the configuration identifier of the corresponding configuration file; each configuration file contains a default variable data of each target configuration option; the target configuration identifier is compared with the configuration identifier carried in each variable header; the configuration file matched with the target configuration identifier is taken as the corresponding target configuration file; Obtaining the target configuration file from the second firmware; Updating the default values of each target configuration option in the target device according to the default variable data in the target configuration file; In response to the adjustment operation of the default value, a new JSON format configuration file is added in the second firmware through the Redfish interface, the new configuration file carries an independent variable header and corresponds to a new SKU; the new JSON format configuration file is used to provide the default value when booting for the first time; Wherein, one configuration file is configured for each SKU, and different SKUs are independent of each other.

2. The method of claim 1, wherein, The way the second firmware obtains the target configuration identifier includes: In the case that the target configuration identifier is carried in the default variable data request, the second firmware analyzes the default variable data request to obtain the corresponding target configuration identifier; In the case that the target configuration identifier is not carried in the default variable data request, the second firmware directly obtains the target configuration identifier.

3. The method of claim 1, wherein, The target configuration file is obtained from the second firmware, comprising: Receiving the target configuration file fed back by the second firmware; Or, receiving the default variable access path fed back by the second firmware, and obtaining the corresponding target configuration file from the second firmware according to the default variable access path.

4. The method of claim 1, wherein, Updating the default values of each target configuration option in the target device according to the default variable data in the target configuration file, comprising: Parsing the target configuration file to obtain the corresponding default variable data; Using the default variable data of the target configuration file to update the default variable data in the first storage block of the target device; Copy the updated default variable data to the second storage block of the target device, and update the default values of each target configuration option in the target device.

5. A default value configuration apparatus characterized by comprising: Comprising: The request sending module is configured to send a default variable data request to the second firmware in response to a first boot instruction of the target device, so that the second firmware searches for a matching target configuration file according to a target configuration identifier obtained in advance; wherein the target configuration identifier is obtained by one of the following hardware methods: determined by a physical dialing state of a dialer on a mainboard of the target device, the dialer being independent of the first firmware and the second firmware; determined by a string burned on an FRU chip on the mainboard of the target device, the second firmware directly reading data of the FRU chip; When the second firmware searches for a matching target configuration file according to the target configuration identifier obtained in advance, the second firmware obtains a variable header corresponding to each configuration file created in advance; wherein the configuration identifier of the corresponding configuration file is carried in each variable header; each configuration file corresponds to a SKU, and each configuration file contains a default variable data of each target configuration option; the target configuration identifier is compared with the configuration identifier carried in each variable header; and the configuration file matching the target configuration identifier is taken as the corresponding target configuration file; The file obtaining module is configured to obtain the target configuration file from the second firmware; The default value updating module is configured to update the default values of the target configuration options in the target device according to the default variable data in the target configuration file; The configuration file adding module is configured to add a new JSON format configuration file in the second firmware through a Redfish interface in response to an adjustment operation of the default values, the new configuration file carrying an independent variable header and corresponding to a new SKU; and the new JSON format configuration file is used to provide the default values when booting for the first time. Each SKU is configured with a configuration file, and different SKUs are independent of each other.

6. An electronic device, comprising: The electronic device comprises: at least one processor; and a memory in network communication connection with the at least one processor; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the default value configuration method in any one of claims 1-4.

7. A computer readable storage medium characterized by The computer readable storage medium stores computer instructions for enabling the processor to execute the default value configuration method in any one of claims 1-4 when executed.

Images