WO2008014635A1

WO2008014635A1 - A method to use global variables for pre-efi initialization modules in efi-based firmware

Info

Publication number: WO2008014635A1
Application number: PCT/CN2006/001746
Authority: WO
Inventors: Xiang Ma; Hua Shao; Zhijun Liu
Original assignee: Intel Corporation
Priority date: 2006-07-18
Filing date: 2006-07-18
Publication date: 2008-02-07
Also published as: CN101484878A; EP2047364A4; EP2047364A1; JP2009544085A; JP4961019B2; KR20090035521A; KR101036675B1; CN101484878B

Abstract

A method for enabling global variable read/write operations in a pre-EFI Initialization (PEI). The method includes the generation of a driver image. The driver image includes at least a code (i.e., text) section, a data section, and a relocation section. A first round fixing on the driver image is performed to fix all address data items with absolute non-volatile memory addresses. A second round fixing on the driver image is performed to fix all address data items fixed in the first round fixing that point to the data section with absolute Cache-As-RAM (Cache-As-Random Access Memory) addresses. The fixed driver image is burned into a non-volatile memory device. Upon booting the non-volatile memory device, the data section of the burned driver image is copied to a Cache-As-RAM (CAR), wherein execution of executable code in the text section enables static and global variables to have read/write access from the CAR.

Description

A METHOD TQ USE GLOBAL VARIABLES FOR PRE-EFl INITIALIZATION MODULES IN EFI-BASED FIRMWARE

BACKGROUND OF THE INVENTION

Field of the Invention

[0001] The present invention is generally related to Firmware. More particularly, the present invention is related to a method to use global variables during a pre-EFI (pre-Extensible Firmware Interface) initialization phase of a Platform Innovation Framework for EFI.

Description

[0002] The Platform Innovation Framework for EFI (Extensible Firmware

Interface), developed by Intel® Corporation in Santa Clara, CA., is a set of robust architectural interfaces, implemented in C, that are designed to perform the full range of operations required to initialize a platform from power on through the transfer of control to an operating system. The Platform Innovation Framework for EFI (also referred to as "the Framework") is divided into two major phases: Pre-EFI initialization (PEI) phase and Driver Execution Environment (DXE) phase. The PEI phase performs minimal processor, chipset and platform configuration to support memory discovery. The DXE phase furthers the PEI phase by completing the initialization of platform, processor and chipset devices.

[0003] In the PEI phase, there is no memory available. Although there is no memory available, processor cache can be temporally initialized to act as RAM (Random Access Memory), thus, enabling the stack and heap to be stored in the cache. This provides the possibility for running high-level programming language compiled modules in the PEI phase.

[0004] A known limitation in the framework is that modules in the PEI phase use global variables as read-only variables, i.e., the global variables cannot be modified. Since memory is not available in the PEI phase, all data and code segments are placed in Flash without relocation.

[0005] It is a well known fact that data in Flash is not as easily modified as data placed in other conventional memory devices. Although PEI code may invoke write access to the global variables in the data section of the flash, the global variables cannot be modified. This limitation provides several drawbacks to PEI modules. First, the ability to share module global variables among functions is hindered. All variables that need to be shared across functions must be passed back and forth through the stack or heap. This can cause large increases in code size. Also, since PEI code runs in flash, compression may not be done. Secondly, it reduces boot performance. The increase in code needs more processor cycles to decode and execute. Furthermore, the processor cache is not enabled at this stage, resulting in slow execution efficiency, especially for frequent global variable access from the flash. Third, it prevents firmware developers from freely developing and testing their code.

[0006] Thus, what is needed is a method to enable global variable support in a

Pre-EFI Initialization (PEI) environment for EFI based firmware. What is also needed is a method to enable global variable modifications during the PEI phase. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate embodiments of the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art(s) to make and use the invention. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

[0008] FIG. 1 is a diagram illustrating an exemplary PE32 (Portable Executable

32) image according to an embodiment of the present invention. [0009] FIG. 2 is a flow diagram describing an exemplary method for modifying a

PE32 image to enable read/write access of global variables during a pre-EFI initialization (PEI) phase according to an embodiment of the present invention. [0010] FIG. 3 is a block diagram illustrating an exemplary modification of a PE32 image to enable read/write access of global variables during a pre-EFI Initialization phase according to an embodiment of the present invention.

