CN113377586A

CN113377586A - Automatic server detection method and device and storage medium

Info

Publication number: CN113377586A
Application number: CN202110550937.6A
Authority: CN
Inventors: 李雪
Original assignee: New H3C Technologies Co Ltd Hefei Branch
Current assignee: New H3C Technologies Co Ltd Hefei Branch
Priority date: 2021-05-20
Filing date: 2021-05-20
Publication date: 2021-09-10
Anticipated expiration: 2041-05-20
Also published as: CN113377586B

Abstract

The disclosure provides a server automatic detection method, a device and a storage medium, which are used for solving the technical problem of low detection efficiency of a server. According to the technical scheme, the automatic testing module is integrated in the Shell Pkg development package of the BIOS based on the UEFI Shell execution environment, peripheral hardware equipment is not relied on, so that a user can complete configuration detection of bottom-layer hardware of the server, write server data parameters into an NVRAM (non-volatile memory) and hardware detection related to hardware register parameter modification by calling the automatic testing module in the UEFI Shell, and the detection efficiency of the server is improved.

Description

Automatic server detection method and device and storage medium

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a method and an apparatus for automatically detecting a server, and a storage medium.

Background

Before a server product is released, the function of a Basic Input/Output System (BIOS) of the server needs to be tested to verify the quality requirements of the product in terms of function, performance and the like. In addition, it is necessary to check and check the bottom hardware configuration information table provided by the BIOS system, for example, to perform full configuration detection on a server with 8 processors, to verify whether the server is configured with a specified number of memories and hard disks, and whether a specified number of external cards are in place. The above testing and inspection work requires a lot of labor time.

At present, the test environment for the bottom hardware of the BIOS system is generally configured under the OS, and after the system enters the OS, a test tool script obtains the current configuration condition of the system by relying on the kernel instruction of the OS to generate a test file result, thereby completing the detection of the basic hardware configuration of a server system. However, the OS is typically installed on the HDD hard disk, and when the OS cannot be accessed due to corruption of system OS files or an abnormality in the HDD hard disk, the test efficiency is affected.

System Management BIOS (SMBIOS) is a unified specification that a motherboard or System manufacturer needs to follow to display product Management information in a standard format. When detecting server bottom hardware equipment configuration information, whether configuration information is accurate in SMBIOS Table needs to be detected usually, SMBIOS Table has tens of sub-Table tables, current mainboard configuration is contained in the sub-tables, the more external card devices are, the more sub-tables are generated, the more cases are tested, the more manpower time is consumed to check, and missing operation is easy to occur.

The BIOS provides a human-machine interface, called BIOS SETUP interface, for setting up data in Non-Volatile random access memory (NVRAM). In the process of testing software and hardware of a server, some configuration options are required to be temporarily changed through a SETUP interface to meet preset conditions of test cases, a restart system is required to be modified for multiple times, the SETUP interface is entered to confirm whether option modification is effective, and when multiple options are modified, human errors such as omission or misoperation are easy to occur.

When hardware testing or debugging is carried out on a server, a temporary BIOS version is usually required to be frequently developed, and a code register is modified through the temporary BIOS version to meet testing requirements.

Disclosure of Invention

In view of this, the present disclosure provides a method, an apparatus, and a storage medium for automatic detection of a server, which are used to solve the technical problem of low detection efficiency of the server.

Fig. 1 is a flowchart of steps of an automatic detection method for a server according to the present disclosure, where the method is applied to an automatic test module in a unified extensible firmware interface UEFI Shell environment, and codes of the automatic test module are integrated in a development kit of a BIOS development kit, where the method includes:

101, an automatic test module acquires preset server bottom hardware reference configuration information;

102, reading actual configuration information of server bottom hardware in a system management BIOS (basic input/output System) Table, namely an SMBIOS (System management basic input/output System) Table, by an automatic test module;

and 103, comparing whether the reference configuration information of the bottom-layer hardware of the server is consistent with the actual configuration information of the bottom-layer hardware of the server by the automatic test module, and outputting a detection result.

Further, the method further comprises:

an automatic test module receives a server data parameter test request, wherein the server data parameter test request carries server data parameters which are related to a test item and are to be written into a non-volatile random access memory (NVRAM);

the automatic test module calls an interface function in UEFI for writing variable data into the NVRAM to write the server data parameters related to the test item;

after the server is restarted, the automatic test module calls an interface function in UEFI for reading variable data from the NVRAM to read the server data parameters related to the test item,

