JP4961019B2 - How to use global variables for PEI modules in EFI based firmware - Google Patents

Description

  The present invention generally relates to firmware. Specifically, the present invention relates to a method for using the variable for pre-EFI initialization (PEI) phase during EFI pre-initialization (pre-EFI initialization: PEI) phase of the Platform Innovation Framework for Extensible Firmware Interface (EFI). .

  The Platform Innovation Framework for Extensible Firmware Interface (EFI) (hereinafter also referred to as “Framework”) was developed by Intel (r) Corporation (Santa Clara, California, USA). A series of robust architectural interfaces, implemented in C and designed to perform all the processing necessary to initialize the platform, from power on to control transfer to the operating system . The framework is mainly divided into two phases. That is, there are a pre-EFI initialization (PEI) phase and a driver execution environment (DXE) phase. In the PEI phase, a minimum number of processors, chipsets and platforms are configured to support memory discovery. In the DXE phase, the PEI phase is advanced by completing the initialization of the platform, processor and chipset device.

  In the PEI phase, no memory is available. Although there is no memory available, the processor cache can be temporarily initialized to function as random access memory (RAM), so that the stack and heap can be stored in the cache. Therefore, it is possible to execute a module compiled in a high-level language in the PEI phase.

  In this framework, it is known that in the PEI phase, there is a restriction in that the module uses a global variable as a read-only variable, that is, the global variable cannot be changed. Since no memory is available in the PEI phase, all data and code segments are placed in flash without being relocated.

  It is well known that data in flash cannot be changed as easily as data placed in other conventional memory devices. The PEI code can invoke write access to global variables in the data section of the flash, but the global variables cannot be changed. Because of these limitations, the PEI module suffers from several disadvantages. First, module global variables cannot be shared between multiple functions. All variables that must be shared between functions must pass through the stack or heap. For this reason, the code size can increase significantly. In addition, since the PEI code is executed in flash, compression may not be executed. Secondly, the boot performance is reduced. As the code increases, more processor cycles are required for decoding and execution. In addition, the processor cache is not enabled at this stage, which slows execution efficiency. In particular, this trend is seen when accessing global variables in flash frequently. Third, firmware developers cannot freely develop and test code.

  Therefore, there is a need for a method that enables global variable support in an EFI pre-initialization (PEI) environment for EFI-based firmware. There is also a need for a method that allows global variables to be changed during the PEI phase.

  The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, in combination with the description of the invention, reveal the principles of the invention. Together, those skilled in the art will be able to make and use the present invention. In the drawings, like reference numbers generally refer to the same, functionally similar, and / or structurally similar elements. The drawing in which an element is initially illustrated is indicated by the most significant digit in the corresponding reference number.

It is a figure which shows an example of the Portable Executable 32 (PE32) image which concerns on one Embodiment of this invention.

6 is a flowchart illustrating an example of a method for changing a PE32 image to enable read / write access to global variables during an EFI pre-initialization (PEI) phase, according to an embodiment of the present invention.

FIG. 6 is a block diagram illustrating an example of a PE32 image change to enable read / write access to global variables during an EFI pre-initialization (PEI) phase, according to one embodiment of the invention.

It is a flowchart explaining an example of the 1st correction method based on one Embodiment of this invention.

