WO1999019796A1 - Method and apparatus for accessing and executing the contents of physical memory from a virtual memory subsystem - Google Patents

Abstract

The present invention is an apparatus and method for accessing and executing instruction sequences in physical memory from virtual memory in a processor-based system. The apparatus comprises a memory for storing instruction sequences by which the processor-based system is processed, where the memory includes a physical memory and a virtual memory. The apparatus also comprises a processor for executing the stored instruction sequences. The stored instruction sequences include process steps to cause the processor to: map a plurality of predetermined instruction sequences from the physical memory to the virtual memory, determine an offset to one of said plurality of predetermined instruction sequences in the virtual memory, receive an instruction to execute the one of the plurality of predetermined instruction sequences, transfer control to the one of the plurality of predetermined instruction sequences, and process the one of the plurality of predetermined instruction sequences from the virtual memory.

Description

Method and Apparatus for Accessing and Executing the Contents of Physical Memory from a Virtual Memory Subsystem

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates in general to memory in processor-based systems, and more particularly to an apparatus and method for accessing and executing the contents of physical memory from a virtual memory subsystem.

2. Description of the Related Art

In virtual memory subsystems, "virtual" memory addressing is employed in which the memory addresses utilized in software programs are mapped indirectly to locations in physical memory . Translation to physical addresses is typically accomplished by the processor, and such physical addresses are inaccessible to user mode software and the Basic Input/Output System (BIOS).

One example of such virtual memory subsystems is that used by Windows NT, which is manufactured and marketed by Microsoft. Inc. In particular. Windows NT incorporates a demand-paged virtual memory subsystem. The memory address space provided to a program running on the Windows NT operating system is safeguarded from other user mode programs just as other programs are protected from it. This ensures that user mode services and applications will not write over each other's memory, or execute each other^'s instructions. Kernel mode services and applications are protected in a similar way. If an attempt to access memory outside of a program's allocated virtual space occurs, the program is terminated and the user is notified. Virtual memory subsystems also prevent direct access by user mode software to physical memory addresses and to input/output devices that are part of a computer system.

There is an increasing trend towards the use of input/output devices on a computer system which are capable of executing operating systems using virtual memory subsystems. In such systems, there is no means for accessing memory outside of a program's virtual memory space, such as BIOS functions. One approach to this problem is to install a device driver which reads a file containing instructions for a device. The driver reads the file and writes (or downloads) these instructions into the device's memory. However, this type of device driver permits only limited addressing capability for memory and input/output operations. In addition, it does not allow execution of the system's processor instructions in physical memory space.

Accordingly, there is a need in the technology for an apparatus and method for accessing and executing the contents of physical memory from a virtual memory subsystem, which facilitates increased addressing capability for memory and input/output operations, and which also allows execution of processor instructions directly from physical memory.

BRIEF SUMMARY OF THF. TWFNTION

The present invention is an apparatus and method for accessing and executing instruction sequences in physical memory from virtual memory in a processor-based system. The apparatus comprises a memory for storing instruction sequences by which the processor-based system is processed, where the memory includes a physical memory and a virtual memory. The apparatus also comprises a processor for executing the stored instruction sequences. The stored instruction sequences include process steps to cause the processor to: map a plurality of predetermined instruction sequences from the physical memory to the virtual memory, determine an offset to one of the plurality of predetermined instruction sequences in the virtual memory, receive an instruction to execute the one of the plurality of predetermined instruction sequences, transfer control to the one of the plurality of predetermined instruction sequences, and process the one of the plurality of predetermined instruction sequences from the virtual memory.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a system block diagram of an exemplary processor system in which the apparatus and method of the present invention is used.

Figure 2 is an overall functional block diagram illustrating the architecture of an operating system which utilizes the apparatus and method of the present invention.

Figure 3 is a block diagram illustrating the access driver 46 initialization process as provided in accordance with the principles of the present invention.

Figure 4A is a flowchart illustrating one embodiment of the initialization process of the present invention.

Figure 4B is a flowchart illustrating the details of process step S110 of Figure 4A.

Figure 4C is a flowchart illustrating the details of process step S130 of Figure 4A.

Figure 5A is a flowchart illustrating the execution process of the present invention.

Figure 5B is a flowchart illustrating the details of process step S240 of Figure 5A. DETAILED DESCRIPTION OF THE PREFERRED INVENTION

