WO1996007136A1 - Operating system device driver autogeneration - Google Patents

Abstract

An innovative system and method provide support in a target operating system for new devices based on device drivers from an existing operating system. Development of a bootable image of a particular operating system utilizes the following steps. First, a trace facility is utilized to initiate an interrupt call to a particular BIOS routine requesting initialization of a target hardware device. The BIOS contains appropriate setup instructions for the device, instructions which are non-obvious and not well documented. The trace facility is piped through a simple filter, which extracts all OUT instructions, and the contents of the DX and AX registers at the time of the OUT instruction. By capturing this sequence of OUT instructions, the state of the device is stored at the end of the initialization. The resultant OUT instructions are converted to 'C' code, and the resulting 'C' code is compiled utilizing a compiler for the target computer system to generate a device driver for the target hardware device which is compatible with the target operating system support for the target computer system.

Description

OPERATING SYSTEM DEVICE DRIVER AUTOGENERAΗON

Copyright Notification

Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

Field of the Invention This invention generally relates to improvements in computer systems and more particularly to a system and method for automatically generating operating system device driver support for a device based on existing device driver support from another operating system.

Background of the Invention

Early computer systems were very complicated, required constant attention, skilled operators and were very expensive. Because of this, each computer could effectively be considered a custom or unique entity. With the resources available, it was possible to customize and fine tune the bootable or run time image of the operating system of the computer for each individual computer. While this was often a complicated task, the number of generations of different versions was limited because of the relatively few variations of and modifications to the system. The cost of this development was in proportion with the cost of the computer system itself. However, this changed with the development of the microprocessor and microprocessor-based computer systems. Costs plummeted and systems became much more variable. One classic example of a microprocessor-based system utilized the S-100 bus system. In the 1970's and early 1980's numerous manufacturers were making various circuit boards which had varying functions, which all operated using the S-100 standard. Thus, peripheral devices, such as terminals or video and keyboard systems, floppy and hard disk controllers, serial and parallel ports and other hardware interface items were quite variable. If operating systems were to incorporate all of the customized features as previously done in larger computer systems, the cost of developing the operating system, particularly the individual boot or loadable image, would have greatly exceeded the cost of the entire computer system itself.

To this end Digital Research Inc. developed an operating system referred to as CP/M. One of the features of CP/M was that it divided the operating system into two distinct portions: 1) the basic input /output system (BIOS), and (2) the remaining portions or the core of the operating system. The BIOS was intended to provide each developer a means for developing the particular interface code required for the hardware of that particular computer. The operating system woul be compatible across the number of different systems without change. A develope was only required to develop the particular code necessary to support the particula hardware of that system, and then the CP/M operating system could be utilized. Changes did not have to be made to the core operating system for each particular system. CP/M and S-100 based systems, in their infancy, were very simple systems However, even with these simple systems, it was hard to get an isolated system operational. Since the software required the BIOS to be provided by the board manufacturer, it generally had to be properly placed on the floppy disk and incorporated into the boot loading process. But if the code was necessary for bootin the system, then this was a problem, unless another system was available. Therefore it was relatively hard to develop and configure an isolated system.

Additionally, as computer systems became complex, the CP/M operating system became quite limited and many features were available which were not recognized by CP/M. An example was high end graphical video interfaces, becaus CP/M was only text based. To solve this problem, developers began circumventin the operating system in many cases. Additionally, certain system level functions which were desirable had not been available in the systems and were not addressed in the core operating system. Examples were timers, Direct Memory Access (DMA) capability and high levels of interrupt functionality. Each vendor implemented th functions differently and so disks and programs became much less portable, becaus each developer patched CP/M to support their unique requirements.

