Ulllted States Patent [19]
`Datta
`
`[54] METHOD OF COMMUNICATION BETWEEN
`FIRMWARE WRITTEN FOR DIFFERENT
`INSTRUCTION SET ARCHITECTURES
`
`[75] Inventor: Sham Datta, Hillsboro, Oreg.
`
`[73] Assignee: Intel Corporation, Santa Clara, Calif.
`
`[21] APPL NO-I 09/201,350
`-
`_
`NOV‘ 30’ 1998
`[22] Flled'
`51
`Int. Cl.7 ........................... .. G06F 9/445~ G06F 9/455
`,
`52 us. Cl. ............................. .. 713 1- 713 2- 395 500.48
`[
`l
`/ ,
`/ ,
`/
`[58] Field of Search ....................... .. 395/50044, 500.47,
`39550048; 713/1, 2, 100; 703/27
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`US006081890A
`[11] Patent Number:
`[45] Date of Patent:
`
`6,081,890
`Jun. 27, 2000
`
`4,077,058
`5,388,215
`
`2/1978 Appell et a1. ......................... .. 395/712
`2/1995 Baker et a1. ..................... .. 395/500.44
`
`P '' imary Examiner—Dennis M- Butler
`Attorney, Agent, or Firm—Leo V. Novakoski
`
`[57]
`
`ABSTRACT
`
`A?rmWare system comprises a legacy ?rmware module and
`a native ?rmware module Written for native and legacy
`instruction set architectures (ISAs), respectively. A data
`structure is associated With the le ac ?rmware module to
`g y
`provide access to one Or more legacy routines through a ?rst
`dispatcher- The native ?rmware nodule includes a Prologue
`routine. The prolog routine locates the data structure asso
`ciated With the legacy ?rmware module and initialiZes it to
`provide a link betWeen the ?rst and second ?rmWare mod
`ules.
`
`3,891,974
`
`6/1975 Coulter et al. ........................ .. 395/500
`
`23 Claims, 4 Drawing Sheets
`
`208
`
`274
`
`UUU UUU UUU UUU
`
`270
`ROUTINES
`
`240
`
`204
`
`234 w
`
`244 g
`
`210
`ROUTINES
`
`1
`
`EX 1024
`IPR of Pat. No. 6,892,304
`
`

`

`U.S. Patent
`
`Jun. 27,2000
`
`Sheet 1 of4
`
`6,081,890
`
`Processo
`110(1)
`
`'
`
`'
`
`'
`
`Processor
`110m)
`
`A
`
`V
`
`120
`
`A
`
`V
`
`A
`
`7
`
`System Logic
`130
`
`System Memory
`140
`
`160
`
`A
`
`V
`
`A
`
`V
`
`peripheral
`device(1)
`180
`
`.
`.
`0 0 0 penphfsrgljggevlce
`
`A
`
`V
`
`Non-Volatile
`Memory
`170
`
`A
`
`V
`
`Fig. 1
`
`2
`
`

`

`U.S. Patent
`
`Jun. 27, 2000
`
`Sheet 2 0f 4
`
`6,081,890
`
`250
`PROLOG
`
`260
`DISPATCHER
`
`1274i
`|
`I
`1
`I
`
`II
`ll
`||
`
`1
`
`270
`ROUTINES
`
`240
`
`[I]
`
`->
`
`DS_SIZE
`
`CK_SUM
`
`230
`DATA STRUCTURE
`
`208
`
`204
`
`234
`
`220
`DISPATCHER__1
`
`210
`ROUTINES
`
`J 244
`
`Fig. 2
`
`3
`
`

`

`U.S. Patent
`
`Jun. 27, 2000
`
`Sheet 3 0f 4
`
`6,081,890
`
`334
`SELECT BSP
`
`310
`INITIATE
`PROCESSOR BOOT
`
`340
`INITIALIZE &
`ALLOCATE MEMORY
`
`V
`
`350
`LOCATE LEGACY FW
`
`7
`
`360
`COPY LEGACY FW
`TO MAIN MEMORY
`
`V
`370
`LOCATENALIDATE
`DS
`
`V
`
`380
`UPDATE DS W/
`NATIVE FW DATA
`
`1
`
`390
`INITIALIZE
`PLATFORM
`
`Fig. 3
`
`4
`
`

`

