Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1996-06-03
2001-07-17
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C713S002000
Reexamination Certificate
active
06263378
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention pertains generally to bootstrap systems and programs for loading operating systems into a computer, and more particularly to bootstrap systems and programs that detect peripheral devices, assign computer resources to these devices and eliminate resource probe conflicts.
2. Description of the Background Art
One important function of any computer operating system is the allocation of computer system resources to peripheral devices. These resources typically include input-output (I/O) port addresses, interrupt request channels (IRQ's), direct memory access (DMA) channels and memory address space. These resources are utilized by peripheral components such as disk drives, video monitors, keyboards, printers, network communication devices, “Small Computer Systems Interface” (SCSI) devices, modems, and the like. These are characterized as “I/O” devices, in the sense that they are all external to the central processor unit and main random access memory (RAM) in the computer. In addition, some operating systems, such as the operating systems sold under the trademark UNIX®, also characterize parts of the computer as “internal” I/O devices, sometimes termed “software devices” or “pseudo-devices”, which are not physically separate components of the computer. (“UNIX” is a registered trademark of UNIX System Laboratories, Inc.)
Modern computer operating systems must be designed to accommodate a wide variety of I/O devices, since different computer users generally want to connect different peripheral devices to a computer, and these devices often come from different sources. Users also want to be able to add peripheral devices to existing computer systems. Furthermore it is desirable to allow internal devices to be controlled in different ways by the system. Therefore the problems of flexibility and adaptability are very important in the handling of I/O devices by any practical operating system. With the rapid proliferation of different systems and devices, these problems have become more serious and are currently of major importance in the industry.
Computer components generally communicate with each other by means of a bus, which is a common pathway through which data passes between computer elements. Although early computer systems were designed with every component connected to a single bus, modern systems employ a variety of different buses in order to maximize the efficiency of information flow; e.g. a computer may include a processor bus, memory bus, address buses, and one or more I/O buses. Each I/O device communicates with the rest of the computer through an I/O bus. The I/O bus is also termed an expansion bus, because peripheral devices are attached to the system by connecting them to the I/O bus. These buses have various different architectures. The original PC I/O bus architecture was termed the “Industry Standard Architecture” (ISA), introduced in 1982. Since then, buses with a variety of improved architecture types have become available, e.g. Micro Channel Architecture (MCA), Extended Industry Standard Architecture (EISA), Peripheral Component Interconnect (PCI) architecture, and Personal Computer Memory Card International Association (PCMCIA) architecture. Each peripheral device is connected via an I/O bus to the computer motherboard, which is the circuit board on which the central processor unit (CPU) resides, through an adapter card. The adapter card translates information to and from the bus protocol.
When the computer is first turned on, or “booted”, it is controlled initially by the bootstrap (“boot”) program, which may reside as “firmware” in a programmable read-only memory in the computer (boot PROM), or on a floppy disk. Although in older computer systems, resources could be allocated to peripherals by setting jumpers or switches on the adapter cards, many current boot programs carry out the determination of the peripheral device configuration by means of the boot program before loading the operating system. This determination entails first detecting the presence and type of peripheral devices connected to the I/O bus, and then assigning resources, such as I/O port addresses and IRQ's to each peripheral device. The peripheral devices are detected by drivers that are included in the boot program. Each driver scans the I/O bus to detect a particular type of peripheral device and then assigns computer resources to that device.
The determination of the device configuration by means of conventional firmware as described above has the drawback that conflicts between computer resources may occur during this determination. Each driver scans the system to determine the presence of corresponding peripheral devices, independently of other drivers that may have previously scanned the system. In assigning resources to a peripheral device, the driver may inadvertently cause another device to reprogram itself and vitiate the allocation by another driver. This phenomenon is known as a probe conflict, and can manifest itself as a system hang or reset, or the failure of a peripheral device to operate. The likelihood of probe conflicts increases as more peripheral devices and adapter cards are added to the system. In order to resolve these conflicts it may be necessary to change switches or jumpers on one or more adapter cards, which can be a time-consuming and troublesome procedure.
The problem of probe conflicts is solved automatically in some of the newer bus architectures, such as PCI, EISA, MCA and PCMCIA. Adapter cards for these buses provide means for devices to be self-identifying and generate device configurations automatically. Computer system standards, known as “Plug and Play”, have been developed to provide software detection and configuration of peripheral devices without probe conflicts by any system that adheres to these standards. However these standards have not been universally adopted, and also they do not provide all of the necessary self-identification information to enable any system to implement automatic device configuration. There are a great number of adapter cards and devices, known as legacy devices, that operate under the older ISA bus architecture. This architecture does not have “Plug and Play” capability, and probe conflicts remain a potential problem.
Probe conflicts can arise in another way when a computer is running under certain operating systems of the UNIX® type, such as the Solaris® operating system. (“SOLARIS” is a registered trademark of Sun Microsystems, Inc.) When the Solaris® operating system is booted on some platforms, it loads every driver and again scans the computer system for devices, both peripheral and internal. Since the real-mode drivers, i.e. drivers that control peripheral devices during booting, are completely different from the Solaris® drivers that control internal devices, the probe conflict situations may also differ and the risk of probe conflicts from certain configurations is even greater.
The foregoing problems have been addressed in the design of the Open Firmware architecture described in the publication entitled “IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices”, IEEE Standard 1275-1994, published by the Institute of Electrical and Electronics Engineers, Inc. This architecture is independent of the hardware environment and operating system of the computer, and provides for “plug-in” device drivers which are located on the peripheral devices that are added to the system, and are written in a machine-independent interpreted language that is similar to the FORTH programming language. The architecture further provides a data structure called a “device tree” that describes the device configuration of the computer system and may be accessed by the operating system. This device tree eliminates the necessity for probing, since it carries information concerning each device in the system which would otherwise be ascertained by the probing process. Finally, the Open Firmware architecture provides a program
Haley Timothy P.
Rudoff Andrew M.
Beyer Weaver & Thomas LLP
Courtenay III St. John
Sun Microsystems Inc.
LandOfFree
System and method for rapid development of bootstrap device... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for rapid development of bootstrap device..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for rapid development of bootstrap device... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2544112