[0011] FIG. 4 is a flow diagram describing an exemplary first round fixing method according to an embodiment of the present invention.

[0012] FIG. 5 is a flow diagram describing an exemplary second round fixing method according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0013] While the present invention is described herein with reference to illustrative embodiments for particular applications, it should be understood that the invention is not limited thereto. Those skilled in the relevant art(s) with access to the teachings provided herein will recognize additional modifications, applications, and embodiments within the scope thereof and additional fields in which embodiments of the present invention would be of significant utility.

[0014] Reference in the specification to "one embodiment", "an embodiment" or

"another embodiment" of the present invention means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrase "in one embodiment" or "in an embodiment" appearing in various places throughout the specification are not necessarily all referring to the same embodiment. [0015] Embodiments of the present invention are directed to a method for enabling global variable modifications (i.e., read/write access) in a Pre-EFI Initialization phase. This is accomplished using a portion of the processor cache as a usage model known as "Cache As RAM" (CAR). By relocating the data section of a driver image from a flash device into a region of CAR, the global variables may be modified freely as if they were in RAM.

[0016] Embodiments of the present invention are described as being implemented in a Flash device during the Pre-EFI Initialization (PEI) phase for EFI based firmware. The PEI phase for EFI based firmware utilizes a PE32 (Portable Executable 32) image format. One skilled in the relevant art(s) would know that the invention is not limited to a Flash device, EFI based firmware, or PE32 image formats. The invention may also be implemented in other non-volatile storage devices using other software/firmware environments requiring other image formats in which global variables are restricted to read-only access.

[0017] EFI based firmware supports the standard PE32 (Portable Executable 32) image format. The PE32 image format organizes code, data and other information, such as, for example, relocation information, by sections. Sections are placed closely together, one after another. Once the image is loaded by a loader, the image layout in memory is almost the same as its file image. An exception is that there could be some bubbles in the memory image layout due to the alignment requirement between sections. Usually, the loader will fix up the memory image if the sections are not loaded at a preferred linking base.

[0018] FIG. 1 is a diagram illustrating an exemplary PE32 (Portable Executable

32) image 100 according to an embodiment of the present invention. PE32 image 100, also referred to herein as an executable driver module 100, comprises a .text section 102, a .data section 104, and a .relocation (.reloc) section 106. In one embodiment, .text section 102 may also be referred to as a .code section 102. In an embodiment, executable driver module 100 is not limited to .text section 102, .data section 104, and .reloc section 106. In embodiments, executable driver module 100 may also include more sections, such as, for example, a .rdata section, a .rsrc section, etc. As previously indicated, an alignment requirement between sections requires sections 102, 104, and 106 to be placed closely together, one after the other. [0019] The .text section 102 comprises executable code for executable driver module 100. The .data section 104 comprises data to be used during execution of the .text section 102. The .reloc section 106 provides information for all address data items to be updated with an absolute Flash address.

[0020] In order for a PE32 image to launch correctly, sections 102, 104, and 106 have to be placed at a continuous virtual or physical memory space. If paging is enabled, sections 102, 104, and 106 need to be in a continuous virtual memory space. If paging is not required, then sections 102, 104, and 106 need to be in a continuous physical memory. With the EFI firmware, paging is always disabled. Therefore, sections 102, 104, and 106 are placed in a continuous physical memory space. This prevents sections 102, 104, and 106 of executable driver module 100 from being separated at discontinuous memory ranges. If an executable module is to be loaded at a different base, all sections (102, 104, and 106) in executable driver module 100 have to be relocated at the new base together. It is not acceptable to just relocate the code section (also referred to as the "text section") to a base and relocate the data section to another discontinuous new base.

[0021] To achieve the goal of being able to modify global variables in the PEI phase, the PE32 sections (102, 104, and 106) of executable driver module 100 have to be separated at different memory ranges. For example, .text section 102 has to be kept in Flash space while .data section 104, in which static and/or global variables are stored, has to be relocated into CAR. The space range for Flash and CAR are different and discontinuous. [0022] To ensure proper execution of executable driver module 100 when keeping .text section 102 and .reloc section 106 in Flash while moving .data section 104 to CAR, building tools are first used to patch .text section 102 and .data section 104 before the code is burnt into the Flash because once the code is in the Flash, the code has to run in place without any fix up or relocation. Thus, the invention requires a first round fixing to fix-up the image at a specified Flash base using the relocation information. The first round fix-up allows all code to be executed in the Flash directly, with all data access occurring in the Flash as well, thus blocking the write access to the global variables. To enable write access to all global variables in executable driver module 100, a second round fixing is needed such that all code that accesses .data section 104 and all the related data that points to the fields in .data section 104 will be updated to operate .data section 104 from the CAR because .data section 104 will be copied from the Flash to the CAR before the code is executed.