`U.S. Patent
`
`Jun. 27, 2000
`
`Sheet 4 0f4
`
`6,081,890
`
`\
`41o
`INTERRUPT?
`
`420
`JUMP TO FW2
`
`V
`
`430
`UPDATE RADD2 IN DS
`
`V
`440
`GENERATE INDEXED CALL
`FOR SELECTED ROUTINE
`
`V
`450
`ACCESS INDEXED LEGACY
`ROUTINE
`
`V
`460
`PROCESS INTERRUPT
`
`V
`
`470
`RETURN TO FW2 VIA RADD.
`
`0
`480
`END INTERRUPT
`
`Fig. 4
`
`5
`
`

`

`6,081,890
`
`10
`
`15
`
`25
`
`35
`
`1
`METHOD OF COMMUNICATION BETWEEN
`FIRMWARE WRITTEN FOR DIFFERENT
`INSTRUCTION SET ARCHITECTURES
`BACKGROUND OF THE INVENTION
`1. Technical Field
`The present invention relates to ?rmware and in particular
`to system and methods for communicating betWeen ?rm
`Ware Written for different instruction set architectures.
`2. Background Art
`FirmWare refers to processor routines that are stored in
`non-volatile memory structures such as read only memories
`(ROMs), ?ash memories, and the like. These memory struc
`tures preserve the code stored in them, even When poWer is
`shut off. One of the principle uses of ?rmWare is to provide
`the routines that control a computer system When it is
`poWered up from a shut doWn state, before volatile memory
`structures have been tested and con?gured. The process by
`Which a computer is brought to its operating state from a
`poWered doWn or poWered off state is referred to as boot
`strapping. FirmWare routines may also be used to reinitialiZe
`or recon?gure the computer system folloWing various hard
`Ware events and to handle certain platform level events like
`system interrupts.
`The bootstrapping process typically begins With the
`processor(s) in a computer system and proceeds outWard to
`system level resources. Initially, each processor tests its
`internal components and interfaces. In multiprocessor
`systems, a single bootstrap processor (BSP) is usually
`selected to handle initialiZation procedures for the system as
`a Whole. These procedures include checking the integrity of
`memory, identifying and initialiZlng other resources in the
`computer system, loading the operating system into
`memory, and initialiZing the remaining processors. Since
`volatile memory structures such as caches and random
`access memory (RAM) are not dependable until later in the
`boot process the processor implements some of its early
`?rmWare routines for the various bootstrapping procedures
`inside nonvolatile memory.
`FirmWare is typically Written in assembly language. This
`is a loW level computer language that provides direct access
`to processor hardWare and, consequently, is closely tied to
`the processor architecture. The processor architecture is
`re?ected in the rest of the platform, in part, because of the
`assembly level ?rmWare that is used to initialiZe, con?gure,
`and service platform level resources. For example, platform
`resources may transfer data through speci?ed registers and/
`or memory locations de?ned by the Instruction Set Archi
`tecture (ISA), and platform level interrupts may be handled
`by referring to speci?ed processor registers. Thus, initial
`iZation and con?guiration of platform level resources are
`tied to the ISA of the underlying processor. These ties
`betWeen assembly level ?rmWare and the ISA also mean that
`the ?rmWare can not be converted to different ISAs Without
`extensive reWriting.
`The ISA-speci?c nature of ?rmWare is signi?cant for
`processors that support more than one ISA. For example, the
`MercedTM processor is the ?rst of a line of processors
`designed by Intel® Corporation of Santa Clara, Calif. to
`implement an Intel Architecture 64-bit ISA (IA-64). These
`IA-64 processors also include resources to execute programs
`coded in an Intel Architecture 32-hit ISA (IA-32). While the
`MercedTM processor and its progeny support IA-32
`instructions, they are not IA-32 processors. Among other
`things, their register structures, memory addressing schemes
`and buses re?ect their native IA-64 architecture rather than
`the legacy IA-32 architecture.
`
`2
`The IA-64 platform is neW, and consequently, there are
`relatively feW resources designed speci?cally for the IA-64
`platform. On the other hand, there is a Wealth of resources
`available for- IA-32 platforms, including mass storage
`media controllers, keyboards, mice, monitors, peripheral
`devices, and the IA-32 ?rmWare that supports them. Huge
`investments have also been made in IA-32 ?rmWare for
`neWer technologies such as Advanced Con?guration And
`PoWer Management Interface (ACPI), Wired For Manage
`ment
`In addition, compression technology is avail
`able to signi?cantly reduce the space required to store IA-32
`?rmWare. Approximately 1 Megabyte (“Mbyte”) of ?rm
`Ware code may be compressed to approximately 512 Kilo
`bytes (Kbytes), using this IA-32 ?rmWare. Supporting these
`legacy resources and ?rmWare technologies on the IA-64
`platform Would alloW developers to preserve the invest
`ments they have already made in the IA-32 platform and
`reduce the time to market of IA-64 systems.
`Supporting legacy ?rmWare (IA-32) on a neW processor
`architecture (IA-64) is a relatively complex undertaking. For
`example, in addition to the obvious differences in register
`siZes, and addressable memory, there are multiple address
`ing modes in the IA-32 ISA that are not present in the IA-64
`ISA. IA-32 employs a mode called protected mode to
`increase the addressable memory siZe from 1 megabyte to 4
`gigabytes. The present invention addresses these and other
`issues associated With the support of legacy ?rmWare in a
`different native environment.
`
`SUMMARY OF THE INVENTION
`
`The present invention provides a system and method that
`support communications betWeen ?rmWare modules based
`on different ISAs.
`In accordance With the present invention, a system com
`prises a ?rst ?rmWare module and a second ?rmWare
`module Written for legacy and native ISAs, respectively. A
`data structure is associated With the ?rst ?rmWare module to
`provide access to one or more legacy routines through a ?rst
`dispatcher. The second ?rmWare module includes a prologue
`routine. The prolog routine locates the data structure asso
`ciated With the ?rst ?rmWare module and initialiZes it to
`provide a link betWeen the ?rst and second ?rmWare mod
`ules.
`
`45
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The present invention may be understood With reference
`to the folloWing draWings, in Which like elements are
`indicated by like numbers. These draWings are provided to
`illustrate selected embodiments of the present invention and
`are not intended to limit the scope of the invention.
`FIG. 1 is a block diagram of a computer system that
`includes a ?rmWare system in accordance With the present
`invention.
`FIG. 2 is a block diagram of a ?rmWare system stored in
`the non-volatile memory of FIG. 1.
`FIG. 3 is a ?oWchart representing a method for booting
`resources designed for a platform that implements a ?rst
`instruction set architecture on a platform designed for a
`second instruction set architecture.
`FIG. 4 is a ?oWchart representing a method for commu
`nicating betWeen ?rst and second softWare modules Written
`for ?rst and second instruction set architectures.
`
`55
`
`65
`
`DETAILED DISCUSSION OF THE INVENTION
`The folloWing discussion sets forth numerous speci?c
`details to provide a thorough understanding of the invention.
`
`6
`
`

`

