TW201832078A - Method for generating a new version of firmware with unified extensible firmware interface generating a new version of firmware with an UEFI and XML profile without changing systematic firmware application codes - Google Patents

Abstract

A method for generating a new version of firmware with an Unified Extensible Firmware Interface, first includes steps of: establishing a native version of firmware with an Unified Extensible Firmware Interface (UEFI) firmware as a base, and simultaneously creating a shared variable data in the native Unified Extendable Firmware Interface (UEFI) firmware; loading the aforementioned native version of the Unified Extensible Firmware Interface (UEFI) firmware and an Extensible Markup Language (XML) profile through an editor of the computer platform window-based application. Therefore, allowing the Unified Extensible Firmware Interface (UEFI) firmware to dynamically add shared variable data to this firmware, and resulting in a new version of the Unified Extensible Firmware Interface (UEFI) firmware combining the native version of firmware with the Unified Extensible Firmware Interface (UEFI) firmware and Extensible Markup Language (XML) profile.

Description

 Method for producing a new unified uniform extendable firmware interface body  

The present invention relates to a method for generating a new version of a uniform extendable firmware interface body, and more particularly to a method for generating a firmware file of a new version of the extendable firmware interface basic input/output system without touching the firmware code of the system. Reduce system firmware development time and can be used on derivative systems.

The basic input and output system (BIOS) refers to the flash memory stored on the motherboard, which contains a lot of basic input and output system platforms such as computers, tablets or smart phones. The subroutine, on the motherboard for processing software and hardware communication settings, its BIOS settings and the hardware of the system platform are related. For example, if you change the BIOS on the motherboard of the system platform arbitrarily, it is likely that the system platform will not start.

The function of the BIOS is to set and control the operation of the central processing unit (CPU) and related chips, the clock and various standard peripheral device settings, such as: printer, mouse, keyboard, hard drive and soft Disc player. When the BIOS boots the system platform, it first determines if all peripherals are located and then loads the operating system into random access memory (DRAM) from a hard drive or disk drive. With this BIOS, operating systems and applications can use the BIOS to inherit the details of the input and output devices, such as the network card media access control (Medium Address Control, MAC address), disk drive capacity and location, etc., if the device changes Just notify the operating system or application through the BIOS changes.

However, with the development of information technology, the traditional BIOS can only assemble code in 16 bits, and there are many basic and unchangeable development restrictions, so even the new CPU and motherboard have more powerful capabilities. Reduce performance in conjunction with traditional BIOS.

Therefore, in order to solve the problem that the traditional BIOS cannot keep up with the advancement of science and technology, the Unified Extensible Firmware Interface Basic Input Output System (UEFI BIOS) has been developed. Compared to the traditional BIOS, users can make more settings for the computer under the UEFI BIOS. For example, the user can set parameters such as the fundamental frequency or multiplier of the Central Processing Unit (CPU), and store the parameters of the current computer operation as a configuration file.

The Unified Extensible Firmware Interface (UEFI) is a computer system specification that defines the software interface between the operating system and the system hardware as an alternative to the previous basic input/output system (BIOS). UEFI Power On Self Test (POST), connected operating system and interface to provide a connection system and hardware.

Since the UEFI program architecture is quite large compared to the old BIOS, it takes a certain amount of time to compile the code every time a new system is developed, and it takes a relatively long time to modify the relevant UEFI settings for verification. Or, when a similar derivative system needs to be generated, and the derivative system may have only a small part, such as different memory specifications, it takes the same time to modify and compile the code to generate a new UEFI firmware. On the derivative system. Therefore, how to complete the new UEFI program architecture in a faster and more concise manner has become an urgent problem to be solved in the field.

Therefore, in order to solve the problem of generating a new version of the Unified Extensible Firmware Interface (UEFI) program architecture, the present invention provides a method for generating a new unified extendable firmware interface body without re-modifying and compiling the code. , reduce the corresponding UEFI system architecture development time or / and quickly generate new UEFI firmware on the derivative system, using the development of the new version of the unified extensible firmware interface firmware stage can be saved without development The time of the code can also be applied to fine-tuning on different derivative systems.

To achieve the above object, the present invention discloses a method for generating a new version of a uniform extendable firmware interface body, which comprises: first establishing a native version of the Unified Extensible Firmware Interface (UEFI) firmware as a base, and simultaneously creating a shared variable. The data is in the native version of the Unified Extensible Firmware Interface (UEFI) firmware; when a new version of the carcass is generated, the native version of the Unified Extensible Firmware Interface (UEFI) firmware is loaded through a computer platform software application editor. And an Extensible Markup Language (XML) profile; and the compiler's compilation adds the variable data shared in the Extensible Markup Language (XML) profile to the native Unified Extensible Firmware Interface (UEFI) Within the firmware file, the Unified Extensible Firmware Interface (UEFI) firmware dynamically adds the shared variable data to the firmware, resulting in a native version of the Unified Extensible Firmware Interface (UEFI) firmware and scalability. A new version of the Unified Extensible Firmware Interface (UEFI) firmware combined with the Markup Language (XML) profile.

