A decoupling method, device, program product, server, and storage medium

Abstract

The application discloses a decoupling method, device, program product, server and storage medium, and relates to the field of servers. In view of the problem that the close coupling between a BMC and a BIOS causes the firmware versions of both to have to be kept in synchronization at all times, a decoupling method is provided, which introduces semantic hash values to replace field names to perform accurate matching of fields. Because the semantic hash values can represent the essential meaning of the fields better than the field names, the semantic hash values do not require complete consistency of surface names. Therefore, replacing the field names with the semantic hash values to perform field matching can improve compatibility and also enable automatic renaming of the field names. Based on this, the method can reduce the coupling between the BIOS and the BMC, so that the BMC and the BIOS versions can be upgraded independently and do not need to be maintained synchronously, thereby significantly reducing operation and maintenance costs.

Description

Technical Field

[0001] This invention relates to the field of servers, and in particular to a decoupling method, apparatus, program product, server, and storage medium. Background Technology

[0002] In the field of server hardware management, the coordinated operation of the Baseboard Management Controller (BMC) and the Basic Input / Output System (BIOS) is crucial for the stable operation of the server.

[0003] In traditional architectures, the BMC and BIOS communicate directly through the Intelligent Platform Management Interface (IPMI). This tightly coupled architecture means that when new features are needed, the interface definitions of both the BMC and BIOS must be modified simultaneously, making compatibility maintenance difficult. Furthermore, when the BIOS calls an interface not implemented by the BMC, the system may enter an infinite loop or crash directly, resulting in high upgrade risks.

[0004] Therefore, those skilled in the art urgently need a decoupling method to solve the problem of BMC and BIOS, which have a tight coupling relationship and require their firmware versions to be kept synchronized at all times. Summary of the Invention

[0005] The purpose of this invention is to provide a decoupling method, apparatus, program product, server, and storage medium to solve the problem that BMC and BIOS, which are tightly coupled with each other, require their firmware versions to be kept synchronized at all times.

[0006] To address the aforementioned technical problems, this invention provides a decoupling method, applied to the BMC side or BIOS side, the method comprising:

[0007] Receive a data request and extract the request fields from the data request;

[0008] Determine the semantic hash value corresponding to the requested field;

[0009] The system searches for matching entries in the local registry based on semantic hash values; wherein, the local registry stores the mapping relationship between the semantic hash values ​​of fields and metadata in the form of entries.

[0010] Read the metadata corresponding to the matched entry, read the raw hardware data from the corresponding hardware based on the metadata, and return the read raw hardware data as the request response result.

[0011] In an alternative embodiment, after searching for a matching entry in the local registry based on the semantic hash value, the method further includes:

[0012] If no matching entry is found, a registry copy is scanned; wherein the registry copy is stored in a shared storage area of ​​the BMC and the BIOS, and the registry copy is a copy of the local registry of the BMC and the BIOS;

[0013] Traverse all fields in the registry copy and calculate the corresponding semantic hash value, then find the copy field whose semantic hash value matches the requested field;

[0014] After finding a matching copy field, query the local registry for local fields that match the copy field;

[0015] Based on the metadata corresponding to the local field, read the original hardware data from the corresponding hardware, determine the request response result based on the read original hardware data, and return it.

[0016] In one optional embodiment, determining and returning the request-response result based on the read raw hardware data includes:

[0017] Based on the differences in metadata between the copy field and the local field, corresponding conversion code is generated; wherein, the differences in metadata include one or more of the following: field name, data type, and measurement unit;

[0018] The original hardware data is converted according to the conversion code;

[0019] The original hardware data after data conversion is returned as the request response result.

[0020] In an optional embodiment, after finding the copy field whose semantic hash value matches the requested field, the method further includes:

[0021] Add a new entry corresponding to the copy field in the local registry.

[0022] In an optional embodiment, it further includes:

[0023] Once an entry is updated in the local registry, the updated entry is synchronized to the registry copy.

[0024] In an optional embodiment, it further includes:

[0025] Upon power-on, the local registry and the registry copy are read;

[0026] Compare the semantic hash values ​​of each entry in the local registry and the registry copy one by one, and record the fields with inconsistent semantic hash values ​​as the difference entries;

[0027] Update the local registry and the registry copy according to the difference entries to keep the local registry and the registry copy synchronized.

[0028] In an optional embodiment, updating the local registry and the registry copy according to the difference entries to keep the local registry and the registry copy synchronized includes:

[0029] If the difference entry exists in the local registry but not in the registry copy, then the difference entry is updated to the registry copy;

[0030] If the difference entry is not present in the local registry but exists in the registry copy, then the difference entry is updated to the local registry;

[0031] If the difference entry exists in both the local registry and the registry copy but is different, then the metadata of the corresponding entry in the local registry is overwritten with the metadata of the corresponding entry in the registry copy.

[0032] In one optional embodiment, the process of determining the semantic hash value includes:

[0033] Obtain the metadata of the field to be calculated, and extract the attribute information from the metadata;

[0034] The extracted attribute information is concatenated to obtain a semantic description string;

[0035] The semantic description string is hashed to obtain the corresponding semantic hash value.

[0036] In an optional embodiment, obtaining the metadata of the field to be calculated and extracting the attribute information from the metadata includes:

[0037] Extract the core attributes from the metadata;

[0038] The core attributes include at least two of the following: physical meaning, measurement object, data type, measurement unit, and value range, and must include physical meaning and measurement object.

[0039] In one optional embodiment, the step of hashing the semantic description string to obtain the corresponding semantic hash value includes:

[0040] The semantic description string is hashed using either the CRC32 algorithm or the MurmurHash3 algorithm to obtain the semantic hash value.

[0041] In an optional embodiment, applied to the BMC side, the method further includes:

[0042] After startup, a capability bitmap is generated based on the configuration file; wherein, the capability bitmap includes at least: a function flag field; each bit in the function flag field indicates the support status of a standard function of the BMC;

[0043] The capability bitmap is sent to the BIOS, and a response code is received from the BIOS; wherein the response code is used to indicate the disabled status of each standard function of the BMC;

[0044] Based on the response code, disable the corresponding standard function.