The present embodiment is described in reference to a processor system 10. Figure 1 illustrates an exemplary processor system 10 which implements the processes of the present invention. The processor system 10 comprises a CPU 12 and a memory module 14. The memory module 14 includes random access memory (RAM) 16 and read-only memory (ROM) 18. In one embodiment, the memory module 14 also includes a main memory or a dynamic random access memory (DRAM) . The CPU 12 and memory module 14 are coupled to a system bus 20. The processor system 10 may also include various I/O and peripheral modules (MISC I/O #1, #2, ... #N) which are coupled along an I/O bus that is in turn coupled to the system bus 20. Examples of the peripheral modules include a console, a printer and a mouse.

The present invention is also described with reference to an operating system installed on the processing system 10. Figure 2 is an overall functional block diagram illustrating the architecture of a processing system 10 utilizing the apparatus and method of the present invention. The processing system 10 comprises an operating system 30 which supports application programs 32 and services 34, Basic Input/Output System ("BIOS") 36 and system hardware 38. The BIOS 36 is a collection of drivers, or software interfaces for hardware devices such as the console (keyboard and display) , a generic printer, the auxiliary device (serial port), the computer's clock and the boot disk device. The BIOS 36 is typically embedded in programmable, read only memory (PROM) . Often, the BIOS functions themselves are actually copied from PROM into RAM 16, taking advantage of the faster access times of RAM 16. This is known as "shadowing" the BIOS 36 because two copies of BIOS 36 results: one in PROM (which will no longer be used) and the other in RAM 16. The portion of RAM 16 which stores the BIOS 36 is known as the BIOS shadow space. An operating system such as Windows NT makes no use of the BIOS 36 after the operating system has been booted and is running. The kernel level drivers in the Windows NT operating system interface directly with the system hardware. The present invention facilitates the use of the BIOS 36 as an interface between system hardware 38 and an operating system 32.

The operating system 30 includes a class driver 40 which interfaces with the application programs 32 and services 34, and an I/O Manager 42. The I/O Manager 42 converts I/O requests from the application programs 32 and services 34 (made via the class driver 40) into properly sequenced calls to various driver routines located in the kernel 44. In particular, when the I/O Manager 42 receives an I/O request, it uses the function codes of the request to call one of several dispatch routines in a driver located in the kernel 44. The kernel 44 provides hardware- independent functions, called system functions, that are accessed by means of a software interrupt. The functions provided by the kernel 44 include file and directory management, memory management, character device input/output and time and date support, among others. In one embodiment, the operating system is the Windows NT operating system. In alternate embodiments, the operating system 30 includes the Solaris or the AIX operating systems or other operating systems based on demand-paged virtual memory subsystems .

The present invention provides an access driver 46, located within the kernel 44, which is responsible for accessing BIOS data located in the BIOS 36 or for accessing system hardware 38 data via the BIOS 36. The access driver 46 is also responsible for accessing the location of a BIOS function address, as well as executing the associated BIOS function. In one preferred embodiment, the access driver 44 comprises source code written in the C language. It is understood that other assembly languages may be utilized in implementing the functions of the access driver 44. The BIOS data and addresses are typically located in physical memory 50 (typically in RAM 14a; see Figure 1) and are accessed by the access driver 46 via a BIOS Interface 48. In one embodiment, the access driver 46 executes code in the BIOS shadow space, typically at physical addresses OxOOOEOOOO through OxOOOFFFFF.

By way of example, if the access driver 46 needs co access BIOS functions located in physical memory at address 0x00000000. It makes a call to the I/O Manager 42, requesting it to map the memory space at physical address 0x00000000 through OxOOOOOFFF to its virtual memory space. The I/O Manager 42 then returns a pointer to the virtual memory space of the access driver 46, for example, 0xfd268000. The access driver may now reference the address space at physical address 0x00000000 by basing or referring its virtual addresses with 0xfd268000. Thus, the access a function located at physical address 0x400, the virtual address used would be 0xfd268400.

In one preferred embodiment , a set of entry-points or functions calls are available to the application programs 30, services 32 or class driver 40 which utilize the access driver 46. The access driver 46 can be opened, closed, and can receive input/output ("I/O") control codes ("IOCTLs") through these entry points. Table 1 illustrates the structure, entry points and applications for the access driver 46.

Figure 3 is a block diagram illustrating the access driver 46 initialization process as provided in accordance with the principles of the present invention. In general, when the access driver 46 is first loaded, its DriverEntry function (see Table 1) is executed. Although a number of other initializations occur in this function (such as the allocation of various resources or objects for normal operation of the access driver 46) , two particularly essential initializations occur: (a) the BIOS shadow area 60 (which includes a BIOS Service Directory 62) located in physical memory 50 and (b) the BIOS data area 64, also located in physical memory 50, are both mapped into the virtual memory (shown in Figure 3 as the BIOS shadow area 70 (which includes the BIOS Service Directory 72) and the BIOS data area 74) of the access driver 46. As a result, application programs 32 or services 34 may, through the class driver 40, access or execute BIOS functions using virtual addressing. It should be noted that execution of the BIOS function must occur from the access driver 46 because the physical address space of the BIOS 36 is mapped only to the access driver 46. In addition, the access driver 46 may be utilized through the implementation of a 32-bit BIOS Power Management Service Interface as described in detail in Appendix A. It is apparent to one skilled in the art that the BIOS Power Management Service Interface may also be implemented for 64-bit, 128-bit and 256-bit configurations. The access driver 46 can also operate in 64-bit, 128-bit and 256-bit configurations.

In particular, the access driver 46, during initialization, locates the BIOS shadow area 60 and the BIOS data area 64 located in physical memory 50. The BIOS shadow area 60 and the BIOS data area 64 are mapped into the virtual address space of the access driver 46. Next, the access driver 46 performs a search for the BIOS Service Directory 72 header. Upon finding and validating the BIOS Service Directory 72, the access driver 46 obtains the virtual address of the BIOS Service Directory 72 header, which provides the offset of the BIOS Service Directory 72 header virtual address from the base virtual address of the BIOS shadow area 70.

In an alternate embodiment, the access driver, during initialization, locates the BIOS shadow area 60, the BIOS data area 64 and the BIOS ROM area located in physical memory 50. The BIOS shadow area 60, the BIOS data area 64 and the BIOS ROM area are mapped into the virtual address space of the access driver 46. Next, the access driver 46 performs a search for the BIOS Service Directory 72 header. Upon finding and validating the BIOS Service Directory 72, the access driver 46 obtains the virtual address of the BIOS Service Directory 72 header. In this alternate embodiment, the availability of the BIOS ROM area in the virtual memory space of the access driver 46 enables the access driver 46 to read and/or write data in flash ROM. As a result, the BIOS ROM can be reflashed or rewritten. In addition, outside application programs which interface with hardware can access the BIOS ROM area through software mechanisms such as that described in the PhoenixPhlash NT specification provided in Appendix B.

Later, calls to an execution function in the access driver 46 will utilize the base virtual address of the BIOS shadow area 70 and the offset to invoke a requested entry point in the BIOS itself. It should be noted that an application program 32 or service 34 may cause execution of the BIOS function anywhere in the BIOS' virtual address space, and not only through the BIOS Service Directory 72.

In one embodiment, the execution function that is called to invoke a requested entry point in the BIOS is the IOCTL_BIOS_EXEC function, which is described in Table 1. The IOCTL_BIOS_EXEC function creates a register stack in a buffer (which is specified by the calling application program 32 or service 34) located in main memory or DRAM. The contents of the stack are the desired register values at the time the BIOS function is invoked. The access driver 46 passes the register stack from the calling application program 32 or service 34. The procedure call itself is performed using a pointer to the function specified in the BIOS Service Directory 72. In one embodiment, the BIOS function called by IOCTL_BIOS_EXEC accepts a 4-byte signature as an argument and locates the BIOS function associated with the signature. Values passed back to the calling application program 32 or service 34 include the base virtual address of the BIOS function, and the offset from the base address of the service's entry point.

A general discussion of the structure, entry functions and applications for access driver 46 will now be provided.

Table 1. Access Driver 46 Functions

Table . Access Driver 46 Functions (continued)

A. Detailed description of the Access Driver 46 functions

1. The "DriverEntry" function

This entry point causes the driver to initialize its variables, map in the BIOS shadow and data areas, and to allocate resources for its normal operation. As each resource or object is allocated, it is tabulated into the variable 'phResAndFlags ' ; this allows a single function ( ' freeResources ' ) to free up resources used by the driver, no matter the reason for the driver being unloaded. The resources allocated or connected to are as follows:

a. Create the Device Object - establishes a device object and name with the system.

b. Initialize Error Logging - creates a link to the Event Log services .

c. Set up the major function entry points.

d. Create a Symbolic link - for use by Service or Application layers.

e. Map in the BIOS shadow - makes this memory space accessible in virtual memory to the driver.

f. Map in the BIOS ROM - makes the ROM area accessible in virtual memory address space. g. Map in the BIOS Data - makes this memory space accessible in virtual memory to the driver.

h. Locate the BIOS 32-bit entry point for use by this driver .

In one embodiment, the device object name is 'Laptop', which is required in order to service the nexus functions required by the Microsoft OEM Adaptation Kit (OAK) . The corresponding symbolic link name is 'PhoenixADA

2. AccessDriverCreateClose

This function is used to inform the driver 46 when an application program 32 or service 34 makes a request to the system for a device handle, or when it closes a handle already obtained. The Access Driver 46 responds to this dispatch entry point by completing the request successfully, but changing no other state variable of the driver 46.

3. AccessDriverUnload

This dispatch entry point is called by the kernel on behalf of the Service Control Manager (SCM) or other application when it is necessary to remove the driver from the system (device close from (SCM) ) . The result of this function call is that all resources tabulated in 'phResAndFlags' are freed to the system and the request is completed successfully. 4. AccessDriverReσ

The Access Driver 46 driver has the function of performing "nexus processing" for the power management model provided as part of the OEM Adaptation Kit (OAK) . This function is integral to the emulation of power management for OEM and standard devices having knowledge of and a requirement to use the OAK control methods . The AccessDriverReg function registers devices into a linked list. It also selectively "deregisters" devices on request. Typically OAK compliant device drivers will make the call for registration when their DriverEntry function is executed (when they are first loaded) . And as part of the DriverUnload function, each registered device must make the call to remove itself from Access Driver 46 's linked list of devices needing power management services .

5. IOCTL Functions

Every interface between the service or application layer and the BIOS is handled by an IOCTL function in the Access Driver 46 driver. Each IOCTL transfer is performed in Buffered Mode, so that the input data to the driver and its output data are transferred through a common system buffer. The pointer to this buffer space is given in the Input/Output (I/O) Request Packet as Irp>AssociatedIrp.SystemBuffer . Upon being given control, the IOCTL (within the driver) will get the system buffer address and use its contents to perform the request. The results of the IOCTL function's execution will be placed in the same system buffer as was used for input .

Each IOCTL that is implemented in the Access Driver 46 driver has a unique data format for IOCTL input data and for its output data. As the functions are described below, their data buffer formats and descriptions of each field are given. Buffer offsets are given in bytes. The minimum buffer size given for each function is a recommended malloc ( ) size to use for the application program's user buffers. System buffer sizes will automatically be derived from the user buffers.

6. IOCTL Locate

The IOCTL_Locate function is the first dispatch entry point to be called by the application program 32 or service 34 after the driver 46 initializes. The function returns the addresses of the BIOS32 Service Interface, the base address of the BIOS shadow area, and the base address of the BIOS Data Area, in flat-model virtual address format (32 bit addresses) . Note that the BIOS32 Service Interface is the single entry point for all BIOS functions executed from the driver level or kernel threads (see Appendix A) . The BIOS32 Service Interface is the single entry point for all BIOS functions executed from the driver level or kernel threads (see Appendix A) . These address spaces are guaranteed to be accessible to this driver (only) during the time the Access Driver 46 driver is loaded.

Input data: None, do not rely on buffer contents Output data: Offset 0: PUCHAR - BIOS Service Directory Offset into Shadow.

Offset 4: PUCHAR - BIOS Shadow

Area Base Virtual Address.

Offset 8: PUCHAR - BIOS Data Area

Base Virtual Address .

Offset 8: PUCHAR - BIOS Data Area

Base Virtual Address .

Offset 12: PUCHAR - BIOS ROM Area Base Virtual Address.

Min. Buffer Size: 16 bytes

7. IOCTL BIOS Read

The IOCTL BIOS_Read function is a general purpose reader of either the BIOS ROM, shadow area, or the data area.

Input Data: Offset 0: ULONG - Mode Flags

Bit 0: 1 = shadow area, 0 = data area.

Bit 2: 1 = ROM area (overrides Bit 0)

Offset 4: PUCHAR - Offset into the BIOS area to start the read

Offset 8: ULONG - Length of the read in bytes.

Output Data: Offset 0: ULONG - Length of the actual read Offset 4: UCHAR array - the actual data read

Min. Buffer Size: 16 bytes

Note: If a 'short read' occurs because the offset into the BIOS area specified an overlap with the end of the mapped BIOS memory, no error is returned. Instead the 'actual data read' field accurately indicates how much of the data is valid in the system buffer.

8. IOCTL BIOS Write

The IOCTL_BIOS_Write function is a general purpose writer of either the BIOS ROM, shadow, or the data area.

Input Data: Offset 0: ULONG - Mode Flags

Bit 0: 1 = shadow area, 0 = data area.

Bit 2: 1 = ROM area (overrides Bit 0)

Offset 4: PUCHAR - Offset into the BIOS area to start the write

Offset 8: ULONG - Length of the write in bytes.

Output Data: Offset 0: ULONG - Length of the actual write

(zero, or request size)

Offset 4 : UCHAR array - the actual data read

Min. Buffer Size: 16 bytes Note: Short writes are not permitted due to the possibility of data corruption.

9. IOCTL BIOS Exec

The IOCTL_BIOS_Exec function is used to execute a BIOS function through the BIOS32 Service Interface. An activation record is passed by value in the system buffer. The AR determines the Base Architecture register contents upon invocation of the entry point to the BIOS. Upon successful completion, the AR contains the Base Architecture context that would normally have been returned to the BIOS caller.

Input Data: Offset 0: ULONG - - Function entry point virtual address .

Offset 4: ULONG - Flags Register

Offset 8: ULONG reserved

Offset 12: ULONG reserved

Offset 16: ULONG reserved

Offset 20: ULONG reserved

Offset 24: ULONG reserved

Offset 28: ULONG reserved

Offset 32: ULONG reserved

Offset 36: ULONG reserved

Offset 40: ULONG reserved

Offset 44: ULONG EBP Register

Offset 48: ULONG EDI Register

Offset 52: ULONG ESI Register

Offset 56: ULONG EDX Register Offset 60: ULONG - ECX Register Offset 64: ULONG - EBX Register Offset 68: ULONG - EAX Register

Output Data: Contents of the system buffer are identical in structure. Register contents may have been influenced by the BIOS function requested. Min. Buffer Size: 80 bytes.

10. IOCTL RTC Read

The IOCTL_RTC_Read function is used to read the contents of the RTC registers in the CMOS RAM. The data from this atomic read is formatted similarly to the SYSTEMTIME structure and returned to the user in the System Buffer.

Input Data: None, do not rely on buffer contents

Output Data: <uses SYSTEMTIME template as shown below>

Offset 0: WORD current year

Offset 2: WORD current month (January=l)

Offset 4: WORD current day of week (Sunday = 0)

Offset 6: WORD current day of month (calendar)

Offset 8: WORD current hour

Offset 10:WORD current minute

Offset 12:WORD current second Offset 14:WORD current millisecond

Min. Buffer Size: 32 bytes.

Note that the Year field in the RTC is 8 bits wide. The contents of the Year field in the RTC will be recalculated to a SYSTEMTIME .Year 16 bit field containing the entire value of the current year, AD. Examples: RTC=00, Year=1980; RTC=23, Year = 2003. Also note that Legacy RTC devices do not provide the millisecond field in their register set. Because of this, the current millisecond field in the Output Data for this function will always be set to zero.

11. IOCTL VERSION

The IOCTL_Version function returns to the caller the major, an minor version of the Access Driver 46 driver. In addition, the functions implemented by this version of the driver are enumerated in a bitmap. The purpose of the bitmap is for services or higher level drivers to evaluate whether or not this version of the driver can be used for their purposes (at installation time, typically) .

Input Data: None, do not rely on buffer contents

Output Data: Offset 0: WORD Major Version (X.)

Offset 2: WORD Minor Version ( .x)

Offset 4: ULONG Bitmap of implemented functions

(see below) Bit 31: 1 if IOCTL_Locate implemented

Bit 30: 1 if IOCTL_BIOS_Read implemented

Bit 29: 1 if IOCTL_BIOS_Write implemented

Bit 28: 1 if IOCTL_BIOS_Exec implemented

Bit 27: reserved

Bit 26: reserved

Bit 25: reserved

Bit 24: 1 if IOCTL_RTC_Read implemented

Bit 23: reserved

Bit 22: reserved for Phlash interlock

Bit 21: reserved for online setup (NVRAM writes)

Bit 20 - 0: reserved for future expansion

Bit 30: 1 if IOCTL_BIOS_Read implemented

Min. Buffer Size: 16 bytes

12. IOCTL PM Suspend

The IOCTL_PM_Suspend function causes IRP_MJ_PNP_POWER, IRP_MN_LT_SUSPEND IRP's to be sent to each device that has registered itself using the Access Driver DriverReg entry point.

Input Data: None, do not rely on buffer contents Output Data: None, do not rely on buffer contents

13. IOCTL PM Resume

The IOCTL_PM_Resume function causes IRP_MJ_PNP_POWER, IRP_MN_LT_RESUME IRP's to be sent to each device that has registered itself using the Access Driver DriverReg entry point.

Input Data: None, do not rely on buffer contents

Output Data: None, do not rely on buffer contents

B. Error Codes Returned by Access Driver 46

The following table defines the error status returned when an IRP is unsuccessfully or only partially completed. Conditions of termination of the functions are given as well. This table is necessary because there is not necessarily a one-to-one correspondence between NTSTATUS values known by the operating system and those used by the Access Driver 46 device driver. In order to reverse translate the codes back into strings usable by an applications writer or an end-user, it is mandatory that only NTSTATUS error codes be used.

Table 2. NTSTATUS Codes returned from Access Driver 46

C. BIOS 32 bit Entrv Point Specification

In order for IOCTLJLocate to find the entry point for the BIOS, the BIOS 32-bit Service Directory is used. A description of the BIOS 32-bit Service Directory is described in Appendix C. The signature that Access Driver 46 will use when locating and executing BIOS functions shall be "_32_" .

If the WinntEntry (BIOS32 Service Directory) structure is not found subject to the conditions stated above, the Access Driver 46 driver will fail at load time, and DriverEntry will indicate that it was unable to initialize as per Table 2.

D. Real-Time Clock Hardware Access

In order to implement the IOCTL_RTC_Read function, it is necessary to define the RTC's registers and methods of access. The RTC registers are located in the CMOS RAM's I/O address space. Only the RTC registers are shown in Table 3. The registers are accessed by outputting a CMOS RAM address to port 0x70, and then reading the subject 8 bit register at port 0x71. The CMOS RAM address is set to point to OxOD after all RTC register have been read.

Table 3 RTC Registers

Figure 4A is a flowchart illustrating one embodiment of the initialization process of the present invention. Beginning from a start state, the process S100 proceeds to process step S110, the variables for the calling program (i.e., the I/O Manager 42) are initialized. Details of this initialization process S110 are provided in Figure 4B and the accompanying text. The process S100 then proceeds to process step S120, where it loads the access driver 46. Initialization of the access driver variables then occurs. During the initialization process, two particularly essential initializations occur: (a) the BIOS shadow area 60 (which includes a BIOS Service Directory 62) located in physical memory 50 and (b) the BIOS data area 64, also located in physical memory 50, are both mapped into the access driver's 46 virtual memory (shown in figure 3 as the BIOS shadow area 70 (which includes the BIOS Service Directory 72) and the BIOS data area 74) of the access driver 46.

The process S100 then advances to process step S130, where pointer initialization occurs. Details of the process step S130 are provided in Figure 4C and the accompanying text. The process S100 then advances to process step S140, where initialization ends. The process S100 then terminates.

Figure 4B is a flowchart illustrating the details of process step S110. Beginning from a start state, the process S110 proceeds to process step S112, where the calling program from the I/O Manager 42 allocates memory for a specified memory structure in the system buffer. The process S110 then advances to process step S114, where the calling program from the I/O Manager 42 determines the location of a number of BIOS functions, their corresponding entry points, lengths and offsets. In one embodiment, this is accomplished by entering the address field of the specified memory structure for the corresponding BIOS function with the virtual address of the BIOS function and by providing a 4-byte ASCII string identifying each BIOS function. Initialization of the calling program then terminates.

Figure 4C is a flowchart illustrating the details of process step S130 of Figure 4A. Beginning from a start state, the calling application program 32 or service 34, through the class driver, makes a call to IOCTL_Locate, as shown in process step S132. In response, the access driver 46 performs a search for the BIOS Service Directory 72 header, as shown in process step S134.

Upon finding and validating the BIOS Service Directory 72, the access driver 46 obtains the virtual address of the BIOS Service Directory 72 header, which provides the offset of the BIOS Service Directory 72 header virtual address from the base virtual address of the BIOS shadow area 70. The process S130 then returns control to the calling application program 32 or service 34.

Figure 5A is a flowchart illustrating the calling execution process of the present invention. Beginning from a start state, the process S200 proceeds to process step S210, where the calling program calls a BIOS function by providing to the access driver 46, the address of the BIOS function it wants to begin execution at. The process S200 then proceeds to process step S220, where the access driver 46 receives a dispatch call to a BIOS function via an IOCTL command from the I/O Manager 42 (see Figure 2) . The process S200 then proceeds to process step S230, where the access driver 46 conducts a range check of the entry point address. In particular, the access driver 46 determines if the entry point address is within the range of addresses mapped to the BIOS shadow area, exclusive of the service directory header. If not, the access driver 46 indicates that the starting virtual address is not within the range of addresses mapped from the physical memory to the virtual memory. This may be indicated through the use of a flag. If the range check is successful, the process S200 proceeds to process step S240, where the access driver 46 executes the BIOS function called. The process S200 then terminates.

Figure 5B is a flowchart illustrating the details of process step S240 of Figure 5A. Beginning from a start state, the process S240 proceeds to process step S242, where the access driver 46 creates a register stack in a system buffer previously specified by the program from the I/O Manager 42. The process S330 then advances to process step S244, where the access driver 46 provides a pointer to the register stack which holds the address of the BIOS function to be executed. The process S240 then proceeds to process step S246, where the calling program from the I/O Manager 42 calls and executes the function whose beginning address is indicated by the pointer, using its physical address as mapped in virtual memory. The process S240 then terminates.

An example of the utilization of the IOCTL_BIOS_EXEC function in the access driver 46 will now be provided. Initially, the application program 32 or service 34 makes a call to the access driver 46 using the command IOCTL_Locate . The data returned by the access driver 46 includes the BIOS Shadow Area Base Virtual Address, the BIOS Service Directory offset from the BIOS Shadow Area Base Virtual Address, and the BIOS Data Area Base Virtual Address.

The following step is then utilized to determine the existence of a BIOS service, its entry point, length and address offset. A calling program from the I/O Manager 42 first allocates memory for a register structure, such as I0C_EXEC1 and then fills in the biosFunction field of the structure with the virtual address given by the IOCTL_Locate function. The other register values are filled in as follows: a 4-byte ASCII string identifying the BIOS service is loaded into the eax register and a zero is loaded into the ebx register.

Next, the caller invokes the IOCTL_BIOS_Exec function of the access driver 46 with the contents of the I0C_EXEC1 structure copied into the system buffer for the IOCTL call. The BIOS function is then executed. The IOCTL_BIOS_Exec function of the access driver 46 returns, with register values for eax, ebx, ecx and edx each containing responses from the service directory. The calling program of the I/O Manager 42 then takes the information returned from the service directory and creates a biosFunction entry point and a structure in the system buffer. It then calls the BIOS function using the IOCTL_BIOS_Exec function in the access driver 46. Returned data are passed in the same I0C_EXEC1 structure .

Examples of the processes shown in Figures 4A 4B, 5A and 5B are illustrated in Appendices D1-D3. In particular, Appendix Dl illustrates exemplary source code for the application program 32, service 34 or class driver 40, used in calling a BIOS function through the class driver 46. Appendices D2 and D3 illustrate exemplary source code for the access driver 46. Appendix D2 illustrates exemplary source code for executing a BIOS function in the shadow area, while Appendix D3 illustrates exemplary source code for creating a register stack and for calling the entry point for executing the BIOS function.

Through the use of the present invention, an apparatus and method for accessing and executing the contents of physical memory from a virtual memory subsystem is provided. The apparatus and method facilitates increased addressing capability for memory and input /output operations, and also allows execution of processor instructions in physical memory space.

Although the present invention has been described in terms of certain preferred embodiments, other embodiments apparent to those of ordinary skill in the art are also within the scope of this invention. Accordingly, the scope of the invention is intended to be defined only by the claims which follow.

Appendix

BIOS Power Management Service for Windows Nt 4.0

Introduction

management services to APM-aware applications. pπmd.ng power

Terms

AP BIOS

S3Ξ.Ϊ2 S^{Ch Pr0Vid}" ^P°^{Wer managemeπt fUnαi0nS} ""«*« <° *« PM specification (currently at

ower Management Kernel Driver (PM Driver)

Prov,des access ^to the BIOS ROM. BIOS Data Area and the 32-Bit Services for Services.

Power Management Service (PM Service)

PowerPAL

»« S "'^e"^{Si0nS WWCh} *«* ""*— ""' « « ^■»«- - device power

on .d.e pnoπ^ty are e ceed and they w,„ _{be prcempt}ed _by an^hread ^ ^ £2^ ™

User Mode

S ES SS^ S" ^Wh'^{Ch aPP}'^iCa,i0n °* ^{mnS' A}" -™* — *- ^« *»

O 99/19796

Architecture Overview

The extensions to the BIOS for support of Windows NT power management consist of two parts:

(a) Modifications to the BIOS32 Service Directory. An entry was added which allows the PM Driver to find the entry point for the BIOS Power Management Service Interface.

(b) New 32-Bit BIOS Power Management Service, which mimics the APM 32-bit interface with some differences, which are noted below. The new interface provides a 0:32 calling method which is more secure and more Windows NT friendly.

When the PM Kernel wishes to use the BIOS services, it must perform the following steps:

1. Find the BIOS32 Service Directory header

2. Call the BIOS32 Service Directory calling interface, specifying the 32-Bit BIOS Power Management Service Interface entry point.

3. Call the BIOS 32-Bit BIOS Power Management Service Interface entry point, asking for APM Connect.

B10S32 Service Directory Modifications

The 32-bit BIOS Service Directory is an existing structure within the Phoenix BIOS which allows a 32-bit protected mode application or operating system to find the entry point for a particular 32-bit service. This specification defines a new standard 32-bit BIOS Service.

The BIOS32 Service Directory consists of a fixed structure which can be detected by the PM driver and a single function which returns the address for a particular service.

The BIOS32 Service Directory Header

A BIOS which implements the BIOS32 Service Directory must embed a specific, contiguous 16-byte pattern somewhere in the physical address range OEOOOOh - OFFFFFh. The pattern must be paragraph aligned (i.e., it must start on a 16-byte boundary). This pattern is known as the BIOS32 Service Directory Header.

The Header is comprised of six distinct fields. The following table describes each field.

Clients of the BIOS32 Service Directory should first determine its existence by locating the Header. This is done by scanning OEOOOOh to OFFFFOh in paragraph increments and looking for a signature match ("_32_") in the first 4 bytes of each paragraph. When, and if, the signature is detected the client shouid perform a checksum of all bytes in the Header. (The Header length, in paragraphs, is found at offset 9h.) All bytes in the Header should ADD together with a result of Oh. If the checksum is valid then the 32-bit entry point field can be used as the address for the BIOS32 Service Directory Calling Interface. If the Header fc nm found then the BIOS32 Service Directory does not exist on the piatfoπn.

The BIOS32 Service Directory entry point, and its associated code and data, maybe located anywhere wⁱthm the 4Gb physical address space. However, it is guaranteed to be physically contiguous (i.e. it will be delⁱvered ,n ROM or FLASH space) and to fit within two pages (i.e., it will not span three pages)

The BIOS Service Directory

1°. ^g n^{Λ entry P}°rv ^{1 10 thC BI}°^{S 32}-^{Bk PθWer Mana}g^{ement Se}™< interface, the PM Driver must call the BIOS Service Directory with the following parameters:

IN: EAX "NTPM" or 0x4E54504D

EBX 0x00000000

OUT: AL Error code: 0x00 = None, 0x81 = Service does not exist

EBX Base address of the 32-Bit Power Management Service code

ECX Length of the 32-bit Power Management Service code (from EBX)

EDX Offset (from EBX) of the 32-bit Power Management Service code entry point.

The entry point of the 32-bit Power Management Service code entry point is FAR (that is requiring both segment and offset to be pushed on the stack.)

CS: The base address must be less than or equal to the (4KB) page address of the page that contains the entry poⁱnt. For example, if the entry point is 0FFF81234h, then the base address must be less than or equal to 0FFF8 lOOOh. The limit must be such that the base address plus the limit generate an address that ⁱs greater than or equal to the last address on the (4KB) page which follows the paee contaⁱnⁱng the entry point. For example, if the entry point is 0FFF81234h then the base address plus the mu must be greater than or equal to 0FFF82FFFh. Simply stated, the base address and the lⁱmⁱt must ^•encompass" both the page that contains the entry point and the following page.

The segment type must be 100b (code, execute only) or 101b (code, execute/read). However the

l

The Default Size bit must be 1 (32 bits).

DS:

Thtcsu ?™ ^{mUSl be equal t0 the CS base addrcss' "π,e ii il must be greater than or equal t0}

The segment type must be 000b (data, read only) or 001 (data, read/write). However, the ⁱmpiementers of the Service Directory cannot assume write access to the DS data segment The system bⁱt must be 1 (non-system segment). The Descriptor Privilege Level (DPL) must be greater than or equal to CPL (see the DPL field in Section O). ^S SS: The segment type must be 01 lb (data, read/write, expand-down) or 001b data, read/write, expand- up). The system bit must be 1 (non-system segment). The Descriptor Privilege Level (DPL) must be equal to the CPL (see the DPL field in Section 0). The Default Size bit must be 1 (32 bits). The Granularity bit must be 1 (4Kb).

Note that the above settings ensure a stack size of at least 4kb. It is the caller's responsibility to ensure that there is at least lkb of unused stack available.

Paging: Paging may or may not be enabled. If paging is enabled, then the address space that is described by the CS and DS selectors must be iineariy contiguous. That is, the original physical contiguity of the Calling Interface as found in ROM or FLASH must be preserved. (The Calling Interface code and data is written to be position-independent and ElP-relative).

IOPL: In order for the Calling Interface to execute I O instructions, the I/O Privilege Level (IOPL) field in EFLAGS must be greater than or equal to the CPL (see the DPL field in Section 0).

Other: The BIOS Data Area, Extended BIOS Data Area and fixed-location ROM data tables cannot be assumed to be available for use by the executing code because of paging. The BDA may be accessed using the pointer provided by the caller.

32-Bit BIOS Power Management Service interface

In general, the 32-Bit BIOS Power Management Interface provides the same functionality as the 32-bit APM entry point. There are two areas of difference: the way in which calling parameters are passed and the way in which certain APM connect functions are supported.

Calling Parameters

The APM 32-Bit Interface passes all parameters in CPU registers. The BIOS Power Management Service Interface passes the parameters on the stack. The equivalent C-style declaration would be: typedef s ruer {

ULONG reservedO ; /* 00 */

ULONG pBDΛ; /* 04 */

ULONG regFlags ; /* 08 */

ULONG reservedl ; /* oc */

ULONG reserved2 ; /* 10 V

ULONG reserved3 ; /* 14 */

ULONG reserved4 ; /* 18 */

ULONG reservedS ; /* IC */

ULONG reservedβ /* 20 */

ULONG reserved7 ; /* 24 */

ULONG reservedβ ; /* 28 */

ULONG reserved-) ; /* 2C V

ULONG regEBP /* 30 */

ULONG regEDI , /* 34 */

ULONG regESI , /* 38 */

ULONG regEDX /* 3C */

ULONG regECX /* 40 */

ULONG regEBX /* 44 */

ULONG regEAX /* 48 */

) regStruct; unsigned char BPMSI ( regStruct* parameters) ; The actual APM function and its behavior will be determined by the value written in _the _CMW«« -r