Wherein, the variable data is formed by a globally unique identifier (GUID) and a variable name and data (Data).

The variable data imported in the Extensible Markup Language (XML) profile is added to the last variable data in the native unified extendable firmware interface (UEFI) firmware. The variable data shared in the Extensible Markup Language (XML) profile will be imported into a non-volatile memory space (NVRAM) of a unified extendable firmware interface.

The invention has the advantages that in order to reduce the corresponding development time or to quickly generate a new UEFI firmware on the derivative system, the present invention first establishes a native unified extendable firmware interface firmware as a base, and simultaneously creates a shared variable. The data is on the native version, by which the variable data is formed by a globally unique identifier (GUID), variable name, and data (Data); then a new version is generated using a window application based on Extensible Markup Language (XML). Uniform extendable firmware interface firmware; this application software must also add the shared variable data and design the contents of this variable data in the extensible markup language. Finally, refer to the required system design to set the relevant data content for expansion. In the markup language (XML), the extended markup language (XML) profile and the native unified extendable firmware interface firmware are compiled on the application software to generate a new unified extendable firmware interface firmware. The process of carcass can be completed without re-editing and compiling the code, enabling developers to significantly reduce system firmware development time or In the system without having to touch the derived system firmware code.

100‧‧‧UEFI firmware device

110‧‧‧ firmware space boot block

120‧‧‧Main block of firmware space

130‧‧‧Non-volatile memory space

200‧‧‧New UEFI firmware device

300‧‧‧Add new variable data

S11, S12, S13, S14‧‧ steps

S21, S22, S23, S24‧‧ steps

1 is a schematic diagram of a spatial block of a UEFI firmware device of the present invention.

2 is a schematic flow chart of the operation of the native UEFI firmware of the present invention.

FIG. 3 is a schematic flowchart of generating a new version of UEFI body according to the present invention.

4 is a block diagram of a block for generating a new version of the UEFI firmware device according to the present invention.

The detailed description of the present invention and the technical description of the present invention are further illustrated by the embodiments, but it should be understood that these embodiments are for illustrative purposes only and are not to be construed as limiting.

Since the Unified Extensible Firmware Interface Basic Input Output System (UEFI BIOS) is developed in accordance with the UEFI Forum specification, the UEFI boot process is described as follows:

1. SEC phase: The main feature of the SEC (security) phase is "cache as RAM", that is, the cache of the processor is treated as a memory. Since the C language needs to use the stack, the system memory at this stage has not been initialized. When no memory is available, the processor cache is used as a memory, and the main memory is pre-initialized before being initialized. Verify the CPU/chipset and motherboard.

2. PEI phase: Similar to the initialization phase of the traditional BIOS, the PEI (pre-EFI initialization) phase is used to wake up the CPU and memory initialization. At this time only a small part of the memory is started. At the same time, the chipset and motherboard are also initialized. The next service program will determine that the CPU chipset is properly initialized. At this point, the EFI driver dispatcher will load the EFI driver memory into the DXE phase (driver execution environment) that starts all memory.

3. DXE phase: The main function of DXE is to communicate EFI driver and hardware. In other words, all the memory, CPU (here refers to the number of non-cores of two or more entities, that is, dual CPU socket processors or even four CPU socket processors), PCI, USB, SATA, and The shell will be initialized.

4. BDS phase: In the BDS (boot device selection) phase, the user can boot from the boot manager program page and select from the detected boot device.

5. TSL phase: Then enter the TSL (short system loading) phase, which is taken over by the operating system. In addition, UEFIShell can be selected during the BDS phase to allow the system to enter a simple command line for basic diagnostics and maintenance.