[0023] FIG. 2 is a flow diagram 200 describing an exemplary method for modifying a PE32 image to enable read/write access of global variables during a pre- EFI initialization (PEI) phase according to an embodiment of the present invention. The invention is not limited to the embodiment described herein with respect to flow diagram 200. Rather, it will be apparent to persons skilled in the relevant art(s) after reading the teachings provided herein that other functional flow diagrams are within the scope of the invention. The process begins with block 202, where the process immediately proceeds to block 204.

[0024] In block 204, an executable driver module 100 is generated. The executable driver module 100 includes global variables that when executed in a Flash device only enable read access of the global variables. The process then proceeds to block 206.

[0025] In block 206, a first round fixing of executable driver module 100 is performed. The first round fixing, which is further described with reference to FIG. 4 below, fixes all address data items with absolute Flash addresses. The process then proceeds to block 208.

[0026] In block 208, a second round fixing of executable driver module 100 is performed. The second round fixing, which is further described with reference to FIG. 5 below, performs a second fix-up for all address data items fixed in the first round fixing that point to .data section 104 of executable driver module 100. The second round fix- up updates these data addresses with an absolute CAR address. During the second round fixing, .text section 102 and .data section 104 may be updated to reflect data addresses with absolute CAR addresses. The completion of the second round fixing provides a final EFI firmware image (final executable driver module) that is now ready to be burned into the Flash. The final EFI firmware image includes the necessary absolute CAR addresses to enable global variables to have read/write access from the CAR. The process then proceeds to block 210.

[0027] In block 210, the final EFI firmware image (final executable driver module) is burnt into the Flash. The process then proceeds to block 212. [0028] When the Flash is booted, a firmware loader will copy .data section 104 from the Flash to the CAR and then transfer control to an image entry point for execution. This enables executable driver module 100 to be executed normally in Flash while .data section 104 is stored and operated in the CAR. During the PEI phase, static and global variables are now available to be accessed freely. In other words, global variables now have read/write access in the CAR.

[0029] FIG. 3 is a block diagram illustrating an exemplary modification of PE32 image (executable driver module) 100 to enable read/write access of global variables during a pre-EFI Initialization (PEI) phase according to an embodiment of the present invention. Shown in FIG. 3 are Flash 302, Flash 302', and CAR 304 (which is part of a processor cache as indicated above).

[0030] Flash 302 comprises executable driver module 100 which includes .text section 102, .data section 104, and .reloc section 106. A first round fixing is shown in .text section 102 and .data section 104 of Flash 302. Based on .reloc section 106, all address data items are fixed with absolute Flash addresses in the first round fixing. A second round fixing is shown in Flash 302'. In the second round fixing, all the related data that points to the fields in .data section 104 will be fixed with absolute CAR addresses.

[0031] FIG. 4 is a flow diagram 400 describing an exemplary first round fixing method according to an embodiment of the present invention. The invention is not limited to the embodiment described herein with respect to flow diagram 400. Rather, it will be apparent to persons skilled in the relevant art(s) after reading the teachings provided herein that other functional flow diagrams are within the scope of the invention.

The process begins with block 402, where the process immediately proceeds to block

404.

[0032] For a PE32 image, .reloc section 106 records all the points in executable driver module 100 that should be fixed after loading. Generally, .reloc section 106 provides the relative virtual address (RVA) information. A RVA is an offset from the base address at which an image is loaded into memory. According to the RVA, all addresses to be patched during the first round fixing are identified in executable driver module 100. Each address-to-be-patched will be updated by adding the specified Flash base for loading.

[0033] In block 404, a point in .reloc section 106 will be parsed. The process then proceeds to block 406.

[0034] In block 406, the address data at the point identified in block 404 is updated with an absolute Flash address. The process then proceeds to decision block

408.

[0035] In decision block 408, it is determined whether there are more points in .reloc section 106 that need to be fixed. If there are more points in .reloc section 106 that need to be fixed, then the process proceeds back to block 404 to parse the next point.

