KR101036675B1 - A method to use global variables for pre-efi initialization modules in efi-based firmware - Google Patents

Abstract

A method for enabling global variable read / write operations in pre-EFI initialization (PEI) is disclosed. The method includes generating a driver image. This driver image contains at least a code section (that is, a text section), a data section, and a relocation section. A first round adjustment to this driver image is performed to adjust all address data items with absolute nonvolatile memory addresses. The second round adjustment for this driver image is performed to adjust all address data items adjusted in the first round adjustment pointing to this data section with a cache-as-random access memory as absolute RAM. This adjusted image is written to the nonvolatile memory device. At boot time of this nonvolatile memory device, the data section of this recorded driver image is copied to a cache as RAM (CAR) and by executing the executable code of this text section, static and global variables can have read / write access from the CAR. have.

Free EFI, Global Variables, Static Variables, Driver Images, Round Adjustments

Description

A METHOD TO USE GLOBAL VARIABLES FOR PRE-EFI INITIALIZATION MODULES IN EFI-BASED FIRMWARE}

The present invention relates generally to firmware. In particular, the present invention relates to global variable usage during the pre-Extensible Firmware Interface (EFI) initialization phase of the Platform Innovation Framework for EFI.

The Platform Innovation Framework for Extensible Firmware Interface (EFI), developed by Intel® Corporation in Santa Clara, Calif., Is implemented in C. It is a set of robust architectural interfaces designed to perform. The Platform Innovation Framework for EFI (hereinafter referred to as the "Framework") is divided into two main phases: the Free EFI Initialization (PEI) phase and the Driver Execution Environment (DXE) phase. The PEI phase performs minimal processor, chipset, and platform configuration to support memory discovery. The DXE phase advances the PEI phase by completing the initialization of the platform, processor and chipset devices.

In the PEI phase there is no memory available. There is no memory available, but you can temporarily initialize the processor cache to act as random access memory (RAM), thus storing the stack and heap in this cache. This allows the module to be compiled by running a high-level programming language in the PEI phase.

A known limitation of the framework is that modules in the PEI phase use global variables as read-only variables, that is, they cannot be changed. In the PEI phase, since no memory is available, all data segments and code segments are placed in flash without relocation.

It is well known that data in flash is not changed as easily as data disposed in other conventional memory devices. Although the PEI code can trigger write access to global variables in the data section of Flash, these global variables cannot be changed. Because of this limitation, the PEI module has several drawbacks. First, the ability to share module global variables between functions is limited. All variables that need to be shared between functions must be passed back and forth across the stack or heap. This can significantly increase code size. In addition, compression is not possible because the PEI code is executed in Flash. Second, boot performance is reduced. As the need for code increases, more processor cycles are required to decompress and execute. In addition, the processor cache can not be activated at this stage, which reduces execution efficiency, especially for frequent global variable accesses from flash. Third, firmware developers cannot freely develop and test their own code.

Therefore, there is a need for a method that enables global variable support in a pre-EFI initialization (PEI) environment for EFI-based firmware. There is also a need for a way to enable global variable changes during the PEI phase.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention, and together with the description, explain the principles of the invention and enable those skilled in the art to make and use the invention. Like reference numerals in the drawings generally refer to like, functionally similar, or structurally similar components. The leftmost digit in that reference indicates the drawing in which the component first appears.

1 illustrates an exemplary Portable Executable 32 (PE32) image in accordance with an embodiment of the present invention.

2 is a flow diagram illustrating an exemplary method of modifying a PE32 image to enable read / write access of a global variable during a pre EFI initialization (PEI) step, in accordance with an embodiment of the invention.

3 is a block diagram illustrating an exemplary PE32 image change to enable read / write access of a global variable during a pre EFI initialization phase, in accordance with an embodiment of the invention.

4 is a flow chart illustrating an exemplary first round fixing method in accordance with an embodiment of the present invention.

5 is a flow chart illustrating an exemplary second round adjustment method in accordance with an embodiment of the present invention.