Please refer to FIG. 1 , which is a schematic diagram of three major firmware space blocks of a UEFI firmware device according to the present invention. A UEFI firmware device 100 can mainly program three firmware space blocks to respectively program the code and data of the different boot stages. 1. The Firmware Volume Boot Block (FV BB) 110 is used to store the code and data related to the booting of the UEFI, such as the SEC phase and the PEI phase, and may also be referred to as the pre-initialization of the extendable firmware (Pre -EFI Initialization Environment, PEI). Second, the Firmware Volume Main Block (FV MAIN) 120 is used to store the code and data related to the booting of the UEFI in the middle and late stages, such as the DXE phase, the BDS phase, and the TSL phase. 3. Non-Volatile RAM (NVRAM) 130 is the place to store the relevant variable data, and the members of the variable data contain GUID (Globally Unique Identifier) / variable name / data ( Data). Each variable data member has its own unique GUID and variable name, so the compiler can create a new empty variable, that is, only define a new GUID and variable name, and the data (Data) is empty data. The data (Data), such as integers and/or strings, required by the variable data is generated by the Windows application based on an Extensible Markup Language (XML) method.

Referring to FIG. 2, in the original UEFI code operation part, the method first starts step S11: establishing common variable data. The invention firstly establishes a native version of the Unified Extensible Firmware Interface (UEFI) firmware as a base, and establishes a shared variable data and a system preset variable data. The content of the variable data is a globally unique identifier (GUID). The variable name and data (Data) are formed, and the variable data exists in the non-volatile memory space (NVRAM) 130 of the UEFI firmware device 100.

Next, step S12 is performed: the common variable data is obtained. This variable data set is set by applying the aforementioned Extensible Markup Language (XML) file through the editor of the Windows application software (for example, Win32).

Steps S11 and S12 are continued to proceed to step S13: determining whether the acquired data meets the set value of the motherboard, and if yes, applying the shared variable data; or step S14: determining whether the acquired data meets the set value of the motherboard, and if not, Use the system's default values. Before importing into the firmware volume boot block (FV BB), you must first confirm whether the variable data is created or not. If it exists, the variable data is copied to the Hand of Block (Hob), and the block handover area is the method of variable control used in the PEI stage.

When the memory initialization is started, the variable data will be obtained first. If it is judged that the data meets the requirements of the system, the variable data will be imported, that is, all the hardware related parameters of the system. On the other hand, if it is judged that the data does not meet the requirements of the system, the system preset value is used to use the input parameter to complete the startup process.

Referring again to Figures 3 and 4, the generation of a new variable data set, i.e., the process of generating a new Unified Extensible Firmware Interface (UEFI) firmware, will be described. First, through step S21 of the editor of a computer platform window application software, the settings of the native version of the Unified Extensible Firmware Interface (UEFI) firmware and Extensible Markup Language (XML) are loaded. This step defines the input parameters required by the editor, and there are two parameters. The first one is the native version of the Unified Extensible Firmware Interface (UEFI) firmware in the UEFI firmware device 100, and the second is scalable. Markup Language (XML) profile. The aforementioned "native" Unified Extensible Firmware Interface (UEFI) firmware may be "First Edition Unified Extensible Firmware Interface (UEFI) Firmware" or may be the closest to the new motherboard to verify the relevant UEFI. The setting is or closest to the UEFI firmware within the UEFI firmware device 100 similar to the new derivative system.

Next, through step S22 of the window application software, a new variable data is created, and the new variable data content includes a new global unique identifier (GUID), a variable name, and a shared GUID of the data (data). ) with data (Data). The presence of all variable data is found in the native version of the Unified Extensible Firmware Interface (UEFI) firmware entered in the previous step through the editor, and all variable data is stored in the non-volatile memory space of the UEFI firmware device 100. Inside (NVRAM) 130, it is necessary to find the variable data of the last token from the non-volatile memory space (NVRAM) 130.

Next, step S23 is performed through the editor of the window application software: the setting of the Extensible Markup Language (XML) is set to the new variable data. Through the compilation of the editor, the new variable data imported in step 22 is added to the last variable data, and the shared variable data part is included with the global unique identifier (GUID), variable name and data ( Data), and all variable data is obtained from the Extensible Markup Language (XML) profile. That is to say, the new version of the Unified Extensible Firmware Interface (UEFI) firmware dynamically adds the shared variable data to this new firmware.

Finally, as in step S24: a new version of the UEFI firmware device 200 is generated. The non-volatile memory space (NVRAM) 130 loaded with the new shared variable data will be different from the aforementioned UEFI firmware device 100 carrying the native version of the Unified Extensible Firmware Interface (UEFI) firmware, and the update is generated as a new version. The UEFI firmware device 200, after adding the new variable data 300 to the non-volatile memory space (NVRAM) 130 of the UEFI firmware device 100, causes the UEFI firmware device 100 to be formed to contain new variable data. New version of UEFI firmware device 200.

That is to say, the new UEFI firmware device 200 will be a unified version of the new version of the Unified Extensible Firmware Interface (UEFI) firmware and the Extensible Markup Language (XML) profile. Body Interface (UEFI) firmware. Finally, the user can use the new Unified Extensible Firmware Interface (UEFI) firmware in the new UEFI firmware device 200 to import into the new system or the derivative system to perform the UEFI boot process.