[0045] In one optional embodiment, the response code includes: a full-featured mode code, a degraded mode code, and a secure mode code;

[0046] When the BMC receives the full-function mode code, it enables all standard functions.

[0047] When the BMC receives the downgrade mode code, it enables only basic functions and disables predefined complex operations.

[0048] When the BMC receives the security mode code, it disables all data interaction interfaces.

[0049] In one optional embodiment, the capability bitmap further includes: a maximum data length field, a protocol version number field, a checksum field, and a reserved field;

[0050] The maximum data length field is used to indicate the maximum data length supported by the BMC in a single communication.

[0051] The protocol version number field is used to indicate the current firmware version of the BMC;

[0052] The verification code field is a verification value calculated based on the function flag field, the maximum data length field, and the protocol version number field, and is used to verify the legality of the capability bitmap;

[0053] The reserved fields are custom fields.

[0054] In one alternative embodiment, sending the capability bitmap to the BIOS includes:

[0055] Write the capability bitmap to the target address in the shared memory area of ​​the BMC and the BIOS;

[0056] The response codes returned by the BIOS include:

[0057] Read the capability bitmap from the target address of the shared storage area.

[0058] In an optional embodiment, applied to the BIOS side, the method further includes:

[0059] Receive a capability bitmap sent by the BMC; wherein the capability bitmap is generated by the BMC after startup according to the configuration file; the capability bitmap includes at least: a function flag bit field; each bit in the function flag bit field indicates the support status of a standard function of the BMC;

[0060] The capability bitmap is parsed, and the support status of key functions is determined based on the function flag field; wherein, the key functions are one or more functions predefined from the standard functions of the BMC;

[0061] Based on the support status of each key function, a corresponding response code is generated and returned to the BMC, so that the BMC can disable the corresponding standard function according to the response code.

[0062] In an optional embodiment, applied to the BIOS side, the method further includes:

[0063] When the BIOS needs to access the shared memory area, it pulls a dedicated signal pin high; wherein, the dedicated signal pin is a dedicated signal pin between the BIOS and the BMC; when the dedicated signal pin is high, the BMC is prohibited from initiating access to the shared memory area;

[0064] After the BIOS completes its access to the shared memory area, it pulls the dedicated signal pin low.

[0065] To address the aforementioned technical problems, the present invention also provides a decoupling device, applied to the BMC side or BIOS side, the device comprising:

[0066] The field extraction module is used to receive data requests and extract the requested fields from the data requests.

[0067] A semantic determination module is used to determine the semantic hash value corresponding to the request field;

[0068] A semantic matching module is used to find matching entries from the local registry based on semantic hash values; wherein, the local registry stores the mapping relationship between the semantic hash values ​​of fields and metadata in the form of entries;

[0069] The request-response module is used to read the metadata corresponding to the matching entry, read the original hardware data from the corresponding hardware based on the metadata, and return the read original hardware data as the request-response result.

[0070] To address the aforementioned technical problems, the present invention also provides a computer program product, comprising a computer program / instructions, wherein the computer program / instructions, when executed by a processor, implement the steps of the decoupling method described above.

[0071] To address the aforementioned technical problems, the present invention also provides a server, comprising: BMC firmware, BIOS firmware, and non-volatile memory;

[0072] The non-volatile memory serves as a shared storage area for the BMC firmware and the BIOS firmware.

[0073] Both the BMC firmware and the BIOS firmware include:

[0074] A processor for implementing the steps of the decoupling method described above.

[0075] To address the aforementioned technical problems, the present invention also provides a non-volatile storage medium storing a computer program, which, when executed by a processor, implements the steps of the decoupling method described above.

[0076] This invention provides a decoupling method applied to either the BIOS or BMC. Upon receiving a data request, the request field is extracted, and then the corresponding semantic hash value is determined based on the request field. The semantic hash value captures the essential meaning of the field, solving problems that traditional field name-based mapping cannot address. Furthermore, this method stores the mapping relationship between the semantic hash value and metadata corresponding to the field in the local registry. Therefore, even if a field name changes due to a firmware upgrade in either the BIOS or BMC, the corresponding metadata (corresponding to the field name before the change) can be found in the local registry using the semantic hash value. This completes the acquisition of the corresponding original hardware data, which is returned as the request response result, thus completing one request processing. Therefore, this method improves the compatibility between the BIOS and BMC. Even if a firmware upgrade in one party causes a change in the field name of a certain field, it can be identified through the semantic hash value, thereby completing data interaction. This method reduces the coupling between the BIOS and BMC, allowing the firmware versions of the BMC and BIOS to be upgraded independently without synchronous maintenance, significantly reducing operational costs.

[0077] The decoupling device, computer program product, server, and non-volatile storage medium provided by this invention correspond to the above-mentioned decoupling method and have the same effect. Attached Figure Description

[0078] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the 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.

[0079] Figure 1 A flowchart of a decoupling method provided in an embodiment of the present invention;

[0080] Figure 2 A hardware application architecture diagram of a decoupling method provided in an embodiment of the present invention;

[0081] Figure 3 A flowchart of a dynamic adaptation scheme provided in an embodiment of the present invention;

[0082] Figure 4 A flowchart illustrating a power-on registry synchronization scheme provided in an embodiment of the present invention;

[0083] Figure 5 A flowchart of a capability negotiation scheme provided in an embodiment of the present invention;

[0084] Figure 6 A structural diagram of a server provided in an embodiment of the present invention;

[0085] Figure 7 This is a structural diagram of a decoupling device provided in an embodiment of the present invention. Detailed Implementation

[0086] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0087] The core of this invention is to provide a decoupling method, apparatus, program product, server, and storage medium.

[0088] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0089] In related technologies, there are currently two main interaction schemes between the Baseboard Management Controller (BMC) and the Basic Input / Output System (BIOS):

[0090] One approach is to control read / write timing using status flags to avoid concurrent access conflicts. The main problem with this solution is its reliance on exact field name matching to ensure the BMC and BIOS access the same status flag. For example, if the BMC changes a field name from "CPU_Temp" to "cpu_Temp", the BIOS cannot accurately match the corresponding field name, resulting in a failure to recognize the change.