ϊ wmill ^ be _n 0^T an °d!S bi^Bts^, 8J ^b-ⁱ1^t5 ° o °f^f re ^rec^gE^FA^laYε^s wi_l ⁱt^H κ ^b _» ^e n * ∞ n-^d- ^Λ -^{e e}™ _A code wi _Jll be • in , bits 8-15 of re reegEπAAYX, « o*therwi •se i •t specification. ^δ * °^' ^ ""* ^∞deS ∞ ^{,dent,cal l0} *« *^■*> in the APM

Software Requirements

Development Software Requirements

The following software development tools are required to build the PM service:

• MASM 6.1 lc assembler from Microsoft

• Phoenix PhDebug for debugging the code

Software Requirements

PM service

•

Porting Changes

Appendix

PhoenixPhlash NT

Flash ROM

Programming

Utility for

Windows NT

Mve^Pr^h _S ^{ni!(AD driVer re,erred ,0 in} *"*"«* B is the Access

99/19796

Phoen-xPHLASH ■ Flash ROM Programming Utility for Windows NT Design Specification

1.0 OVERVIEW 6

Using COriver to access hardware 5

2.0 MODES OF OPERATION 7

2.1 Win32 Console 7

2-3 Completion Codes 11

2.4 Device Dependent Modules 12

2.4.1 Autodetection 13

2.4.2 Zero 13

2.4.3 Erase 13

2.4.4 Program 13

2.5 Supported Devices 13

3.0 PLATFOR .DLL DETAIL 16

3.1 File Format 15

3.2 File Header Format 15

33 Block Table Format 17

3.3 J Multiple Flash Blocks IS

3-3.4 Processing Boot Blocks and £5CD storage jg

3.3.5 Block Table Examples 19

3.4 PLATFORM.DLL Functions 19

3.4.1 Function EnableFIashO 20

3.4-2 Function DisabieFlashO 20

3.4.3 Function BeginFlash(DWORD Block ndex) 21

3.4.4 Function EndF.ash(D ORD Blockjndex) 21

3.4.5 Function GetBlock(DWORD lndex7D WORD BufTer_Addrass) 21

3.4.6 Function CmdLine(char far *szOptions) 22

3.4.7 Function AutoSenseO 22

3.4.8 Function hFlas able(ch-j far *J2ϋrrorMsg) 23

3.4.9 Function Reboot() 23

3.4.10 Function CheckSumO 23

3.4.11 Function GetBIOSFileSizeO 23

3.4.12 Function GetManufactlDO 24

3.4.13 Function GetPartlDO 24

3.4.14 Function GetFlagsO 24

3.4.15 Function GeϋmageBufO 24

3.4.16 Function GetMfglDAddrO 24

3.4.17 Function GetPanlDAddrO 25

3.4.18 Function GetRetryCountO 25

3.4.19 Function GctblockTabteSizeO 25 3.4 JO Function GetpartTypesSizeO 25 PhosnlxPHLASH - Flash ROM Programming Utility for Windows NT Design Specification

3.4-21 Function Ge BlockTableO 25

3.4.22 Function GetpartTypesO 26

3.4-23 Function GetDLLVersionO 26

3.4-24 Function GetROMFileName 26

3.4-25 Function GetDLLFuncDeflneO 26

4.0 BJOS.ROM DETAIL 27

5.0 GENERAL IMPLEMENTATION GUIDELINES 28

APPENDIX B1 ^■ FUTURE ENHANCEMENTS 29

Completion Codes with Keyboard LEDs 2

APPENDIX B2 - PHLASHNT.H COMPLETION AND ERROR CODES 30

APPENDIX B3 - PLATFORM.DLL SAMPLE SOURCE CODE 31

PLATFORM.CPP ₃₁

9/19796

PhoanixPH ASH - Flash ROM Programming Utility for Windows NT Design Sptctflcatioπ

1.0 Overview

The PhoenixPhlash flash utility will be used to program BIOS images into flash ROMs in AT compatible systems. The utility will consist of the following files:

PHLASHNT XE - used to program the flash ROM PLATFORM.DLL - used to perfoπn platform dependent functions BIOS.ROM - actual BIOS image to be programmed into flash ROM

This specification provides a detailed description of the functionality for the PHLASHNT.EXE program. Because PLATFORM.DLL and BIOS.ROM are platform specific, only the general format of these two files is covered in this document

PhoenixPhlash will be executed as a Win32 console application.

High priority is being placed on flexibility, adaptability and supportability for this design project. As much customization capability as possible will be placed into the PLATFORM.DLL file so that many different platforms and configurations can be supported without modifying PHLASHNT.EXE. PhoenixPhlash will support platforms with a single flash ROM part, as well as platforms with multiple flash ROMs. Flash ROMs from I Mbit to 4Mbits or greater will be accommodated, including boot block devices and devices with any configuration of multiple flashable regions.

For each supported part, all code specific to the particular flash ROM part (e.g. Intel 2SFxxxx) will be part of the PHLASHNT.EXE module. All code and parameters specific to a platform (e.g. flash enable code and flash ROM address range) will be part of the PLATFORMXILL module.

PHLASHNT.EXE, the main module of the PhoenixPhlash utility, will contain all code which is platform independent It will contain user interface code, code to load and verify the PLATFORMJ5LL file and the platform independent portions of code to program a flash device.

PHLASHNT.EXE will be a Win32 executable file, generated using Microsoft C++ V4.2 or later.

Using CDriver to access hardware

PHLASHNT.EXE uses the C river C++ class which works in conjunction with the PhoenixAD driver to enable Windows NT user-mode applications to access I O ports; to access BIOS data and code area; and to execute BIOS32 services. The CDriver class provides a simple and flexible interface between the application program and the PhoenixAD driver:

CDriver works in conjunction with the PhoenixAD driver to provide the following functions to user-mode application programs.

Access to I/O ports

Execute J3IOS32 services . Pho^βnixPHUϋiH ^■ Flash ROM Programming Utility _far wind— _MT „..,„_ ^^^^

flexιb,luy to both applica^tions and the kernel driver designs. ^PTOVldeS

To assure future compatibility, PHLASHNT.EXE does not call the Pho_en_ix n _A • dⁱrectly; instead, it calls the meώods in the CDriver class. ««««*«> dπver

... PhosnlxPHLASH - Rash ROM Primming I .ty for Wln_dn ,. ,r n^. -p^^

2.0 Modes of Operation

2.1 Win32 Console

PHLASHNT.EXE will be started in a Windows MT -_ΛΛ.- ,, ^ .. command line flags (if any). wⁱn^dows NT wⁱndow, followed by optional

Comm

IB-βlename

file has a name other than PLATFOK ϋLL ^{T ώe falnarv}

t ^^AT70R

/CS

CHECKSUM BIOS ROM - Computes checksum o nine om - the checksum is not zero,

Checksum fails, the program

«* help screen. /? can 796

PhocnrxPHLASH - RHH ROM Programming Utility for Windows NTDoβlgn Specification

I

IMAGE SIZE VERIFICATION - Proceed only if the ROM image file size is the same as the size of the flash part. MODE=n

OPERATION - Selects the operating mode for PHLASHNT. The following operating modes are currently supported:

0 Update only the BIOS image (the normal operating mode). In this mode, PHLASHNT replaces the current BIOS image with the new image. The DMI information in the system BIOS is maintained. This is the default mode and is selected if the MODE command line flag isn't present or if an operating mode isn't specified.

1 Update only the DMI information. In this mode, PHLASHNT writes the strings specified via the DMI command line flags to the Flash. The DMI information in the system BIOS is maintained unless new DMI strings are specified on the command line.

2 Update both the BIOS and DMI information (save system DMI strings). In this mode, PHLASHNT both replaces the current BIOS image and writes the strings specified via the DMI command line flags to Flash. The DMI information in the system BIOS is maintained unless new DMI strings are specified on the command line.

3 Update both the BIOS and DMI information (reset system DMI strings). In this mode, PHLASHNT both replaces the current BIOS image and writes the strings specified via the DMI command line flags to Flash. The DMI information m the system BIOS is replaced with the DMI strings from the new BIOS ROM image and/or new DMI strings specified on the command line.

These options are not displayed by the help (IH) option for security reasons.

IN

NEW (different) - Proceed only for different version of BIOS ROM. If the data structure at BCPSYS, which includes BIOS version and build date &. time, is same as the corresponding structure in the BIOS.ROM file then the programs terminates without flashing.

10

OVERRIDE PLATFORM.DLL OPTIONS - Disable all flags set in PLATFORM.DLL. Without this switch, options set in the PLATFORM.DLL are combined with options specified on the command line. When this switch is used, only command line options are used.

I?

PRODUCTION - Maximize speed of flashing. All user feedback is reduced to a minimum (no sound, or screen update). This is used to reduce the time needed to flash a part in a production environment. Only the final success failure is reported. /19796

PhoenlxPHLASH - » .ash ROM Programming Utility for Windows NT Design Specification

/PN

BIOS PART NUMBER CHECK - Proceed only if the BIOS part number in BIOS.ROM is the same as the part number in the current BIOS. PF="list of options"

Command line options to be passed to the platform dependent module PLATFORM.DLL. On some platforms it may be desirable to pass command line options to the platform dependent procedures. This is done via the CmdLineO function. When both the CmdLineO address is non-zero and this command line option is present, then the string immediately following the equal sign will be passed to PJ ATFORM.DLL (enclose the string in double quotes if the string includes spaces).

/Rn

RETRY - If flashing a block fails, reϋy n times instead of aborting.

The /Rn option can be used in crisis mode by setting psiRetryCount with the desired retry count in PLATFORM.CPP.

/S

SILENT - Silent operation without audio feedback.

IV

VERIFY - After each block is programmed, data in the flash part address space will be compared to the data in the BIOSJIOM file. Any discrepancies are reported and the program will either re-try programming of the same block or the system will halt (depending on the response to a prompt). Because the check is made after the flash memory was erased, the system will be very unstable and it may not be possible to properly notify the user and recover.

ZERO BLOCKS - Zero flash blocks before erasing.

filename

BIOS ROM image file name. Any command line option without the leading back-slash will be interpreted as the file name for the BIOS ROM image file. A filename is only required when necessary to specify a full path for the ROM BIOS image and/or the ROM BIOS image file is different than BIOSJIOM.

(^filename

Response file. Any of the command line options described above may be placed in a response file. PHLASHNT will read the file and process the options as though they were entered on the command line. The options may be placed on a single line or on separate lines. Each line may be up to 1024 characters in length.

The following command line flags are used to write information to Flash for later retrieval through the Phoenix Desktop Management Interface (DMI). DMI command line flags are ignored if the target BIOS image does not support the DMI interface (doesn't have a DMI BCP structure installed) or the PHLASHNT operation mode is BIOS only (see above). 19796

PhountxPKLASH - Flash R Λi Programming Utility for Windows NT Design Specification

All flags have the format IDxxString, where xx is one or two characters identifying the specific DMI string (see below). DMI command line flags are optional; Le., if a given DMI command line flag isn't specified, the previous contents of the corresponding DMI string buffer aren't modified, unless a default string is specified in PLATFORM.DLL. In this case, PHLASHNT always writes the default string to the corresponding DMI string buffer. If a DMI command flag is specified without the String field, the corresponding DMI string buffer is cleared (set to a null string). String can only contain printable ASCII characters. String must be enclosed in quotes if it contains spaces. The maximum length of each DMI string is platfoira specific; PHLASHNT returns an error if the passed string is longer than the corresponding target buffer. The following DMI fields are currently supported. These options are not displayed by the help (IH) option for security reasons.

/DSS String Specifies the system serial number string.

IDMSString Specifies the system manufacturer's name string.

IDPSString Specifics the system product (model) identification string.

IDMSS' tring Specifies the system version string.

IDSMString Specifies the motherboard serial number string.

IDMMString Specifies the motherboard manufacturer's name string.

IDPMString Specifics the motherboard product (model) identification string.

IDVMString Specifies the motherboard version string.

IDSCStrwg Specifies the chassis serial number string.

IDMCStrύtg Specifies the chassis manufacturer's name string.

IDPCString Specifies the chassis product (model) identification string.

IDVCString Specifies the chassis version string. DO 1 String Specifies OEM string 1.

IDOnString Specifies OEM string n.

The system and chassis switches arc available only with DMI version 2.0.

The older forms of the command line switches, given below, were originally for DMI 1-2 and are kept for compatibility. These are equivalent to /DSM, /DMM, /DPM and /DVM respectively.

IDSString Specifies the motherboard serial number string.

IDMString Specifies the motherboard manufacturer's name string.

IDPString Specifics the motherboard product (model) identification string. 9/19796

PhoenixPH H - Fit-jf i ROM Programming Utility for Windows UT Design Specification

IDVString Specifies the motherboard version string.

Next, the flash program will load the PLATFORM.DLL file and call the platform dependent function EnabieFIashΩ in PLATFORM.DLL to prepare the platform for flashing. PLATFORM.DLL will indicate memory region where the BIOS ROM image is to be loaded in memory and will indicate what memory regions to use for the flash device. Memor regions may be in conventional memory or in extended memory. After the ROM image is loaded in memory device programming begins.

For each block of the flash ROM to be programmed:

1) BcginFlashO is called in PLATFORM.DLL

2) The proper flash algorithm in PHLASHNT.EXE is executed.

3) EndFlashO is called in PLATFORM-DLL.