[0036] Returning back to decision block 408, if it is determined that there are no more points to be parsed in .reloc section 106, then the process proceeds to block 410 where the first round fixing ends.

[0037] First round fixing is also illustrated in Flash 302 of FIG. 3. Shown in Flash

302 of FIG. 3 are example points in .reloc section 106; data location B and absolute

Flash addresses Ma and Mb in .data section 104; and data code locations A and C and absolute Flash address Mc in .text section 102. Ma is the absolute Flash address for code location A. Mb is the absolute Flash address for data location B. Mc is the absolute Flash address for code location C. [0038] Exemplary points Ra, Rb, and Rc are shown highlighted in .reloc section

106. Ra includes relocation information that points to code location A (located in .text section 102). The address data at location A is updated with an absolute Flash address Ma, which resides in .data section 104. Rb includes relocation information that points to data location B (located in .data section 104). The address data at location B is updated with an absolute Flash address Mb, which resides in .data section 104. Lastly, Rc includes relocation information that points to code location C (located in .text section 102). The address data at location C is updated with an absolute Flash address Mc, which resides in .text section 102.

[0039] Flash 302' illustrates the second round fixing method. Flash 302' shows .reloc section 106 highlighting example points Ra, Rb, and Rc, .data section 104', and .text section 102'. The .data section 104' includes data location B and absolute CAR addresses Mb' and Ma'. The .text section 102' includes locations A and C and absolute Flash address Mc. Note that .text section 102 of Flash 302 is modified in Flash 302' (.data section 102') to accommodate the address change of Ma'. [0040] If an address, such as, for example Mb and Ma of Flash 302, is found in .data section 104, this indicates that the code in .text section 102 is accessing a static or global variable. Since .data section 104' of Flash 302' is to be copied to CAR 304, these addresses (Mb and Ma) must be updated to reflect an absolute CAR address (Mb' and Ma') as shown in ,data section 104' in Flash 302'. Thus, a further patch is needed by adding a gap between the specified Flash base and the CAR base. For other addresses located outside of .data section 104 of Flash 302 or .data section 104' of Flash 302' (such as, for example, Mc found in .text section 102 and .text section 102'), no further patching is required because these addresses are to remain in the Flash. In other words, the .text section 102 will be executed in the Flash.

[0041] By looking at the fixed addresses in the first round fixing, it is very easy to decide whether an address resides in .data section 104 or not. All access to the addresses of the Flash in .data section 104 will be redirected to CAR 304 in .data section 104'. After redirecting the addresses of the Flash in .data section 104 to obtain .data section 104', .data section 104' is copied from Flash 302' to CAR 304. At this time, executable driver module 100 may execute normally with .data section 104' stored and operated in CAR region 304. This significantly improves the boot performance because all static and global variable access occurs in CAR 304 instead of the Flash after the relocation. Thus, by applying additional patches to the addresses pointing to .data section 104 after the first round fix, it is possible to separate the .data section from the entire image layout and relocate it to any other specified address. By locating .data section 104' into CAR 304, executable driver module 100 may have read and write access to global variables in the PEI phase.

[0042] As shown in Flash 302', the previous fixed address data at location B (Mb) is updated with an absolute CAR address Mb' and the previous fixed address data at location A (Ma) is updated with an absolute CAR address Ma'. Since the fixed address data at location C (Mc) resides in the .text section 102, and the .text section will remain in the flash, the fixed address data at location C (Mc) will not be updated. [0043] CAR 304 is a portion of processor cache in which .data section 104' is copied. As indicated above, after the firmware is burned into the Flash space, the firmware loader will copy .data section 104' from the Flash to the CAR. The transfer of .data section 104' to CAR 304 enables PEI static and global variables to have read/write access through CAR 304.

[0044] FIG. 5 is a flow diagram 500 describing an exemplary second round fixing method according to an embodiment of the present invention. The invention is not limited to the embodiment described herein with respect to flow diagram 500. Rather, it will be apparent to persons skilled in the relevant art(s) after reading the teachings provided herein that other functional flow diagrams are within the scope of the invention. The process begins with block 502, where the process immediately proceeds to decision block 504.