While the invention has been described with reference to exemplary embodiments for particular applications, it should be understood that the invention is not so limited. Those skilled in the art will appreciate that various modifications, applications, and embodiments can be added within the scope of the present invention and in additional fields where the embodiments of the present invention have significant utility.

As used herein, the phrase "one embodiment", "specific embodiment", or "other embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is at least one of the embodiments of the present invention. It is included in the. Thus, the phrases "in one embodiment" or "in a specific embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

Embodiments of the present invention are directed to a method for enabling global variable changes (ie, read / write access) during a free EFI initialization step. This is accomplished by using part of the processor cache in 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, global variables can be freely changed as if they were in RAM.

Embodiments of the invention are described as being implemented in a flash device during a pre-EFI initialization (PEI) phase of EFI-based firmware. The PEI phase of EFI-based firmware uses the PE32 (Portable Executable 32) image format. Those skilled in the art will appreciate that the present invention is not limited to flash devices, EFI based firmware, or PE32 image formats. The invention may also be implemented in other nonvolatile storage devices utilizing other software / firmware environments that require different image formats where global variables are limited 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, section by section. The sections are arranged closely in succession. When the loader loads the image, the image layout of the memory is about the same as its file image. In exceptional cases there may be bubbles in the memory image layout due to the need for alignment between sections. Normally, if the section is not loaded into the preferred linking base, this loader will handle the memory image.

1 illustrates an exemplary Portable Executable 32 (PE32) image 100 in accordance with an embodiment of the present invention. PE32 image 100, also referred to herein as execution driver module 100, includes a .text section 102, a .data section 104, and a .reloc section 106. In one embodiment, the .text section 102 may also be referred to as the .code section 102. In a particular embodiment, the execution driver module 100 is not limited to the .text section 102, the .data section 104, the .relocation section 106. In embodiments the executable driver module 100 may include more sections, such as, for example, .rdata section, .rsrc section, and the like. As described above, the alignment requirement between the sections is such that the sections 102, 104, 106 are arranged in close succession.

The text section 102 contains the executable code for the executable driver module 100. The .data section 104 contains data to be used during execution of the .text section 102. The relocation section 106 provides information about all address data items to be updated to absolute flash addresses.

Sections 102, 104, and 106 must be placed in contiguous virtual or physical memory space for the PE32 image to launch correctly. Sections 102, 104 and 106 should be in contiguous virtual memory space if paging is possible. Sections 102, 104 and 106 should be in contiguous physical memory space unless paging is required. Paging is not always possible with EFI firmware. Thus sections 102, 104, 106 are disposed in contiguous physical memory space. This prevents sections 102, 104, 106 of the execution driver module 100 from being separated into discrete memory ranges. When an executable module is loaded into another base, all sections 102, 104, 106 of the executable driver module 100 are relocated together to that new base. Relocation of code sections (also called "text sections") to the base and relocation of data sections to other discrete new bases are not allowed.

The PE32 sections 102, 104, and 106 of the execution driver module 100 must be separated into different memory ranges to achieve the goal of being able to change global variables in the PEI phase. For example, the .text section 104 where static and / or global variables are stored must be relocated to the CAR while the .text section 102 must be maintained in flash space. The spatial ranges for the flash and the CAR are different and discontinuous.

To ensure proper execution of the execution driver module 100 when the .data section 104 is moved to the CAR while retaining the .text section 102 and the .relocation section 106 in the flash, the code is placed in the flash. The build tool first uses the build tool to patch the .text section 102 and the .data section 104 before the code is written to Flash because it must be executed in place without adjustment or relocation. Thus, the present invention requires a first round adjustment that uses the relocation information to adjust the image to a particular flash base. The first round adjustment allows all code to be executed directly in flash, and all data accesses occur in that flash as well, blocking write access to the global variables. In order to enable write access to all global variables in the execution driver module 100, all code accessing the .data section 104 and the .data section 104 will be copied from flash to the CAR before code execution. A second round adjustment is needed so that all relevant data pointing to the fields in the .data section 104 are updated to operate the .data section 104 from the CAR.