In response to the growing demand for more powerful computer systems, International Business Machines Corporation (IBM) developed and introduced the IBM Personal Computer (PC). The IBM PC was architected around an Intel 8088 microprocessor. The PC/DOS or MS/DOS operating system from Microsoft Corp. was incorporated and utilized with the IBM PC. While MS/DOS had similarities with CP/M, one change was made: the interrupt, timer and DMA functions were integrated into the operating system. The particular hardware relating to the interrupts, the timers and DMA was located on the system board of the computer and therefore it was considered not to be a changeable item, so that incorporation into the operating system core was acceptable. Various devices, such as the video system, the hard disk and floppy disk drive controllers and the various serial and parallel ports were considered to be changeable items as they were commonly located in interchangeable slots. Therefore, these items remained flexible and were supported by device drivers. Device drivers could either be located in the system ROM provided by the manufacturer, or on floppy disk, which could then be incorporated into the runtime operating system. As part of the setup and initialization of an MS /DOS system, these various extended device drivers were referenced and introduced into the operating system as it was being loaded.

Time passed and computer systems again became more powerful. MS/DOS became limited and so extensions were rapidly developed for it, particularly in the video area and other areas where performance was limited. Because certain system level functions were incorporated into the core of MS /DOS, it was a relatively non- transportable system, that is, major portions must be rewritten to transfer to a system having certain functions in other locations or differently defined.

Another major operating system, UNIX, was being developing in research and academia at the same time as CP/M and MS/DOS. UNIX was also a relatively non-transportable system which was very difficult to configure. In order to boot a UNIX-based system, a complete binary boot image of the run time operating system was required, including all of the necessary device drivers and system board interface software. All of this information had to be assembled into a single module which was then loaded. However, this was difficult to do on a single standalone system when all of the various drivers had to be gathered and then assembled. It became very difficult when the system was not operational. Conventionally, all of the necessary device drivers were loaded onto another UNIX system and the generation process was performed there, with the result being returned to the intended system. For various reasons, UNIX became a standard operating system with the advantage that the application programs were freely transportable between various hardware platforms. However, this transportability was not true of the core UNIX operating system because the core or kernel also included certain system board or system related hardware code. The kernal varied between hardware platforms. Therefore, the UNIX kernel had to be re-written and re-developed for each particular computer system by each particular manufacturer and was not readily transportable. This limited the widespread use of UNIX.

The operating system of a preferred embodiment of this invention must have an automated mechanism for generating device drivers and integrating them into the operating system to support diverse hardware platforms.

Summary of the Invention The present invention facilitates operating system support for new devices based on device drivers from an existing operating system. Computer systems based on microprocessors use a separate Input/Output (I/O) address space for many functions. This I/O address space is not accessible using normal memory read and write instructions, but instead via special I/O instructions, referred to as IN and OUT instructions. There are two forms of IN and OUT instructions. The first operates on a single byte, while the second operated on a two-byte word. The two forms are usually distinguished by a trailing "B" or "W" in the operation instruction code (opcode). This results in four instruction opcodes: INB, INW, OUTB and OUTW. Other processors distinguish I/O addresses from memory addresses by the instruction used to access them, or alternatively, by bits in the address.

Development of a bootable image of a particular operating system utilizes the following steps. First, a trace facility is utilized to initiate an interrupt call to a particular BIOS routine requesting initialization of a target hardware device. The BIOS contains appropriate setup instructions for the device, instructions which are non-obvious and not well documented. The trace facility is piped through a simple filter, which extracts all OUT instructions, and the contents of the DX and AX registers at the time of the OUT instruction. By capturing this sequence of OUT instructions, the state of the device is stored at the end of the initialization. The resultant OUT instructions are converted to "C" code, and the resulting "C" code is compiled utilizing a compiler for the target computer system to generate a device driver for the target hardware device which is compatible with the target operating system support for the target computer system.

To increase compatibility with the target hardware device, additional filters can be used to capture sequences of IN instructions. Some boards actually use IN instructions to trigger certain controller state changes. As a further check, additional filters can be utilized to capture MEMORY READ/WRITE instructions for memory mapped controllers.

Brief Description of the Drawings

Figure 1 is a block diagram of an exemplary computer system in accordance with a preferred embodiment;

Figure 2 is a block diagram of a prior art operating system; Figure 3 is a block diagram of the operating system in accordance with a preferred embodiment;

Figure 4 is a block diagram of the various software storage elements and internal allocations of the software storage elements of a computer system in accordance with a preferred embodiment; and