[0045] In decision block 504, it is determined whether an address data item that was fixed in the first round fixing points to .data section 104. If there is an address data item that was fixed in the first round fixing that points to .data section 104, the address data item is selected in block 506, and the process proceeds to block 508. If there is no address data item that was fixed in the first round fixing that points to .data section 104, then the process proceeds to block 512, where the process ends. [0046] In block 508, the address data item selected in block 506 is updated with an absolute CAR address. The process then proceeds to decision block 510. [0047] In decision block 510, it is determined whether there are more address data items that were fixed in the first round fixing that point to .data section 104. If there are more address data items that were fixed in the first round fixing that point to .data section 104, then the process returns to block 506 to select the next address data item to be fixed. [0048] Returning to decision block 510, if it is determined that there are no more address data items that were fixed in the first round fixing that point to .data section 104, then the process proceeds to block 512, where the process ends. [0049] Embodiments of the present 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 find applicability in any computing, consumer electronics, or processing environment. The techniques may be implemented in programs executing on programmable machines such as mobile or stationary computers, personal digital assistants, set top boxes, cellular telephones and pagers, consumer electronics devices (including DVD (Digital Video Disc) players, personal video recorders, personal video players, satellite receivers, stereo receivers, cable TV receivers), and other electronic devices that may include 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. Program code is applied to the data entered using the input device to perform the functions described and to generate output information. The output information may be applied to one or more output devices. One of ordinary skill in the art may appreciate that the invention can be practiced with various system configurations, including multiprocessor systems, minicomputers, mainframe computers, independent consumer electronics devices, and the like. The invention can also be practiced in distributed computing environments where tasks or portions thereof may be performed by remote processing devices that are linked through a communications network. [0050] Each program may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. However, programs may be implemented in assembly or machine language, if desired. In any case, the language may be compiled or interpreted.

[0051] Program instructions may be used to cause a general-purpose or special- purpose processing system that is programmed with the instructions to perform the operations described herein. Alternatively, the operations may be performed by specific hardware components that contain hardwired logic for performing the operations, or by any combination of programmed computer components and custom hardware components. The methods described herein may be provided as a computer program product that may include a machine accessible medium having stored thereon instructions that may be used to program a processing system or other electronic device to perform the methods. The term "machine accessible medium" used herein shall include any medium that is capable of storing or encoding a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methods described herein. The term "machine accessible medium" shall accordingly include, but not be limited to, solid-state memories, optical and magnetic disks, and a carrier wave that encodes a data signal. Furthermore, it is common in the art to speak of software, in one form or another {e.g., program, procedure, process, application, module, logic, and so on) as taking an action or causing a result. Such expressions are merely a shorthand way of stating the execution of the software by a processing system to cause the processor to perform an action or produce a result. [0052] While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined in accordance with the following claims and their equivalents.

Claims

What Is Claimed Is:

1. A method for enabling global variable read/write operations in a pre-EFI Initialization (PEI) comprising: generating a driver image, the driver image comprising a code section, a data section, and a relocation section; performing a first round fixing on the driver image to fix all address data items with absolute non-volatile memory addresses; performing a second round fixing on the driver image to fix all address data items fixed in the first round fixing that point to the data section with absolute Cache-As-RAM (Cache-As-Random Access Memory) addresses; and burning the fixed driver image into a non-volatile memory device, wherein upon booting the non-volatile memory device, the data section of the burned driver image is copied to a Cache-As-RAM (CAR), wherein execution of executable code in the code section enables static and global variables to have read/write access from the CAR.

2. The method of claim 1 , wherein the driver image comprises a Portable Executable 32 (PE32) image.

3. The method of claim 1 , wherein the driver image is executed in the nonvolatile memory.

4. The method of claim 1 , wherein the non-volatile memory comprises a Flash memory device.

5. The method of claim 1 , wherein performing a first round fixing comprises: parsing each point in the relocation section; and updating each address data item associated with each point in the relocation section with the absolute non-volatile address.

6. The method of claim 1 , wherein performing a second round fixing comprises: determining whether the address data items fixed in the first round fixing point to the data section; and if the address data items fixed in the first round fixing point to the data section, updating the fixed address data items with the absolute CAR addresses.

7. A method for using global variables in a pre-EFI phase comprising: separating a data portion from a code portion and a relocation portion of a driver image; copying the data portion to a region of a processor cache used as RAM (Random Access Memory); and transferring control to an image entry point of the driver image for execution of the driver image, wherein the global variables are accessed from the processor cache used as RAM.