2 is a flow diagram 200 illustrating an exemplary method of modifying a PE32 image to enable read / write access of a global variable during a pre EFI initialization (PEI) step, in accordance with an embodiment of the invention. The invention is not limited to the embodiment described herein in connection with the flowchart 200. Rather, those skilled in the art will appreciate that many other functional flow diagrams are within the scope of the present invention in accordance with the teachings of the present invention. The process starts at block 202 and proceeds directly to block 204.

In block 204 the execution driver module 100 is generated. Execution driver module 100 includes global variables that allow only read access of global variables when executed in a flash device. The process then proceeds to block 206.

In block 206 a first round adjustment of the execution driver module 100 is performed. The first round adjustment, described further below with reference to FIG. 4, adjusts all address data items with absolute flash addresses. The process then proceeds to block 208.

In block 208 a second round adjustment of the execution driver module 100 is performed. The second round adjustment, described further below with reference to FIG. 5, performs a second adjustment for all address data items adjusted in the first round adjustment that points to the .data section 104 of the execution driver module 100. The second round adjustment updates these data addresses with an absolute CAR address. During the second round adjustment, the .text section 102 and the .data section 104 may be updated to reflect the data address with the absolute CAR address. Once the second round adjustment is complete, the final EFI firmware image (final execution driver module) is ready for burning to flash. The final EFI firmware image contains the required absolute CAR address so that global variables can have read / write access from the CAR. The process then proceeds to block 210.

In block 210 the final EFI firmware image (final execution driver module) is written to flash. The process then proceeds to block 212.

Once the flash has booted, the firmware loader will copy the .data section 104 from flash to the CAR and then transfer control to the image entry point for execution. This allows the execution driver module 100 to execute normally in flash while the .data section 104 is stored and operated in the CAR. Static and global variables can now be freely accessed during the PEI phase. In other words, global variables now have read / write access to the CAR.

3 is a block diagram illustrating an exemplary modification of a PE32 image (executable driver module) 100 to enable read / write access of a global variable during a pre-EFI initialization (PEI) phase, in accordance with an embodiment of the invention. to be. 3 shows flash 302, flash 302 ′, and CAR 304 (which is part of the processor cache shown above).

Flash 302 includes an executable driver module 100 that includes a .text section 102, a .data section 104, and a .relocation section 106. The first round adjustment is shown in the .text section 102 and the .data section 104 of the flash 302. Based on the relocation section 106, all address data items are adjusted with absolute flash addresses in the first round adjustment. The second round adjustment is shown in flash 302 '. In the second round adjustment all relevant data pointing to the fields of the .data section 104 will be adjusted with an absolute CAR address.

4 is a flowchart 400 illustrating an exemplary first round adjustment method in accordance with an embodiment of the present invention. The invention is not limited to the embodiment described herein in connection with flow diagram 400. Rather, those skilled in the art will appreciate that many other functional flow diagrams are within the scope of the present invention in accordance with the teachings of the present invention. The process begins at block 402 and proceeds directly to block 404.

In the PE32 image, the redeployment section 106 writes all points to the executable driver module 100 that must be adjusted after loading. In general, the relocation section 106 provides relative virtual address (RVA) information. RVA is the offset from the base address at which the image was loaded into memory. All addresses to be patched during the first round adjustment according to this RVA are verified in the execution driver module 100. Each address to be patched will be updated by adding a specific flash base for loading.

In block 404 the points of the .relocation section 106 will be parsed. The process then proceeds to block 406.

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.

The decision block 408 determines whether there are more points in the .relocation section 106 that need to be adjusted. If there are more points in the redeployment section 106 that need to be adjusted, the process returns to block 404 to analyze the next point.

Returning to decision block 408 and determining that there are no more points to be analyzed in the relocation section 106, the process proceeds to block 410 where the first round adjustment ends.

The first round adjustment is also shown in flash 302 of FIG. 3. In the flash 302 of FIG. 3, the sample point is located in the .reposition section 106, the data position B and the absolute flash address (Ma, Mb) are in the .data section 104, and the data is in the .text section 102. The code locations A and C and the absolute flash address Mc are shown. Ma is the absolute flash address of the code position A. Mb is the absolute flash address of the data position B. Mc is the absolute flash address of the code position (C).

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