[0091] The second approach is a version negotiation scheme, where the BMC pre-broadcasts its version number, and the BIOS selects the appropriate compatible interface set based on a pre-defined rule base after receiving the version number broadcast by the BMC. However, this scheme requires all possible version combinations to be configured in the pre-defined rule base, and adding new rules requires recompiling the firmware, resulting in high maintenance costs. Furthermore, this scheme relies excessively on manual intervention and cannot handle unforeseen field changes.

[0092] To address the above problems, this invention provides a decoupling method applicable to the BMC side or the BIOS side. For example... Figure 1 As shown, the method includes:

[0093] S11: Receive data requests and extract request fields from the data requests.

[0094] S12: Determine the semantic hash value corresponding to the requested field.

[0095] S13: Search for matching entries in the local registry based on the semantic hash value.

[0096] The local registry stores the mapping between the semantic hash values ​​of fields and metadata in the form of entries.

[0097] S14: Read the metadata corresponding to the matching entry, read the raw hardware data from the corresponding hardware based on the metadata, and return the read raw hardware data as the request response result.

[0098] As can be seen from steps S11 and S12 above, this method calculates the semantic hash value of the request field on the receiving side of the data request, aiming to reduce the requirements on the data request initiator. However, if the data request initiator is also a BMC or BIOS, it has the same built-in method logic. When initiating a data request, it can directly carry the semantic hash value of the request field. For example, if a data request is GetData(0x8A7B3C9D), 0x8A7B3C9D is the semantic hash value of the request field. This semantic hash value can be calculated by the initiator based on the request field, or it can be found in the local registry. In addition, although the above method flow is not limited, when this data interaction occurs between the BMC and the BIOS, the data request initiator is generally the BIOS, and the data request receiver is generally the BMC.

[0099] Furthermore, the semantic hash value can be calculated by extracting the semantics from the request fields and then performing a hash calculation on the extracted semantics. For example, assuming there is a data request for "get CPU temperature", the semantics "CPU" and "temperature" can be extracted to calculate the corresponding semantic hash value.

[0100] Furthermore, considering that directly extracting semantics from data request fields is difficult to achieve and may not meet accuracy requirements, this embodiment also provides another possible implementation method. The process for determining the semantic hash value includes:

[0101] S21: Obtain the metadata of the field to be calculated and extract the attribute information from the metadata.

[0102] S22: Concatenate the extracted attribute information to obtain a semantic description string.

[0103] S23: Perform a hash calculation on the semantic description string to obtain the corresponding semantic hash value.

[0104] The attribute information includes, but is not limited to: physical meaning, measurement object, data type, measurement unit, and value range. Physical meaning represents the physical quantity being measured, such as temperature or voltage. Measurement object represents the component being measured, such as a central processing unit (CPU) or memory. Data type includes common data types such as integer, floating-point, and string. Measurement unit is related to the physical meaning, such as degrees Celsius (°C), degrees Fahrenheit (°F), and volts (V). Value range represents the minimum and maximum allowed values.

[0105] It should be noted that the attribute information given in the examples above represents only a portion of the metadata. Metadata includes much more information than those shown in the examples, such as the corresponding sensor and data address. When calculating semantic hash values, using more or fewer attribute information is not necessarily better, and not all attribute information is helpful for field matching. For example, using too much attribute information can make semantic hash value calculation too difficult. Furthermore, because semantic hash values ​​are influenced by many factors, the improvement in compatibility is reduced. However, using too little attribute information can also reduce the essential meaning of the field that the semantic hash value can represent, potentially leading to a situation where the determined semantic hash value cannot uniquely identify a field.

[0106] Based on this, this embodiment further provides an optional implementation scheme, where step S21 specifically involves extracting core attributes from the metadata. These core attributes include at least two of the following: physical meaning, measurement object, data type, measurement unit, and value range, and must include both physical meaning and measurement object. For example, the request field "Get CPU Temperature" in the above example includes the physical meaning "temperature" and the measurement object "CPU". This embodiment focuses on key metadata related to the matching field and strictly controls its quantity to avoid the problem of semantic hash values ​​not uniquely identifying a field, while ensuring compatibility.

[0107] In another alternative embodiment, all possible core attributes given above can be included in the semantic hash value calculation. For example, suppose the physical meaning is "temperature"; the measurement object is "cpu"; the data type is "uint16" (16-bit unsigned integer); the unit of measurement is "celsius" (degrees Celsius); and the value range is "0:120" (minimum value 0, maximum value 120). Then, a semantic description string "temperature:cpu:uint16:celsius:0:120" can be concatenated. Based on this semantic description string, the corresponding semantic hash value can be calculated. In this case, regardless of the field name in the BMC and BIOS, it can be determined through the semantic hash value.

[0108] For example, suppose there is a field named "CPU_Temp" in BMC firmware version V2.0, which represents the CPU temperature. In the BIOS, firmware version V2.1 renames this field to "SOC_Temp," representing the System-on-Chip (SoC) temperature. However, since the field name does not participate in the semantic hash value calculation, the semantic description string of the field remains unchanged (i.e., the metadata used to determine the semantic string remains unchanged), and therefore the determined semantic hash value remains unchanged. In other words, changing the field name does not affect the hash value, so even if the name changes, compatibility is not affected.

[0109] Furthermore, this embodiment does not impose restrictions on the hash algorithm used in step S23 to calculate the semantic hash value; a suitable hash algorithm can be selected according to actual needs. Specifically, this embodiment provides an optional scheme for the metadata used to calculate the semantic hash value, determining the semantic description string through a limited number of core attributes. Because the semantic description string in this embodiment has a limited length, a lightweight hash algorithm with a low collision rate can meet the requirements, such as the Cyclic Redundancy Check 32 (CRC32) algorithm, or MurmurHash3 (a non-cryptographic hash function, 32-bit or 128-bit).

[0110] After calculating the semantic hash value, which corresponds to step S13, this method sets up a local registry on the BIOS or BMC side. The local registry stores the mapping relationship between the semantic hash values ​​of fields and their metadata. A set of semantic hash values ​​and metadata for a group of fields is stored in the local registry as an entry. Other information, such as the field name, can also be stored in the local registry. For traditional schemes that match metadata by field name, the BIOS and BMC also maintain a data table storing the mapping relationship between field names and metadata. The local registry in this method can be obtained by adding the corresponding semantic hash value to the entry.