This process is repeated for each flash block specified in PLATFORM.DLL. This allows for multiple devices on a single platform, multiple blocks within a device and block dependent initialization termination code for each block. This also allows for automatic saving and restoring of memory regions such as boot blocks.

During flashing, progress information is presented to the user:

1) If production mode is not selected, an appropriate message window will be displayed on the screen, which will include time of day, gas gauge style progress indicator and status line message.

2) Approximately once every second a short beep is sounded.

3) At the start and completion of each step an appropriate code is sent to the debug port.

Video will be updated at least once every second. The sound will be generated approximately every second. Note that in production environment progress update can be disabled.

After flashing is complete, DisableFlashO is executed from the PLATFORM.DLL file. One of two distinct sounds will be generated to indicate success or failure of the flash process. If video is available, an appropriate message window will be displayed. After a short pause system is re-booted.

2.3 Completion Codes

Although the program will proceed through many steps and will be capable of reporting to the user status at each step, only three major stages are identified by sound and keyboard LED codes. The three major stages are:

1 ) Read and verify PLATFORM.DLL file

2) Perform platform specific initialization

3) Program the part Plι-.ntePHLASH . Fl.« R_0M pngnmmm utility for vy-jo... NT Clan s-.e_i._i-.._!.-

^Sound Keyboard

LEDs ON Description

low buzz + 3 short tones CAPS, NUM, SCROLL 1 Befor_{e «}.,«_«-, _«ι _♦* _M

Stage 1 - Failure occurred before locatine PLATFORM TY7 T _\Λ~^ _r. . _.

2.4 Device Dependent Modules

te fitoSS °^f ^ ^{mem0,y SUP 0∞4} "*" ^ ^be " "=" «∞«" ™-ul= ,o perfoπ-

1 ) Identify ^the part and return the manufacturer ID and the part ID

2) Zero a range of flash memory (set all bits to 0)

3) Erase a range of flash memory (set all bits to I)

4) Program a range of flash memory /19796

PhoenixPH ASH - Flesh ROM Programming U.!Hty for Windows NTr_ jsign Specification

2.4.1 Autodetection

In this module wiil be the code necessary to read the Manufacturer 3D. and part ID from the flash memory part If IDs cannot be determined, zero is returned. The built-in auto- detect module wiil not be used when the AutoSenseO function is provided in the PLATFORM.DLL file; the provided AutoSenseO function will be used instead.

2.4.2 Zero

There are several part types which require that the flash memory is set to zero before it can be programmed. In this module will be the code necessary to set memory range to zeros.

2.4.3 Erase

Most flash memory parts require that the flash memory is s t to all ones before the part can be programmed. These parts often allow erasure of a full block of flash memory with a single write operation. In this module will be the code necessary to set memory range to ones.

When block descriptors are defined in the PLATFORMJDLL file, descriptors must be set up so that there is at least one descriptor for each "erasable" block in the flash memory. For example in Intel 28F004 flash memory there is one lδkByte BOOT block, two 8kByte PARAMETER blocks, one 6kByte MAIN block and three 128kByte EXTENDED blocks. Each of the seven blocks can be erased with a single write and there must be at least one descriptor for each of the seven blocks.

2.4.4 Program

In this module will be the code necessary to read the data bytes form the BIOS ROM image and program these into the flash part.

2.5 Supported Devices

Initial set of flash memory devices supported by PHLASHNT.EXE will include the parts listed in the table below. For each part type a manufacturer and part ID and part description is listed. As new parts become available it may be necessary to add additional modules lo PHLASHNT.EXE so that a new type of flashing algorithm is provided ( new AutoDeteciO, ZeroQ. Erase() and ProgramO functions). If it is possible for the new part to use one of the existing algorithms and only the Manufacturer or Part ID changes, then this can be indicated in the PLATFORM.DLL file and no modification of PHLASHNT.EXE is needed (see section on PartTypes for more detail).

Type Mfg ID Part ID Description

2 0x01 OxAl AMD 28F256

2 0x01 0x25 AMD 28F512

1 0x01 0xA7 AMD 28F010

1 0x01 0xA2 AMD 28F010A

2 0x01 0x2A AMD 28F020 PhoanlxPHLASH - Flaah ROM Pro^gramming Utility far Window, NT Daa.cn z ^^

2 0x01 0x29

2 AMD 28F020A

0x01 0x20

2 AMD 9F010

0x01 0xA4

2 AMD 29F040

0x01 0x51

10 AMD 29F200T

0x01 OxBO

10 AMD 29F002T

0x01 0x34

10 AMD 29F002B