`3
`However, those of ordinary skill in the art, having the bene?t
`of this disclosure, Will appreciate that the invention may be
`practiced Without these speci?c details. In addition, various
`Well-knoWn methods, procedures, components, and circuits
`have not been described in detail in order to focus attention
`on the features of the present invention.
`FIG. 1 is a block diagram of one embodiment of a
`computer system 100 that is suitable for implementing the
`present invention. The disclosed embodiment of computer
`system 100 includes one or more processors 110(1)—110(n)
`(collectively, processors 110) that are coupled to system
`logic 130 through a processor bus 120. A system memory
`140 is coupled to system logic 120 through bus 150. A
`non-volatile memory 170 and one or more peripheral
`devices 180(1)—180(j) (collectively, devices 180) are
`coupled to system logic 130 through peripheral bus 160.
`Peripheral bus 160 represents, for example, one or more
`peripheral component interconnect (PCI) buses. industry
`standard architecture (ISA) buses, extended ISA (EISA)
`buses, and comparable peripheral buses. Non-volatile
`memory 170 may be a static memory device such as a read
`only memory (ROM) or ?ash memory. Peripheral devices
`180 include, for example, a keyboard, mouse or other
`pointing devices, mass storage devices such as hard drives
`and digital video discs (DVD), a display, and the like. These
`devices, together With system logic 130 de?ne the comput
`ing platform-iii for system 100.
`For the disclosed embodiment of system 100, processors
`110 may implement a ?rst instruction set architecture (ISA),
`e.g., IA-32 and a a second ISA, e.g., IA-64. As noted above,
`IA-32 has enjoyed Widespread use and there is a signi?cant
`infrastructure in place to support IA32-based platforms. This
`infrastructure includes a large number of peripheral devices
`180 and the basic input output systems (BIOS or ?rmWare)
`necessary to boot, con?gure, and support these devices. On
`the other hand, IA-64 is a relatively neW platform and has
`correspondingly less infrastructure support.
`The present invention provides a means to support legacy
`resources, eg resources developed for the IA-32 platform,
`on a different platform, e.g. IA-64. For one embodiment,
`non-volatile memory 170 stores a hybrid ?rmWare system
`that includes ?rst and second modules for legacy and native
`platforms, respectively. A mechanism is provided to alloW
`communications betWeen the ?rst and second modules.
`FIG. 2 is an expanded block diagram of a ?rmWare system
`200, including a ?rst ?rmWare module (FWl) 2(04 and a
`second ?rmiiWar-e module (FW2) 208. The disclosed
`embodiment of FWl 204 includes one or more routines 210,
`a dispatcher 220, and a data structure 230. Data structure 230
`is tagged by an identi?er block 240 that alloWs it to be
`identi?ed and validated by FW2 208.
`Routines 210 provide ?rmWare level support for resources
`associated With the legacy platform. For example, routines
`210 may include IA-32 code sequences that initialiZe and
`con?gure keyboards, input devices, video displays or similar
`devices that have been developed for IA-32 platforms.
`Routines 210 may also include procedures for handling
`platform level interrupts and procedures to implement neWer
`computer technologies like ACPI, WFM.
`For one embodiment of ?rmWare system 200, a call table
`242 associated With WI 204 may be used to store pointers
`244 to different routines 210. Each pointer 244 is assigned
`an index through Which the pointer (and its associated
`routine 210) may be accessed. For example, dispatcher 220
`may receive an indexed input from FW2 208 and use the
`included index to access one of routines 210 via call table
`242.
`
`45
`
`55
`
`65
`
`6,081,890
`
`10
`
`15
`
`25
`
`35
`
`4
`Data structure 230 includes multiple storage locations
`234, Which may be used to point to different components of
`?rmWare system 200. This information alloWs routines from
`one ?rmWare module to access routines in another ?rmWare
`module. For the disclosed embodiment, locations 234 are
`provided to store pointers to dispatcher 220 (DISPl), a
`return address (RADD1) in WI 204, a shared memory
`location 278(SHiDATA) , a dispatcher 260 (DISP2) in
`FW2, and a return address (RADD2) in FW2 208. The value
`of DISP2, SHiDATA, and an initial value of RADD2 may
`be provided by FW2 208 When it ?rst accesses data structure
`230. For the disclosed embodiment, shared memory location
`278 is associated With FW2 208, but it may be de?ned by
`either WI 204 or FW2 208.
`DISPl may be set When data structure 230 is compiled
`and built in FWl 204, since the relative location of dis
`patcher 220 is available at build time. RADD1 is set When
`a routine 210 in FWl 204 accesses a routine in FW2 208.
`RADD1 points to a location in ?rmWare module 204 to
`Which control is returned folloWing execution of the routine
`in FW2 208. Similarly, RADD2 is set When a routine in FW2
`208 accesses a routine in FWl 204. RADD2 points to a
`location in FW2 208 to Which control is returned folloWing
`execution of the routine in FWl 204. SHiDATA is a pointer
`to a shared memory location de?ned in block 278. The value
`of SHiDATA may be set When data structure 230 is copied
`to system memory 140, and memory is allocated for
`SHiDATA. The shared memory location is used to store the
`input arguments and output parameters When a particular
`procedure in one ?rmWare block calls another procedure in
`the other ?rmWare block.
`Identi?er block 240 is associated With data structure 230
`and includes information that alloWs FW2 208 to locate and
`validate data structure 230. One embodiment of identi?er
`block 240 includes an identi?cation string (ID13 STRING),
`a siZe parameter (DSiSIZE), and a checksum value (CHKi
`SUM). IDiSTRING is a string of characters for Which FWl
`204 may be scanned. DSiSIZE indicates the siZe of data
`structure 230 and CHKiSUM is a value derived from data
`structure 230. FW2 208 may process the data of siZe
`DSiSIZE folloWing identi?er block 240 to determine a
`value. Comparing the value With CHKiSUM indicates
`Whether any errors have been generated during transmission
`or storage of data structure 230.
`FW2 208 includes prolog routine 250, dispatcher 260, and
`routines 270. The disclosed embodiment of FW2 208 also
`de?nes a shared memory location 278. Routines 270 provide
`?rmWare support for platform infrastructure associated With
`the second ISA. For example, routines 270 may include
`IA-64 code sequences that initialiZe and con?gure processor
`(s) 110, system logic 130, system memory 140, and other
`resources that operate in the native IA-64 environment.
`Dispatcher 260 provides access to routines 270. One
`embodiment of FW2 208 employs a call table 274 for
`dispatcher 260 similar to that employed by FWl 204.
`For the disclosed embodiment of the invention, prolog
`routine 250 coordinates initialiZation and con?guration pro
`cedures for system 100 When a boot or reset condition is
`triggered. For example, folloWing certain processor level
`initialiZation and checking procedures, prolog routine 250
`may establish a communication link With FWl 204. This
`may be accomplished by scanning FWl 204 for identi?er
`block 240 and processing it to locate and validate data
`structure 230. The location of data structure 230 is stored for
`future reference, and one or more entries (DISP2,
`SHiDATA) in data structure 230 are initialiZed for subse
`quent communications.
`
`7
`
`

`

`6,081,890
`
`5
`For one embodiment of the invention, FW2 208 includes
`system level software, eg a system abstraction layer (SAL),
`Which abstracts features of computer system 100 to ensure
`that a uniform set of system level features is available. FW2
`208 may also include a processor abstraction layer (PAL,)
`that interacts primarily With the processor core of the IA-64
`platform. In this embodiment, FW2 208 accesses legacy
`?rmWare (e.g. IA-32 BIOS) via FW1 204 to initialiZe. test,
`and con?gure legacy platform infratstructure. FW2 208, eg
`the SAL, emulates the IA-32 eXecution environment in
`Which the legacy ?rmWare like IA-32 BIOS operates.
`For one embodiment of the invention, FW2 208 scans
`legacy FW1 204 in non-volatile memory 170 and copies
`parts of it to system memory 140 during boot operations.
`Loading legacy FW1 204 into system memory 140 alloWs
`FW2 208 to initialiZe selected entries in data structure 230
`and crette all environment in Which legacy routines 210 may
`operate. Running routines 210 from system memory 140 is
`also faster than running them from non-volatile memory
`170.
`The foregoing discussion refers to actions, procedures, etc
`implemented by FW1 204 and FW2 208. Persons skilled in
`the art Will recogniZe that it is actually processors 110, eg
`the BSP, that perform these functions by implementing
`instructions in the ?rmWare modules.
`FIG. 3 is a How chart representing a method 300 for
`booting system 100 in accordance With the present inven
`tion. When a reset condition is detected, the native ?rmWare
`module, e.g. FWM2, initiates 310 a boot sequence in
`processor(s) 110. This may include, for example, a built in
`self test (BIST) and processor identity (ID) check. For one
`embodiment of the invention, these boot steps are imple
`mented by a PAL ?rmWare component, Which hands control
`over to a SAL ?rmWare component When the initial steps ale
`complete.
`The native ?rmWare module also determines 330 Whether
`the computer system is a symmetric multi-processor system
`(SMP). If it is, a bootstrap processor (BSP) is selected 334
`to continue With the boot process. If it is not, the single
`processor is the BSP. In either case, the BSP implements the
`native ?rmWare module to initialiZe and allocate memory
`340 for portions of the native and/or legacy ?rmWare
`modules. The legacy ?rmWare and its associated data struc
`ture are located 350 in the non-volatile memory 170. For
`eXample, the legacy ?rmWare module may be located
`through a ?rmWare Interface Table (FIT), Which lists
`addresses and siZes for ?rmWare components in the non
`volatile memory. The data structure may be located by
`scanning the legacy ?rmWare module for an identi?er block
`associated With the data structure.
`For one embodiment of method 300, an initialiZation
`routine in the native ?rmWare module, e.g. prolog routine
`250, copies 360 the legacy ?rmWare module to the system
`memory, and locates and validates 370 the associated data
`structure. The data structure may then be updated 380 With
`one or more pointers to resources in the native ?rmWare
`module. The order of events indicated in FIG. 3 is not
`essential to the present invention. For eXample, the data
`structure may be located in the legacy ?rmWare module and
`validated before it is copied it to main memory. In this case,
`the location of the data structure is updated When it is copied
`to the main memory, The native ?rmWare module may use
`pointer information in the data structure to call routines in
`the legacy ?rmWare module to initialiZe 390 legacy platform
`resources. These legacy routines may also refer to routines
`in the native ?rmWare module (via dispatcher 260) to
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`complete various initialiZation steps that are clone using
`FW2 (208). Exemplary legacy routines that may be invoked
`in the boot process include routines to set up an interrupt
`table for the IA-32 platform resources as Well as various
`routines to initialiZe these resources. IA-32 platform
`resources to be initialiZed may include a direct memory
`access (DMA) controller, keyboard, mouse, video display,
`and PCI card. Legacy ?rmWare routines may also implement
`speci?cations like ACPI, WFM, and System Management
`BIOS 2.0 (SMBIOS).
`In order to implement these and other IA-32 routines
`correctly, the native, e.g. IA-64, platform virtualiZes the
`legacy environment, eg IA-32. In the eXample above, the
`virtual environment accommodates the mode sWitching
`behavior of IA-32 routines and other features of the archi
`tecture and memory model for Which these routines Were
`Written. For eXample, in the IA-32 memory model, the IA-32
`BIOS is copied to an entry point in the system memory that
`is 16 bytes beloW 4GB, and the body of the IA-32 ?rmWare
`is copied to the system memory beginning at 1MB. As
`described beloW, the virtual environment replicates the entry
`point and address range of the IA-32 BIOS Within the IA-64
`environment. It also handles the full memory range
`addressed by the IA-32 BIOS in a single mode (Big Real
`Mode or BRM) With only a minor modi?cation of the legacy
`code.
`For one embodiment of the present invention, an entry
`point for the native ?rmWare is located beloW 4GB in the
`system memory. The entry point provides access to the
`native ?rmWare module, Which copies the legacy ?rmWare
`(IA-32 BIOS) to a memory location betWeen 1MB and
`1MB—128 KB. This may be done When the system is
`bootstrapped and the ?rmWare is shadoWed to the system
`memory. Thereafter, When an interrupt or a hardWare event
`generated by a legacy resource occurs, control is transferred
`to the native ?rmWare. The native ?rmWare then uses the
`legacy ?rmWare dispatcher (pointed to by the data structure)
`to access the appropriate legacy routine.
`Mode sWitching behavior in the legacy routines may be
`handled by removing the mode sWitching function from the
`legacy ?rmWare. In the legacy environment, the mode
`sWitching function must precede calls to memory addresses
`above 1MB, Which can only proceed in protected mode. This
`function sWitches the processor in and out of the protected
`mode. Deleting these functions from the legacy ?rmWare
`eliminates the mode sWitching behavior, but leaves the
`subsequent call to access data in the protected mode address.
`Since the native ?rmWare sets up BRM before invoking any
`legacy ?rmWare routine, addresses above 1MB are accessed
`properly Without mode sWitching.
`FIG. 4 is a ?oWchart representing one embodiment of a
`method 400 for using a data structure e. g. data structure 230,
`as a communication link betWeen the native and legacy
`?rmWare modules. It is assumed that the ?rmWare modules
`(or parts thereof) have been copied to system memory and
`the data structure has been initialiZed to indicate the loca
`tions of their dispatchers, ea. dispatchers 260 and 220 in the
`native and legacy ?rmWare module, respectively.
`Method 400 is initiated When an interrupt is detected 410
`and processor control jumps 420 to the native ?rmWare
`module
`This happens automatically under the dis
`closed processor architecture, Which takes control into
`native mode upon occurrence of an interrupt event. FW2
`updates 430 the data structure With a return address so that
`control can be returned to the appropriate location in FW2
`When the interrupt handler completes. FW2 also generates
`
`8
`
`