[0111] Based on the local registry settings, when the BMC and BIOS cannot achieve an exact match through field names due to firmware version inconsistencies, the corresponding entry can be found in the local registry using semantic hash values. Then, the corresponding metadata is read from the matched entry, and the raw hardware data is read from the corresponding hardware based on the metadata. For example, taking CPU temperature as an example, the raw data detected by the corresponding temperature sensor, such as 85℃ (integer, °C), can be read. This data is the data required for the received data request and is returned as the request response result, thus completing one data request processing.

[0112] Furthermore, as described above, the request processing implemented by this method can achieve accurate field matching even when field names differ. Therefore, in the data interaction between the BMC and BIOS, field name renaming can be further implemented. That is, when receiving a data request, the field name of the requested field is renamed to the field name on the current side, and when returning the request response result, the field name on the current side can also be renamed to the field name of the request initiator. For example, taking the field name "CPU_Temp" on the BMC side and "SOC_Temp" on the BIOS side as an example: the data request sent by the BIOS to the BMC carries the field name "SOC_Temp"; after receiving the request, the BMC can determine through semantic hash value that the requested field is the corresponding field name "CPU_Temp" in the local registry, and can then rename the requested field name to "CPU_Temp" for convenient subsequent processing. Similarly, when it is necessary to return the request response result, the field name can be renamed back from "CPU_Temp" to "SOC_Temp" for easy identification by the BIOS side.

[0113] As described above, this method provides a decoupling approach by introducing semantic hash values ​​instead of field names for precise field matching. Since semantic hash values ​​better represent the essential meaning of a field than field names, they do not require exact consistency in surface names. Therefore, using semantic hash values ​​for field matching improves compatibility and enables automatic renaming of field names. Based on this, this method reduces the coupling between the BIOS and BMC, allowing the BMC and BIOS versions to be upgraded independently without synchronous maintenance, thus significantly reducing operational costs.

[0114] On the other hand, as can be seen from the above embodiments, although this method can improve compatibility by using semantic hash values ​​instead of field names for matching, in practical applications, when the BIOS and BMC firmware versions differ significantly, the local registry may not be able to match the corresponding field based on the semantic hash value of the requested field. To solve this problem, the present invention also provides an optional implementation scheme, wherein after step S13, the above method further includes:

[0115] S31: If no matching entry is found, scan a copy of the registry.

[0116] The registry copy is stored in a shared memory area between the BMC and BIOS, and this copy is a replica of the local registry of the BMC and BIOS. The shared memory area can be configured as follows: Figure 2 As shown, this can be achieved through any storage medium that can be accessed by both the BMC and BIOS. For example, in... Figure 2 In this context, electrically erasable programmable read-only memory (EEPROM) is used as the carrier of the shared memory area.

[0117] S32: Traverse all fields in the registry copy and calculate the corresponding semantic hash value, then find the copy field whose semantic hash value matches the requested field.

[0118] S33: After finding a matching copy field, query the local registry for local fields that match the copy field.

[0119] S34: Read the raw hardware data from the corresponding hardware based on the metadata corresponding to the local fields, determine the request response result based on the read raw hardware data, and return it.

[0120] First, it should be noted that the registry copy stored in the shared storage area can include two copies: a copy of the local registry on the BMC side and a copy of the local registry on the BIOS side. Whenever the local registry on the BMC or BIOS side changes, the corresponding copy in the shared storage area needs to be updated synchronously to ensure that the registry copy stored in the shared storage area remains up-to-date. In this case, the registry copy scanned in step S31 is the peer copy. That is, if the recipient of the current data request is the BMC, its peer is the BIOS, and the registry copy scanned in step S31 is the BIOS's registry copy. In another embodiment, the registry copy can also be a copy jointly maintained by the BMC and the BIOS. This scheme is easier to implement than the previous one, but the maintenance requirements are also higher. In practical applications, a suitable scheme can be freely chosen according to needs, and this embodiment does not impose any restrictions on this.

[0121] When the BMC and BIOS versions differ significantly, meaning the local registry version is too old to find a matching field using semantic hash values, this embodiment, based on the registry copy setting, can read the latest registry copy from the shared storage area. Then, by traversing each field in the registry copy and calculating its semantic hash value, it finds the entry matching the requested field, thereby reading the corresponding metadata and retrieving the required raw hardware data from the corresponding hardware. Therefore, this embodiment, when the BMC and BIOS versions differ significantly, resulting in no matching entry in the local registry, can use the registry copy stored in the shared storage area to complete field matching, accurately obtaining the raw hardware data to complete the response, further improving compatibility.

[0122] Furthermore, when the method provided in the above embodiments is required (when a registry copy is needed), it indicates a significant version difference between the BMC and BIOS. In this case, the same field may exhibit substantial metadata changes. These changes, besides the field name changes in the examples above, may also manifest in several key attributes used to determine the semantic description string, such as data type, measurement unit, and value range (generally, a change in physical meaning or measurement object constitutes a new field, which is one reason why the key attributes in the above embodiments must include physical meaning and measurement object). In this situation, even if the matching field can be found based on the registry copy in the shared storage area using the solution provided in the above embodiments, and the corresponding raw hardware data can be retrieved, it may still fail to be recognized by the peer due to differences in the data type, measurement unit, and value range of the raw hardware data.

[0123] To address the aforementioned issues, this embodiment further provides an optional implementation scheme, wherein step S34, which involves determining and returning the request-response result based on the read raw hardware data, specifically includes:

[0124] S341: Generate corresponding conversion code based on the difference attributes of the metadata corresponding to the replica field and the local field. The difference attributes include one or more of the following: field name, data type, and unit of measurement.

[0125] S342: Performs data conversion on the raw hardware data according to the conversion code.

[0126] S343: Returns the raw hardware data after data conversion as the result of the request response.