Figure 5 is a flowchart setting forth the detailed logic in accordance with a preferred embodiment.

Detailed Description Of The Invention

Referring now to Figure 1, a computer system in accordance with a preferred embodiment is presented. The computer system is an exemplary computer system on which an operating system organized and configured according to the present invention operates. As such, none of the specific hardware details or organizations are considered critical but are provided merely for explanatory purposes. Many additional elements can be added and certain elements illustrated can be removed.

In the illustrated computer system, a bus 20 forms the backbone of the computer system. Attached to this bus is a Central Processing Unit (CPU) 22 which performs the processing functions of the computer system. The CPU could be a microprocessor such as the Intel 8088 or a RISC chip such as the PowerPC. The main system Read Only Memory (ROM) 24 and system Random Access Memory (RAM) 26 are connected to the system bus 20 for use by the CPU 22. In an alternate embodiment the CPU 22 and the RAM 26 are on a separate bus which is coupled to the bus 20 by means of various buffers and a bus controller. Additionally, CMOS memory 28 is connected to the system bus 20 for long term but changeable storage of specific information. As an option this can be Electrically Erasable Programmable ROM (EEPROM). A terminal is also connected to the system bus 20. The terminal typically includes a keyboard 30, a video controller 32 and a monitor/display 34 which is connected to the video controller 32. The terminal provides an operator interface to the computer system. The computer system also includes various forms of mass storage, such as a diskette drive 36 and its associated controller 38, which is connected to the system bus 20. Additionally, the preferred computer system also includes a hard disk drive 40 and its associated controller 42, which is connected to the system bus 20. Optionally, a CD-ROM drive 44 and its controller 46 can be connected to the system bus 20.

This architecture allows various sources of mass storage to be used in the computer system. Various serial and parallel ports (not shown) may also be connected to the system bus 20. An interrupt controller 62, a Direct Memory Access (DMA) controller 64 and timer 66 are connected to the system bus 20 to allow the CPU 22 to control these basic functions.

The computer system includes a series of slots 48 for use by interchangeable circuit boards or adapters. The slots 48 preferably conform to certain standards, for instance the Extended Industry Standard Architecture (EISA) or MicroChannel Architecture (MCA). To support this capability, the bus 20 may actually be two or more separate buses so that CPU performance and adapter performance can be separately maximized with appropriate control and conversion circuits connecting the various buses. One exemplary adapter is a second hard disk controller 50. Preferably, the hard disk controller 50 also includes a ROM 52. The hard disk controller 50 is connected to a hard disk 54. The hard disk controller 50 may, for example, be a high performance hard disk controller such as a SCSI controller, while the hard disk 40 may be a low to medium performance hard disk provided for minimum functionality of the computer system. As another example, a tape drive 56 can be incorporated via one of the slots 48. As yet another example, a network interconnection controller (NIC) 58 may be provided in one of the slots 48. Preferably the NIC card 58 includes a ROM 60 for storing a device driver or other control code.

The computer system is controlled by an operating system. Organizations of operating systems according to the prior art are generally shown in Figure 2. Exemplary operating systems are MS /DOS by Microsoft Corporation and UNIX by a number of vendors. The operating system is partitioned so that there is main operating code 100 and a device driver area 102. The device driver area 102 addresses certain generally changeable aspects of the computer system, such as the disk drives, the video or terminal units and the various serial and parallel ports. The main operating system code 100 includes the basic operating system kernel itself and certain code relating to interrupt processing, direct memory access control, timing functions and similar system control oriented functions. The particular problem as noted in the background is that the operating system of a preferred embodiment of this invention must have an automated mechanism for generating device drivers and integrating them into the operating system to support diverse hardware platforms.

To this end, an operating system according to the present invention is configured as shown in Figure 3. The operating system is shown in block 101 with the interrupts, Direct Memory Access (DMA), timer and access control 102 resident in the RAM of the computer system. The DOS device drivers 100 and 110, normally resident in the ROM of a computer system, cannot be used with the operating system 100 because the Operating System is not DOS compatible. A preferred embodiment of the invention facilitates the construction of a compatible device driver initialization 103 and access and control function 104. These compatible device driver portions are extracted from the incompatible, original DOS device drivers 100 and 110.

