Browse Prior Art Database

GENERIC BOOT LOADER FOR INITIALIZING A DEVICE CARD ATTACHED TO A COMPUTER VIA AN EXPANSION BUS

IP.com Disclosure Number: IPCOM000004654D
Original Publication Date: 2001-Mar-19
Included in the Prior Art Database: 2001-Mar-19
Document File: 3 page(s) / 12K

Publishing Venue

Motorola

Related People

James A. Golding: AUTHOR [+3]

Abstract

Successful products are commonly modified to create new products that address particular market segments or customer requirements. This development model is valid for personal computer expansion (or device) cards. These products usually comprise the device card and personal computer software (a driver). It is desirable that device card changes not require changes to the accompanying driver, as this removes the possibility of introducing errors and reduces the number of software programs that must be maintained. A driver program provides the mechanism with which high-level software communicates with the device card and initializes (or boots) the device card at power-up. In the past, when a device card was modified the driver had to change so that it could properly initialize the new card at power-up. This was true even if the high-level software was not being changed. Here we describe a generic boot mechanism that allows a single driver to initialize any of several different device cards.

This text was extracted from a RTF document.
This is the abbreviated version, containing approximately 32% of the total text.

GENERIC BOOT LOADER FOR INITIALIZING A DEVICE CARD ATTACHED TO A COMPUTER VIA AN EXPANSION BUS

by James A. Golding, Edward A. Pope and Ronald M. Zuckerman

ABSTRACT

Successful products are commonly modified to create new products that address particular market segments or customer requirements. This development model is valid for personal computer expansion (or device) cards. These products usually comprise the device card and personal computer software (a driver). It is desirable that device card changes not require changes to the accompanying driver, as this removes the possibility of introducing errors and reduces the number of software programs that must be maintained.

A driver program provides the mechanism with which high-level software communicates with the device card and initializes (or boots) the device card at power-up. In the past, when a device card was modified the driver had to change so that it could properly initialize the new card at power-up. This was true even if the high-level software was not being changed. Here we describe a generic boot mechanism that allows a single driver to initialize any of several different device cards.

BACKGROUND

This disclosure pertains to the development of device cards that attach to a personal computer (PC) expansion bus. Such an implementation is shown in Figure 1. Device card (1) is implemented as a printed circuit board that plugs into connector (2) attached to PC expansion bus (3). Via this connector a program running on the PC's central processing unit (CPU) can access the device card to exchange commands and data. In a personal computer with a peripheral component interconnect (PCI) bus, it is also possible for the device card to access PC memory without intervention by the PC's CPU.

The device cards referenced herein contain their own CPU (4), program memory (5), and data memory (6). The program (7) that executes on a device card's CPU is archived in the PC's memory. Archiving the device card's program on the PC makes it is faster, easier, and cheaper to change device card functions. When the PC is turned on, a program (8), called a device driver (or just driver), on the PC runs to identify the device card, retrieve the device card's archived program from PC memory, and deliver this micro-code to the device card. The process of delivering the micro-code to the device card at power-up is called bootstrapping or booting the device card.

The device card's CPU contains a simple, built-in boot program (9) that allows it to accept micro-code from an external source and write this to the CPU's program memory (5). When the device card is powered on, its CPU begins executing this built-in program. Once the built-in boot program has received all of the micro-code from the external source (in this case, the driver on the PC), it terminates the built-in boot program and begins executing the micro-code that it just ...