[0127] The renaming of field names has been fully explained in the above embodiments and will not be repeated in this embodiment. To better illustrate how this embodiment implements the conversion of data type and measurement unit, the following example is provided: Suppose that the BIOS sends a request to the BMC to obtain data with a semantic hash value of 0x9A3B4C5D, corresponding to the request field "Get CPU temperature". This semantic hash value can be pre-calculated by the BIOS and carried in the data request, or it can be calculated by the BMC based on the request field after obtaining the data request. For specific implementation schemes, please refer to the above embodiments, which will not be repeated here. After querying the local registry and the registry copy in the shared storage area, the BMC knows that for the request field "Get CPU temperature", the data type expected by the BIOS is single-precision floating-point (float) and the measurement unit is °F; while the data type of the raw hardware data that the BMC can read is 8-bit unsigned integer (uint8) and the measurement unit is °C. At this time, the conversion code generated in step S341 is used to implement the following two conversion operations:

[0128] 1. Unit conversion: ℃ to ℉.

[0129] The corresponding conversion formula is: ℉ = ℃ × 9 / 5 + 32. Assuming the original hardware data obtained by the BMC is 85℃, then 85... 1.8 + 32 = 185℉.

[0130] 2. Type conversion: Convert an integer (int) to a floating-point (float) type.

[0131] Then the above 185 is converted to 185.0.

[0132] Based on the above conversion, the original hardware data 85 (int, °C) can be converted into 185.0 (float, °F) which can be directly recognized by the BIOS and returned as a response result.

[0133] As can be seen from the above, in addition to renaming fields, this embodiment can also achieve unit conversion and data type conversion, further decoupling between BMC and BIOS, and further improving compatibility.

[0134] Based on the request processing schemes provided in steps S11-S14 and S31-S34 above, the following can be obtained: Figure 3 The dynamic adaptation process is as follows: First, steps S11 and S12 receive data requests and calculate semantic hash values. Then, corresponding to step S13, the semantic hash value is used to query matching entries in the local registry. If a match is found, the process proceeds to step S14, where data is read and returned. If a match fails, the process proceeds to step S31, where a registry copy is scanned. Then, corresponding to step S32, all fields in the registry copy are traversed, and the corresponding semantic hash values ​​are calculated. A copy field whose semantic hash value matches the requested field is found. If a match is found, subsequent steps S33, S34, and S35 are continued, namely, generating conversion code to perform data conversion, returning the converted data as the response result, and updating the local registry. If a match fails, an error code can be returned to inform the maintenance personnel of the current problem and prompt them to handle it promptly.

[0135] Furthermore, when steps S31-S34 are triggered, it indicates that the local registry is no longer up-to-date. To ensure the timeliness of the local registry, this embodiment also provides an update method, which, after step S32, further includes:

[0136] S41: Add a new entry in the local registry corresponding to the copy field.

[0137] In other words, this embodiment uses the latest registry copy stored in the shared storage area as a basis to update the corresponding entries in the local registry. When the local registry alone cannot accurately match a field, and the registry copy is required, the field matched by the registry copy is added as a new entry to the local registry. Then, when there is a subsequent data request for this field, the field matching can be completed using the updated local registry.

[0138] In addition, this embodiment also provides another update scheme, and the above method further includes:

[0139] S42: When an entry is updated in the local registry, the updated entry is synchronized to the registry copy.

[0140] As can be seen from the above embodiments, the series of operations implemented through the registry copy in the above embodiments impose certain requirements on the version of the registry copy, requiring the registry copy to be synchronized with the latest version. Since the registry copy is stored in a shared storage area, in actual operation and maintenance, firmware version upgrades for the BMC or BIOS usually only involve upgrading the BMC or BIOS, specifically updating the local registry on the BMC or BIOS side. Therefore, to ensure that the registry copy can be updated synchronously, this embodiment updates the registry copy accordingly whenever an entry is updated in the local registry, ensuring synchronization between the two registry copies.

[0141] The two embodiments described above provide incremental updates with triggering conditions, suitable for flexible and dynamic registry updates during BIOS and BMC operation. However, these update schemes cannot handle overall updates after a device power outage. To address this issue, this embodiment further provides an optional implementation scheme. For example... Figure 4 As shown, the above method also includes:

[0142] S43: Upon power-up, read the local registry and a copy of the registry.

[0143] S44: Compare the semantic hash values ​​of each entry in the local registry and the registry copy one by one, and record the fields with inconsistent semantic hash values ​​as the difference entries.

[0144] If there are no difference entries, the current process S431~S433 can be terminated directly.

[0145] S45: Update the local registry and registry copy based on the differences in the entries, keeping the local registry and registry copy in sync.

[0146] In addition, such as Figure 4 As shown, when the server powers on and off, both the BMC and BIOS execute the aforementioned registry synchronization process. This can be done in any order to avoid concurrency conflicts. Furthermore, in another optional embodiment, after each registry update, the corresponding version number can be determined using a hash calculation (e.g., the CRC32 checksum of the registry can be used as the version number). Subsequently, whether registry synchronization is needed can be quickly determined by checking if the version numbers are the same.

[0147] This embodiment provides a method for actively synchronizing the local registry and a copy of the registry when the BMC or BIOS is powered on, to ensure synchronization between the two registry entries. Furthermore, this embodiment, combined with the dynamic synchronization schemes for the BMC and BIOS operation described in the previous two embodiments, can cover the entire lifecycle of the BMC and BIOS, achieving comprehensive registry synchronization and ensuring that subsequent processes such as data request processing and data conversion utilizing the registry can proceed normally.

[0148] Furthermore, regarding the specific update between the two registry entries in step S45 above, this embodiment also provides an optional further implementation scheme. Step S45 specifically includes:

[0149] S451: If the difference entry exists in the local registry but not in the registry copy, then update the difference entry to the registry copy.

[0150] S452: If the difference entry is not present in the local registry but exists in the registry copy, then update the difference entry to the local registry.

[0151] S453: If a difference entry exists in both the local registry and a copy of the registry but is different, then the metadata of the corresponding entry in the local registry is overwritten with the metadata of the corresponding entry in the copy of the registry.

[0152] As described above, this embodiment provides specific registry synchronization solutions for three possible scenarios of differing entries in practical applications. Based on this embodiment, all situations where differences exist between the local registry and the registry copy in practical applications can be covered, thereby obtaining reliable and comprehensive updates.