It is a flowchart explaining an example of the 2nd correction method based on one Embodiment of this invention.

  Although the invention is described herein with reference to example embodiments that are intended for particular applications, it should be understood that the invention is not limited to such example embodiments. Those of ordinary skill in the art, upon reference to the teachings herein, will conceive of additional variations, applications and embodiments that fall within the scope of the present invention, as well as additional technical fields where embodiments of the present invention have great utility. Will.

  When referred to herein as an “one embodiment”, “an embodiment” or “another embodiment” of the present invention, the specific features, structures or characteristics described in connection with that embodiment are Means included in at least one embodiment. Thus, the phrases “according to one embodiment” or “according to an embodiment” are used in various places in this specification, but do not necessarily refer to the same embodiment.

  Embodiments of the present invention relate to a method that allows global variable changes (ie, read / write access) in an EFI pre-initialization (PEI) phase. This object is realized by using a part of the processor cache as a usage model known as “Cache as RAM (CAR)”. By relocating the data section of the driver image from the flash device to the area of the CAR, the global variables can be freely changed as if they were in RAM.

  Embodiments of the present invention are described as being implemented in a flash device during the EFI pre-initialization (PEI) phase of EFI-based firmware. In the PEI phase of EFI-based firmware, the Portable Executable 32 (PE32) image format is used. One skilled in the art will appreciate that the present invention is not limited to flash devices, EFI-based firmware, or PE32 image formats. The present invention may also be implemented in other non-volatile storage devices based on different software / firmware environments that require different image formats where global variables are restricted to read-only access.

  EFI-based firmware supports the standard Portable Executable 32 (PE32) image format. The PE32 image format organizes code, data, and other information, such as relocation information, by section. The sections are arranged in close proximity to each other. When the image is loaded by the loader, the image layout in memory is substantially the same as the file image. An exception is that there is a slight bubble in the memory image layout because alignment is required between sections. In many cases, the loader modifies the memory image if the section is not loaded on the preferred linking base.

  FIG. 1 is a diagram showing an example of a Portable Executable 32 (PE32) image 100 according to an embodiment of the present invention. The PE32 image 100, also referred to herein as an executable driver module 100, comprises a text (.text) section 102, a data (.data) section 104, and a relocation (.reloc) section 106. According to one embodiment, text section 102 may also be referred to as code section 102. According to embodiments, the executable driver module 100 is not limited to the text section 102, the data section 104, and the relocation section 106. According to the embodiment, the executable driver module 100 may further include more sections, for example, an r data section, an rsrc section, and the like. As described above, since alignment is required between sections, sections 102, 104, and 106 need to be arranged in close proximity to each other.

  The text section 102 contains executable code for the executable driver module 100. Data section 104 includes data that is utilized during execution of text section 102. The relocation section 106 provides information on all address data items that are updated with absolute flash addresses.

  In order for the PE32 image to boot properly, sections 102, 104 and 106 must be placed in a contiguous virtual or physical memory space. When the paging scheme is enabled, sections 102, 104 and 106 need to be in a contiguous virtual memory space. If no paging scheme is required, sections 102, 104 and 106 need to reside in contiguous physical memory. In the case of EFI firmware, the paging method is always disabled. Thus, sections 102, 104 and 106 are placed in a contiguous physical memory space. Thus, sections 102, 104, and 106 of executable driver module 100 are not divided into a plurality of discrete memory ranges. If the executable module is loaded into another base, all sections (102, 104 and 106) of the executable driver module 100 must all be relocated to the new base. It is not allowed to relocate only code sections (also called “text sections”) to a base and relocate a data section to another discontinuous new base.

  In order to achieve the goal of being able to change global variables in the PEI phase, the PE32 section (102, 104 and 106) of the executable driver module 100 must be divided into different memory ranges. For example, the text section 102 must be kept in flash space, while the data section 104 in which static and / or global variables are stored must be relocated to the CAR. The spatial ranges of the flash and the CAR are different from each other and are discontinuous.

  In order to properly execute the executable driver module 100 while moving the data section 104 to the CAR while keeping the text section 102 and the relocation section 106 in flash, build before the code is burned to flash. Patch the text section 102 and data section 104 based on the tool. This is because once the code enters flash, it must be executed without modification or relocation on the fly. For this reason, in the present invention, the first correction is required in which the image is corrected on a specific flash base based on the rearrangement information. In the first modification, all code is executed directly in flash and all data accesses are also done in flash, so write access to global variables is blocked. In order to allow write access to all global variables in the executable driver module 100, a second modification is required. According to the second modification, all the code accessing the data section 104 and all related data pointing to the fields in the data section 104 are updated to read from the CAR and process the data section 104. This is because the data section 104 is copied from flash to CAR before the code is executed.

  FIG. 2 is a flowchart 200 illustrating an example method for changing a PE32 image to enable read / write access to global variables during a pre-EFI initialization (PEI) phase, according to one embodiment of the invention. The present invention is not limited to the embodiments described herein with reference to flowchart 200. It will be apparent to those skilled in the art that other functional flowcharts are within the scope of the present invention upon reference to the teachings herein. Processing begins at block 202 and proceeds immediately to block 204.

  In block 204, the executable driver module 100 is generated. Executable driver module 100 includes a global variable that, when executed on a flash device, only allows read access. Subsequently, the process proceeds to block 206.

  At block 206, a first modification of the executable driver module 100 is performed. Although the first correction will be described later in detail with reference to FIG. 4, all address data items are corrected with the flash absolute address. Subsequently, the process proceeds to block 208.

  At block 208, a second modification of the executable driver module 100 is performed. The second modification, which will be described in detail later with reference to FIG. 5, is a second modification for all address data items modified in the first modification that point to the data section 104 of the executable driver module 100. Implement the correction. The second modification updates these data addresses with CAR absolute addresses. In the second modification, text section 102 and data section 104 may be updated with a CAR absolute address to reflect the data address. Completing the second modification will result in a final EFI firmware image (final executable driver module) ready to be burned to flash. The final EFI firmware image contains the absolute CAR address needed to allow read / write access of global variables to the CAR. Subsequently, the process proceeds to block 210.

  At block 210, the final EFI firmware image (final executable driver module) is burned to flash. Subsequently, the process proceeds to block 212.

  When the flash boots, the firmware loader copies the data section 104 from the flash to the CAR and transfers control to the image entry point for execution. As a result, the executable driver module 100 can be normally executed in the flash while the data section 104 is stored and processed in the CAR. By doing so, static variables and global variables can be freely accessed in the PEI phase. That is, with this configuration, the global variable has read / write access in the CAR.

  FIG. 3 shows an example of a change in the PE32 image (executable driver module) 100 to enable read / write access to global variables during the pre-EFI initialization (PEI) phase according to one embodiment of the present invention. It is a block diagram. In FIG. 3, flash 302, flash 302 ', and CAR 304 (part of the processor cache as described above) are shown.

  The flash 302 includes an executable driver module 100 having a text section 102, a data section 104, and a relocation section 106. The first modification is illustrated in text section 102 and data section 104 of flash 302. In the first modification, all address data items are modified with the absolute address of the flash based on the relocation section 106. The second modification is illustrated in flash 302 '. In the second modification, all relevant data pointing to the field in the data section 104 is modified with the CAR absolute address.

  FIG. 4 is a flowchart 400 illustrating an example of a first correction method according to an embodiment of the present invention. The present invention is not limited to the embodiments described in connection with flowchart 400 herein. It will be apparent to those skilled in the art that other functional flowcharts are within the scope of the present invention upon reference to the teachings herein. Processing begins at block 402 and proceeds immediately to block 404.

  For PE32 images, the relocation section 106 records all points in the executable driver module 100 that are to be modified after loading. The relocation section 106 generally provides relative virtual address (RVA) information. RVA is an offset from the base address at which the image is loaded into memory. RVA identifies all addresses to which the patch is applied in the first modification within the executable driver module 100. Each patch application address is updated by adding a flash base specified for loading.

  At block 404, the points in the relocation section 106 are analyzed. Subsequently, the process proceeds to block 406.

  In block 406, the address data of the point specified in block 404 is updated with the flash absolute address. Proceed to decision block 408.

  At decision block 408, it is determined whether there are any other points in the relocation section 106 that need to be corrected. If there are other points in the relocation section 106 that need to be corrected, return to block 404 to analyze the next point.

  Returning to decision block 408, if it is determined that there are no more points in the relocation section 106 to be analyzed, the process proceeds to block 410 and the first correction is terminated.

  The first correction is also illustrated in flash 302 of FIG. In flash 302 of FIG. 3, examples of points in relocation section 106, data location B in data section 104 and flash absolute addresses Ma and Mb, data code locations A and C in text section 102, and flash An absolute address Mc is illustrated. Ma is the flash absolute address for code position A. Mb is the flash absolute address for data location B. Mc is the flash absolute address for code position C.

  The illustrated points Ra, Rb, and Rc are highlighted in the relocation section 106. Ra includes relocation information that points to code position A (in text section 102). The address data at code position A is updated with the flash absolute address Ma in the data section 104. Rb includes relocation information that points to data location B (in data section 104). The address data at the data position B is updated with the flash absolute address Mb in the data section 104. Finally, Rc contains relocation information that points to code position C (within text section 102). The address data at the code position C is updated with the flash absolute address Mc in the text section 102.

  The flash 302 'indicates the second correction method. Flash 302 'shows relocation section 106, data section 104', and text section 102 'highlighting the illustrated points Ra, Rb, and Rc. The data section 104 ′ includes a data position B and CAR absolute addresses Mb ′ and Ma ′. The text section 102 'includes positions A and C and a flash absolute address Mc. Note that the text section 102 of the flash 302 has been modified in the flash 302 '(data section 102') to store the address change Ma '.

  When addresses such as Mb and Ma of flash 302 are found in data section 104, it can be seen that the code in text section 102 is accessing a static or global variable. Since the data section 104 ′ of the flash 302 ′ is copied to the CAR 304, these addresses (Mb and Ma) are the CAR absolute addresses (Mb ′ and Ma ′) as shown in the data section 104 ′ of the flash 302 ′. Must be updated to reflect. This necessitates further patching by adding a gap between the specified flash base and the CAR base. Other addresses located outside the data section 104 of the flash 302 or the data section 104 'of the flash 302' (eg, the Mc in the text section 102 and the text section 102 ') remain in the flash and are further patched do not have to. That is, the text section 102 is executed in flash.

  By referring to the address corrected in the first correction, it can be very easily determined whether or not the address is in the data section 104. All accesses to addresses in the flash data section 104 are redirected to the CAR 304 data section 104 ′. After redirecting the address of the data section 104 of the flash to obtain the data section 104 ′, the data section 104 ′ is copied from the flash 302 ′ to the CAR 304. At this stage, executable driver module 100 may execute normally based on data section 104 ′ stored and processed in CAR area 304. By doing so, booting performance is greatly improved because all accesses of static variables and global variables are performed by the CAR 304 instead of the flash after the rearrangement. Therefore, by further applying a patch to the address pointing to the data section 104 after the first modification, the data section is separated from the entire image layout and relocated to any other specific address. Can do. By placing the data section 104 ′ in the CAR 304, the executable driver module 100 can have read / write access to global variables in the PEI phase.

  As shown in the flash 302 ', the previously corrected address data (Mb) of the position B is updated with the CAR absolute address Mb', and the previously corrected address data (Ma) of the position A is updated to the CAR absolute address Ma. Update with ´. The corrected location C address data (Mc) is in the text section 102 and the text section remains in flash, so the corrected location C address data (Mc) is not updated.

  The CAR 304 is the part of the processor cache where the data section 104 'is copied. As described above, when the firmware is burned into the flash space, the firmware loader copies the data section 104 'from the flash to the CAR. By moving the data section 104 ′ to the CAR 304, PEI static and global variables can have read and write access through the CAR 304.

  FIG. 5 is a flowchart 500 illustrating an example of the second correction method according to an embodiment of the present invention. The present invention is not limited to the embodiments described herein with reference to flowchart 500. It will be apparent to those skilled in the art that other functional flowcharts are within the scope of the present invention upon reference to the teachings herein. Processing begins at block 502 and proceeds immediately to decision block 504.

  In decision block 504, it is determined whether the address data item modified in the first modification points to the data section 104. If there is an address data item modified in the first modification pointing to the data section 104, the address data item is selected in block 506 and processing proceeds to block 508. If there is no address data item modified in the first modification pointing to the data section 104, the process proceeds to block 512 and the process ends.

  In block 508, the address data item selected in block 506 is updated with the CAR absolute address. Proceed to decision block 510.

  In decision block 510, it is determined whether there are any other address data items that have been modified in the first modification pointing to the data section 104. If there are other address data items that were modified in the first modification pointing to the data section 104, return to block 506 to select the next address data item to be modified.

  Returning to decision block 510, if it is determined that there are no more address data items modified in the first modification pointing to the data section 104, the process proceeds to block 512 and the process ends.

  Embodiments of the invention may be implemented using hardware, software, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. The techniques described herein may be applied to any computing environment, consumer electronics environment, or processing environment. The technology relates to portable or fixed computers, portable information, comprising a processor, a storage medium (including volatile and non-volatile memory and / or storage elements), at least one input device, and one or more output devices. Terminal (PDA), set-top box, mobile phone and pager (registered trademark), consumer electronics (DVD (digital video disc) player, personal video recorder, personal video player, satellite receiver, stereo receiver, cable) (Including television receivers) as well as other electronic devices, which may be implemented in a program executed on a programmable machine. The program code is applied to data input using the input device, and executes the above-described function to generate output information. The output information may be applied to one or more output devices. One skilled in the art can appreciate that the present invention can be implemented with various system configurations. Such system configurations are multiprocessor systems, minicomputers, mainframe computers, independent household appliances, and the like. The invention may also be practiced in distributed computing environments where tasks or portions thereof are remote processing devices that are linked through a communications network.

  Each program may be implemented in a high level procedural programming language or an object oriented programming language to communicate with the processing system. However, if desired, the program may be implemented in assembly language or machine language. In any case, the language can be compiled or interpreted.

  Based on a program instruction, a general-purpose or application-specific processing system programmed with the instruction may execute the processing described in this specification. Alternatively, the process may be performed by a specific hardware element with hardwired logic that performs the process, or by any combination of programmed computer elements and custom hardware elements. It may be. The methods described herein may be provided as a computer program product that includes a machine-accessible medium that stores instructions that cause a processing system or other electronic device to be programmed to perform the method. As used herein, the term “machine-accessible medium” can store or encode a sequence of instructions to be executed on a machine and cause the machine to perform any one of the methods described herein. Any medium can be included. Thus, the term “machine accessible medium” is intended to include, but is not limited to, solid state memory, optical and magnetic disks, and a carrier wave that encodes a data signal. In addition, it is recognized in the art that software is recognized as performing an operation or producing a result in one form or another form (for example, a program, procedure, process, application, module, logic, etc.). Then it is normal. Such a representation is merely intended to briefly describe the execution of software by a processing system that causes a processor to perform an operation or generate a result.

  While various embodiments of the invention have been described above, it is to be understood that these embodiments are for purposes of illustration and are not intended to limit the invention. It will be apparent to those skilled in the art that various modifications can be made in the structure and details without departing from the spirit and scope of the invention as defined in the claims. Therefore, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined by the appended claims and their equivalents.

Claims (19)

A computer comprising a processor enables a global variable read / write operation in EFI pre-initialization (PEI),
The processor generates a driver image having a code section, a data section, and a relocation section;
The processor performs a first modification to the driver image to modify all address data items with non-volatile memory absolute addresses;
All the processor, to implement the second round fixing to the driver image, the cache absolute address as a random access memory (RAM), said pointing to data section, were fixed in the first round fixing Modifying the address data item of
The processor comprises burning the modified driver image to a non-volatile memory device;
When the non-volatile memory device boots, the processor copies the data section of the burned driver image to a cache (CAR) as RAM and executes the executable code of the code section to And global variables can be read / written from the CAR. The method of claim 1, wherein the driver image comprises a Portable Executable 32 (PE32) image. The driver image The method of claim 1 or 2 is executed in the nonvolatile memory. The method according to claim 1, wherein the non-volatile memory includes a flash memory device. The processor performing the first modification comprises:
The processor analyzing each point in the relocation section;
The processor according to any one of claims 1 to 4 , further comprising: updating each address data item associated with each point in the relocation section with the non-volatile memory absolute address. Method. The processor performs the second correction,
The processor determining whether the address data item modified in the first modification points to the data section;
The processor includes the step of updating the modified address data item with the cache absolute address if the address data item modified in the first modification points to the data section. Item 6. The method according to any one of Items 1 to 5 . A computer comprising a processor uses a global variable in the pre-EFI phase,
A first modification in which the processor modifies an address data item of the driver image on a non-volatile memory basis using the relocation portion of the driver image having a code portion, a data portion and a relocation portion; and a random Patch the code portion by performing a second modification that modifies all address data items modified in the first modification, pointing to the data part by an absolute cache address as an access memory (RAM) Applying the patch and burning the patch-applied code in a non-volatile memory;
The processor copying the data portion to an area of a processor cache that is utilized as random access memory (RAM);
The processor transfers control to an image entry point of the driver image to execute the driver image; and
The global variable is accessed from the processor cache used as RAM. The method of claim 7 , wherein the non-volatile memory comprises a flash memory device. An electronic device that enables the use of global variables in the EFI pre-initialization (PEI) phase,
A processor;
An executable driver image having a code portion, a data portion, and a relocation portion;
A nonvolatile memory you store the executable driver image,
With processor cache,
The code portion includes executable code, the data portion includes data utilized by the executable code, and the relocation portion is determined by a non-volatile memory absolute address during a first modification of the executable driver image. Contains information on all address data items to be updated,
The processor cache area is used as a random access memory (RAM) cache (CAR),
The data portion of the executable driver image is stored in the executable driver image to allow processing of static and global variables in the CAR while the processor is executing the executable driver image. The first correction and the second correction that corrects all the address data items corrected in the first correction that point to the data portion by the cache absolute address as the RAM were performed. Later copied to the CAR
Electronic devices . After the executable said driver image first round fixing and the second round fixing, before execution of the executable driver image, according to claim 9, baking the executable driver image in the non-volatile memory Electronic devices . The electronic device according to claim 9 or 10 , wherein the nonvolatile memory includes a flash memory device . On the computer,
Generating a driver image with a code section, data section and relocation section,
And performing a first round fixing to the driver image, the step of modifying all address data items in non-volatile memory absolute address,
And performing a second round fixing to the driver image, the point to the data section, all said modified address data items in the first round fixing, the cache absolute address as a random access memory (RAM) A stage to fix,
A step that baking the modified driver image in the non-volatile memory device,
Copying the data section of the burned driver image to a cache (CAR) as RAM upon booting of the non-volatile memory device ;
Is a program for executing
During execution of executable code in the code section, static variables and global variables can be read and written from the CAR.
Program . The program according to claim 12 , wherein the driver image includes a Portable Executable 32 (PE32) image. The program according to claim 12 or 13 , wherein the driver image is executed in the nonvolatile memory. The program according to claim 12 , wherein the nonvolatile memory includes a flash memory device. The stage of the first revision is
Comprising the steps of analyzing each point in the relocation section,
Wherein each address data item associated with each point in the relocation section, the program according to any one of claims 12 to 15 and a step of updating by the non-volatile memory absolute address. The stage of the second revision is
The method comprising the said address data items fixed in the first round fixing, it is determined whether or not point to the data section,
Wherein when the first round of the address data items that were fixed in fix points to the data section, claims 12 and a step of updating the corrected address data item in the cache absolute address 16 The program according to any one of the above. On the computer,
A first modification to modify an address data item of the driver image on a non-volatile memory basis using the relocation portion of the driver image having a code portion, a data portion and a relocation portion; and a random access memory (RAM) ) To apply the patch to the code part by performing a second modification that modifies all address data items modified in the first modification, pointing to the data part by the cache absolute address as Burning the patched code into non-volatile memory;
Copying the data portion to an area of a processor cache being utilized as random access memory (RAM);
The method comprising transferring control to an image entry point of the driver image for execution of the driver image,
Is a program for executing
Global variables are accessed from the processor cache used as RAM.
Program . The program according to claim 18 , wherein the nonvolatile memory includes a flash memory device.

Images