0x01 OxDC

10 0x01 AMD 29F002BXT

0x5D

3 0x1 F AMD 29F002BXB

0xD5

8 ATMEL 29C010

0x1 F OxDA

3 ATME 29C020

OxlF 0x35

1 ATMEL 29LV010

OxlC OxDO

1 0x89 Mitsubishi 28F101

OxB9

1 Intel 2SF256

0x89 0xB8

1 Intel 28F512

0x89 0xB4

1 Intel 28F010

0x89 OxBD

4 Intel 28F020

0x89 0x94

4 Intel 28F001 BX-T

0x89 0x95

4 Intel 28F001 BX-B

0x89 0x7C

4 0x89 Intel 28F002 BX-T

Ox7D

4 Intel 28F002 BX-B

0x89 0x74

4 Intel 28F200 BX-T

0x89 0x75

4 Intel 28F200 BX-B

0x89 0x78

4 Intel 28F004 BX-T

0x89 0x79

4 Intel 28F004 BX-B

0x89 0x70

4 Intel 28F400 BX-T

0x89 0x71

5 Intel- 28F400 BX-B

OxBF 0x07

12 OxBF SST29EE010/29LE0I0

0x10

5 SST29EE020

OxBF 0x5D

6 SST 29EE512

OxBF 0x04

1 SST28SF040

0x20 0x07

7 ST M28F101

0xC2 Oxl l

11 MX 28F1000

0xC2 0x2A MX 28F2000

/19796

PhoanixPH- .SH • Fiaah ROM Programming Utility for Window* NT Design Specification

3.0 PLATFOR .DLL Detail

This module contains all platform dependent code and parameters needed to program a flash device on a particular platform.

3.1 File Format

PLATFORM.DLL is a Windows DLL that is produced by compiling PLATFORM.CPP (using Microsoft Visual C++ 42 or later). It contains specific platform data and executable code. A sample source code of the PLATFORM.CPP file is included in Appendix B3.

File version for PLATFORM.DLL will start with version "NT 1.00* Versions are specified in the sz Version variable contained in PLATFORM .DLL.

3.2 File Header Format

The PLATFORM.DLL file will havethe formatdescribed below:

// Global variable Declarations

DWORD dwFileSize // ROM image file size.

BYTE bManufactID // Manufacturer of flash device

BYTE bPartID // Part ID of flaah device

DWORD d Flags // Option flags

DWORD d ImageBuf // Linear address of image buffer

DWORD dwMfglDAddr // Linear address of mfg ID

DWORD d PartlDAddr // Linear address of part ID

BYTE bRetryCount // Count for /Rn option (default - 0) char s∑VersionU // PLATFORM.DLL version char szROMFileN-iπιe(] // Name of BIOS image file

DWORD dwDLLFuncDefinε // Indicates what functions are defined

BYTE bbloc Table≤ize // number of blocks in blockTable

BL0C _D£SCRIPTOR blocJtTable ( )

BΪTE bpartTypesSize // number of flash parts to add

DEVICETABLE partTypes U dwFileSize Number of bytes in the BIOS.ROM file. bManufactID Manufacturer ID bPartZS Part ID dwFlags Option flags. Must be combination of the following values:

FLAG_AUTOSENSEOFF Don't read ID from the part FLAG BACKUP Backup system BIOS ROM FLAG^{^}NEWBIOSONLY Don't flash if 64k at FOOO.O same FLAG^"PRODUCTION Max speed (sound & video off) PhoentxPHLASH - Flaah ROM Pro^gramming Utility for Window. NT Deaiπn *_{n t}r.^_:

FLAG SILENT Do not generate any sounds

FLAG^'VERIFY Verify each block after flash

FLAG~PLATFORMCMD PLATFORM option str present

FLAGJBIOSPARTNUM Flash only same BIOS part number

FLAG CHECKSUM Checksum BIOS.ROM

FLAG TMOS Clear CMOS checksum

FLAG IMAGESIZE Verify image size matches flash part dwImageBuf Address for BIOS.ROM image buffer in e en_d ,-,_«.-. •« •

E^ff"" *^{■ Iώear address} * ^■ K5& SE3.ΩS

address dwImageBuffer + dwFil s ^{g Stamng at} *^■ dwMfglDAddr dwPartlDAddr These two optional fields contain the linear addresses for _th_e fl._ch mαnory ID bytes. When these fields are «ro the dJftS addresses ofEOOOOh and EOOOlh will be used. ^fault bRetryCount Number of times to retry if flashing fails. izVersion Version of PLATFORM.DLL szROMFileName Reserved must be the string "BIOS.ROM". This field i_{s u«}~ι _♦« ⁱdenufy and verify format of the PLATFORM.DLL file dwD T.FunrQafina

bblocJ-TablβSizβ number of blocks described in blockTable d BIockTable

SS_. P *⁸ *^e P^r°Sram ed one contiguous block at a time Each descriptor. ^ ^{prOErammcd mUSt have a} corresponding block bpartTypββSizβ number of flash parts to a_dd dwPartTypes

