WO2016082755A1

WO2016082755A1 - Displaying setup interface

Info

Publication number: WO2016082755A1
Application number: PCT/CN2015/095493
Authority: WO
Inventors: Xiangang FU
Original assignee: Hangzhou H3C Technologies Co., Ltd.
Priority date: 2014-11-25
Filing date: 2015-11-25
Publication date: 2016-06-02
Also published as: CN105653306B; CN105653306A

Abstract

At least two Setup interfaces are stored in the non-volatile storage. An identifier of the Setup interface currently in use may be acquired when entering the DXE phase. The interface data of the Setup interface having the identifier may be loaded. The interface data includes the interface description data and the interface parsing data. The interface description data may be parsed by using the interface parsing data having the identifier. Then upon satisfying a given requirement, the Setup interface is displayed according to the result of the parsing.

Description

DISPLAYING SETUP INTERFACE

Background

Uniform Extensible Firmware Interface (UEFI) is a proposed standard for the system, interface and service of personal computer (PC) firmware by Intel Corporation, which aims at providing a set of designated boot services uniform for all the platforms before loading the operation system. UEFI is considered as the successor of the conventional Basic Input Output System (BIOS) which has been used for over twenty years.

Brief Description of the Drawings

Fig. 1 illustrates a schematic for a hardware architecture for the main board in an example of the present disclosure；

Fig. 2 illustrates a schematic for another hardware architecture for the main board in an example of the present disclosure；

Fig. 3 illustrates a flowchart for a process of displaying a Setup interface in an example of the present disclosure；

Fig. 4 illustrates a flowchart for a process of generating a BIOS Image in an example of the present disclosure；

Fig. 5 illustrates a schematic for a boot process of BIOS and its interaction with Baseboard Management Controller (BMC) ； and

Fig. 6 illustrates a logic structure schematic of a device for displaying a Setup interface in one example of the present disclosure.

Detailed Description

Significantly different from the conventional BIOS, the UEFI’s system construction has several advantages including modularization, parameter stack transfer of C language style, and dynamic linking. The UEFI is easier to realize and has an improved fault-tolerance and error correction. Further, the UEFI is operating in a 32-bit or 64-bit mode which means a faster operating rate which exceeds the 16-bit code addressability of the conventional BIOS.

UEFI BIOS is designed with a modularization mechanism, which can be logically divided into two parts, hardware initialization and extensible firmware interface, in which the extensible firmware interface is a programmable open interface. With the extensible firmware interface, the providers of main board may realize more various powerful functions such as various kinds of backup and diagnosis functions which can be realized through the UEFI. The UEFI BIOS also provides a powerful networking function which may enable a reliable fault diagnosis remotely by the host, without entering the operating system.

The UEFI BIOS has a built-in graphic driving function which may provide a color graphic environment of a high resolution to display the Setup interface. When the user enters the Setup interface, he or she may click with a mouse to adjust various boot configuration parameters. As the UEFI develops, the boot configuration parameters which can be adjusted by the user on the Setup interface are more and more various, thus involving more and more complicated functions.

The boot process for the UEFI BIOS system includes the following five phases:

SEC (security) phase: taking the cache of the processor as a temporary memory, pre-validating the chipset of the processor and the main board；

PEI (Pre-EFI Initialization) phase: waking up the processor and initializing the memory；

DXE (Driver Execution Environment) phase: loading the driver and initializing the hardware；

BDS (Boot Device Selection) phase: the user may enter the Setup interface to select a boot device；

TSL (Transitory System Load) phase: according to the selected boot device, the operating system continues the boot process or enters related command lines to execute basic diagnosis and maintenance.

The data required for displaying the Setup interface may be usually stored in a BIOS ROM (read only memory) as a part of the BIOS Image. In DXE phase, after loading the HII (Human Interface Infrastructure) driver and initializing the HII database to construct the operating environment for a graphic interface, the processor reads the data for displaying the Setup interface from the BIOS ROM, and loads the data into the memory. When entering the BDS phase, if the user presses a preset key to enter the Setup interface, then the Setup interface is displayed using the loaded data.