`

`6,081,890
`
`7
`440 an indexed call, using the legacy dispatcher address
`speci?ed in the data structure and an index associated With
`the source of the interrupt. Interrupt hardWare may identify
`the source of the interrupt. The legacy dispatcher address
`may be stored by FW2 or read on the ?y from the data
`structure. In either case, the indexed call accesses 450 the
`Icgacy routine (interrupt handler) in FWl that is identi?ed
`by the index. For one embodiment, the legacy dispatcher
`uses a call table to identify the handler associated With the
`index.
`The legacy routine processes 460 the interrupt in the
`virtualiZed legacy mode provided by the native mode. When
`interrupt processing completes, control is returned 470 to the
`native ?rmWare, using the return address speci?ed in the link
`data structure. The native ?rmWare may re?ect any status
`changes to the native mode interrupt resources When the
`interrupt completes 480.
`The mechanism described above may also be used When
`an operating system loader program requests the ?rmWare to
`make a legacy ?rmWare call, and When a hardWare interrupt
`occurs. A variation of this mechanism, Which is described
`beloW, may also be used to process selected hardWare
`interrupts. For example, selected hardWare interrupts may be
`handled through a legacy interrupt vector table. This table
`resides at architecturally speci?ed address locations, elimi
`nating the need to access it through the data structure
`described above. When a hardWare interrupt Occurs, pro
`cessor control reverts to native mode (IA-64), and the native
`?rmWare determines if the interrupt handler is legacy ?rm
`Ware code. If it is, the native ?rmWare module reads the
`legacy interrupt vector table, using architected legacy
`address locations, to determine the address of the legacy
`interrupt routine. The native ?rmWare sends the CPU
`directly to the legacy service routine after adjusting the
`return stack pointer to point to an IA-32 illegal instruction.
`The illegal instruction may be planted in the legacy ?rmWare
`module by the native ?rmWare module. After the legacy
`handler executes, the illegal instruction is encountered,
`generating a voluntary fault that returns control to native
`mode. This second method can not be used to access legacy
`?rmWare routines that are embedded in code. Locating these
`routines requires recourse to the data structure described
`above.
`There has been provided a system and method that alloW
`routines, Written for a ?rst instruction set architecture, to be
`implemented by routines, Written for a second instruction set
`architecture. The routines are initially embodied in ?rst and
`second ?rmWare module. The ?rst ?rmWare module
`includes a data structure that speci?es a pointer to a ?rst
`dispatcher. The ?rst dispatcher provides access to a ?rst set
`of routines Written for the ?rst ISA. The second ?rmWare
`module includes a prolog routine to locate the data structure
`in the ?rst ?rmWare routine, update the data structure With
`a second pointer, and copy portions of both modules to a
`dynamic memory structure. The second pointer provides
`access to a second set of routines Written for the second ISA.
`The invention has been described With reference to spe
`ci?c embodiments. Persons skilled in the art and having the
`bene?t of this disclosure Will recogniZe that these embodi
`ments may be modi?ed in a variety of Ways Without devi
`ating from the spirit of the invention. For example, While the
`disclosed embodiments refer to IA-32 and IA-64 ISAs, the
`invention is applicable to other ISAs. Similarly, the inven
`tion has been described for ?rmWare that supports legacy
`platform resources. HoWever, it may be bene?cially applied
`to code provided for other purposes on other media, Where
`translation betWeen the different ISAs Would be costly. The
`
`10
`
`15
`
`25
`
`45
`
`55
`
`65
`
`8
`speci?c examples are provided only to more clearly illus
`trate various features of the invention, Which is limited
`solely by the scope of the appended claims.
`I claim:
`1. A system comprising:
`a ?rst ?rmWare module including one or more routines
`Written for a ?rst instruction set architecture (ISA), the
`routines being accessible through a ?rst dispatcher;
`a data structure associated With the ?rst ?rmWare module,
`the data structure including a ?rst entry to store a
`pointer to the ?rst dispatcher; and
`a second ?rmWare module including a prolog routine
`Written for a second ISA to locate the data structure and
`access the routines in the ?rst ?rmWare module using
`the ?rst dispatcher.
`2. The system of claim 1, Wherein the data structure
`includes signature code to identify the data structure to the
`second ?rmWare module.
`3. The system of claim 1, Wherein the data structure
`includes a second entry to store a pointer to a dispatcher
`associated With the second ?rmWare module.
`4. The system of claim 3, Wherein the second ?rmWare
`module includes one or more routines in the second ISA, the
`one or more routines being accessible through the associated
`dispatcher.
`5. The system of claim 1, Wherein the second ?rmWare
`module includes one or more routines in the second ISA and
`a shared memory region is de?ned in the second ?rmWare
`module to accommodate data from the one or, more routines
`in the ?rst and second instruction sets.
`6. The system of claim 1, Wherein the prolog code of the
`second ?rmWare module copies portions of the ?rst ?rm
`Ware Module to a location in at random access memory,
`stores a location associated With the data structure, and
`updates the second entry of the data structure With a dis
`patcher address for the second ?rmWare module.
`7. A processor system comprising:
`a processor;
`a system memory; and
`a non-volatile memory in Which is stored:
`a ?rst ?rmWare module including a data structure and
`routines in a ?rst instruction set architecture (ISA)
`accessible through the data structure, the routines to
`provide access to legacy resources in the system; and
`a second ?rmWare module including a prolog routine to
`identify the data structure in the ?rst ?rmWare mod
`ule and access the ?rst set of routines.
`8. The system of claim 7, Wherein the second ?rmWare
`module further includes routines in a second ISA to access
`native resources in the system.
`9. The system of claim 8, Wherein the prolog routine
`copies portions of the ?rst ?rmWare module into the system
`memory and updates the data structure to provide the ?rst
`?rmWare imodule With access to the routines in the second
`ISA.
`10. The system of claim 7, Wherein the second ?rmWare
`module includes a boot routine that generates an operating
`environment for the ?rst ?rmWare module When the system
`is booted.
`11. The system of claim 10, Wherein the ?rst ISA includes
`?rst and second operating modes and Wherein an operating
`environment generated by the second ?rmWare module
`virtualiZes the ?rst and second operating modes of the ?rst
`ISA.
`12. Amethod for communicating betWeen ?rst and second
`?rmWare routines Written in ?rst and second instruction sets,
`respectively, the method comprising:
`
`9
`
`

`

`9
`associating a data structure With the ?rst ?rmware routine,
`the data structure including an entry through Which
`routines in the ?rst ?rmWare module may be accessed;
`assigning a signature code to identify the data structure;
`and
`providing the second ?rmWare routine With a prolog
`function to locate the data structure and to update the
`data structure With pointer information for the second
`?rmWare module.
`13. The method of claim 12, Wherein the pointer infor
`mation provides the ?rst ?rmWare module With access to the
`routines in the second ?rmWare module.
`14. The method of claim 12, further comprising using the
`prolog function to copy portions of the ?rst and second
`?rmWare modules to a dynamic memory structure .
`15. A method for implementing legacy routines, Wri