8. The method of claim 7, wherein prior to separating the data portion from the code portion and the relocation portion of the driver image, performing a first round fixing and a second round fixing to patch the code portion and burning the patched code into non-volatile memory.

9. The method of claim 8, wherein non-volatile memory comprises a Flash memory device.

10. The method of claim 8, wherein performing a first round fixing comprises fixing the driver image at a specified non-volatile memory base using the relocation portion.

11. The method of claim 8, wherein performing a second round fixing comprises updating all code in the code portion that accesses the data portion and all related data that points to the data portion to operate the data in the processor cache used as RAM while executing the code portion of the driver image in the non-volatile memory.

12. A mechanism for enabling the use of global variables during a pre-EFI Initialization (PEI) phase comprising: an executable driver image including a code portion, a data portion, and a relocation portion, the code portion comprising executable code, the data portion comprising data to be used by the executable code, and the relocation portion comprising information for all address data items to be updated with an absolute nonvolatile memory address during a first round fixing of the executable driver image; a non-volatile memory to store and execute the executable driver image; and a processor cache, wherein a region of the processor cache to be used as Cache-As-RAM (Random Access Memory) (CAR), the data portion of the executable driver image to be copied to the CAR after the first round fixing and a second round fixing of the executable driver image to enable static and global variables to operate in the CAR during execution of the executable driver image.

13. The mechanism of claim 12, wherein after the first round fixing and the second round fixing of the executable driver image, to burn the executable driver image onto the non-volatile memory before execution of the executable driver image.

14. The mechanism of claim 12, wherein the non-volatile memory comprises a Flash memory device.

15. The mechanism of claim 12, wherein the second round fixing of the executable driver image to update all code in the code portion that accesses the data portion and all related data that points to the data portion to operate the data in the CAR while executing the code portion of the driver image in the non-volatile memory.

16. An article comprising: a storage medium having a plurality of machine accessible instructions, wherein when the instructions are executed by a processor, the instructions provide for generating a driver image, the driver image comprising a code section, a data section, and a relocation section; performing a first round fixing on the driver image to fix all address data items with absolute non-volatile memory addresses; performing a second round fixing on the driver image to fix all address data items fixed in the first round fixing that point to the data section with absolute Cache-As-RAM (Cache-As-Random Access Memory) addresses; and burning the fixed driver image into a non-volatile memory device, wherein upon booting the non-volatile memory device, the data section of the burned driver image is copied to a Cache-As-RAM (CAR), wherein during execution of executable code in the code section enables static and global variables to have read/write access from the CAR.

17. The article of claim 16, wherein the driver image comprises a Portable Executable 32 (PE32) image.

18. The article of claim 16, wherein the driver image is executed in the nonvolatile memory.

19. The article of claim 16, wherein the non-volatile memory comprises a Flash memory device.

20. The article of claim 16, wherein instructions for performing a first round fixing comprises instructions for: parsing each point in the relocation section; and updating each address data item associated with each point in the relocation section with the absolute non-volatile address.

21. The article of claim 16, wherein instructions for performing a second round fixing comprises instructions for: determining whether the address data items fixed in the first round fixing point to the data section; and if the address data items fixed in the first round fixing point to the data section, updating the fixed address data items with the absolute CAR addresses.

22. An article comprising: a storage medium having a plurality of machine accessible instructions, wherein when the instructions are executed by a processor, the instructions provide for separating a data portion from a code portion and a relocation portion of a driver image; copying the data portion to a region of a processor cache used as RAM (Random Access Memory); and transferring control to an image entry point of the driver image for execution of the driver image, wherein the global variables are accessed from the processor cache used as RAM.

23. The article of claim 22, wherein prior to instructions for separating the data portion from the code portion and the relocation portion of the driver image, instructions for performing a first round fixing and a second round fixing to patch the code portion and burning the patched code into non-volatile memory.

24. The article of claim 23, wherein non-volatile memory comprises a Flash memory device.

25. The article of claim 23, wherein instructions for performing a first round fixing comprises instructions for fixing the driver image at a specified non-volatile memory base using the relocation portion.

26. The article of claim 23, wherein instructions for performing a second round fixing comprises instructions for updating all code in the code portion that accesses the data portion and all related data that points to the data portion to operate the data in the processor cache used as RAM while executing the code portion of the driver image in the non-volatile memory.