Referring now to Figure 4, the organization of the various software modules, device drivers and operating system portions in a system according to the present invention is illustrated. The memory map is presented in a traditional bottom up mapping of memory addresses from 0 to 100000+. Memory is organized on a word boundary with the Interrupt Vectors stored in low memory commencing at address 00000 as shown at label 490. BIOS data is stored in memory address 00400 as indicated at label 480. Graphic display adapter memory spans the region indicated by label 470, while the graphic BIOS extension is located at label 460. The Disk BIOS extension 450, Network BIOS extension 440 and the System BIOS 430 are located just below the high memory commencing at 420. The interrupt vectors 480 trap interrupts from the various hardware devices and pass control to the device specific BIOS routine, such as the graphics BIOS extension 460 to support a graphic hardware device. Thus, a preferred embodiment of the invention would use the existing device-specific BIOS routine 460 to create a new device support module, providing support in a new operating system environment for an existing DOS or other operating system supported graphics device.

Referring to Figure 5, a detailed flowchart of the logic in accordance with a preferred embodiment is provided. Processing commences at terminal 500 and immediately proceeds to function block 502 where a trace program is initiated. This is accomplished on an Intel platform utilizing a hardware trace facility. Then, at function block 504, an INT 10 call is initiated to a BIOS device driver. In a preferred embodiment, the BIOS device driver is a Video BIOS. The Video BIOS contains appropriate setup instructions for the video controller. These instructions are often not well documented and sometimes are even not published. Function block 506 refers to trapping the setup instructions. This is accomplished when the trace facility is piped through a software enabled filter, which extracts all OUT instructions, and the contents of the DX and AX registers at the time of the OUT instruction. By capturing this sequence of OUT instructions, the state of the -8-

controller at the end of the INT 10 (Initialize Graphics Board) command can be obtained.

This technique was successfully utilized for an NEC Versa portable Intel clone machine, with a Western Digital chipset. Because the controller controls a flat panel display, it was not apparent what sequence of instructions was appropriate to initialize the flat panel display to 640x480x8 bit color graphic mode. A DOS diskette was booted with the DEBUG program provided with DOS using a script that assembled and ran an INT 10 instruction. This resulted in the capture of the initialization sequence to diskette. The diskette was transferred to a UNIX box and the data is filtered utilizing a software filter enabled in a programming language, AWK to process the commands, match appropriate fields, and extract the matched fields. However, one of ordinary skill in the pertinent art will realize that all programming languages have string matching capabilities and could be substituted for the AWK implementation of a preferred embodiment. The AWK script converts OUT instructions to "C" code. The resulting "C" code is compiled as a portion of the device driver support for the NEC monitor on UNIX.

Further, additional filters can be used to capture sequences of IN instructions, for complete correctness. Some boards actually use IN instructions to trigger certain controller state changes. Alternatively, this method could be utilized to capture MEMORY READ /WRITE instructions, for memory mapped controllers. Additional processing of the OUT/IN instructions can occur to eliminate certain redundant or unnecessary instructions. For example, the sequences of OUT instructions at known addresses that initialize the Video CLUT (DAC). This technique saves space and instructions.

To completely automate this processing, the following boot sequence can be used to automatically generate a device driver for a target operating system.

• insert a non-DOS diskette that is programmed to boot up the trace program, and does a trace/filter of INT 10 (video setup)

• capture the results to that same diskette, using only BIOS calls (not DOS)

• remove the diskette (call it the "key"), and boot the installation diskettes for the target Operating System • when asked, insert the "key" diskette. The target OS boot process reads the results of the trace results, and constructs a device driver for the graphics controller.

This method should work for all known VGA and SVGA and VESA compliant controllers. This method also works for initialization code of ANY device with startup code in ROM at known addresses, and an interface for normal operation at known fixed addresses. The code presented below is utilized in a preferred embodiment to query a device driver in ROM and obtain the information necessary to generate a function device driver for another operating system environment.