In the existing technologies, no matter whether it is the interface being operated with combination of characters and direction keys or a simple graphic interface being operated with a mouse, the BIOS provides only one Setup interface； even the user may upgrade the BIOS or replace the burnt BIOS ROM to replace it with a new Setup interface, there is still only one Setup interface provided for the user after the upgrading or replacing. The easy extensibility of the UEFI may greatly increase the types of the boot configuration parameters which can be set by the user on the Setup interface. However, there are problems. For a non-professional user, it may be not necessary for he or she to modify the most of the boot configuration parameters； and if he or she wants to select the desired parameters to be modified from a great number of parameters, it may consume too much time or even cause serious consequence upon a operation error. Besides, if the number of the boot configuration parameters are reduced or limited to satisfy the needs of the non-professional users, it may be not good for the professional users to utilize the UEFI to improve the performance of the main board.

In one example of the present application, the control logic for displaying the Setup interface operating on the main board may display different Setup interfaces according to the user’s setting, so as to allow the user to load the desired corresponding Setup interface according to his or her own needs, thus improving the efficiency of setting the boot configuration parameters. In different examples of the present application, the main board may have a structure as shown in Fig. 1 or Fig. 2. Referring to Fig. 1, a processor 110 of a main board 10 may access an memory 140 through a north bridge 120, a south bridge 130 may be connected to the processor through the north bridge 120, and a non-volatile storage 150 may be connected with the south bridge 130； further, the south bridge 130 may be connected to a BMC (Baseboard Management Controller) ； a control logic for displaying the Setup interface may be stored in a non-volatile storage 150 and in the boot process, the control logic may be read by the processor 110 into the memory 140 to execute. Referring to Fig. 2, a processor 210 of a main board 20 may access an memory 230 through a PCH (Platform Controller Hub) 220, and a non-volatile storage 240 may be connected with the PCH 120； further, the PCH 120 may be connected with the BMC； a control logic for displaying the Setup interface may be stored in the non-volatile storage 240, and in the boot process, the control logic may be read by the processor 210 into the memory 230 to execute.

In the above example, the interface data for at least two Setup interfaces are stored in the

non-volatile storage

150 or 240. Each of the Setup interfaces may have its own identifier which may be a characteristic or variable distinguishing the interface from other interfaces. For example, each of the Setup interfaces may be configured with a unique code as its identifier, or configured with the address of the interface data of the Setup interface in the non-volatile storage as its identifier. The interface data of each of the Setup interfaces may include an interface description data and an interface parsing data. The interface description data defines the appearance of the interface, including objects to be displayed (such as letters or characters) and specific ways to display these objects (such as forms) . The interface parsing data defines in what specific way (such as interface input mode) to display the interface description data into the interface. The interface data may be stored in the non-volatile storage as a part of the BIOS Image.

The non-volatile storage for storing the interface data for at least two Setup interfaces may be a ROM, two or more data regions (such as data section or data block) are defined in the ROM, and each of the data regions may be stored with the interface data of a Setup interface. The non-volatile storage for storing the interface data for at least two Setup interfaces may be a non-volatile storage chip connected with the south bridge or the PCH through a SPI (Serial Peripheral Interface) , for example, the interface data of a Setup interface is independently stored in a Flash chip connected with the south bridge through a SPI, and the address switching and management of the flash chip is performed by BMC.

The flowchart of the control logic for displaying a Setup interface is as shown in Fig. 3.

At block 310, when entering the DXE phase, acquiring the identifier of a Setup interface currently in use.

When the Setup interfaces available for use is more than one, the user may select one of them as the Setup interface currently in use in a specific way. After entering the DXE phase, according to the specific way in which the user selects the Setup interface currently in use, acquire the identifier of the Setup interface currently in use.