[0153] On the other hand, according to relevant technologies, if the BMC and BIOS versions are incompatible, the BIOS may call interfaces that are not implemented by the BMC. In this case, the system may enter an infinite loop or crash directly, posing a significant risk. To address this risk, this embodiment further provides a risk prevention scheme. For example... Figure 5 As shown, when applied to the BMC side, this method also includes:

[0154] S5-A1: After startup, it generates a capability bitmap based on the configuration file.

[0155] The capability bitmap includes at least a function flag field. Each bit in the function flag field indicates the support status of a standard function of the BMC. For example, for a certain bit in the function flag field, 0 = temperature monitoring, 1 = power control, thereby determining the standard functions currently supported by the BMC.

[0156] S5-A2: Sends the capability bitmap to the BIOS and receives the response code returned by the BIOS.

[0157] The response code is used to indicate the disabled status of various standard functions of the BMC.

[0158] S5-A3: Disable the corresponding standard function based on the response code.

[0159] Correspondingly, when applied to the BIOS side, this method also includes:

[0160] S5-B1: Receive capability bitmap sent by BMC.

[0161] In the BMC-side method described above, the capability bitmap is generated by the BMC after startup based on the configuration file.

[0162] S5-B2: Analyzes the capability bitmap, determining the support status of critical functions based on the function flag field. Critical functions are one or more predefined functions from the standard functions of the BMC.

[0163] S5-B3: Generates corresponding response codes based on the support status of each key function and returns them to the BMC so that the BMC can disable the corresponding standard function based on the response codes.

[0164] Furthermore, this embodiment does not limit the specific form of the response codes, but at least one type of response code should not disable any functions, and another type should disable all or some functions. To this end, this embodiment provides an optional response code scheme, specifically including: a full-function mode code (e.g., 0xAA), a downgraded mode code (e.g., 0x55), and a security mode code (e.g., 0x00). Specifically, when the BMC receives a full-function mode code, all standard functions are enabled; when the BMC receives a downgraded mode code, only basic functions are enabled, and predefined complex operations are disabled; when the BMC receives a security mode code, all data interaction interfaces are disabled.

[0165] The three response codes described above correspond to three different compatibility modes, as shown in Table 1 below:

[0166] Table 1 Compatibility Mode Table

[0167]

[0168] Therefore, this embodiment can achieve risk prevention based on capability bitmaps and response code mechanisms. When the BMC and BIOS versions are incompatible, the capability bitmap in this embodiment can determine compatibility in advance, avoiding crashes caused by directly calling interfaces in traditional solutions. Secondly, this embodiment can also achieve resource optimization. For example, when the BIOS declares that it does not support a certain function, the BMC can actively close the relevant data acquisition threads. Finally, this embodiment can also implement a dynamic matching strategy for degradation. For example, in the degradation mode mentioned above, the BMC will filter high-risk operation requests, such as data type conversion in the data conversion mentioned above. In the safe mode mentioned above, all data conversion operations are prohibited.

[0169] Furthermore, this embodiment does not limit the specific format of the capability bitmap. And apart from the aforementioned function flag field, this embodiment does not limit whether the capability bitmap includes other fields. For example, this embodiment provides an optional implementation where the capability bitmap further includes: a maximum data length field, a protocol version number field, a checksum field, and a reserved field. The maximum data length field indicates the maximum data length supported by the BMC in a single communication. The protocol version number field indicates the current firmware version of the BMC. The checksum field is a checksum calculated based on the function flag field, the maximum data length field, and the protocol version number field, used to verify the validity of the capability bitmap. The reserved field is a custom field.

[0170] For example, the aforementioned capability bitmap can specifically be an 8-byte capability bitmap, including:

[0171] 1. Function Flag Field (1 Byte in length, corresponding to byte 0 of the capability bitmap): One bit indicates the support status of a function (e.g., 1 = supported, 0 = not supported). For example, bit 1 indicates the support status of the power control function, bit 2 indicates the support status of the fan control function, etc.

[0172] 2. Maximum Data Length Field (length is 1 byte, corresponding to byte 1 in the capability bitmap): Indicates the maximum data length (unit: bytes) that the BMC can support in a single communication. If the data length requested by the BIOS exceeds this value, it will be rejected or split.

[0173] 3. Protocol Version Number Field (2 bytes long, corresponding to bytes 2-3 of the capability bitmap): Used to identify the version number of the capability negotiation protocol itself, for future expansion. The protocol version number is usually big-endian or little-endian, and needs to be uniformly agreed upon in the design. For example, "0x01 0x00" represents version 1.0.

[0174] 4. Checksum field (2 bytes long, corresponding to bytes 4-5 of the capability bitmap): The checksum value is obtained by performing a check calculation (such as CRC16) on the first 4 bytes (function flag, maximum data length, protocol version number) to ensure the integrity (legitimacy) of the capability bitmap data.

[0175] 5. Reserved field (length is 2 bytes, corresponding to bytes 6-7 of the capability bitmap): This is a custom field reserved for future use. It must be set to 0 when not in use.

[0176] Based on the capability bitmap provided in this embodiment, the BMC can not only inform the BIOS of the functions it supports, but also the maximum allowed request length, protocol version number, and reserved fields for future expansion. Furthermore, the capability bitmap also includes a checksum field for the BIOS to verify the validity of the capability bitmap it reads.

[0177] Furthermore, as can be seen from the above embodiments, a shared storage area is set up between the BMC and the BIOS to store a copy of the registry. For this shared storage area, this embodiment also provides an optional implementation scheme for enabling the interaction of capability bitmaps between the BMC and the BIOS. Specifically, as shown... Figure 5 As shown, the sending of the capability bitmap in step S5-A2 specifically involves writing the capability bitmap to a target address (e.g., 0x1000) in the shared memory area of ​​the BMC and BIOS. Step S5-B1 specifically involves reading the capability bitmap from the target address in the shared memory area. The response code is handled similarly and can also be used for interaction via the shared memory area. In the example of an 8-byte capability bitmap as described in the above embodiment, the response code can be written to address 0x1008.