In the case of the application of the new Unified Extensible Firmware Interface (UEFI) firmware, similar to the process of the native UEFI firmware operation in Figure 2 above, the variable data obtained (including the original version of the variable data and the new Whether the added variable data) matches the set value of the motherboard, if it is met, the variable data of the above modification is applied; if it is not, the system preset value is adopted. Before the firmware variable boot block (FV BB) is updated by the newly modified variable data, it must be confirmed whether the variable data is created or not. If it exists, the variable data is copied to the Hand of Block (Hob), and the block handover area is the method of variable control used in the PEI stage.

When the memory initialization is started, the variable data will be obtained first. If it is judged that the data meets the requirements of the system, the variable data will be imported, that is, all the hardware related parameters of the system. On the other hand, if it is judged that this data does not meet the requirements of this system, the system preset value will be used as the input parameter.

The following is an embodiment of the invention for modifying the setting of the system memory parameters. The main parameters of the motherboard are Reference Board ID/Data Width/Channel 1 Rank 0 Enable/Channel 1 Rank 1 Enable/Slot Density/DRAM Frequency Lo /DRAM Frequency Hi/DVFS Enable/DRAM Type/Memory Down/Slot Bus Width/DRAM Speed Grade. (Reference Board ID: Reference Board ID/Data Width: Data Width (x8, x16, x32)/Channel 1 Rank 0 Enable: Channel 1 Capacity 0 On / Channel 1 Rank 1 Enable: Channel 1 Capacity 1 On / Slot Density: Slot Density (1Gbit, 2Gbit, 4Gbit, 8Gbit, 16Gbit)/DRAM Frequency Lo: Memory minimum speed (1066MHz) / DRAM Frequency Hi: Memory maximum speed (1600MHz) / DVFS Enable: Dynamic voltage frequency adjustment / DRAM Type: Memory Category (DDR3L, LPDDR3)/Memory Down: Embedded Memory/Slot Bus Width: Slot channel width (32bits, 64bits) / DRAM Speed Grade: Fast, Typical, Slow, Slow Slow).

The set content of the Extensible Markup Language (XML) in the editor is as follows:

Assume that the memory required for implementing System A is set to Reference Board ID=1, DRAM Frequency Hi: 1066MHz, DRAM Type: LPDDR3, etc., when this relevant variable data is added to the new version of the new version of UEFI firmware device 200. When the Extendable Firmware Interface (UEFI) firmware is implemented, System A will judge whether the Reference Board ID is 1, and if so, it will import the new related variable data settings. If not, it will load the unified version with the original version. Preset value for the Extendable Firmware Interface (UEFI) firmware. As shown in the above Extensible Markup Language (XML), the data (Data) of the Reference Board ID (Reference Board ID) is 3, so the new related variable data settings are not imported, but the original version is loaded. The default value of the Unified Extensible Firmware Interface (UEFI) firmware.

The above is only the preferred embodiment of the present invention, and the scope of the invention is not limited thereto, that is, the simple equivalent changes and modifications made by the scope of the invention and the description of the invention are All remain within the scope of the invention patent.

Claims (4)

 A method for generating a new version of a unified extendable firmware interface body, comprising: first establishing a native version of the Unified Extensible Firmware Interface (UEFI) firmware as a base, and simultaneously creating a shared variable data for the native version to be uniformly extendable Firmware Interface (UEFI) firmware; when creating a new version of the carcass, load the native version of the Unified Extensible Firmware Interface (UEFI) firmware and an Extensible Markup Language (XML) through a computer platform software application editor. The configuration file; and the compiler's compilation to import the variable data shared in the Extensible Markup Language (XML) profile into the native version of the Unified Extensible Firmware Interface (UEFI) firmware, thereby enabling unification The Extended Firmware Interface (UEFI) firmware dynamically adds the shared variable data to this firmware file to generate a Unified Extensible Firmware Interface (UEFI) Firmware and Extensible Markup Language (XML) profile containing the native version. A new version of the Unified Extensible Firmware Interface (UEFI) firmware.    The method of claim 1, wherein the variable data is formed by a globally unique identifier (GUID), a variable name, and data (Data).    The method of claim 2, wherein the variable data imported in the Extensible Markup Language (XML) profile is added to the last variable of the native unified extendable firmware interface (UEFI) firmware. Behind the information.    The method of claim 3, wherein the variable data shared in the Extensible Markup Language (XML) profile is imported into a non-volatile memory space (NVRAM) of a unified extendable firmware interface. ).