In one example, the intellectualized management unit BMC integrated on the main board may be connected to the south bridge or PCH, which enables real-time monitoring and adjustment for the temperature and voltage on the main board, including management of power on and power off and monitoring for the boot process； BMC usually has a networking function which allows the user to set the parameters and issue the monitoring commands remotely. A management parameter which can be set by the user may be added in the BMC to store the identifier of the Setup interface currently in use. Since the BMC is able to monitor the boot process, when learning that the boot process enters the DXE phase, the BMC sends the identifier of the Setup interface currently in use to the processor, and then the processor obtains the identifier of the Setup interface currently in use.

In another example, a parameter of the Setup interface may be added in the boot configuration parameters of the BIOS to set and store the identifier of the Setup interface currently in use. The user may set the parameter in the Setup interface and select one of the Setup interfaces available for use as the Setup interface currently in use. In this way, the identifier of the Setup interface currently in use may be stored in the BIOS as the value of the parameter of the Setup interface. When entering the DXE phase, the processor reads the value of the parameter in the BIOS to obtain the identifier of the Setup interface currently in use.

Since the BMC is operating independently of the system on the main board, when using the BMC to set the Setup interface currently in use, the user may make variations to the settings at any time, and enable the variations to take effect after rebooting the system on the main board. In contrast, when setting the boot configuration parameters through BIOS, the user may reboot the system first to enter the Setup interface if the user wants to make variations to the settings, and after the variations are made, the user may reboot the system again to enable the variations to take effect.

At block 320, loading the interface data of the Setup interface having the identifier.

According to the identifier of the Setup interface currently in use, the processor reads the interface data of the Setup interface corresponding to the identifier from the non-volatile storage, the interface data including the interface description data corresponding to the identifier and the interface parsing data corresponding to the identifier, and loads the interface data into the memory.

At block 330, parsing the interface description data by using the interface parsing data having the identifier.

After the interface data is loaded, parse the loaded interface description data with the loaded interface parsing data, the details of the parsing can be referred to the specifications of generating and compiling of the interface description data, for example, using a IFR (Internal Forms Representation) parser to parse the interface description data in a binary form compiled and generated from VFR (Visual Forms Representation) files and UNI (Unicode) files.

At block 340, upon satisfying a given requirement, displaying the Setup interface according to the result of the parsing.

When obtaining the result of the parsing, upon satisfying a given requirement such as that in the boot process the user presses a preset key to enter the Setup interface, then according to the result of the parsing, display the Setup interface to the user.

It should be noted that, after entering the DXE phase, the loaded driver of UEFI for the buses and hardware may run independently. And, generally, the driver in acquiring the identifier of the Setup interface currently in use and loading the interface data of the Setup interface in block 310 and block 320, is different from the driver in parsing the interface description data in block 330. In one example, the driver for running block 330 may acquire the identifier of the Setup interface currently in use from the driver for running block 310 and block 320, so as to correctly invoke the interface description data and the interface parsing data. The way of transferring the parameter values between the drivers operating independently is associated with the specific implementations of the drivers.

In another example, the identifier of the Setup interface currently in use may be acquired again before parsing the interface data. In one example, when using the BMC to set the Setup interface currently in use, a request for the identifier of the Setup interface currently in use may be sent to the BMC before parsing the interface data, and then the BMC sends back the identifier of the Setup interface currently in use as a reply. In another example, when the Setup interface currently in use is set as one of the boot configuration parameters in BIOS, the values of the boot configuration parameters in the BIOS are read to obtain the identifier of the Setup interface currently in use.

Further, the information interaction with the BMC, including sending a request for the identifier of the Setup interface currently in use to the BMC and receiving the identifier of the Setup interface currently in use from the BMC, may be performed through an IPMI (Intelligent Platform Management Interface) interface, or through the register on the processor. The IPMI interface may be embodied in hardware with a south bridge chip LPC (Low Pin Count) ； or in software, embodied with KCS (Keyboard Controller Style) , or embodied with BT (Block Transfer) , or embodied in combination of KCS and BT. The information interaction with the BMC may also be performed by a user defined protocol and taking the implementation of the software as a parameter of the boot configuration parameters, the user may select the implementation of the software according to practical needs. Therefore, it maybe convenient to transfer information between the BMC and the system on the main board through the IPMI interface.