Flash 302 'represents the second round adjustment method. Flash 302 'shows .. relocation section 106, .data section 104', and .text section 102 ', highlighting sample points Ra, Rb, Rc. The data section 104 'contains the data location B and the absolute CAR addresses Mb', Ma '. The text section 102 'contains the positions A and C and the absolute flash address Mc. Note that the .text section 102 of the flash 302 is changed in the flash 302 '(.data section 102') to accommodate Ma's address change.

For example, if an address such as Mb or 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 the .data section 104 'of the flash 302' will be copied to the CAR 304, these addresses Mb, Ma are absolute CAR as shown in the .data section 104 'of the flash 302'. It must be updated to reflect the addresses Mb 'and Ma'. Therefore, another patch is needed by adding a gap between the specific flash base and the CAR base. Mc in the .data section 104 of the flash 302 or other address located outside the .data section 104 'of the flash 302' (e.g., in the .text section 102 and the .text section 102 '). Such addresses remain in flash, so no further patching is required. In other words, the .text section 102 will be executed in Flash.

Looking at the address adjusted in the first round adjustment, it is very easy to determine whether the address is in the .data section 104 or not. All accesses to the address of the flash in the .data section 104 will be redirected to the CAR 304 in the .data section 104 '. After redirecting the address of the flash of .data section 104 to obtain .data section 104 ', .data section 104' is copied from flash 302 'to CAR 304. In this case, the execution driver module 100 may execute normally when the .data section 104 'is stored in the CAR area 304 and operated. This significantly improves boot performance since all static variable and global variable access occurs in CAR 304 instead of flash after relocation. Thus, by applying an additional patch to the address pointing to the .data section 104 after the first round adjustment, it is possible to separate the .data section from the overall image layout and relocate it to another specific address. By placing the .data section 104 'in the CAR 304, the execution driver module 100 can have read and write access to global variables in the PEI phase.

As shown in flash 302 ', the previously adjusted address Mb at position B is updated with the absolute CAR address Mb' and the previously adjusted address data Ma at position A. Is updated with an absolute CAR address Ma '. The adjusted address data Mc in position C is not updated because the adjusted address data Mc in position C is in the .text section 102 and this .text section remains in the flash. will be.

CAR 304 is part of the processor cache to which the .data section 104 'is copied. After the firmware has been written to the flash space as described above, the firmware loader will copy the .data section 104 'from flash to the CAR. Once the .data section 104 'is moved to the CAR 304, the PEI static and global variables can have read / write access through the CAR 304.

5 is a flowchart 500 illustrating an exemplary second round adjustment method in accordance with an embodiment of the present invention. The present invention is not limited to the embodiment described herein with respect to flowchart 500. Rather, those skilled in the art will appreciate that many other functional flow diagrams are within the scope of the present invention in accordance with the teachings of the present invention. The process begins at block 502 and proceeds directly to block 504.

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

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.

The decision block 510 determines whether there are more address data items adjusted in the first round adjustment that point to the .data section 104. If there are more address data items adjusted in the first round adjustment that point to the .data section 104, the process returns to block 506 to select the next address data item to be adjusted.

Returning to decision block 510 and if there are no more address data items adjusted in the first round adjustment pointing to .data section 104, the process proceeds to block 512 and 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 find utility in any computing, consumer electronics or processing environment. This technology includes mobile or stationary computers, personal digital assistants, set-top boxes, cellular phones and pagers, consumer electronics (Digital Video Disc) players, personal video recorders, personal video players, satellite receivers, stereo receivers, cable TV receivers. And, on a programmable machine, such as a processor, a storage medium (including volatile memory and nonvolatile memory and / or storage elements), other electronic devices that may include at least one input device and one or more output devices, and the like. Can be implemented as a program. Program code is applied to data entered using an input device to perform the functions described and to generate output information. Output information may be input to one or more output devices. Those skilled in the art will appreciate that the present invention may be practiced in a variety of system configurations, including multiprocessor systems, minicomputers, mainframe computers, standalone consumer electronic devices, and the like. The invention may 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.

Each program may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. However, it can be implemented in assembly or machine language if necessary. In any case, these languages are compiled or machine translated.

Programming instructions may be used to cause a general purpose or dedicated processing system programmed with these instructions to perform the operations described herein. Alternatively, this operation may be performed by a specific hardware component or a combination of programmed computer components and custom hardware components that include hardwired logic to perform the operation. The methods described herein may be provided as a computer program product that may include a machine accessible medium having instructions stored thereon that can be used to program a processing system or other electronic device that performs these methods. The term "machine accessible medium" as used herein may include any medium that can store or encode a family of instructions for execution by a machine and cause the machine to perform any of the methods described herein. . Thus, the term "machine accessible medium" includes, but is not limited to, solid state memory, optical and magnetic disks, and a carrier encoding data signals. Moreover, in the present technology, it is common for software to take any action or cause any result in any form (eg, program, procedure, process, application, module, logic, etc.). This representation is merely a shorthand way of describing the execution of the software by the processing system in which the processor performs an action or produces a result.

While various embodiments of the present invention have been described so far, it should be understood that these embodiments are exemplary only and not limiting. Those skilled in the art should appreciate that various modifications may be made in form and detail of the embodiments without departing from the spirit and scope of the invention as set forth in the claims. Therefore, the scope of the present invention should not be limited by the above-described exemplary embodiments, but should be defined in accordance with the following claims and their equivalents.

Claims (26)

As a method of enabling global variable read / write operations in pre-EFI initialization (PEI), The method is performed by a computer, the method comprising: Generating a driver image comprising a code section, a data section, and a relocation section; Performing a first round fixing on the driver image to fix address data items in the driver image with absolute addresses of a nonvolatile memory; Address data items adjusted in the first round adjustment and pointing to the data section may be added to the driver image to adjust with absolute addresses of a Cache-As-Random Access Memory (Cache-As-RAM; CAR). Performing a second round adjustment on the second; And Burning the adjusted driver image to a nonvolatile memory device Including; When booting the nonvolatile memory device, the data section of the written driver image is copied to a Cache-As-RAM (CAR) as the RAM and execution of executable code in the code section. Static and global variables are read / write accessed from a Cache-As-RAM (CAR). The method of claim 1, Wherein the driver image comprises a Portable Executable 32 (PE32) image. The method of claim 1, The driver image is executed in the nonvolatile memory. The method of claim 1, And the nonvolatile memory comprises a flash memory device. The method of claim 1, Performing the first round adjustment, Parsing each point of the relocation section; And Updating each address data item associated with each point in the relocation section with an absolute address of the nonvolatile memory. How to include. The method of claim 1, Performing the second round adjustment, Determining whether the address data items adjusted in the first round adjustment point to the data section; And If the address data items adjusted in the first round adjustment point to the data section, updating the adjusted address data items with the absolute addresses of a Cache-As-RAM (CAR) as the RAM; How to include. As a method for using global variables in the pre-EFI initialization (PEI) phase, The method is performed by a computer, the method comprising: Separating the data portion from the code portion and the relocation portion of the driver image; Copying the data portion to an area of a processor cache used as random access memory (RAM); And Transferring control to an image entry point of the driver image to execute the driver image Including, The global variables are accessed from the processor cache used as RAM. The method of claim 7, wherein Prior to separating the data portion from the code portion and the relocation portion of the driver image, perform a first round adjustment and a second round adjustment to patch the code portion and transfer the patched code to a nonvolatile memory. Recording. The method of claim 8, And the nonvolatile memory comprises a flash memory device. The method of claim 8, Performing a first round adjustment comprises adjusting the driver image at a specified base address of the nonvolatile memory using the relocation portion. The method of claim 8, Performing a second round adjustment of the code portion accessing 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 nonvolatile memory. Updating code and associated data pointing to the data portion. A system that enables the use of global variables during the pre-EFI initialization (PEI) phase, An executable driver imager including a code portion, a data portion, and a relocation portion; A nonvolatile memory for storing and executing the executable driver image; And Processor cache Including; The code portion includes executable code, the data portion includes data to be used by the executable code, and the relocation portion is an address to be updated with the absolute address of the nonvolatile memory during the first round adjustment of the executable driver image. Contains information about data items, The area of the processor cache is used as a Cache-As-Random Access Memory (Cache-As-RAM; CAR), where the data portion of the executable driver image is a static and global variable during execution of the executable driver image. Cache-As-RAM (CAR) after the first round adjustment and the second round adjustment of the execution driver image to enable them to operate in the Cache-As-RAM (CAR). System copied to. The method of claim 12, And write the executable driver image to the nonvolatile memory before executing the executable driver image after the first round adjustment and the second round adjustment of the executable driver image. The method of claim 12, The nonvolatile memory includes a flash memory device. The method of claim 12, The second round adjustment of the execution driver image causes the data portion to operate the data in a Cache-As-RAM (CAR) as the RAM while executing the code portion of the driver image in the nonvolatile memory. And update the code of the code portion to access the associated data pointing to the data portion. A computer readable storage medium having stored thereon a plurality of computer accessible instructions, When the instructions are executed by a processor, the instructions cause the computer to: Generating a driver image comprising a code section, a data section, and a relocation section; Performing a first round adjustment to the driver image to adjust address data items in the driver image with absolute addresses of a nonvolatile memory; Address data items adjusted in the first round adjustment and pointing to the data section may be added to the driver image to adjust with absolute addresses of a Cache-As-Random Access Memory (Cache-As-RAM; CAR). Performing a second round adjustment on the second; And Writing the adjusted driver image to a nonvolatile memory device To perform a method comprising a, When booting the nonvolatile memory device, the data section of the written driver image is copied to a Cache-As-RAM (CAR) as the RAM and is static and global during execution of executable code in the code section. A computer readable storage medium in which variables are read / write accessed from a Cache-As-RAM (CAR) as RAM. The method of claim 16, And the driver image comprises a Portable Executable 32 (PE32) image. The method of claim 16, And the driver image is executed in the nonvolatile memory. The method of claim 16, And the nonvolatile memory comprises a flash memory device. The method of claim 16, The instructions for performing the first round adjustment are: Analyzing each point of the relocation section; And Updating each address data item associated with each point in the relocation section with an absolute address of the nonvolatile memory. Computer-readable storage medium containing instructions for. The method of claim 16, The instructions for performing the second round adjustment are: Determining whether the address data items adjusted in the first round adjustment point to the data section; And If the address data items adjusted in the first round adjustment point to the data section, updating the adjusted address data items with the absolute addresses of a Cache-As-RAM (CAR) as the RAM; Computer-readable storage medium containing instructions for. A computer readable storage medium having stored thereon a plurality of computer accessible instructions, When the instructions are executed by a processor, the instructions cause the computer to: Separating the data portion from the code portion and the relocation portion of the driver image; Copying the data portion to an area of a processor cache used as random access memory (RAM); And Transferring control to an image entry point of the driver image to execute the driver image To perform a method comprising a, A computer readable storage medium in which global variables are accessed from the processor cache used as RAM. The method of claim 22, Prior to instructions for separating the data portion from the code portion and the relocation portion of the driver image, perform a first round adjustment and a second round adjustment to patch the code portion and apply the patched code. A computer readable storage medium comprising instructions for writing to a nonvolatile memory. 24. The method of claim 23, And the nonvolatile memory comprises a flash memory device. 24. The method of claim 23, The instructions for performing a first round adjustment include instructions for adjusting the driver image at a specified base address of the nonvolatile memory using the relocation portion. 24. The method of claim 23, Instructions for performing a second round adjustment include accessing the data portion to operate the data in the processor cache that is used as a RAM while executing the code portion of the driver image in the nonvolatile memory. And instructions for updating the code of the code portion and related data pointing to the data portion.

Images