[0178] Furthermore, as can be seen from the above embodiments, the decoupling between the BMC and BIOS achieved based on this method involves access between the BMC and BIOS and the shared memory area. This many-to-one access includes read and write operations, which may lead to concurrency conflicts. To address this issue, this embodiment also provides a further implementation scheme. Applied to the BIOS side, the method further includes:

[0179] S61: When the BIOS needs to access the shared memory area, it pulls the dedicated signal pin high.

[0180] Among them, such as Figure 2 As shown, the dedicated signal pin is a dedicated signal pin between the BIOS and BMC, and a dedicated signal line is used to connect the BMC firmware and the BIOS firmware. When the dedicated signal pin is high, the BMC is prohibited from accessing the shared memory area.

[0181] S62: After the BIOS completes its access to the shared memory area, it pulls the dedicated signal pin low.

[0182] Specifically, the entire process, as exemplified, includes: When the BIOS needs to access the shared memory area (EEPROM), the BIOS pulls the GPIO pin of the BIOS firmware high. When the BMC detects the GPIO is high, it will not initiate access to the shared memory area to avoid conflicts. After the BIOS completes its operation, it pulls the GPIO low, releasing control. At this point, the BMC detects the GPIO is low and can begin accessing the shared memory area. This ensures ordered access to the shared memory area by the BMC and BIOS, effectively avoiding concurrent conflicts.

[0183] Furthermore, this embodiment also provides an optional implementation scheme for partitioning in the shared storage area, as shown in Table 2 below.

[0184] Table 2 Shared Storage Zone Planning Table

[0185]

[0186] The present invention also provides an embodiment corresponding to a server. For example... Figure 6 As shown, the server provided in this embodiment includes: BMC firmware 1, BIOS firmware 2, and non-volatile memory 3. The non-volatile memory serves as a shared storage area for the BMC firmware and BIOS firmware. Both the BMC firmware and BIOS firmware include a processor for implementing the decoupling method provided in any of the above embodiments. This method can be divided into two parts: one part is the dynamic adaptation part corresponding to steps S11~S45, used to handle request interactions between the BIOS and BMC; the other part is the capability bitmap part corresponding to steps S5-A1~S5-A3 / S5-B1~S5-B3, used for risk prevention before formal request interactions. Based on the difference between these two core functions, the above two parts of the method can be implemented in the processor through two different functional modules and threads. Figure 6 As shown, it can be specifically divided into a capability negotiation module and a dynamic adaptation engine. The dynamic adaptation engine is used to implement the methods corresponding to steps S11 to S45 above, and the capability negotiation module is used to implement the methods corresponding to steps S5-A1 to S5-A3 and S5-B1 to S5-B3 above.

[0187] Since the embodiments of the server part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the server part, and they will not be repeated here.

[0188] In the above embodiments, a decoupling method has been described in detail. The present invention also provides an embodiment corresponding to a decoupling device. It should be noted that the present invention describes the device embodiment from two perspectives: one based on functional modules, and the other based on hardware.

[0189] From the perspective of functional modules, this embodiment provides a decoupling device, applied to the BMC side or BIOS side. For example... Figure 7 As shown, the device includes:

[0190] The field extraction module 41 is used to receive data requests and extract the requested fields from the data requests.

[0191] The semantic determination module 42 is used to determine the semantic hash value corresponding to the request field.

[0192] The semantic matching module 43 is used to find matching entries in the local registry based on semantic hash values. The local registry stores the mapping relationship between the semantic hash values ​​of fields and metadata in the form of entries.

[0193] The request-response module 44 is used to read the metadata corresponding to the matching entry, read the original hardware data from the corresponding hardware based on the metadata, and return the read original hardware data as the request-response result.

[0194] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0195] The present invention also provides an embodiment corresponding to a computer program product. A computer program product includes a computer program / instructions, which, when executed by a processor, can implement the steps of the decoupling method as described in any of the above embodiments.

[0196] Similarly, the embodiments of the computer program product portion correspond to the embodiments of the method portion. Therefore, please refer to the description of the embodiments of the method portion for the embodiments of the computer program product portion, which will not be repeated here.

[0197] Finally, the present invention also provides an embodiment corresponding to a non-volatile storage medium. A computer program is stored on the non-volatile storage medium, and when the computer program is executed by a processor, it implements the steps described in the above method embodiments (which may be a method corresponding to the BMC side, a method corresponding to the BIOS side, or a method corresponding to both the BMC side and the BIOS side).

[0198] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a non-volatile storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0199] The foregoing has provided a detailed description of the decoupling method, apparatus, program product, server, and storage medium provided by the present invention. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make various improvements and modifications to the present invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the present invention.

[0200] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A decoupling method, characterized in that, Applied to the BMC side or BIOS side, the methods include: Receive a data request and extract the request fields from the data request; Determine the semantic hash value corresponding to the requested field; The system searches for matching entries in the local registry based on semantic hash values; wherein, the local registry stores the mapping relationship between the semantic hash values ​​of fields and metadata in the form of entries. Read the metadata corresponding to the matching entry, read the raw hardware data from the corresponding hardware based on the metadata, and return the read raw hardware data as the request response result; If no matching entry is found, a registry copy is scanned; wherein the registry copy is stored in a shared storage area of ​​the BMC and the BIOS, and the registry copy is a copy of the local registry of the BMC and the BIOS; Traverse all fields in the registry copy and calculate the corresponding semantic hash value, then find the copy field whose semantic hash value matches the requested field; After finding a matching copy field, query the local registry for local fields that match the copy field; Based on the metadata corresponding to the local field, read the original hardware data from the corresponding hardware, determine the request response result based on the read original hardware data, and return it.

2. The decoupling method according to claim 1, characterized in that, The step of determining and returning the request response result based on the read raw hardware data includes: Based on the differences in metadata between the copy field and the local field, corresponding conversion code is generated; wherein, the differences in metadata include one or more of the following: field name, data type, and measurement unit; The original hardware data is converted according to the conversion code; The original hardware data after data conversion is returned as the request response result.

3. The decoupling method according to claim 1, characterized in that, Following the step of finding a copy field whose semantic hash value matches the requested field, the method further includes: Add a new entry corresponding to the copy field in the local registry.