In the present disclosure, through storing the interface data for at least two different Setup interfaces in the non-volatile storage and according to the identifier of the Setup interface currently in use set by the user, loading the corresponding Setup interface, the above example of the present disclosure may satisfy diversified demands for use of the Setup interface from different users and improve the efficiency of setting the boot configuration parameters by the user. Further, the setting based on BMC also enables a flexible switchover control between multiple Setup interfaces.

In another example of the present disclosure, the interface data for at least two Setup interfaces may be stored as a part of the BIOS Image； and the user may set the identifier of the Setup interface currently in use from the management tools provided by the BMC. In this example, a process of generating a BIOS Image may be as shown in Fig. 4:

At block 410, receiving a VFR file and a UNI file written by the user for each of the Setup interfaces. The VFR file describes the set of forms of the Setup interface and formats thereof, and the character string resource in the UNI file is referenced as the text displayed in the Setup interface. Each Setup interface has its own VFR file and UNI file.

At block 420, compiling the VFR file and the UNI file of each Setup interface respectively to generate the interface description data of each Setup interface in a binary form.

At block 430, according to the parameters of each Setup interface such as interface input mode, generating the IFR interface parsing data of the Setup interface.

At block 440, storing the interface description data and the interface parsing data of each Setup interface into the non-volatile storage as a part of the BIOS Image. Since there is a mapping relation between the identifier of each Setup interface and its storage address, the processor may read the interface data of the Setup interface having an identifier according to the identifier and its mapping relationship.

The BIOS boot process of the system on the main board and its interaction with the BMC may be as shown in Fig. 5:

At the BMC, at block 551, receiving a parameter configuration provided by the user through a management interface provided by the BMC, including selecting which Setup interface to be set.

At the BMC, at block 552, storing the parameters set by the user including the identifier of the Setup interface currently in use through the management interface.

At block 553, the BMC controls the main board to be powered on.

At block 511, at the main board, the BIOS is powered on.

At block 512, executing the SEC phase and the PEI phase in the boot process.

At block 513, when the SEC phase and the PEI phase are completed, entering the DXE phase.

The BMC monitors the boot process of the system on the main board. When monitoring that the boot process enters the DXE phase, at block 554, at the BMC, sending the stored identifier of the Setup interface currently in use to the system on the main board.

At the system on the main board, at block 514, in the DXE phase, loading the driver for the buses and hardware including loading the HII driver and initializing the HII database to construct a hardware and software environment required for displaying the Setup interface.

At block 515, receiving the identifier of the Setup interface currently in use which is sent from the BMC.

It should be noted that, there is no timing relationship between block 514 and block 515.

At block 516, according to the identifier of the Setup interface currently in use, loading the interface data corresponding to the Setup interface including the interface description data of the Setup interface currently in use and the interface parsing data of the Setup interface currently in use.

At block 517, sending a request for the identifier of the Setup interface currently in use to the BMC before parsing the interface description data.

At the BMC, at block 555, when receiving the request from the system on the main board, the BMC sends back the identifier of the Setup interface currently in use to the system on the main board.

At the system on the main board, at block 518, receiving the identifier of the Setup interface currently in use replied from the BMC.

At block 519, parsing the interface description data corresponding to the Setup interface currently in use using the interface parsing data corresponding to the Setup interface currently in use.

At block 520, the boot process enters the BSD phase.

At block 521, determining whether the use presses a preset key to enter the Setup interface, if yes, executing block 522, and otherwise, executing block 523.