L DOS

DOS command line in accordance with 502 of Figure 5.

DEBUG <SCRIPT.l >LOG

Debug script 'SCRIPT.l' in accordance with 504 of Figure 5_.

a 100 nop mov ah,0 mov al,5f int 10 jmp 107 nop

<- [required extra CR/NL to end assemble mode] t 10000 q

An example of a debug manual for use in debugging applications in accordance with a preferred embodiment is the MacsBug Reference and Debugging Guide, Apple Computer Corp., 1990.

Sample debug output file 'LOG' in accordance with 5_Q6 of Figure 5_.

-a 100 1512:0100 nop 1512:0101 mov ah,0 1512:0103 mov al,5f 1512:0105 int 10 1512:0107 nop 1512:0108

-t lOO

AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=1512 ES=1512 SS=1512 CS=1512 IP=0101 NV UP El PL NZ NA PO NC 1512:0101 B400 MOV AH,00

AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=1512 ES=1512 SS=1512 CS=1512 IP=0103 NV UP El PL NZ NA PO NC 1512:0103 B05F MOV AL,5F

AX=005F BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000 DS=1512 ES=1512 SS=1512 CS=1512 IP=0105 NV UP El PL NZ NA PO NC 1512:0105 CD10 INT 10

AX=005F BX=0000 CX=0000 DX=0000 SP=FFE8 BP=0000 SI=0000 DI=0000 DS=1512 ES=1512 SS=1512 CS=E000 IP=6ECD NV UP DI PL NZ NA PO NC E000:6ECD 80FC1C CMP AH,1C

AX=005F BX=0000 CX=0000 DX=0000 SP=FFE8 BP=0000 SI=0000 DI=0000 DS=1512 ES=1512 SS=1512 CS=E000 IP=6ED0 NV UP DI NG NZ AC PE CY E000:6ED0 77D4 JA 6EA6

AX=005F BX=0000 CX=0000 DX=0000 SP=FFE8 BP=0000 SI=0000 DI=0000 DS=1512 ES=1512 SS=1512 CS=E000 IP=6ED2 NV UP DI NG NZ AC PE CY E000:6ED2 FC CLD

AX=005F BX=0000 CX=0000 DX=0000 SP=FFE8 BP=0000 SI=0000 DI=0000 DS=1512 ES=1512 SS=1512 CS=E000 IP=6ED3 NV UP DI NG NZ AC PE CY E000:6ED3 FB STI AX=005F BX=0000 CX=0000 DX=0000 SP=FFE8 BP=0000 SI=0000 DI=0000 DS=1512 ES=1512 SS=1512 CS=EO00 IP=6ED4 NV UP El NG NZ AC PE CY E000:6ED4 IE PUSH DS

II. UNIX

UNIX command line to filter the resulting file in accordance with function block 508 and 510 of Figure 5

sed 's/=/= /g' < LOG I sed 's/,/ , /g' I awk -f filter.awk > video_init.c

explanation:

• first send changes 'AX=005F to 'AX= 005F' to allow AWK to find the register values easier. second send changes 'OUT DX,AX' to 'OUT DX , AX' to allow AWK to find the source and destination register fields easier. • the AWK script puts the C code header and trailer into the file, finds all OUT instructions, and puts the appropriate outw (word) or outb (byte) 'C call into the file.

• Note that IN instructions are ignored here.

• Spaces are significant in the command line above.

AWK script 'filter.awk' in accordance with function blocks 508 and 510.

BEGIN { printf("void video_init()\n{\n"); }

/INT/ { break;

/AX=/ { line2 = linel; linel = $0; dx = $8; ax = $2; al = substr($2,3,2); break;

}

/OUT/ { if ($4 == "DX") stringl = dx; else

1 stringl = "unknown";

} if ($6 == "AX") { string2 = ax; lstring = "w"; } else if ($6 == "AL") { string2 = al; lstring = "b";

} else string2 = "XXX"; printf("\tout%s(0x%s,0x%s);\n",lstring,stringl,string2);

}