4. The decoupling method according to claim 1, characterized in that, Also includes: Once an entry is updated in the local registry, the updated entry is synchronized to the registry copy.

5. The decoupling method according to claim 1, characterized in that, Also includes: Upon power-on, the local registry and the registry copy are read; Compare the semantic hash values ​​of each entry in the local registry and the registry copy one by one, and record the fields with inconsistent semantic hash values ​​as the difference entries; Update the local registry and the registry copy according to the difference entries to keep the local registry and the registry copy synchronized.

6. The decoupling method according to claim 5, characterized in that, Updating the local registry and the registry copy based on the difference entries to keep the local registry and the registry copy synchronized includes: If the difference entry exists in the local registry but not in the registry copy, then the difference entry is updated to the registry copy; If the difference entry is not present in the local registry but exists in the registry copy, then the difference entry is updated to the local registry; If the difference entry exists in both the local registry and the registry copy but is different, then the metadata of the corresponding entry in the local registry is overwritten with the metadata of the corresponding entry in the registry copy.

7. The decoupling method according to claim 1, characterized in that, The process of determining the semantic hash value includes: Obtain the metadata of the field to be calculated, and extract the attribute information from the metadata; The extracted attribute information is concatenated to obtain a semantic description string; The semantic description string is hashed to obtain the corresponding semantic hash value.

8. The decoupling method according to claim 7, characterized in that, The step of obtaining the metadata of the field to be calculated and extracting the attribute information from the metadata includes: Extract the core attributes from the metadata; The core attributes include at least two of the following: physical meaning, measurement object, data type, measurement unit, and value range, and must include physical meaning and measurement object.

9. The decoupling method according to claim 8, characterized in that, The step of hashing the semantic description string to obtain the corresponding semantic hash value includes: The semantic description string is hashed using either the CRC32 algorithm or the MurmurHash3 algorithm to obtain the semantic hash value.

10. The decoupling method according to any one of claims 1 to 9, characterized in that, Applied to the BMC side, the method also includes: After startup, a capability bitmap is generated based on the configuration file; wherein, the capability bitmap includes at least: a function flag field; each bit in the function flag field indicates the support status of a standard function of the BMC; The capability bitmap is sent to the BIOS, and a response code is received from the BIOS; wherein the response code is used to indicate the disabled status of each standard function of the BMC; Based on the response code, disable the corresponding standard function.

11. The decoupling method according to claim 10, characterized in that, The response codes include: full-feature mode codes, degraded mode codes, and security mode codes; When the BMC receives the full-function mode code, it enables all standard functions. When the BMC receives the downgrade mode code, it enables only basic functions and disables predefined complex operations. When the BMC receives the security mode code, it disables all data interaction interfaces.

12. The decoupling method according to claim 10, characterized in that, The capability bitmap also includes: a maximum data length field, a protocol version number field, a checksum field, and a reserved field; The maximum data length field is used to indicate the maximum data length supported by the BMC in a single communication. The protocol version number field is used to indicate the current firmware version of the BMC; The verification code field is a verification value calculated based on the function flag field, the maximum data length field, and the protocol version number field, and is used to verify the legality of the capability bitmap; The reserved fields are custom fields.

13. The decoupling method according to claim 10, characterized in that, Sending the capability bitmap to the BIOS includes: Write the capability bitmap to the target address in the shared memory area of ​​the BMC and the BIOS; The response codes returned by the BIOS include: Read the capability bitmap from the target address of the shared storage area.

14. The decoupling method according to any one of claims 1 to 9, characterized in that, Applied to the BIOS side, the methods also include: Receive a capability bitmap sent by the BMC; wherein the capability bitmap is generated by the BMC after startup according to the configuration file; the capability bitmap includes at least: a function flag bit field; each bit in the function flag bit field indicates the support status of a standard function of the BMC; The capability bitmap is parsed, and the support status of key functions is determined based on the function flag field; wherein, the key functions are one or more functions predefined from the standard functions of the BMC; Based on the support status of each key function, a corresponding response code is generated and returned to the BMC, so that the BMC can disable the corresponding standard function according to the response code.

15. The decoupling method according to any one of claims 1 to 9, characterized in that, Applied to the BIOS side, the methods also include: When the BIOS needs to access the shared memory area, it pulls a dedicated signal pin high; wherein, the dedicated signal pin is a dedicated signal pin between the BIOS and the BMC; when the dedicated signal pin is high, the BMC is prohibited from initiating access to the shared memory area; After the BIOS completes its access to the shared memory area, it pulls the dedicated signal pin low.

16. A decoupling device, characterized in that, Applied to the BMC side or BIOS side, the device includes: The field extraction module is used to receive data requests and extract the requested fields from the data requests. A semantic determination module is used to determine the semantic hash value corresponding to the request field; A semantic matching module is used to find matching entries from the local registry based on semantic hash values; wherein, the local registry stores the mapping relationship between the semantic hash values ​​of fields and metadata in the form of entries; The request-response module is used to read the metadata corresponding to the matching entry, read the raw hardware data from the corresponding hardware based on the metadata, and return the read raw hardware data as the request-response result. If no matching entry is found, the module scans a registry copy. The registry copy is stored in the shared storage area of ​​the BMC and the BIOS, and is a copy of the local registry of the BMC and the BIOS. The module iterates through all fields in the registry copy and calculates the corresponding semantic hash value, searching for a copy field whose semantic hash value matches the request field. After finding a matching copy field, the module queries the local registry for a local field that matches the copy field. Based on the metadata corresponding to the local field, the module reads the raw hardware data from the corresponding hardware, determines the request-response result based on the read raw hardware data, and returns it.

17. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the decoupling method as described in any one of claims 1 to 15.

18. A server, characterized in that, include: BMC firmware, BIOS firmware, and non-volatile memory; The non-volatile memory serves as a shared storage area for the BMC firmware and the BIOS firmware. Both the BMC firmware and the BIOS firmware include: A processor for implementing the steps of the decoupling method as described in any one of claims 1 to 15.

19. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a computer program, which, when executed by a processor, implements the steps of the decoupling method as described in any one of claims 1 to 15.

Images