At block 522, displaying the Setup interface according to the result of the parsing in block 519, and executing the operations set by the user on the Setup interface. When the user exits the Setup interface, turning to block 511 to reboot.

At block 523, continuing other operations of the boot process. For example, entering the TSL phase and loading the OS, or entering the command lines according to the control from the user, or powering off according to the control from the user, etc.

In correspondence with the above process, the present application provides a device for displaying a Setup interface applied on the main board, and the device may be embodied in software or in hardware or in combination of both. Taking the software implementation as an example, as a logic device, it may be formed by machine readable instructions stored in a non-transitory storage medium and executable by a processor, for instance the control logic in execution for displaying the Setup interface read into the memory by the processor in Fig. 1 or Fig. 2. If implemented by hardware it may be by logic such as special purpose logic circuitry, a processor, application specific logic chip (ASIC) , field programmable gate array (FPGA) or the like.

Fig. 6 illustrates a device 6 for displaying a Setup interface in one example of the present disclosure applied on the main board. The interface data for at least two Setup interfaces may be stored in the non-volatile storage. The device 6 includes a first identifier acquiring unit 61, a loading unit 62, a parsing unit 63 and a displaying unit 64, in which: the first identifier acquiring unit 61 is configured to acquire the identifier of the Setup interface currently in use when entering the DXE phase； the loading unit 62 is configured to load the interface data of the Setup interface having the identifier, the interface data including the interface description data and the interface parsing data； the parsing unit 63 is configured to parse the interface description data having the identifier using the interface parsing data having the identifier； the displaying unit 64 is configured to, upon satisfying a given requirement, display the Setup interface according to the result of the parsing.

In one example, the device 6 may further include a second identifier acquiring unit 65 configured to acquire the identifier of the Setup interface currently in use before parsing the interface data.

The first identifier acquiring unit 61 may be configured to receive the identifier of the Setup interface currently in use which is sent by the baseboard management controller (BMC) when entering the DXE phase； the second identifier acquiring unit 65 may be configured to send a request for the identifier of the Setup interface currently in use to the BMC before parsing the interface data； and configured to receive the identifier of the Setup interface currently in use which is sent by the BMC.

In one example, the identifier of the Setup interface currently in use sent from the BMC is received through IPMI or through the register of the processor.

In another example, the identifier of the Setup interface currently in use is stored as the value of one of the Setup interface parameters； the Setup interface parameters are the boot configuration parameters of the Basic Input Output System (BIOS) ； at this time, the first identifier acquiring unit maybe configured to read the Setup interface parameters in BIOS to acquire the identifier of the Setup interface currently in use.

The non-volatile storage storing the interface data of at least two Setup interfaces may include: a ROM storing the interface data of each Setup interface into different data regions； or, a non-volatile storage chip connected with the south bridge or the platform controller hub (PCH) through a serial peripheral interface (SPI) .

The interface data of the at least two Setup interfaces may be stored in a BIOS Image file, the BIOS Image file including: the interface description data in a binary form generated by compiling VFR files and UNI files of at least two interfaces； and the interface parsing data of each interface.

The foregoing disclosure is merely illustrative of examples of the disclosure but are not intended to limit the disclosure, and any modifications, equivalent substitutions, adaptations, thereof made without departing from the spirit and scope of the disclosure shall be encompassed in the claimed scope of the appended claims.

Claims

A method for displaying a booting Setup interface, which is applied on a main board, wherein the interface data of at least two Setup interfaces are stored in a non-volatile storage, the method including:

acquiring the identifier of the Setup interface currently in use when entering the driver execution environment (DXE) phase；

loading the interface data corresponding to the identifier, the interface data including the interface description data and the interface parsing data；

parsing the interface description data by using the interface parsing data； and

upon satisfying a given requirement, displaying the Setup interface according to the result of the parsing.
The method according to claim 1, wherein the method further includes: acquiring the identifier of the Setup interface currently in use again before parsing the interface description data.
The method according to claim 2, wherein