/IN/ { printf("\n")_;

END { printf("\n} \n");

Sample 'C code file 'video_init.c' produced by this method in accordance with function blocks 508_. and 5 O of Figure 5.

void video_init()

{ outw(0x03CE,0x050F); outb(0x03D4,0x2A); outb(0x03CE,0x0B); outw(0x03CE,0xC40B); outb(0x03CE,0x0C); outb(0x03CE,0x0C); outw(0x03CE,0x010C); outw(0x03C4,0x4806); outb(0x03C4,0xl0); outw(0x03C4,0x0006);

UNIX command line for the compiler: in accordance with function block 520 of Figure 5.

cc -o video_init.o video_init.c

A compiler reference manual utilized in accordance with a preferred embodiment of the invention is AIX Version 3.2 for RISC System /6000. XL C User's GUIDE, SC09-1259-02 (1992).

The autogeneration of a device driver for other devices such as disk drives, diskette drives, modems, and other peripherals would require including the step of tailoring the initialize device command to initialize the particular peripheral. The initialization call would be initiated from the DEBUG process and be documented in the technical reference or the processor handbook for the target peripheral device. For example, the video device call is an INT 10 as shown above with reference to Figure 5, function block 504.

While the invention has been described in terms of a preferred embodiment in a specific system environment, those skilled in the art will recognize that the invention can be practiced, with modification, in other and different hardware and software environments within the spirit and scope of the appended claims.

Claims

Having thus described our invention, what we claim as new, and desire to secure by Letters Patent is:

A computer implemented method for automatically generating a device driver for a device attached to a computer with an attached storage, said device driver supporting a first target operating system, comprising the step of:

(a) issuing an initialize device command to said device driver to commence initialization of said device;

(b) trapping a set of commands issued by said device driver during said initialization of said device and storing said set of commands in a storage;

(c) filtering said set of commands issued by said device driver;

(d) translating said set of commands into a program language compatible with second target operating system; and

(e) recompiling said program language to create a device driver compatible wit said second target operating system.

2. A method as recited in claim 1, including the step of tailoring the initialize device command to initialize a printer device driver.

3. A method as recited in claim 1, including the step of tailoring the initialize device command to initialize a modem device driver.

4. A method as recited in claim 1, including the step of tailoring the initialize device command to initialize a communication device driver.

5. A method as recited in claim 1, including the step of tailoring the initialize device command to initialize a disk device driver.

6. A method as recited in claim 1, including the step of tailoring the initialize device command to initialize a diskette device driver.

7. A method as recited in claim 1, including the step of tailoring the initialize device command to initialize a graphic device driver. -15-

8. A method as recited in claim 1, including the step of tailoring the initialize device command to initialize a telephony device driver.

9. An apparatus for automatically generating a device driver for a device attached to a computer, comprising:

(a) a processor;

(b) a memory under the control of said processor;

(c) a device attached to said processor;

(d) means for automatically generating a device driver for said device, said device driver supporting a first target operating system, including:

(e) means for issuing an initialize device command to said device driver to commence initialization of said device;

( ) means for trapping a set of commands issued by said device driver during said initialization of said device and storing said set of commands in a storage;

(g) means for filtering said set of commands issued by said device driver;

(h) means for translating said set of commands into a program language compatible with a second target operating system; and means for recompiling said program language to create a device driver compatible with said second target operating system.

10. An apparatus as recited in claim 9, including means for tailoring the initialize device command to initialize a printer device driver.

11. An apparatus as recited in claim 9, including means for tailoring the initialize device command to initialize a modem device driver.

12. An apparatus as recited in claim 9, including means for tailoring the initialize device command to initialize a communication device driver.

13. An apparatus as recited in claim 9, including means for tailoring the initialize device command to initialize a disk device driver.

14. An apparatus as recited in claim 9, including means for tailoring the initialize device command to initialize a diskette device driver.

15. An apparatus as recited in claim 9, including means for tailoring the initialize device command to initialize a graphic device driver.

16. An apparatus as recited in claim 9, including means for tailoring the initialize device command to initialize a telephony device driver.