typedef struct {

BYTE eMfgID // Manufacturer ID BYTE cPartID; // Part ID WORD wFlashType; // Flash algorithm type char szPartName (28] ; ) DEVICETABLE; // Optional description

9796

PhoenixPHI-ASH - Flash ROM Programming Utility for Windows NT Design 8peeif.cat.on

Many platforms allow the same BIOS.ROM image to be used with several different flash parts. This table is used when a new part becomes available, the part is not among.-the parts currently supported by PHLASHNT.EXE and the part uses the same flashing algorithms as one of the supported parts. procEπable enable flashing proc procDisable disable flashing proc procBegin begin flashing proc procEnd end flashing proc procGetBIock get next BIOS block for backup proc procCmdLine process custom command line options proc procSense custom autosense proc rodsFIashable custom OEM proc to determine if ok to proceed procReboot custom reboot proc procCheckSu custom checksum proc to be used if the BIOS ROM image checksum is not zero

A sample source code for PLATFORM.DLL file is shown in Appendix B3.

3.3 Block Table Format

Block table consists of a list of block descriptors, Each block descriptor in the block table is defined by the following structure: typedef struct (

DWORD dwBlockSize ; // Number of bytes in the block DWORD d FilβOffset; // Offset within BIOS .ROM file DWORD dwLine a Addr ess; // Linear 32-bit addreβs of flash ROM BYTE cMfgID; // Manufacturer ID or zero BYTE cPartID; // Part ID or zero WORD wfllocfcAttr; // Block attributes ) BLOCK DESCRIPTOR;

The block table is terminated by a descriptor with all entries set to zero. dwBlockSize Block Size in bytes. Blocks must be contiguous. dwFUeOfiset Offset of this block within the BIOS.ROM file. dwLinearAd dress Starting address of this block in 32-bit address space cMfgID Manufacturer ID or zero to auto-sense. cPartID Part ID or zero to auto-sense. wBIockAttr Determines actions to be taken for this block. Must be a combination of the following flags:

ATTR ZERO Block must be zeroed before programming

ATΠCERASE Block must be erased before programming

ATTR^'SAVE Save content of this block before prog. ATTR~PROG Program this block ATTR~RESTORE Restore content of this block after prog. 9796

PhoenlxPHLASH - Flaah ROM Programming Utility for Windows NT Design Specification

Only one of ATTR^SAVE, ATTR_PROG, ATTR_RESTORE can be used at a time. If no attribute is Specified, then PHLASHNT.EXE leaves the block unchanged. However, even if all of these are omitted, procedures BeginFlashO and EndFlashO are still called. BeginFlashO and EndFlashO can be used when two blocks are in different flash devices, or when a boot block requires additional functions to enable the block for write and to disable it before next block is programmed. BeginFlashO can also be used for conditional block processing. If BeginFlashO returns nonzero, the current block is not processed.

Each ATTR SAVE block must be followed by an ATTR RESTORE block before another ATTR SAVE block can beuseH. ^""

Note that for a given flash memory range there may be several block descriptors. For example to preserve a 16k flash memory Boot Block in 64k erasable flash memory block, three block descriptors would be used. First descriptor to save the 16k boot block, second to erase and program 64k and third to restore the boot block.

To reduce the time required for flashing, it is recommended that the ATTRJZERO flag is not used, because this will avoid the zeroing step and cut the flashing time in half. Only few of the older flash memory types suggested that part is zeroed before it is re-programmed. Most parts do not require this operation.

3.3.3 Multiple Flash Blocks

The block table will be used to support multiple device flashing and multiple blocks within each device. For such platforms the ROM image file must contain the images for all flash pans to be programmed and the Block Table must contain proper offsets and lengths for each block of data to be flashed.

To properly configure the platform before and after each flash block, PHLASHNT.EXE will call function BeginFIash(BlockJndex) to allow PLATFORM.DLL to perform any such set-up. It is the responsibility ^"of BeginFlashO & EndFlashO functions to perform any initialization or termination between blocks as needed.

3.3.4 Processing Boot Blocks and ESCD storage

To program a memory range in the flash memory, there may have to be several different block descriptors, for the same memory range. This may be needed to preserve boot block or ESCD storage within a single 'erase' memory range.

Many flash parts are erased by a small number of write operations, one for each memory block. For example Intel 2SF400 flash memory has seven blocks (one 16k boot block, two 8k parameter blocks, one 64k main block and three 128k extended blocks). This part can be erased widi only seven write operations. Phoen^lxPHLASH - Flas^h ROM Programming Utility for Win_dows NT Daalgn Specification

For other parts, erase function may erase 64k of flash memory at a time, regardless of division of this range into boot and parameter blocks. In such cases it is important that there are three block descriptors for such a 64k range of memory. The first block descriptor in the table is used to save boot block, second block descriptor to erase and r parnoggera. m the parameter blocks and the third descriptor to restore the boot block in this

Some parts require that a additional platform dependent actions need to be taken before a boot block can be programmed. For example Intel parts require that VHH voltage, in addition to VPP voltage, is properiy set. In such cases block descriptor must also have e saucchh b alo fcukn)c.tions in BeginFlashO and EndFlashO procedures (called before and after

3.3.5 Block Table Examples

P TLheAT coFdOeR iMn . tChPeP f.ollowing examples would be placed in the "blockTable" section of

Erase a 4KB block at FC000.

DO 4 * 1024 ; 4KB

DO 0 ; Ti.lt Offset

OO OOOrCODOh ; Linear addraas of Chi* block

OB 0 ; M< ID (0 - default₎

08 0 ; part ID (0 * default₎

DW ATTR_ERASΣ ; Action flags

Z ODero, th 1e2nβ p «ro 1g02ra4m a 128KB b ;lo 1c2k8K aBt E0000 on the specified part.

00 0 ; Til* offset

DD OOOEOOOO ; Linear address of h_is block

D8 01b ; tUg ID (0 - default₎

D8 20h _; rart ID (0 - default₎

DH ATTR ZERO OR ATTR PROG ; Action flags

3.4 PLATFORM.DLL Functions

Currently supported functions are:

DisableFlash

BeginFIash

EndFlash

GetBlock

CmdLine

AutoSense

IsFlashable

Reboot

Checksum /19796

PhoenlxPHLASH - Flash ROM Programming Utility for Windows NT Daalgn Specification

The following junctions allow PHLASHNT.EXE to access global variables and data structures contained in PLATFORM.DLL: _:-_:

GetBIOSFilcSize

GetManufactID

QetPartlD

GetFlags

GctlmagcBuf

GetMfglDAddr

GetPartlDAddr

GctRetryCount

GetblockTableSize

GetpartTypesSizc

GctBlockTable

GetpartTypes

GetDLLVersion

GetROMFileName

GetDLLFuπcDcfine

3.4.1 Function EπabIeFIash()

Entry: None

Returns: Error code (or zero)

This function must be present in the PLATFORM.DLL. It is called before any attempt to access the flash memory. Actions typically performed by this function include:

Map flash device into memory

Disable Cache, Shadowing and Power management

Flush Cache

Disable PCI bridge

Enable ROM for write (VPP on)

Most platforms require that a jumper is changed before the pan can be enabled for flashing. EnableFlashO procedure must verify that this jumper has been removed and return an error code if it was determined that jumper settings are incorrect. See Appendix B for error codes.

3.4.2 Function DIsableFlashQ

Entry: None

Returns: Error code (or zero)

This optional function is called after the last block has been programmed (or error was detected). It will be called immediately before PHLASHNT.EXE exits (typically as a last call before re-boot). It should perform all functions necessary to be able to clεaniv re- 19796

Phoβnis..* ,-i: ASH - Flash ROM Programming Utility for Windows NT Design Specification

Action typically performed by this function include: Disable ROM Write (VPP off)

3.4.3 Function BβgiπF!aab(DWORD Blockjndex)

Entry: Index of the block about to be programmed (or zero if table not used)

Exit: None

Returns: Error code (or zero)

This optional function is called by PHLASHNT.EXE immediately before the flash block is processed. It will be called for each block (found in the block table).

Actions typically performed by this function include:

Save BOOT block before it is erased

Switch from one device to another (on platfoπns with multiple devices)

Enable VHH for boot block re-program

Determine if the current block should be processed

If BeginFlashO returns nonzero, the current block will not be processed.

3.4.4 Function EndFlash(DWORD Blockjndex)

Entry: Index of the block just programmed (or zero of table not used)

Returns: Error code (or zero)

This optional function is called by PHLASHNT.EXE immediately after the flash block was processed. It will be called for each block (found in the block table).

Actions typically performed by this function include:

Restore BOOT block saved by BeginFlashO function Clean-up between programming two different devices Disable VHH if boot block was just programmed

3.4.5 Function GetBIock(bWORD Index, DWORD BufferJVddress)

Entry: Index of the block to be copied and linear address of a 64k buffer

Exit: Buffer is filled with the next block of existing BIOS ROM image

Returns: Negative error code, zero, or positive block index 99/19796

PhoenlxPHLASH » Flash ROM Programming Utility for Windows NT Daalgn Specification

This optional function is called by PHLASHNTJΞXE whenever the /BACKUP flag is specified. GetBlockO is used to assist when saving the existing content of the flash memory before the flash memory is changed. Because many BIOS images are decompressed into shadow RAM, it is not always possible for PHLASHNT 3GE to access all of the BIOS ROM image without platform dependent system setup. Function GetBlockO is necessary to allow for platform dependent accessing of the existing BIOS ROM image. BIOS ROM image is saved by PHLASHNT.EXE using the following steps:

1) Call GetBlock(Index, Buffer) with Index set to 0 and the 64k buffer, pointed to by the parameter Buffer, filled with a pre-defined pattern. If the pattern in the buffer is not changed, program exits with error. If the pattern is changed, then the buffer is saved as the first 64k block in the BIOS.BAK. file, then program proceed to next step.

2) Call GetBlock(Index, Buffer) with Index set to the value returned by the previous call to GetBlockO, save the 64k buffer into BIOS.BAK and repeat this until the value returned by GetBlockO is a non-positive number.

3) If the last value returned by GetBlockO is zero, then proceed with flashing of the memory. If the last value returned is negative error code, report the error, delete BIOS.BAK and exit.

It is the responsibility of the GetBlockO implementation to ensure that the platform is in a proper state to allow the GetBlockO to copy BIOS ROM image into the buffer and that the platform is restored to the original mode before GetBlockO returns control to PHLASHNT.EXE. In particular, GetBlockO is called before a call is made to EnableFlashO- The buffer pointer passed to GetBlockO is always in the real memory range below 640k, to allow direct transfer to disk.

3.4.6 Function CmdLIne(charfar 'βzOptions)

Entry: Pointer to a string with the platform specific command line options

Returns: Error code (or zero)

This optional function is called by PHLASHNT.EXE immediately after the PLATFORM.DLL was read in. It is passed the address of the string containing al! the platform specific command line parameters (specified after the equal sign with /PLATFORM="..." command line option). The string includes the leading and trailing double quotes, if any.

3.4.7 Function AutoSenseO

Entry: Manufacturer and device IDs retrieved from PLATFORM.INI header

Returns: New ID retrieved from the flash part (or zero) Phoen-xPHU . « - Flash ROM Pro r ■..^•jning Utility for Windows NT Design Specmcation

This function is called by PHLASHNT.EXE immediately after EnableFlashO function in the PLATFORM.DLL was called. The AutoSenseO function enables auto detection of memory flash parts when "non-standard" memory organization is used for the flash memory. For example when two separate parts are used for even and odd BIOS addresses (in which case the conventional auto detect mechanism will fail), this function can be used to obtain and verify ID for each of the parts.

IDs are one byte long and are packed into a DWORD, with manufacturer ID in BYTE 0 and device ID in BYTE 1.

3.4.8 Function lsFiashable(char far *szErrorMsg)

Entry: Pointer to string to contain returned error message.

Exit* szErrorMsg containing error message string.

Returns: Eiror code (or zero)

This optional function is called before EnableFlashO to determine if it is ok to proceed. If the function returns a nonzero error code, the string szErrorMsg is dϋspiayed and the program terminates. Up to 254 bytes plus a terminating NULL may be returned in szErrorMsg.

An example of how this might be used is: for the same platform, an OEM sells a system with and without Plug and Play capabilities. The IsFlashableO f nction can determine if the system currently has Plug and Play and will not flash a Plug and Play BIOS on a platform that doesn't already have it.

3.4.9 Function RebootQ

Entry: None.

Returns: None.

This optional function is called after programming is complete to reset the system. If provided, this is called instead of PHLASHNPs own reboot code.

3.4.10 Function CheckSumQ

Entry: None.

Returns: Error code (or zero)

This optional function is called before programming to determine if the checksum of the BIOS ROM image is correct. Normally, the BIOS ROM image checksum for a NuBIOS image is zero. This routine may be used to provide an altemative checksum verification method when it is known that the ROM image checksum will not be zero. If this function returns non-zero, PHLASHNT will terminate.

3.4.11 Function GatBIOSFileSizeO

Entry: None.

Returns: Size of BIOS image 99/19796

PhoanlxPH ASH - Ftash ROM Programming Utility for Windows NT Design Specification

This function returns the contents of the global variable .^'.dwFileSize from PLATFORM.DLL.

3.4.12 Function Get anufactlD()

Entry: None.

Returns: Manufacturer ID

This function returns the contents of the global variable bManufactID from PLATFORM.DLL.

3.4.13 Function GetPartJD()

Entry: None.

Returns: Part ID

This function returns the contents of the global variable bPartID from PLATFORM.DLL.

3.4.14 Function GβtFIags()

Entry: None.

Returns: option flags

This function returns the contents of the global variable dwFlags from PLATFORM.DLL.

3.4.15 Function GetlmageBufO

Entry: None.

Returns: Location of Image Bufffer

This function returns the contents of the global variable dwImagcBuf from PLATFORM.DLL.

3.4.16 Function GetMfglDAddr()

"Entry: None.

Returns: Address where Manufacturer ID is located

This function returns the contents of the global variable dwMfglDAddr from PLATFORM.DLL. /19796

P_hoβnixPh-_*SH - Flaah ROM Programming Utility for Wtricwa NT Design Specification

3.4.17 Function GetPartlDAddr()

Entry: None.

Returns: Address where Part ID is located

_*

This function returns the contents of the global variable dwPartlDAddr from PLATFORM.DLL.

3.4.18 Function GβtRetryCount()

Entry: None.

Returns: Number of times to retry flashing if failure occurs

This function returns the contents of the global variable bRetryCount from PLATFORM.DLL.

3.4.19 Function GetblockTablβSizeO

Entry: None.

Returns: Number of blocks in blockTable

This function returns the contents of the global variable bblockTableSize from PLATFORMJDLL.

3.4.20 Function GetpartTypeβSlzeO

Entry: None.

Retums: Number of additional flash parts that PLATFORM.DLL will describe

This function retums the contents of the global variable bpaπTypesSize from PLATFORM.DLL.

3.4.21 Function GetBJockTable()

Entry: None.

Returns: address of blockTable

This function retums the address of the global structure blockTable from -PLATFORM.DLL. PhosnixPHLASH - Flaah ROM Programming Utility for Windows NT Design Specification

3.4.22 Function GetpartTypeβ()

Entry: None.

Returns: address of partTypes

This function returns the address of the global structure partTypes from PLATFORM.DLL.

3.4.23 Function GatDLLVersionO

Entry: None.

Returns: Version of PLATFORM -DLL

This function retums the contents of the global variable szVersion from PLATFORM.DLL.

3.4.24 Function GetROMFHeNameQ

Entry: None.

Returns: Name of BIOS ROM file

This fimction returns the contents of the global variable szROMFiieNamc from PLATFORM.DLL.

3.4.25 Function GetDLLFuncDβflne()

Entry: None.

Returns: Indicates what platform-dependent functions are defined in PLATFORM DLL

This function retums the contents of the global variable dwDLLFuncDefine from PLATFORM.DLL.

19796

PrtoanlxPHtASH - Flaah ROM Programming Utility for Windowa NT Design Specification

4.0 BIOS.ROM Detail

The ROM image file size must be large enough to contain all blocks in the flash device(s) to be programmed. Any required post-processing of the BIOS image, such as boot block swapping or data compression, must be already incorporated into the ROM image file.

PhoanlxPHLASH - Flash ROM Programming Utility for Windows NT Design _SBMWatiHI,

5.0 General Implementation Guidelines

Programs will be developed using Microsoft Visual C++, V4.2 or later:

AppendixBI -Future enhancements

Completion Codes with Keyboard LEDs

If the program fails to complete any of the _thr~ _«„•_«-. -.

CAPS NUM, SCROI ^ J^ ptataum NUM ?! ^re P^iatfωm nut none After platform init Successful completion

/19796

PhoanixPHLASH - Rash ROM Programming Utility for Windowa NT Design Specification

Appendix B2-PHLASHNT.H Completion and error codes

FFh Memory alloc for BIOS.BA buffer foiled

FEh BIOS.BAK already exists (rename or delete it)

FDh File Create failed on BIOS.BAK

FCh File Write feiled on BIOS.BAK

FBh File Close failed on BIOS AK

FAh BIOS backup not supported in PLATFORM.DLL

F9h File Open fa-Jed on PLATFORM.DLL

F8h File Read failed on PLATFORM JDLL

F7h Ffle Close failed on PLATFORM.DLL

F6h Failed to locate signature bytes in PLATFORMDLL

F5h Unsupported PLATFORM DLL file version

F2h Device table in PLATFORMDLL has too many entries

Flh Device table in PLATFORM.DLL has unsupported flash type

FOh Combined SAVE or RESTORE attributes in PLATFORM.DLL

EFh SAVE block without matching RESTORE block in PLATFORM.DLL

ECh Part ID not found in table of supported parts

EBh PLATFORM.DLL found errors m command line parameters

EAh Alloc for BIOS ROM image failed

E9h Open failed on BIOS ROM image file

E8h Read failed on BIOS ROM image file

E6h File Close failed on BIOS.ROM

E4h Attempt to read flash memory ID failed

E3h PLATFORM.DLL tailed to return flash memory ID

E2h Could not find BCPSYS block in BIOS ROM file image

E 1 h File does not contain the same BIOS part number

EOh File does not contain different version of BIOS ROM image

DFh Data wrinen to flash does not match BIOS ROM image

DEh Write to flash memory feiled

DDh Erase flash memory block failed

DCh VPP is not at expected level

DBh Erase sequence failed

DAh New DMI string is too large

D9h The BIOS ROM file may not be used with this system

D8h Alloc for DMI OEM string failed

D7h No space for the specified DMI OEM string in the BIOS ROM

D6h DMI OEM strings not supported (BCPDMI 0.1 + required)

D5h Could not find BCPDMI block in BIOS ROM file image

D3h BIOS ROM file may be corrupt (checksum not zero)

D2h BIOS ROM file size doesn't match flash part size

Dlh DMI system and chassis strings require BCPDMI 2.1+ 9/19796

PhoanixPHLASH - Flaah ROM Programming Utility for Windowa NT Deaign Specification

AppendixB3-PLATF0R .DLL Sample source code

PLATFORM.CPP

TITLE PIATrORM.CPP - 32-Bit DLL to provide platform dependent functionality to PHLASHNT.EXE

* Copyright (c) 1997 by Phoenix Technologies. Ltd.. All Rights Raaβrved.

• Phoenix Technologies Ltd. COHΓIDEHTIA .

* rileneunβ : PLATFORM.CPP

*

* Project: PHLASHNT.EXE

* Functional Block:

Comments : The vβriaBla dwDLLruπcoβ inβ la used in PHLASHHT to determine what plβtϊorn specific functions in PLATFORM.DLL have been defined. Listed below are the poeaible value* of tfwDU.rvuicOef-.ne and what functions they Indicate are defined In this module:

DLL EHABLEfASH Enablerlash

ΠLITDISABLEΠASH DiβaώleFlash DUTBEGINΓLASH BeginFlash DLL E DΠASK EndFlaah DLL 5ETBL0CK βetBloek DLL CHDLIKE CadLine DLL~AUTOSE»SE AυtoSanae

DLlZ∑FIA≤HABLE XaFlaahablβ

DL -R£BOOT Reboot

DLL~CHECK3UH Checksum

♦ coneents:

* Version Control Information:

« SLog: K:/n->/arehiv«/nutools/phlash.nt/atage2/drivers/platfor».cpv $

• Rev 1.0

* Initial reviaion.

♦include "stβafx.h" ♦include <afxdllx.h>

♦include <atdio.h>

♦include "D: \NUT0OLS\PHLASH.KT\STACE2\phXae-mt.h"

♦define PLATrORM CPP / —

// Global variable Declarations

//

DWORD dwfileSlze ■ 0x00040000. // ROM image file site BYTE bNanufactiD a 0xβ9; // Manufacturer of flash device arrr bPar iD • OxBD; // Part ID of flaeb device

// Option flags DWORD dwrlags •» πAC_B-^,05PARTKUM I F1AG_CKECKSUM | TLAC IKAGESIZE; DWORD dwlmsgeβuf • 0x00200000; // linear addreaa of image buffer WORD dwMfglDAddr - OxrrrtOOOO; // Linear address of ri ID 9/19796

PhoanixPHLASH - Flaah ROM Programming Utility for Windowa NT Design Specification

DWORD d part DAddr - OxFFFEOOOl; // Linear addrass of part ID

BYTE bRβtrycount - 0; // Count for /Rn option (default - 0) char asVersiond - "RT 1.00*7 // nj.rroim.OLL version •-• char sxRCMFileH-u-*(J - 'BIOS.ROM"; // Mama of BIOS image file

// Indicates what funeeiona are defined in PLATFORM.DLL

DWORD dwDLLFuncDefine DLL EKABLEFLASH I

DLL~DISABLEΠA3H

DLL^'BCSIHΠASH

DLL^'EHDΠASB LL^'SETBLOCX

DUTCHDLΣHE

DLL~AσTOSEHSE

DLL^'ISFXASHABLE DLL REBOOT DLL^'CHECKSOH ;

// define blockTable //

BYTE bblockTableSize 5; // number of blocks in blockrable BLOCK_DEflCRIPT0R blockTable (3

(

128 * 1024, It 128KB (Low) 0, // File offset

OXFFΓEOOOO, // Linear addrass of flash ROM o, // KfglD (same as default) o. // PartlD (same as default)

ATTR ZERO ) , ~

<

12B • 1024, // 128KB (High) 0x00020000, // File offset

OXFΓXOOOO, // Linear addrass of flash ROM

0. // HfglD (sane as default)

0. // PartlD (same as default)

ATTR ZERO

>,

(

128 • 1024, // 128KB (Low) 0, // Tile offset

OXΓFΓEOOOO, // Linear address of flasn ROM o, // HfglD ItMiu as default) o, // PartlD (a m* as default)

ATTR ERASE

(

128 • 1024, // 128KB (Low)

0. // File offset

OxFFFEOOOO, // Linear addresa of flash ROM

0. // MfgID (same aa default)

0, // PartlD (same aa default)

ATTR PROS

>,

(

128 • 1024, // 128KB (ttigh)

0x00020000, // File offset

OxFFFEOOOO, // Linear addrass of flash ROM

0, // MfgID (same as default)

0, // PartlD (aa e as default)

ATTR PROS

)/ ~

( // Heed to terminate blockTable with

0, // a block set to 0. 0, 0, o, o. 99/19796

Phi ..-.nixPHL-wSH - Flaah ROM Programming Utility for Windowa NT Deaign Specification

);

// m. ■

// define partTypes //

BYTE bpartTypesSlze • // number of flash parts on platform // Sat to 0 if partTypes la not υaedl

DEVICETASLE parcTypea() (

{

0x89, // Manufacturer ID of flaah device

OxBD, // Device to of flash device

1. // Flashing algorithm type

0, // IGNORE wpartsixe

^•Intel 2BF020" // (lame of flaah device

),

( // Bead to terminate partTypes with

0, // a block eat to 0.

0,

0,

0.

);

HIHSTAKCE hKeεnβl32 - 0; // NOTE: Do NOT change this line of code.

Functions

* Function name: DllMain

• Daacziption:

* Parameters:

• Returns:

• Notes: DO NOT HODirr THIS FUHCTIOH βxtern "C" int APIEHTRY

DllMain (HINSTANCE hinstance. DWORD dwReason. LPVOID IpRsservedi

( if (dwReason — DLL PROCESS ATTACH) (

TRACEO (-PIATFORH.DLL B«gin!\n">; hκerne!32 - LoadLlbtaryt "Kernel32.Dll" ); // Get Handle to Kernel32.Dll else if (dwReason DLL PROCESS DETACH)

(

TRACEO ("PLATFORM.DLL Terminating! \n") ; it (hκβrnel32)

FreβLlbraryt hKβrnal32 );

) return 1; // ok

} // DllMain ()

. /.......--.-...

^" * Function Mama: EnableFlash

• Description:

* Parameters! 9/19796

PhoenlxPHLASH - Fiaah ROM Programming Utility for Windows NT Design Specification

* Returns:

«

• Hotes:

DLL FUNC TYPE void Enableriaβh() ( print ("EnablβFlashVn"); // (stub)

> Function Name: Dlsableriash

•

* Description:

* Parameters:

• Returns:

*

• Motes:

DLL F-TNC TYPE void DisabiβFlash< ) ( prxntf ("DiaaJblβFlaaiΛn"); // (stub)

• runcεlon Kama: Bagxnriaah

»

• Description:

^• Parameters:

• Returns:

#

• Notes:

DLL_rCNC_TYP£ short BeginFlashl ϋSHORT bloekNu ber )

( return 0; // (stub)

• Function Name: εndrlaah

*

^« Description:

• Parameters:

• Returns:

*

• Notes:

DLL rcTNC TYPE short EndTlaahl USHORT blockUumnβr ) ( return 0; // (stub)

^■ rune ion Name: GetBloek

•

• Daacription:

• Parameters: ' * Returns:

• Notes;

DLL ΓDNC TYPE SHORT GetBloc l OLONG dwindex, PDLONG dwoβt )

( 99/19796

PhoenlxPHLASH - Fiaah ROM Programming Utility for Windowa NT Design Specification

prlncf CGetBlock: dwindex, wDst passed in»»d, %d\n", dwindex, dwost ) / // (stub₎ raturn 0;

)

•

■ Function Kama: CmdLlne

•

* Description:

* Parameters:

* Returns:

•

* Notes:

*

DLL rutJC TYPE DSHORT CαdLina t char •Platformstring ) { print (-CmdLinβVn*) ; // (stub) return ( 0 ) ; // (stub)

) /** ••••--.•-.... .-.-........,.......*..-....*.»..*.. ........

#

^» Function Masta: AuteSense

*

* Description:

* Paramatara :

* Returns:

»

* Notes:

* The manufacturer ID is in BYTE 0 and device ID in BYTE 1

DLL ruNC TYPE DWORD AutoSβniaC CHORD PartMfgZD ) i return! 0x0000 ); // (stub)

) /............ ♦ ...... ...........

*

* Function Ka e: Isrlashable

*

* Daecrlption:

* Parameters:

* Returns:

»

* Notes:

•

0LL tWC TYPE DSHORT Iβriashablβ ( ) ( print f CIsFlashablβ n" ) ; // (stub) return 0;

) /••••••»•*••*• **^♦•♦ ......... ..............

•

* function Name: Reboot

*

* Description:

* Parameters: " Returns:

•

* netas:

DLL ΓTOC TYPE void Reboo () ( ^" prlntf

// (stub) ) 99/19796

PhoenlxPHLASH - Flash ROM Programming Utility for Windowa NT Deaign Specification

* function Namar Checksum

•

* Description:

* Parametera:

* Returns: ψ

* Motes:

DLL rσMC TYPE void Checksum() ( prints("Chβcksus n"I / // (stub)

/ // NOTE) DO NOT MODIFY THE FUNCTIONS LISTED BELOW. //

DLL rvnc TYPE DWORD Getaxαsrllesise(void) ( return(dwFilaSiiβ); ) DLL^" πic TYPE BYTE OatHaaufactID(void) ( return(bManutactlD) ; 1 DLL FDNC^' TYPE BYTE GetPβrtlD(void) ( return(bPartlD) ; } DLL^" FCNC TYPE DWORD GetFlaga (void) { return(dwriagβ); ) DLL FUNC TYPE DWORD CetXmageauf(void) ( return(dwImageBuf); ) DLL^{" '}FDNC TYPE DWORD CβtM gIDAdd (void) ( return (dwMfglDAddr) ; ) DLL ^'FDHC TYPE DWORD GaePartlOλddr(void) { rβturn(dwpartΙDAddr); ) DLL^" FϋNC ^'TYPE BYTE GatRatryCβunt (void) ( return(bRβtryCount); ) DLL^" ΓUNC TYPE BYTE GatblockTahleSise(void) ( retur (bblockTableSize) ; ) DLL^"'ΓDNC^' TYPE BYTE GetpartTypesSiza (void) ( return (bpartTypβsSize); ) DLL'^'ΠJNC^' TYPE BLOCK DESCRIPTOR *GetBloekTabla(void) ( return UblockTabl (0) ) ; DLL^" FONC TYPE DCVICETASLE "CatpartTypae (void) ( return (-partTypes (0) ) ) DLL ^'ΠINC TYPE char *βetDLLVera-.on(void) ( return (sxVersion) ; ) DLL^*'rtwc TYPE char •GetxθMrileName(void) ( return (ssROMFilaNaaa); ) DLL^"'FDNC^' TYPE DWORD GβtDLLF--ncDβflae(vold) ( return (dwDLLFυncoefine) ; )

Appendix

Abstract: This paper presents a proposal for a new BIOS service, which will be known as the BIOS32 Service Directory. The new service will provide information about those services in d e BIOS that are designed for callers running in a 32-bit code segment. (The BIOS32 Service Directory will itself be a 32-bit BIOS service.) The expected clients of mis service are 32-bit operating systems and 32-bit device drivers. The expected providers of this service are BIOS vendors thai implement one or more 32-bit BIOS services.

Introduction

benefits which Ξ £i ^βn™ⁿ« dements, etc., are a few

The BIOS32 Service Direc^toiy has two components: the Header and _th_{e Call .}„.

^tx-plemcnt-rs alike _to easily addnc SZ-b oS^ces ,^⁰^^^^ Standard BIOS 32-bit Service Directory

Interface to the BIOS32 Service Directory, and a summary w_t*h _iTam .

The BIOS32 Service Directory Header

A BIOS which implements the BIOS32 Service Dirεαorv mus_{t ««■}, _A •*

IT.- Header is comprised of six distinct fields. Tie following able describes each field.

O 99/19796

Standard BIOS 32-bit Service Directory

The BIOS32 Service Directory Calling Interface

If the BIOS32 Service Directory existence has been determined (via the Header test- above) then the 32-bit physical address found in the Header can be used as the entry point to the Calling Interface. Clients should CALL FAR to this address. The client's raiting environment has the following requirements.

3.1 Code Segment

The CS code segment selector must be set up with a segment descriptor with the following values:

• The base address must be less than or equal to the (4kb) page address of the page that contains the entry point For example, if the entry point is 0FFF81234h then the base address must be less than or equal to 0FFF81000h.

• The limit must be such that the base address plus the limit generate an address that is greater than or equal to the last address on the (4kb) page which follows the page containing the entry point For example, if the entry point is 0 FF81234h then the base address plus the limit must be greater than or equal to 0FFF82FFFh.

Simply stated, the base address and the limit must "encompass" both the page that contains the entry point and the following page.

• The segment type must be 100b (code, execute only) or 101b (code, execute/read). However, the implemεntors of the Service Directory cannot assume read access to the CS code segment.

The system bit must be 1 (no system segment).

It is recommended that the Descriptor Privilege Level (DPL) be 0. (The CS descriptor DPL becomes the Current Privilege Level, or CPL). If the CPL is not 0, then the OS must provide trapping and virtualization services for ring 0 privileged instructions (such as those that access CRx). Note also the dependency of this field on the IOPL field in EFLAGS (see Section

0).

The Default Size bit must be 1 (32 bits).

The BIOS32 Service Directory entry point, and its associated code and data, may be located anywhere within the 4Gb physical address space. However, h is guaranteed to be physically contiguous (i.e„ it will be delivered in ROM or FLASH space) and to fit within two pages (i.e., it will not span three pages). Standard BIOS 32-bit Service Dirarrnr.-

3.2 Data Segments

2^ 35^* " ^{sdECtor m t be sπ} * "* ^{a sesmω} *^«*^« ™* ».

The base address must be equal to the CS base address

"

There are no requirements concerning the ES, FS, and GS da_ta segmen_t selectors.

3.3 Stack Segment

SiSjSS™^{* S=lett0r mU*} "^β * ^UP ^ " "^^m ^-iptor -dH tbe

^'

e ranularity bit must be 1 (4Kb).

Note that the above settings ensure a stack size of at leas_{t 4kh} i_t ._{< th}, -.,₁₁ - responsibility ^to ensure that there is at least Ikb of ^ed s^av^le * " *

!3- Standard BIOS 32-bit Service n.rartnrv

3 -4 Paging

Pagⁱng may or may not be enabled. If paging is enabled, then the address

3.5 IOPL

? ^C ^r ^{e Ca ng foterface to} ^^ ^m instructions, the I O Privileee

^d ^ϊ ^_Tf ^{kSa0TY CaUin iΩlafa} J^S * ***»« and all parameters are *Z?t £. ?^ ϊ ^WglSter * ^{n0t IpeβfiBd M tt ou}9^m P^ameter for a fimction, then ⁱt wⁱll be preserved. All flags are preserved. Function vines are p ssed ώS

OΪEΞ ^ ?- ^^ ^^ ^ ³³^ bac in register AL. A^P»tαm ≤ι55 OOh ⁱndⁱca^tes ^that ^the function was successful. A return status of 80h indica_tes ΛaTthe

£2hr£ ^^{Caθn (}^^L) * ^{n0t SUppθrted} ∞* ^ ^retum *» -HKd *e

3.6 The Component Existence Function (BL =» Oh)

w l_fr S ,^{Existeπce f}™$»^{n rctums} information about whether a specific 32-b^it BIOS service exists and, if it does, what memory space i_t occupies.

Input:

BL, 0h

EAX, Component JD

The Component ID is a 4-byte ASCII string which uni_quel_y ⁱdentⁱfies the 32-bit BIOS service. The specifications forparticular BIOS ^[ servⁱces define their own Component IDs. (tt is important that those specifications define whether the Component JD ∞mz is packed left to right, or right to left.)

EBX, Reserved, set to Oh Standard BIOS 32-bit Service Directory

Output:

If requested 32-bit service does not exist

AL = 81h If requested 32-bit service does exist

AL- Oh

EBX =^■ base address of 32-bit BIOS service

ECX = length of 32-bit BIOS service

EDX = oiBet (from EBX) of 32-bit BIOS service entry point

The meaning of the EBX, ECX, and EDX registers is dependent on the particular 32-bit BIOS service specification. That is. they may represent exact values for setting up segment selectors, minimal "encompassing" values, etc.

3.7 Future Functions

Future BIOS32 Service Directory functions may be defined in subsequent revisions of this document The function parameter interlace is not constrained to register passing and may employ input output parameters on the stack. This is feasible due to the static definition of the stack (see Section 0).

Summary

This paper describes the BIOS32 Service Directory. It identifies two distinct memory components: the Header and the Calling Interface. Tie Header is a paragraph of signature data located in the memory range OEOOOOh - OFFFFFh. The Calling Interface is a body of code that occupies a physically contiguous section of memory anywhere in the 4Gb address space and is less than two pages (8kb) in length. The Header contains a pointer into the Calling Interface memory area.

The BIOS 32 Service Directory Calling Interface functions describe additional memory areas that contain code and data for specific 32-bit BIOS services. A memory map for a hypothetical Header, Calling Interface and the "XYZ" 32-bit BIOS service follows. O 99/19796

Standard BIOS 32-bit Service Directory

UAAAAΛAUU2i^^

3 BIDS32 Service Directory

3 » 3 ffffffff■ Calling Interface

3 Coddea/Data a--fffff>

3—

3

"XYT 32-bit BIOS Serrtce Code/Data

. ^3 ffffffffa

*' EOOOOh

OOOOh

This paper provides for a standard method of accessing 32-bit BIOS services. The extensibility of the BIOS32 Service Directory Calling Interface may be used easily to advance a standard method as new 32-bit BIOS services are recognized and implemented.

#ifdef TESTEXEC

// test bios execute function. printf {'phadtest - test bios execution breakpoint\n*) ; ioExec = (PIOC_EXECl)systemBuffer; ioExec->biosFunction = biosShadowAreaBaseVA + biosServiceDirectoryVA; strncpy ( (PUCHAR) (&ioExec->regEAX) , BIOS_PM_SIGNATURE..4) ; ioExec->regEBX = OL; if (DeviceloControl.hDriver, IOCTL_BIOS_EXEC. bufferPtr, 256, bufferPtr, 256. fcactualXfr, NULL)) { printf ("IOCTL 2052 -BIOS Execute ⁽%s⁾ - success\n" , BIOS_PM_SIGNATURE) ; printf ("It b ces returned: %Ld\n^u , actualXfr⁾ ; printf ("Register contents: \n" ⁾ ; printf ("AL = %X\n" , (ioExec->regEAX ⁾ S. Oxff) ; printf ("EBX = %LX\n" , ioExec->regEBX ⁾ printf ("ECX = %LX\n" , ioExec->regECX ⁾ printf ("EDX = %LX\n" , ioExec->regEDX ⁾

}else{ ioCode = GecLastError O ; princf ( " IOCTL 2050 failed on %LX\n" , ioCode⁾ ;

rtendif

Appendix Dl

57- / / case IOCTL_BIOS_EXEC.

#if ef DEBUGMZ

MzIoKdPrint (4}> ♦βndif

.

// The functⁱon executes code in the shadow area. ioExecBios ^{» (}PIOCEXECD ⁽Ixp->AaseciatedIrp.Sy₈te Buff er₎ ,

// check the range of the requested function. actualxfrd = rangeCheck ⁽ioExecBios^biosFunction, // _{funccion addχeas}.

M KODEi sSrαnSn?w- ^/ ;^;; ^o iⁿt^^{ly look c β}-.°-

. // lengthnof -r-om.sp BaIcOeS..

// failed range check, if ⁽actualxfrd « o) { return ⁽loCtlFinish ⁽Irp, STATOS.ACCESΞ.DENIED. sizeof ₍IOC_EX-.CU_{) ) ;} )

/ now execute the function.

execflios ⁽ioExecBios, j.oi-xecBios->biosFunction> _; ioExecBios->runStat = ι_; return ⁽ loCtlFinishdrp, STATUS.SUCCTSS. sizeof (IOC.EXECD_{) ) •} ^il don't forget to return exec struct.. / /

Appendix D2

U «ϊy^£SS?^{n Crea}"^{S * rβgiStβr C}°^atext: "* ^«"^■ *• void execBios (

PI0C_EXEC1 βysteabuffer, ULONG enerypoinε

{

♦ifdef BIOS_FAR_CALL void ⁽fax *address32) (PIOC_EXECl) ,• ♦else void ⁽*address32) (PIOC_EXECl) ; ♦endif

^•address32 = ⁽void ^{(•) (}PI0C- -XΞC1) ) entrypoint_; —asm (

^h^βaX'e«^YSteabUffarl „ " ^{tr C}° "» ^" "b ffer ^U*^h =^s // πiake it a FAR call _j call taddres_S 21 // call to the Serive Directory

II ^(*addrεss32) (svsteabuf f er) • // »ι- • ^γ "^βrl ' " Chis is service interface.

)

Appendix D3

Claims

CLAIMS : What is claimed is :

1. An apparatus for accessing and executing instruction sequences in a physical memory from a virtual memory in a processor-based system, comprising:

a memory for storing instruction sequences by which the processor-based system is processed, the memory including a physical memory and a virtual memory; and

a processor for executing the stored instruction sequences; and

wherein the stored instruction sequences include process steps to cause the processor to: (a) map a plurality of predetermined instruction sequences from the physical memory to the virtual memory; (b) determine an offset to one of said plurality of predetermined instruction sequences in the virtual memory; (c) receive an instruction to execute the one of said plurality of predetermined instruction sequences; (d) transfer control to the one of said plurality of predetermined instruction sequences; and (e) process the one of said plurality of predetermined instruction sequences from the virtual memory.

2. The apparatus of Claim 1, wherein in step (c) , the instruction is made from an application program.

3. The apparatus of Claim 1, wherein in step (c) , the instruction is made from a class driver.

4. The apparatus of Claim 1, wherein step (a) comprises the steps of:

(a.l) mapping a plurality of BIOS instruction sequences from the physical memory to the virtual memory, said BIOS instruction sequences including a BIOS service directory; and

(a.2) mapping BIOS data from the physical memory to the virtual memory.

5. The apparatus of Claim 4, wherein step (b) comprises the steps of:

(b.l) determining a starting virtual address of the BIOS service directory; and

(b.2) determining a starting virtual address of one of the plurality of BIOS instruction sequences by reference to the BIOS service directory.

6. The apparatus of Claim 5, wherein step (d) comprises the steps of:

(d.l) creating a register stack in a memory location;

(d.2) identifying a location of the starting virtual address of one of the plurality of BIOS instruction sequences in the register stack; and

(d.3) transferring control to the one of the plurality of BIOS instruction sequences.

7. The apparatus of Claim 6, wherein in step (d.l), the memory location is a buffer located in a dynamic random access memory (DRAM) .

8. The apparatus of Claim 6, wherein in step (d.l), the memory location is a buffer located in a main memory.

9. The apparatus of Claim 6, wherein step (e) comprises the steps of: (e.l) determining if the starting virtual address is within a range of addresses mapped from the physical memory to the virtual memory; and

(e.2) if so, executing the one of the plurality of BIOS instruction sequences from the virtual memory, otherwise indicating that the starting virtual address is not within the range of addresses mapped from the physical memory to the virtual memory.

10. A method for accessing and executing instruction sequences in physical memory from virtual memory in a processor- based system, comprising the steps of:

(a) mapping a plurality of predetermined instruction sequences from the physical memory to the virtual memory;

(b) determining an offset to one of said plurality of predetermined instruction sequences in the virtual memory;

(c) receiving an instruction to execute the one of said plurality of predetermined instruction sequences;

(d) transferring control to the one of said plurality of predetermined instruction sequences; and

(e) processing the one of said plurality of predetermined instruction sequences from the virtual memory.

11. The method of Claim 10, wherein in step (c) , the instruction is made from an application program.

12. The method of Claim 10, wherein in step (c) , the instruction is made from a class driver.

13. The method of Claim 10, wherein step (a) comprises the steps of:

(a.l) mapping a plurality of BIOS instruction sequences from the physical memory to the virtual memory, said BIOS instruction sequences including a BIOS service directory; and

(a.2) mapping BIOS data from the physical memory to the virtual memory.

14. The method of Claim 13, wherein step (b) comprises the steps of:

(b.l) determining a starting virtual address of the BIOS service directory; and (b.2) determining a starting virtual address of one of the plurality of BIOS instruction sequences by reference to the BIOS service directory.

15. The method of Claim 14, wherein step (d) comprises the steps of:

(d.l) creating a register stack in a memory location;

(d.2) identifying a location of the starting virtual address of one of the plurality of BIOS instruction sequences in the register stack; and

(d.3) transferring control to the one of the plurality of BIOS instruction sequences.

16. The method of Claim 15, wherein in step (d.l), the memory location is a buffer located in a dynamic random access memory (DRAM) .

17. The method of Claim 15, wherein in step (d.l), the memory location is a buffer located in a main memory.

18. The method of Claim 15, wherein step (e) comprises the steps of:

(e.l) determining if the starting virtual address i LSε within a range of addresses mapped from the physical memory to the virtual memory; and

(e.2) if so, executing the one of the plurality of BIOS instruction sequences from the virtual memory, otherwise indicating that the starting virtual address is not within the range of addresses mapped from the physical memory to the virtual memory.

19. Computer-executable process steps for accessing and executing instruction sequences in physical memory from virtual memory in a processor-based system, the process steps including:

(a) mapping a plurality of predetermined instruction sequences from the physical memory to the virtual memory;

(b) determining an offset to one of said plurality of predetermined instruction sequences in the virtual memory;

(c) receiving an instruction to execute the one of said plurality of predetermined instruction sequences; (d) transferring control to the one of said plurality of predetermined instruction sequences; and

(e) processing the one of said plurality of predetermined instruction sequences from the virtual memory.

20. Computer-executable process steps of Claim 19, wherein in step (c) , the instruction is made from an application program.

21. Computer-executable process steps of Claim 19, wherein step (a) comprises the steps of:

(a.l) mapping a plurality of BIOS instruction sequences from the physical memory to the virtual memory, said BIOS instruction sequences including a BIOS service directory; and

(a.2) mapping BIOS data from the physical memory to the virtual memory.

22. Computer-executable process steps of Claim 21, wherein step (b) comprises the steps of:

(b.l) determining a starting virtual address of the BIOS service directory; and (b.2) determining a starting virtual address of one of the plurality of BIOS instruction sequences by reference to the BIOS service directory.

23. Computer-executable process steps of Claim 22, wherein step (d) comprises the steps of:

(d.l) creating a register stack in a memory location;

(d.2) identifying a location of the starting virtual address of one of the plurality of BIOS instruction sequences in the register stack; and

(d.3) transferring control to the one of the plurality of BIOS instruction sequences .

24. Computer-executable process steps of Claim 23, wherein in step (d.l), the memory location is a buffer located in a dynamic random access memory (DRAM) .

25. Computer-executable process steps in Claim 23, wherein in step (d.l), the memory location is a buffer located in a main memory.

26. Computer-executable process steps of Claim 23, wherein step (e) comprises the steps of:

(e.l) determining if the starting virtual address is within a range of addresses mapped from the physical memory to the virtual memory; and

(e.2) if so, executing the one of the plurality of BIOS instruction sequences from the virtual memory, otherwise that the starting virtual address is not within the range of addresses mapped from the physical memory to the virtual memory.

27. An apparatus for accessing instruction sequences in a physical memory from a virtual memory in a processor-based system, comprising:

. a memory for storing instruction sequences by which the processor-based system is processed, the memory including a physical memory and a virtual memory; and

a processor for executing the stored instruction sequences ; and

wherein the stored instruction sequences include process steps to cause the processor to: (a) map a plurality of predetermined instruction sequences from the physical memory to the virtual memory; (b) determine an offset to one of said plurality of predetermined instruction sequences in the virtual memory; (c) receive an instruction to execute the one of said plurality of predetermined instruction sequences; (d) transfer control to the one of said plurality of predetermined instruction sequences; and (e) process the one of said plurality of predetermined instruction sequences from the virtual memory.

28. The apparatus of Claim 27, wherein step (a) comprises the steps of:

(a.l) mapping a plurality of BIOS instruction sequences from the physical memory to the virtual memory, said BIOS instruction sequences including a plurality of BIOS read only memory (ROM) instruction sequences and a BIOS service directory; and

(a.2) mapping BIOS data from the physical memory to the virtual memory.

29. The apparatus of Claim 28, wherein step (b) comprises the steps of:

(b.l) determining a starting virtual address of the BIOS service directory; and (b.2) determining a starting virtual address of one of the plurality of BIOS instruction sequences by reference to the BIOS service directory.

30. The apparatus of Claim 29, wherein step (d) comprises the steps of:

(d.l) creating a register stack in a memory location and;

(d.2) identifying a location of the starting virtual address of one of the plurality of BIOS ROM instruction sequences in the register stack.

31. The apparatus of Claim 30, wherein step (e) comprises the steps of:

(e.l) determining if the starting virtual address is within a range of addresses mapped from the physical memory to the virtual memory; and

(e.2) if so, reading the one of the plurality of BIOS ROM instruction sequences from the virtual memory, otherwise indicating that the starting virtual address is not within the range of addresses mapped from the physical memory to the virtual memory.

32. A method for accessing instruction sequences in physical memory from virtual memory in a processor-based system, comprising the steps of:

(a) mapping a plurality of predetermined instruction sequences from the physical memory to the virtual memory;

(b) determining an offset to one of said plurality of predetermined instruction sequences in the virtual memory;

(c) receiving an instruction to execute the one of said plurality of predetermined instruction sequences;

(d) transferring control to the one of said plurality of predetermined instruction sequences; and

(e) processing the one of said plurality of predetermined instruction sequences from the virtual memory.

33. The method of Claim 32, wherein step (a) comprises the steps of:

(a.l) mapping a plurality of BIOS instruction sequences from the physical memory to the virtual memory, said BIOS instruction sequences including a plurality of BIOS read only memory (ROM) instruction sequences and a BIOS service directory; and (a.2) mapping BIOS data from the physical memory to the virtual memory.

34. The method of Claim 33, wherein step (b) comprises the steps of:

(b.l) determining a starting virtual address of the BIOS service directory; and

(b.2) determining a starting virtual address of one of the plurality of BIOS instruction sequences by reference to the BIOS service directory.

35. The method of Claim 34, wherein step (d) comprises the steps of:

(d.l) creating a register stack in a memory location; and

(d.2) identifying a location of the starting virtual address of one of the plurality of BIOS ROM instruction sequences in the register stack.

36. The method of Claim 35, wherein step (e) comprises the steps of: (e.l) determining if the starting virtual address is within a range of addresses mapped from the physical memory to the virtual memory; and

(e.2) if so, reading the one of the plurality of BIOS ROM instruction sequences from the virtual memory, otherwise indicating that the starting virtual address is not within the range of addresses mapped from the physical memory to the virtual memory.