acquiring the identifier of the Setup interface currently in use when entering the DXE phase includes: receiving the identifier of the Setup interface currently in use which is sent from the baseboard management controller (BMC) when entering the DXE phase；

acquiring the identifier of the Setup interface currently in use again before parsing the interface data includes: sending a request for the identifier of the Setup interface currently in use before parsing the interface data； and receiving the identifier of the Setup interface currently in use which is sent from the BMC.
The method according to claim 3, wherein receiving the identifier of the Setup interface currently in use which is sent from the BMC includes: receiving the identifier of the Setup interface currently in use through the intelligent platform management interface (IPMI) or through a register of the processor.
The method according to claim 1 or 2, wherein

the identifier of the Setup interface currently in use is stored as the value of one of the Setup interface parameters； the Setup interface parameters are boot configuration parameters for the basic input output system (BIOS) ； and

acquiring the identifier of the Setup interface currently in use includes: reading the Setup interface parameters in the BIOS to acquire the identifier of the Setup interface currently in use.
The method according to claim 1, wherein, the non-volatile storage storing the interface data of at least two Setup interfaces includes:

a read-only memory (ROM) storing the interface data of each of the Setup interfaces into different data regions； or

a non-volatile storage chip connected with a south bridge or platform controller hub (PCH) through a serial peripheral interface (SPI) .
The method according to claim 1, wherein, the interface data of the at least two Setup interfaces are stored in a BIOS Image file, the BIOS Image file including:

the interface description data in a binary form generated by compiling Visual Forms Representation (VFR) files and Unicode (UNI) files of the at least two interfaces； and

the Internal Forms Representation (IFR) interface parsing data of each of the interfaces.
A device for displaying a Setup interface for boot settings which is applied on the main board, wherein, the interface data of at least two Setup interfaces are stored in a non-volatile storage, the device including:

a first identifier acquiring unit, configured to acquire the identifier of the Setup interface currently in use when entering the driver execution environment (DXE) phase；

a loading unit, configured to load the interface data of the Setup interface having the identifier, the interface data including the interface description data and the interface parsing data；

a parsing unit, configure to parse the interface description data by using the interface parsing data； and

a displaying unit, configured to display the Setup interface according to the result of the parsing upon satisfying of a given requirement.
The device according to claim 8, wherein, the device further includes: a second identifier acquiring unit, configured to acquire the identifier of the Setup interface currently in use again before parsing the interface data.
The device according to claim 9, wherein

the first identifier acquiring unit is to receive the identifier of the Setup interface currently in use which is sent from the baseboard management controller (BMC) when entering the DXE phase； and

the second identifier acquiring unit is to send a request for the identifier of the Setup interface currently in use to the BMC again before parsing the interface data and receive the identifier of the Setup interface currently in use which is sent from the BMC.
The device according to claim 10, wherein the identifier of the Setup interface currently in use which is sent from the BMC is received through the intelligent platform management interface (IPMI) or the register of the processor.
The device according to claim 8, wherein, the identifier of the Setup interface currently in use is stored as the value of one of the Setup interface parameters； the Setup interface parameters are boot configuration parameters of the basic input output system (BIOS) ；

the first identifier acquiring unit is to read the Setup interface parameters in the BIOS to acquire the identifier of the Setup interface currently in use.
The device according to claim 8, wherein, the non-volatile storage storing the interface data of the at least two Setup interfaces includes:

a ROM storing the interface data of each of the Setup interfaces into different data regions； or

a non-volatile storage chip connected with a south bridge or the platform controller hub (PCH) through a serial peripheral interface (SPI) .
The device according to claim 8, wherein, the interface data of the at least two Setup interfaces are stored in a BIOS Image file, the BIOS Image file including:

the interface description data in a binary form generated by compiling Visual Forms Representation (VFR) file and Unicode (UNI) file of each of the at least two interfaces； and

the interface parsing data of an Internal Forms Representation (IFR) interface of each Setup interface.