and judging whether the server data parameters related to the test items written before the server is restarted are consistent with the server data parameters related to the test items read from the NVRAM after the server is restarted.

Further, the method further comprises:

the automatic test module receives a test request of a hardware test item, wherein the test request of the hardware test item carries a parameter value needing to be written into a register of a hardware controller;

and the automatic test module writes the parameter values of the registers of the hardware controllers into the corresponding registers of the hardware controllers.

Further, the method further comprises:

and writing the steps for realizing the method into a script file by using a script language, executing the script file in a UEFI Shell environment, and automatically calling the automatic test module to perform automatic test after the script file runs.

Further, the method further comprises:

and writing the server bottom layer hardware benchmark configuration information into a nonvolatile storage region of a BIOS, and after the UEFI Shell environment is started, the automatic test module acquires the preset server bottom layer hardware benchmark configuration information from the BIOS.

Fig. 2 is a schematic structural diagram of an automatic server detection device provided in the present disclosure, and each functional module in the device 200 may be implemented by software, hardware, or a combination of software and hardware. The apparatus 200 comprises:

a reference configuration information reading unit 210, configured to obtain preset reference configuration information of the hardware in the bottom layer of the server;

an actual configuration information reading unit 211, configured to read actual configuration information of server bottom layer hardware in a system management BIOS Table, that is, an SMBIOS Table;

and a judgment and result output unit 212, configured to compare whether the reference configuration information of the server bottom-layer hardware is consistent with the actual configuration information of the server bottom-layer hardware, and output a detection result.

Further, the apparatus 200 further comprises:

a server data parameter receiving unit, configured to receive a server data parameter test request, where the server data parameter test request carries server data parameters to be written into a non-volatile random access memory NVRAM, where the server data parameters are related to a test item;

the server data parameter reading/writing unit is used for calling an interface function in UEFI (unified extensible firmware interface) for writing variable data into the NVRAM (non-volatile random access memory) and writing the server data parameters related to the test items; the server is also used for calling an interface function in UEFI (unified extensible firmware interface) for reading variable data from the NVRAM to read the server data parameters related to the test item after the server is restarted;

and the server data parameter judging unit is used for judging whether the server data parameters which are written before the server is restarted and are related to the test items are consistent with the server data parameters which are read from the NVRAM after the server is restarted or not after the server is restarted.

Further, the apparatus 200 further comprises:

the hardware register parameter receiving unit is used for receiving a test request of a hardware test item, wherein the test request of the hardware test item carries a parameter value which needs to be written into a register of a hardware controller;

and the register parameter writing unit is used for writing the parameter value of the register of the hardware controller into the corresponding register of the hardware controller.

Further, the apparatus 200 further comprises:

the reference configuration information writing unit is used for writing the reference configuration information of the bottom-layer hardware of the server into a nonvolatile storage area of the BIOS;

and after the UEFI Shell environment is started, the reference configuration information reading unit acquires the preset server bottom layer hardware reference configuration information from the BIOS.

According to the technical scheme, the automatic testing module is integrated in the Shell Pkg development package of the BIOS based on the UEFI Shell execution environment, peripheral hardware equipment is not relied on, so that a user can complete configuration detection of bottom-layer hardware of the server, write server data parameters into an NVRAM (non-volatile memory) and hardware detection related to hardware register parameter modification by calling the automatic testing module in the UEFI Shell, and the detection efficiency of the server is improved.

Drawings

In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments of the present disclosure or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and other drawings can be obtained by those skilled in the art according to the drawings of the embodiments of the present disclosure.

Fig. 1 is a flowchart illustrating steps of an automated server detection method according to the present disclosure;

fig. 2 is a schematic structural diagram of an automated server detection apparatus according to the present disclosure;

fig. 3 is a schematic structural diagram of an electronic device according to an embodiment of the disclosure.

Detailed Description

The terminology used in the embodiments of the present disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the embodiments of the present disclosure. As used in the embodiments of the present disclosure, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term "and/or" as used in this disclosure is meant to encompass any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information in the embodiments of the present disclosure, such information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of embodiments of the present disclosure. Depending on the context, moreover, the word "if" as used may be interpreted as "at … …" or "when … …" or "in response to a determination".

