United States Patent (191
`Shah et al.
`
`[11] Patent Number:
`[45] Date of Patent:
`
`4,589,063
`May 13, 1986
`
`[75]
`
`[54] DATA PROCESSING SYSTEM HAVING
`AUTOMATIC CONFIGURATION
`Inventors: Baku! V. Shah; James A. Maskevitch,
`both of Palo Alto, Calif.
`[73] Assignee: Fortune Systems Corporation, San
`Carlos, Calif.
`[21] Appl. No.: 520,354
`[22] Filed:
`Aug. 4, 1983
`Int. Q.4 ................................................ G06F 3/00
`[51]
`[52] U.S. a ..................................................... 364/200
`[58] Field of Search ... 364/200 MS File, 900 MS File,
`364/300
`
`[56]
`
`References Cited
`U.S. PATENT DOCUMENTS
`4,438,493 3/1984 Cushing et al ...................... 364/200
`4.491,916 1/1985 Vallhonrat .......................... 364/200
`
`Primary Examiner-Raulfe B. Zache
`Attorney, Agent, or Firm-Townsend & Townsend
`
`ABSTRACT
`[57]
`A method and apparatus for automatic configuration of
`a computer system is provided wherein one or more
`system peripheral or 1/0 devices can be interfaced to
`the computer system through 1/0 boards that plug into
`a system motherboard. Each of the 1/0 devices in(cid:173)
`cludes a controlling device driver module that operates
`under a program code stored in a read only memory
`resident on the 1/0 board and by which the device
`driver module allows the computer system to communi(cid:173)
`cate with its associated peripheral and 1/0 devices.
`Accordingly, a system user is not required to change
`the computer operating system kernel to support each
`new 1/0 device or system configuration change.
`
`13 Qaims, 8 Drawing Figures
`
`19
`
`CRT
`
`OPTION SLOT:
`......... ~~~~ ......... ANY CONTROLLER
`IN ANY SLOT;
`....,.___,..____,_....,...__,ANY NUMBER
`OF SLOTS
`
`OLYMPUS et al. EX. 1015 - 1/10
`
`

`

`U.S. Patent May 13, 1986
`1s __ ___
`TTY
`BOOT
`ROM
`
`II
`
`12
`
`10~
`
`4,589,063
`
`Sheet 1of5
`17
`KEYBOARD
`18
`
`SIO
`
`FDC
`
`CPU
`MC68000
`
`MMU
`
`19
`
`13
`
`16
`
`m MEM
`(mm)
`
`CTC
`
`14
`
`NV
`RAM
`FIG._/.
`
`OPTION
`E SLOT
`
`A B C 0
`20
`
`...
`
`19
`r
`
`I
`13 ..... ~ m MEM
`r-------- - - - : i
`40- ~E_R_NE!:-_L "!.~J
`r22
`r21
`
`OPTION SLOT:
`ANY CONTROLLER
`IA B c 0 El
`IN ANY SLOT;
`ANY NUMBER
`OF SLOTS
`
`l20
`
`CRT - CONTROLLER -
`CRT
`---------,
`[Q~~~~ ~Q.~ _j ... 210
`r23
`
`r24
`PIO
`PRINTER - CONTROLLER
`,--- ---- ---1
`@~!Y~~ BQ~ -1 ~23o
`r26
`r25
`- CONTROLLER
`·--
`:o"RiVER ROM- --250
`- --
`(21
`
`HOC
`
`HARO
`DISC
`
`r2a
`MODEM -
`
`r30
`
`COM-A
`·----------.,
`CONTROLLER
`L Q~!_Y_E_R_~Q~ _. -210
`f29
`
`COM-B
`
`@~yg~)f~f~j --290
`FIG.-2.
`
`RS-232C - CONTROLLER
`
`OLYMPUS et al. EX. 1015 - 2/10
`
`

`

`0
`
`4,589,063
`
`U.S. Patent May 13, 1986
`Sheet 2 of5
`ADDRESS SPACE
`800000 hex
`USER ADDRESS
`SPACE
`
`I M BYTE REAL MEMORY
`
`OLYMPUS et al. EX. 1015 - 3/10
`
`

`

`U.S. Patent May 13, 1986
`COMPILED KERNEL
`14
`
`RAM
`
`CHAR
`
`LINE
`
`BLOCK
`
`4,589,063
`Sheet 3of5
`SLOT A-N
`110 DRIVER
`30 /.
`'
`
`OPEN
`CLOSE
`READ
`WRITE
`
`ROM
`
`I
`I
`I
`I
`I
`F/G.-5A.
`
`COMPILED KERNEL
`
`DEVICE TABLE SLOT A-N
`RAM
`
`RAM
`
`RAM
`
`CHAR
`
`LINE
`
`CLOCK
`
`/' 31
`OPEN 7
`CLOSE
`READ
`WRITE
`
`110 DRIVER 30
`OPEN
`CLOSE
`READ
`WRITE
`
`ROM
`
`31
`
`ROM
`
`OPEN
`CLOSE
`READ
`WRITE
`
`OLYMPUS et al. EX. 1015 - 4/10
`
`

`

`U.S. Patent May 13, 1986
`
`Sheet4 of5
`
`4,589,063
`
`D
`E IT
`
`COPY
`FILES
`
`UST
`FILES
`
`, . . PRINT
`
`UTILITIES
`
`---------- ------------
`
`KERNEL
`
`40
`
`CHAR DEVICE
`TABLE
`
`BLOCK DEVICE
`TABLE
`
`100
`
`20
`
`DISK I
`
`OPERATING
`SYSTEM
`KERNEL
`
`DISK 2
`
`TAPE
`
`TTY
`
`COM·A
`
`1 - - - -3---4120 BYTES
`
`2
`
`}4 BYTES
`1
`----------------------------
`
`...-+-+-+---+-o
`
`:
`
`} MANY BYTES (ANYWHERE FROM )
`OPEN
`0 TO 1000 BYTES
`....___:---C-LO_S_E---1
`
`READ
`WRITE
`
`IO
`
`DRIVER ROM l
`
`CODE
`
`OLYMPUS et al. EX. 1015 - 5/10
`
`

`

`U.S. Patent May 13, 1986
`
`Sheet 5of5
`
`4,589,063
`
`auto· h
`
`fd-c
`
`c-LANGUAGE
`IMPLEMENTATION OF
`THE DRIVER
`
`COMPILER
`
`IOo
`
`IMAGE OF THE DRIVER
`
`D ··· D···
`~~/
`10, J LOADER I
`t LJ ROM- IMAGE
`
`F/G._7.
`
`OLYMPUS et al. EX. 1015 - 6/10
`
`

`

`1
`
`DATA PROCESSING SYSTEM HAVING
`AUTOMATIC CONFIGURATION
`
`4,589,063
`
`2
`data processing system configuration. This is a particu(cid:173)
`larly acute problem, considering the relatively technical
`naivete of the average system user in this day of the
`ubiquitous data processing system.
`
`A set of schematic diagrams and a partial program S
`listing are submitted as part of this patent application.
`
`BACKGROUND OF THE INVENTION
`1. Field of the Invention
`The present invention relates to a data processing IO
`system. More particularly, the present invention relates
`to the automatic configuration of a data processing
`system when interfacing the system to one or more of
`various peripheral devices.
`2. Description of the Prior Art
`As data processing needs of system users grow, the
`number of devices supported by a data processing sys(cid:173)
`tem also grows. Multiple data processing applications
`require a variety of system input and output devices.
`For example, word processing applications require key- 20
`boards, displays, and printers; investment and analysis
`applications require telecommunications and graphics.
`In addition to supporting multiple applications and
`their associated input/output devices, data processing
`systems provide computer support to increasing num- 2S
`bers of users. Accordingly, a data processing system is
`required to support any number of terminal devices and
`supporting memory space.
`A major factor in making the decision to purchase a
`particular data processing system confronts the person 30
`selecting a system for business or personal applications.
`Will the basic system purchased today be compatible
`with the various input/output devices that may be re(cid:173)
`quired to meet growing data processing system work(cid:173)
`loads? The ability to reconfigure a data processing sys- 35
`tern to provide enhanced and augmented user features
`and to accommodate additional users is thus a crucial
`factor in finally deciding which data processing system
`to purchase.
`Many data processing systems are offered that pro- 40
`vide expansion slots by which additional input/output
`and memory devices may be connected to the system.
`In such systems, every change in the system configura(cid:173)
`tion effected as a result of the addition or substitution of
`I/O or memory devices requires a reconfiguration of 45
`the system software. In particular, the system software
`must be recompiled for each change to the system con(cid:173)
`figuration so that the system is compatible with the
`added or substituted devices. Thus, a memory upgrade
`from floppy disc to hard disc requires a new operating SO
`system version, that is "aware" of the substituted stor(cid:173)
`age medium. Similarly, adding additional input and
`output devices requires identification of the device and
`appropriate device commands in the operating system
`software. Absent such recompile or reconfiguration of SS
`the software, the operating system does not know
`which device is located where, nor does it know the
`particular requirements of the device for the exchange
`of data or for device control.
`The present practice is to provide a diskette contain- 60
`ing a new operating system version every time a system
`configuration is enhanced or otherwise altered. As a
`result, several operating system versions may exist for a
`particular data processing system at any given time.
`Depending on system configuration, not all operating 65
`system software will run the system correctly. As a
`result, there is much confusion and wasted effort in
`providing a new operating system for each change of
`
`SUMMARY OF THE INVENTION
`The present invention provides a method and appara-
`tus for automatic configuration of a computer system.
`One or more of several 1/0 devices are interfaced to the
`system through I/O boards that plug into various op(cid:173)
`tion slots in a system motherboard. Each of the 1/0
`devices includes a controlling device driver module.
`The device driver modules are controlled by pro(cid:173)
`gram code stored in a read only memory (ROM) resi-
`lS dent on the 1/0 board. To communicate with the I/O
`devices, any program running on the data processing
`system must know what is connected to the system and
`where the device driver modules are to be found. In the
`present invention, a system user is not required to
`change the operating system kernel to support each new
`I/O device or system configuration. Rather, each de-
`vice driver module is self-identifying and system config(cid:173)
`uration is performed by autoconfiguration modules
`within the system software.
`Autoconfiguration operation is as follows: After sys(cid:173)
`tem power up and initialization, every option slot is
`polled by the system. That is, every slot is addressed for
`access to the driver ROM in the I/O controller resident
`at that slot (if present). A ROM header includes infor(cid:173)
`mation by which the system can verify if there is a valid
`ROM present at that slot location. Thereafter, a check
`sum is performed on that entire ROM.
`After verifying that a valid ROM is present at a
`polled slot, the computer system then looks for a driver
`module header to determine if the device associated
`with the driver ROM is a character driver, block driver,
`or line driver, or if it is intended to be used as a diagnos(cid:173)
`tic device. It is important to note that each driver ROM
`can contain more than one device driver module. Thus,
`although five option slots are provided in the preferred
`embodiment of the invention, more than five peripheral
`devices can be operated through the option slots.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a block diagram of a data processing system
`incorporating the present invention;
`FIG. 2 is a block diagram of a data processing system
`incorporating the present invention and showing an
`expansion slot to which a series of peripheral devices
`are connected;
`FIG. 3 is a schematic representation of a data process(cid:173)
`ing system operating system kernel showing allocation
`of address space according to the present invention;
`FIG. 4 is a schematic representation of a driver ROM
`according to the present invention;
`FIG. Sa is a schematic representation of a compiled
`operating system kernel and I/O driver ROM prior to
`autoconfiguration by the present invention;
`FIG. Sb is a schematic diagram of an operating sys(cid:173)
`tem kernel and 1/0 driver ROM subsequent to autocon(cid:173)
`figuration by the present invention;
`FIG. 6 is a schematic diagram of an autoconfigured
`operating system kernel incorporating 1/0 driver ROM
`code after autoconfiguration by the present invention;
`and
`FIG. 7 is a schematic representation of driver image
`compilation and coding, according to the present inven(cid:173)
`tion.
`
`OLYMPUS et al. EX. 1015 - 7/10
`
`

`

`25
`
`3
`DETAILED DESCRIPTION OF A PREFERRED
`EMBODIMENT
`The present invention is incorporated into the data
`processing system 10, as shown in FIG. 1. The data 5
`processing system includes a central processing unit
`(CPU) 11, a memory multiplexing unit 12, a system read
`only memory (ROM) memory 13, a non-volatile ran(cid:173)
`dom access memory (RAM) memory 14, a boot ROM
`memory 15, a control and timing circuit (CTC) 16, an 10
`input/output (110) circuit 17, and a floppy disc control(cid:173)
`ling circuit (FDC) 18. Each of these functional units in
`the system hardware architecture is integral with a
`system motherboard 19.
`In the preferred embodiment of the invention, system 15
`motherboard 19 contains a plurality of functionally
`identical slots 20 (A-E) into which optional I/O boards
`may be plugged. As shown in FIG. 2, every 1/0 board
`includes two ROMs, each of which is capable of hold(cid:173)
`ing 8-Kbytes or 16-Kbytes maximum of control soft- 20
`ware. The ROMs are accessed by the data processing
`system at the address of the system motherboard slots
`they are plugged into. The presence of an 1/0 board in
`a particular slot is verified by accessing a board-present
`register in the system software.
`For example, FIG. 2 shows option slot 20 including a
`CRT controller 21 in slot A for controlling CRT 22 in
`accordance with instructions resident in driver ROM
`21a. Also shown is a print 1/0 controller 23 at option 30
`slot B for controlling a printer 24 in accordance with
`instructions resident in ROM 23a; a hard disc controller
`25 present in option slot C for controlling a hard disc
`memory storage device 26 in accordance with instruc(cid:173)
`tions resident in driver ROM 25a; a first communica- 35
`tions controller 27 in option slot D for controlling a
`modem 28 in accordance with instructions resident in
`driver ROM 21a; and a second communications con(cid:173)
`troller 29 present in option slot E for controlling an
`RS-232C interface 30 in accordance with instructions 40
`resident in driver ROM 29a. The configuration shown
`in FIG. 2 is provided as an example of the various op(cid:173)
`tions provided to a system user by the present invention.
`Clearly, any number of variations of peripheral devices
`can be connected to any of the option slots as desired. 45
`Additionally, although slots A-E are shown, it should
`be understood that any number of option slots can be
`provided as desired for the computer system. For exam(cid:173)
`ple, graphics controllers, analog-to-digital interfaces,
`computer network interface equipment can all be con- 50
`nected to the computer system if such configuration is
`desired.
`FIG. 3 shows the parcelling of address space within
`computer system memory 13 (FIG. 1). Beginning at
`user address space 7 AOOOOhex and extending to address 55
`space 7F0000hex• autoconfiguration and device driver
`address space is provided. Initially, slot A is assigned a
`65 Kbyte space extending from address 7 AOOOhex to
`7AFFFFhex· This address space is occupied by the slot
`A device driver ROM. Accordingly, plugging a device 60
`into slot A automatically makes that device part of the
`computer system address space. That portion of the 65
`Kbyte slot address space assigned to the particular I/O
`device which is not used by the device driver ROM is
`provided for data transport between the device and the 65
`system.
`After system power is turned on, four routines-each
`of which is performed by a different program-are
`
`4,589,063
`
`4
`executed before the user can interact with the system.
`The programs include:
`(1) an initial program resident in a system mother-
`board ROM;
`(2) a device dependent boot routine;
`(3) a primary boot routine; and
`(4) a stand-alone program, such as the operating sys(cid:173)
`tem.
`Upon system power up, the initial program in the
`system motherboard main memory ROM 13 is exe(cid:173)
`cuted. When the program has completed execution, it
`passes control to a boot ROM 15 resident device(cid:173)
`dependent boot routine. The boot routine initializes the
`devices connected to the 1/0 boards. The program next
`reads in a boot program from a specified I/O device
`driver module. The boot program from the device
`driver module reads in a stand-alone program from the
`specified I/O device and begins program execution. If
`the boot routines did not succeed, control is returned to
`the system motherboard ROM.
`After the system has read the nonvolatile RAM and
`brought in the primary boot program, the primary boot
`program brings in a secondary boot program which
`thereafter brings in a stand-alone program, such as the
`operating system. The stand-alone program can be on
`any device and typically initializes the device drivers
`which were found by the autoconfiguration search. As
`a result, the system finds out what devices are con(cid:173)
`nected to the option slots and creates tables incorpo(cid:173)
`rated within the operating system by which the periph(cid:173)
`eral devices may be operated. Nonvolatile RAM 14
`stores the following information:
`(1) the name of the boot device (controller);
`(2) the name of the boot program; and
`(3) information by which system optimization can be
`achieved.
`The most frequently used stand-alone program is the
`operating system. Other embodiments of the invention
`provide stand-alone programs for restoring file systems,
`for diagnostics, etc. All stand-alone programs incorpo(cid:173)
`rate the present autoconfiguration invention.
`If brought in at the stand-alone program, the operat(cid:173)
`ing system kernel first calls an autoconfiguration rou(cid:173)
`tine to query a set of predetermined memory locations
`to find and link all device driver modules in the system.
`Once the linking process is complete, the kernel initial(cid:173)
`izes the various I/O devices and the device internal data
`structures. After system initialization is finished, control
`is passed to user programs which immediately make use
`of all I/O devices attached to the system.
`The autoconfiguration invention includes:
`(1) the system motherboard ROM;
`(2) a rundown linking, kernel initialization routine;
`and
`(3) the 1/0 board based routines (boot, device driver
`modules, stand-alone drivers, and diagnostics).
`Each ROM contains a descriptor that identifies that
`ROM as a valid device driver module and that describes
`the ROM's contents. A ROM plan linking routine is
`called from the operating system kernel (or the stand(cid:173)
`alone program). The routine queries all of the mother(cid:173)
`board slots to determine which 1/0 devices are plugged
`into the slots. If an 1/0 device is plugged into the slot,
`the linking routine performs the following functions:
`(1) Stores the address of each device driver module in
`a table. Note: a ROM may contain more than one
`device driver module;
`(2) Calls the I/O device's initialization routine; and
`
`OLYMPUS et al. EX. 1015 - 8/10
`
`

`

`4,589,063
`
`25
`
`5
`(3) Copies the routine address, including an offset
`dictated by the slot location of the I/0 device,
`when the operating system kernel detects a specific
`initialization routine.
`The routine address is copied into an array of ad- 5
`dresses in RAM. The array is used by the operating
`system to vector off to appropriate subroutines in order
`to perform specific device dependent functions. Each
`I/O driver is assigned a specific major device number,
`which serves as an index into a series of device tables. 10
`An initialization routine is called for each device
`present that provides such a routine. The routine
`"pokes" the device it is associated with to obtain infor(cid:173)
`mation, such as trap vectors, number of device driver
`modules present. Any initial setup required for the I/0 15
`device is done, including initializing interrupt vectors,
`etc., if appropriate. The initialized routine also requests
`a block of static memory for storing information on
`I/O's, etc., from the operating system kernel.
`At this point, the system has enough information to 20
`determine a route device. The name of the device to be
`used as a route is stored in a ROM. The name of the
`device is compared against those of devices present in
`the system. If the named device is present, then the
`ASCII device name is converted into a major/minor
`device number for use by the operating system.
`The system is then ready to execute the user code.
`Typically, the first program run determines if all appro(cid:173)
`priate special functions exist. Special system calls are 30
`made through the operating system to I/0 devices that
`are connected into the system. A major/minor pair and
`a block/character type are passed to the operating sys(cid:173)
`tem kernel. Given this information, the operating sys(cid:173)
`tem kernel either returns a name for the major/minor, 35
`or it returns an error. If a name is returned, a special file
`is created for that 1/0 device. There could be many
`special files for a particular device. It is not desirable to
`have all special or possible special files always present.
`For example, discs may have up to seven active parti- 40
`tions in the preferred embodiment of the invention.
`The system ROM is organized to allow for multiple
`device driver modules in one driver ROM. Because the
`device driver module is ROM-resident on an I/0 board,
`the base address of the ROM depends on which mother- 45
`board slot the 1/0 board is plugged into. The device
`driver modules do not depend on the actual position of
`the code.
`Typical driver ROM organization and contents are
`shown in FIG. 4. Thus, a device located in any one of 50
`the option slots first contains a ROM header of 128
`bytes. Thereafter each device driver module is located
`including a driver module header by which driver type
`is designated.
`A ROM descriptor, referred to as a "magic number", 55
`is provided to indicate whether a valid ROM is present
`at a motherboard slot. Included with the descriptor is a
`string from which special file names can be constructed,
`a listing of all devices accessed via ROM, a copyright
`notice, a device number indication of the number of 60
`drivers controlled by the driver ROM, and a driver
`type identification code. The present invention provides
`four types of drivers: block driver, character driver, line
`driver, and diagnostic. Each driver has a unique magic
`number.
`Referring to FIG. Sa, RAM 14 is shown resident in
`the compiled operating system kernel prior to autocon(cid:173)
`figuration. In the FIG., ROMs 30 and 31 are shown
`
`6
`located in the various option slots 20 and including
`various 1/0 drivers.
`In FIG. Sb, the compiled operating system kernel and
`RAM 14 are shown after autoconfiguration wherein a
`device table comprised of RAM modules 14a-14c has
`been assembled including links via option slot 20 to the
`various 1/0 driver ROMs 30-32. Each link shown ena(cid:173)
`bles the system to control the 1/0 device via the driver
`ROM according to commands sent over the various
`links, such as "open", "close'', "read", and "write".
`The linking structure is shown in more detail in FIG.
`6, wherein the operating system kernel 40 is shown
`supporting a plurality of utilities, such as edit, copy files,
`list files, and print. Use of these utilities provides kernel
`interaction with the character, block, and line device
`tables so that the appropriate 1/0 devices are operated
`in accordance with utility requests. Thus, a disc access
`would be routed by the operating system control
`through the character device table, wherein the appro(cid:173)
`priate driver could be located according to its magic
`number and table address.
`Each 1/0 device is assigned 20 bytes of table space in
`the preferred embodiment of the invention. Of these 20
`bytes, a series of five 4-byte links are established to the
`1/0 driver ROM code. The 1/0 driver ROM code 41
`can consist of as many bytes as necessary to perform
`whatever function is associated with the code. For
`example, to read a disc the kernel would go to the char(cid:173)
`acter device table, which would then locate a particular
`disc to be read. That disc space in the table would con(cid:173)
`sist of the open, close, read, and write links. The kernel
`would then direct the request to write to disc through
`the table to that appropriate 1/0 driver code section via
`the link established between the kernel and the I/0
`driver ROM. In this way, the I/O driver becomes part
`of the operating system kernel. Once the link is ac-
`cessed, the selected 1/0 device is operated to write as
`requested.
`Once the table is established and autoconfiguration
`has occurred, any 1/0 driver ROM code can be exe(cid:173)
`cuted. It will be appreciated that the code contained in
`the 1/0 driver ROM is fixed and unalterable. Referring
`to FIG. 7, it can be seen how ROM functions are imple(cid:173)
`mented. The operating system kernel includes a com-
`piler 100 which produces an image of the ROM driver.
`The ROM driver image is compiled and reproduced as
`an object code relocatable module, which is then run
`through a loader.
`The system incorporates an entire ROM image that
`can be relocated within the system under operating
`system kernel control as is convenient. The ROM image
`is located in a particular address space with a header
`indicating the specific address location. Accordingly,
`looping and moving around within a program loop is
`specific to the memory location of the entire module. In
`this way, an absolute location is known, although the
`driver is not initially located anywhere in the system
`until autoconfiguration. This arrangement allows the
`compiler to operate in such a way that it does not have
`to specify absolute addresses but rather specifies ad(cid:173)
`dresses contained in the link table that was formed dur-
`ing the autoconfiguration process. The above structures
`also reside in the RAM. They are used by the device
`driver modules to access external objects and to store
`65 data variables. The structures allocated are initialized
`by a run time linker.
`The present invention provides an apparatus for auto(cid:173)
`configuration of a data processing system. Because each
`
`OLYMPUS et al. EX. 1015 - 9/10
`
`

`

`25
`
`7
`peripheral device is self-identifying, it contains its own
`compatible software, and an 1/0 device can be added to
`the system without the need for operating system recon(cid:173)
`figuration. n this way, a system can grow as user needs
`grow. Additionally, technological advances in periph- 5
`era) devices can be readily accommodated by the data
`processing system without the need to modify system
`operation. Reconfiguration can be performed on site by
`a technically naive user by simply plugging the 1/0
`device into the system option slot. Once plugged in, the 10
`device and its associated driver become an integral part
`of the data processing system operating system kernel as
`though they were always part of the system.
`The foregoing was given for purposes of illustration
`and example. It will be appreciated by those reading this 15
`patent application that the present invention can be
`produced in various equivalent embodiments. For ex(cid:173)
`ample, the number of option slots can be varied, as also
`can the number of device drivers. Accordingly, the
`present invention should be limited only by the breadth 20
`of the claims.
`We claim:
`1. Apparatus for data processing system autoconfigu-
`ration, comprising:
`a system motherboard, including a plurality of data
`processing system pollable peripheral device slots;
`at least one device driver module resident on an 1/0
`board, for connecting an associated selected pe(cid:173)
`ripheral device to said data processing system via a 30
`corresponding motherboard slot and for control(cid:173)
`ling said peripheral device in accordance with data
`processing system operation;
`an identifying header, prefatory to said device driver
`module and responsive to data processing system 35
`peripheral device slot polling to uniquely identify
`an associated peripheral device to said data pro(cid:173)
`cessing system; and
`a data processing system-resident peripheral device
`table for collating polled peripheral device identity 40
`and for establishing a bidirectional information
`transfer link between said data processing system
`and said device driver module, whereby said data
`processing system is automatically configured for
`coordinated operation with said peripheral device. 45
`2. The apparatus of claim 1, wherein said device
`driver module controls a character peripheral device.
`3. The apparatus of claim 1, wherein said device
`driver module controls a block peripheral device.
`4. The apparatus of claim 1, wherein said device 50
`driver module controls a line peripheral device.
`5. The apparatus of claim 1, said identifying header
`further comprising:
`a unique device driver module identifying label; and
`a peripheral device identifying label.
`6. The apparatus of claim 5, said identifying header
`further comprising a device driver module version iden(cid:173)
`tification label.
`
`8
`7. The apparatus of claim 1, said identifying header
`further comprising a proprietary notice label.
`8. The apparatus of claim 1, said identifying header
`further comprising indicium of the number of device
`driver modules resident on said 1/0 board.
`9. Method for data processing system autoconfigura(cid:173)
`tion, comprising:
`initializing said system with a program resident in a
`system motherboard main memory;
`initializing all peripheral devices associated with said
`system with a device-dependent boot routine;
`reading a peripheral device driver module boot pro(cid:173)
`gram with said device-dependent boot routine;
`reading a stand-alone program from a selected pe(cid:173)
`ripheral device with said peripheral device driver
`module boot program;
`calling an autoconfiguration routine with said stand(cid:173)
`alone program;
`querying a set of predetermined memory locations
`with said autoconfiguration routine to find and link
`all peripheral devices associated with said system;
`and
`passing system control to user programs for user
`system operation.
`10. Method for data processing system autoconfigu(cid:173)
`ration, comprising:
`polling a plurality of system motherboard peripheral
`device option slots to determine which peripheral
`device is connected to each slot;
`storing a peripheral device driver module address in a
`linking table;
`calling each peripheral device initialization routine;
`and
`copying an initialized routine address and option slot
`offset into said linking table.
`11. The method of claim 10, said polling step further
`comprising reading an option slot associated peripheral
`device driver module descriptor to uniquely identify
`said device.
`12. Method for data processing system autoconfigu(cid:173)
`ration, comprising:
`polling a plurality of system motherboard option slots
`to access an associated peripheral device driver
`module;
`reading a peripheral device driver module header to
`verify that a valid peripheral device is associated
`with each option slot and to uniquely identify each
`peripheral device;
`storing peripheral device driver module location and
`identification information in an autoconfiguration
`linking table, whereby each peripheral device and
`its associated device driver become an integral part
`of said data processing system's operating system
`kernel.
`13. The method of claim 12, further comprising the
`step of determining peripheral device type by polling
`said peripheral device driver module.
`• • • • •
`
`4,589,063
`
`55
`
`60
`
`65
`
`OLYMPUS et al. EX. 1015 - 10/10
`
`