Unified Extensible Firmware Interface (UEFI) Shell (an interactive command line environment, also known as Pre-OS) provides a user with an Interface to interact with the UEFI Interface. The UEFI Shell is not used when an Operating System (OS) is normally started, a user needs to configure the System through the UEFI Shell when a certain function is implemented in the UEFI Shell, and the Shell environment can execute an extensible firmware interface (efi) application program, load efi device drivers, and boot the Operating System.

The UEFI Shell application is an open source project, a source code package of the UEFI Shell application is already contained in a BIOS program code, the UEFI Shell can be independently compiled into efi applications, a Shell. For the code implementation of the Shell, the Shell conforms to the general UEFI application, and the Shell internally supports the function of adding a debugging command and also supports the running of a script file with a naming format of x.nsh. The BIOS program code development is developed based on the EFI Development Kit (EDK), which includes a plurality of development packages named xxxPkg, of which ShellPkg is one.

The basic idea of the technical scheme is that an automatic test module is integrated in a Shell Pkg development package of a BIOS (basic input/output System) by relying on a unified UEFI Shell execution environment of pure software, and peripheral hardware equipment (such as a hard disk) is not relied on, so that a user can automatically complete a test requirement and output and store a test result only by calling the automatic test module in the UEFI Shell, and the detection efficiency of a server is improved.

Example 1

According to the method, after UEFI Shell is started, preset server bottom hardware reference configuration information (which can be understood as a factory configuration requirement of a server) and actual hardware configuration information of the server in a server SMBIOS Table are automatically read and compared through an automatic test module, and finally a detection result which can reflect whether the requirement is consistent with the actual configuration is output.

The method for detecting the configuration of the bottom hardware information of the server in the automatic detection method of the server in the embodiment of the disclosure comprises the following steps:

a1, an automatic test module acquires preset server bottom layer hardware reference configuration information from a BIOS or UEFI Shell;

in this embodiment, the preset server bottom layer hardware reference configuration information may be stored in the following manner:

the first mode is that the reference configuration information of the bottom layer hardware of the server is written into a nonvolatile storage area of a BIOS in a file form, and the preset reference configuration information of the bottom layer hardware of the server is read from the BIOS after the UEFI Shell is started. A user can write the reference configuration information of the underlying hardware of the server into a nonvolatile storage area of the BIOS in a file form through an interface provided by an automatic testing module integrated in the UEFI Shell. The file format for storing the preset reference configuration information of the bottom-layer hardware of the server may be a JSON format, and the like, and the work is not particularly limited. Json (JavaScript Object notification) is a JavaScript Object notation, and belongs to a lightweight text data interchange format. The automated test module may write the server bottom layer hardware benchmark configuration information into a JSON file of a benchmark configuration file (e.g., JSON _ static.

In the second method, the underlying hardware reference configuration information of a server is embedded in the code of the automatic test module, and since the factory configurations of each batch of servers are usually consistent, the underlying hardware reference configuration information of a batch of servers can be embedded in the code of the automatic test module.

The server bottom layer hardware benchmark configuration information may include, but is not limited to, a combination of one or more of the following:

(1) CPU information: CPU number of bits, CPU ID, cache capacity, vendor information, etc.;

(2) expanding the equipment information: the number of PCIE devices in place, equipment manufacturer ID, slot number, equipment type, equipment address information and the like;

(3) memory information: memory number of bits, memory device address information, etc.

Step A2, the automatic test module reads the actual configuration information of the server bottom layer hardware in the SMBIOS Table;

in the process of power-on self-test of the server, the BIOS system writes the current actual configuration information of the server into the SMBIOS Table, the actual configuration information of the bottom hardware of the server stored in the SMBIOS Table can be read through SMBIOS Handle Service, and the hardware configuration information contained in the Table is analyzed according to the SMBIOS Spec specification. The automated testing module may write the actual configuration information of the underlying hardware of the server into a JSON file of an actual configuration file (e.g., the name JSON _ smbios. JSON) for subsequent comparison detection.

And A3, comparing whether the reference configuration information of the bottom-layer hardware of the server is consistent with the actual configuration information of the bottom-layer hardware of the server by the automatic test module, and outputting a detection result.

For example, the automated testing module analyzes and compares contents in the reference configuration file JSON _ static.json and the actual configuration file JSON _ smbios.json, and if configurations of one or some options in the two configuration files are inconsistent, writes inconsistent entries into the detection RESULT file JSON _ SMBIOS _ RESULT file for the user to check the detection RESULT.

Example 2

NVRAM (Non-Volatile Ram) is a Non-Volatile random access memory that can keep data from being lost after power is turned off. That is, the random access memory is used to store information such as motherboard data in the NVRAM without losing after the server is powered off. In the BIOS Flash chip, a part of area is configured in a designated address range to endow NV (Non-Volatile) with the attribute of no loss in Power failure, in the early stage of server startup, BIOS writes related server data parameters (including server performance Power consumption parameters, initialized external card drive hardware parameters, OEM function configuration data and the like) and mainboard information into the NV area by initializing the NV area, and in the subsequent Power On Self Test (POST) process, BIOS finishes initialization of related functions of server hardware by reading data in the NV area as an index.

The human-computer interaction interface provided by the BIOS for setting data in the NVRAM is called a BIOS SETUP interface, and a user can manually change parameters of server data in an NVRAM area under the SETUP interface. In the process of testing actual software and hardware of a server, usually a tester needs to manually change the configuration of some or some server data parameters through a SETUP interface for many times so as to meet the preset conditions of a test case, then the server is restarted and enters the SETUP interface to observe whether the options are changed successfully and take effect, and when the number of the modified server data parameters is large, human errors such as omission or misoperation are easy to occur.

In the embodiment of the disclosure, the modification function of the server data parameter related to the preset condition of the test case is built in the automatic test module in the UEFI Shell, and a tester can automatically complete the steps of reading/writing the server data parameter in the NVRAM, restarting the server and verifying whether the modification of the server data parameter in the NVRAM is effective directly by selecting the test option provided by the automatic test module under the Shell, thereby reducing misoperation and improving test efficiency.

The method for detecting the server data parameters in the automatic detection method of the server in the embodiment of the disclosure comprises the following steps:

b1, an automatic test module receives a server data parameter test request, wherein the request carries a test item identifier and/or server data parameters;

if the request carries the server data parameter to be written into the NVRAM, the automatic test module can directly execute the write operation; if the test item identifier is carried, the automatic test module can read the server data parameter to be written into the NVRAM from the preset position through the test item identifier.

B2, the automatic test module calls an interface function in UEFI for writing variable data into the NVRAM to write server data parameters related to the test item;

for example, after an automated testing module is run in the Shell, a plurality of testing options are displayed, after a server data parameter testing option is selected, the automated testing module displays a plurality of testing sub-options, each sub-option corresponds to a preset condition of a test case, and after a certain sub-option is selected (which is equivalent to sending a server data parameter testing request, and the selected sub-option is equivalent to a testing item identifier), the automated testing module automatically executes corresponding parameter writing and restarting verification operations.

B3, automatically restarting the server by the automatic test module;

b4. after the server is restarted, the automatic test module calls an interface function in UEFI for reading variable data from NVRAM to read the server data parameters related to the test item;

step B5. determines whether the server data parameters associated with the test item written before the server reboot are consistent with the server data parameters associated with the test item read from NVRAM after the server reboot.

In order to continue to complete the test after the server is restarted, the automatic test module may write the current test item identifier into an NVRAM variable parameter for recording test intermediate data (for example, setting the variable parameter TestFlag to 1 indicates that there is an ongoing test, setting 0 indicates that there is no ongoing test, storing the test item identifier in testcurrvar, etc.), and after the server is started, the automatic test module automatically reads the intermediate data to verify and give a detection result.

The starting address and SIZE of the NVRAM region, SIZE, are typically already generated at the time of BIOS code compilation. For example, the first 4 bytes in the region with NVRAM Base + NVRAM Header Size as the start address are defined as 'NVAR' as signal, which is used to identify the NVRAM region, followed by the first variable: StdDefaults.

The NVRAM starting address is accessed under Shell, and the data stored in the NVRAM can be read. The _FVHis a Firmware volume Header (Firmware volume Header), identifies the Header position of the FV file, and can obtain the storage address of the variable Data according to the NVRAM Data storage offset address recorded in the Header, and the storage structure of the variable Data in the NVRAM is Signature ('NVAR') + Size + Next + Flag + Guid + Name + Data.

The first part is Signature, which is used to identify data attributes with a specific identifier. For example, if the data is required to be endowed with the NV attribute without losing due to power failure, the data attribute of the variable is set to be 'NVAR' through Signature;

the second part is Size, which is used for recording the Size occupied by the data structure of the variable in the memory;

the third part is Next, which is used to point to the storage address of the Next variable;

the fourth part is Flag, which is used for identifying the read-write attribute of the variable;

the fifth part is Guid used for recording 128bit variable codes which can uniquely distinguish the variables;

the sixth part is Name, which is used for recording the Name of the variable;

the seventh part is Data, which records the actual parameter values of the variables.

All SETUP option configuration variables are stored according to the above rules.

The variable parameter in the NVRAM can be read and written through a GetVariable/SetVariable function of UEFI, and the Guid and the Name can be used as the parameters of the function, namely, the storage address of the variable in the NVRAM can be uniquely identified, so that the read-write function of the service data parameter in the bottom NVRAM area is realized.

Example 3

Aiming at partial hardware test requirements, BIOS is required to temporarily modify registers of some controllers to disable or start corresponding functions, or BIOS software is required to develop and provide tests by modifying versions of some hardware parameters for multiple times, and finally a group of parameters with optimal mainboard performance are extracted.

According to the method, the UI operation interface is provided for a user through the automatic test module, the user is allowed to input specified test options through a command line in the Shell, and the user can select the specified test items to perform automatic test according to a specific hardware debugging case; debugging parameters can be dynamically input according to actual requirements, and after the automatic test module identifies the input parameters, the automatic test module automatically matches and writes the input parameters into the corresponding register, so that the problem that BIOS developers frequently go out temporary debugging versions is solved.

For different hardware test items, registers of the hardware controller to be modified may be different, for example, for a USB/PCIE eye pattern test, electrical parameters of the USB/PCIE controller need to be modified, so that the USB/PCIE eye pattern achieves an optimal effect; for CPU performance testing, CPU performance parameters need to be adjusted.

In the prior art, usually after a hardware developer provides a specific hardware parameter configuration requirement, a BIOS development engineer writes in a BIOS code to implement a corresponding controller hardware parameter, and then compiles a BIOS version, and after the BIOS version is powered on, a hardware test item can detect whether the set of parameter configuration can enable an eye diagram/performance to reach an optimal standard by a hardware test means.

According to the automatic testing module under the Shell environment, a hardware engineer can manually write parameter configuration under the Shell environment, the automatic testing module writes corresponding parameter configuration into a corresponding register of a controller, a BIOS development engineer is not required to add writing codes of the register of the hardware controller into BIOS codes, decoupling of a BIOS version and a hardware testing project is achieved, and hardware testing efficiency is improved.

For example, the speed of the Pdie equipment needs to be changed from Gen3 to Gen1 in the hardware test, a BIOS software developer needs to modify the value of a Pdie speed register in a code to Gen1 originally, a BIOS ROM bin file is generated after the code is compiled, the BIOS version is provided for the hardware tester, and the hardware tester writes the BIOS version onto a mainboard for testing.

After the technical scheme is adopted, hardware testers do not need to rely on a BIOS engineer to modify a compiling code to complete the burning process, only the process of entering the Shell environment is needed, the program of the automatic Test module provided by the present disclosure is operated, a hardware Test item Auto Test Pceie Speed is selected in a popup menu, and then a parameter value Gen1 of a Pceie Speed register needing to be written into Pceie in the hardware Test item is input, so that the operation of writing the Gen1 into the Pceie Speed register is completed. After the system is restarted, the hardware test can be started.

Based on the above description, in the automatic server detection method according to an embodiment of the present disclosure, the method for detecting the test item related to the modification of the register parameter of the server hardware controller includes the following steps:

c1, an automatic test module receives a test request of a hardware test item, wherein the request carries a parameter value needing to be written into a register of a hardware controller;

c2., the automatic test module writes the parameter values of the registers of the hardware controllers into the corresponding registers of the hardware controllers;

step C3. executing the hardware test item after the server is restarted;

the method for setting the register of the hardware controller provided by the disclosure is a basis for developing a hardware test project, for example, if a USB/PCIE eye pattern test project needs to be performed, firstly, a user is required to run the automatic test project provided by the disclosure in Shell, the user selects a USB/PCIE eye pattern test option in Shell environment, after inputting a corresponding register parameter value, an automatic test module writes the register parameter value into the register, and the user can use corresponding performance monitoring equipment (such as an oscilloscope) to detect the eye pattern performance of the output signal of the USB/PCIE equipment, thereby detecting whether the server reaches the corresponding performance standard.

Since the present disclosure integrates an automated testing module in the UEFI Shell environment, the present disclosure supports a script file, and a tester can write the testing steps of the above-described various tests into the script file using a scripting language, and automatically execute various test items by executing the script file in the Shell environment. For example, test steps of a plurality of test items are written into one nsh script file, then the script file is executed in a Shell environment, after the script file runs, an automatic test module provided by the present disclosure is automatically called to carry out automatic test, and test results can be output in a file form or on a screen so that a tester can check the test results.

Fig. 3 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure, where the electronic device 300 includes: a processor 310, such as a Central Processing Unit (CPU), a communication bus 320, a communication interface 340, and a storage medium 330. Wherein the processor 310 and the storage medium 330 may communicate with each other through a communication bus 320. The storage medium 330 stores therein a computer program which, when executed by the processor 310, implements the functions of the steps of the methods provided by the embodiments of the present disclosure.

The storage medium may include a Random Access Memory (RAM) or a Non-Volatile Memory (NVM), such as at least one disk Memory. In addition, the storage medium may be at least one memory device located remotely from the processor. The Processor may be a general-purpose Processor including a Central Processing Unit (CPU), a Network Processor (NP), etc.; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.

It should be recognized that embodiments of the present disclosure can be realized and implemented by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory memory. The method may be implemented in a computer program using standard programming techniques, including a non-transitory storage medium configured with the computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner. Each program may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language. Furthermore, the program can be run on a programmed application specific integrated circuit for this purpose. Further, operations of processes described by the present disclosure may be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The processes described in this disclosure (or variations and/or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or combinations thereof. The computer program includes a plurality of instructions executable by one or more processors.

Further, the method may be implemented in any type of computing platform operatively connected to a suitable interface, including but not limited to a personal computer, mini computer, mainframe, workstation, networked or distributed computing environment, separate or integrated computer platform, or in communication with a charged particle tool or other imaging device, and the like. Aspects of the disclosure may be embodied in machine-readable code stored on a non-transitory storage medium or device, whether removable or integrated into a computing platform, such as a hard disk, optically read and/or write storage medium, RAM, ROM, or the like, such that it may be read by a programmable computer, which when read by the storage medium or device, is operative to configure and operate the computer to perform the procedures described herein. Further, the machine-readable code, or portions thereof, may be transmitted over a wired or wireless network. The invention described in this disclosure includes these and other different types of non-transitory computer-readable storage media when such media include instructions or programs that implement the steps described above in conjunction with a microprocessor or other data processor. The disclosure also includes the computer itself when programmed according to the methods and techniques described in this disclosure.

The above description is only an example of the present disclosure and is not intended to limit the present disclosure. Various modifications and variations of this disclosure will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure should be included in the protection scope of the present disclosure.

Claims

1. An automatic detection method for a server is applied to an automatic test module in a Unified Extensible Firmware Interface (UEFI) Shell environment, wherein codes of the automatic test module are integrated in a development kit of a Basic Input Output System (BIOS) development kit, and the method comprises the following steps:

the automatic test module acquires preset server bottom hardware reference configuration information;

the automatic test module reads actual configuration information of server bottom hardware in a system management BIOS Table, namely an SMBIOS Table;

and the automatic test module compares whether the reference configuration information of the bottom-layer hardware of the server is consistent with the actual configuration information of the bottom-layer hardware of the server, and outputs a detection result.

2. The method of claim 1, further comprising:

3. The method of claim 2, further comprising:

4. A method according to claim 1, 2 or 3, characterized in that the method further comprises:

5. The method of claim 1, further comprising:

6. The automatic detection device of a kind of server, characterized by that, the device is applied to unified extensible firmware interface UEFI Shell environment, the code of the device is integrated in the development kit of the BIOS development kit of basic input output system, the device includes:

the system comprises a reference configuration information reading unit, a server bottom layer hardware reference configuration information reading unit and a server bottom layer hardware reference configuration information processing unit, wherein the reference configuration information reading unit is used for acquiring preset server bottom layer hardware reference configuration information;

the actual configuration information reading unit is used for reading actual configuration information of server bottom layer hardware in a system management BIOS Table, namely an SMBIOS Table;

and the judgment and result output unit is used for comparing whether the reference configuration information of the bottom-layer hardware of the server is consistent with the actual configuration information of the bottom-layer hardware of the server or not and outputting a detection result.

7. The apparatus of claim 6, further comprising:

8. The apparatus of claim 7, further comprising:

9. The apparatus of claim 6, 7 or 8, further comprising:

10. A storage medium having stored thereon a computer program, characterized in that the computer program, when being executed by a processor, carries out the method steps of any one of claims 1, 2, 3 or 5.