One key Open Firmware feature is support for self-identifying devices. Consider a computer with an "open" expansion bus, such as VMEbus or Sbus. An independent board vendor (i.e. not a system manufacturer) of a card to plug into that bus would like for the system to recognize and be able to use that card. In the operating system environment, that may be easy - the board vendor can supply a driver on a diskette, and that driver may be loaded onto a hard disk or installed into the operating system.
In the firmware environment, acquiring drivers is more difficult; the firmware has to operate before the system is ready to read the disk. It is better to have the board driver in a ROM somewhere. Since it is difficult to merge third-party drivers into existing system ROMs, it is better to store such a driver in a ROM on the card for the "plug-in" device to which it applies. This approach has been taken before, but in most existing firmware systems, the driver is stored as ISA-dependent machine language binary code, and thus only works on computer systems compatible with a particular architecture.
Open Firmware uses the "plug-in driver" technique, but instead of storing those drivers in machine language, Open Firmware encodes the drivers in a machine-independent language called "FCode". FCode is a byte-coded "intermediate language" for the Forth programming language. Forth, an industry-standard interactive programming language, is based on a stack-oriented "virtual machine" that may be easily and efficiently implemented on any computer. FCode drivers are "incrementally compiled" into system RAM for later execution. The same FCode driver can be used on systems with different processor types. Thus, for example, a particular Futurebus+ add-in card could be a boot device for a 680x0-based Futurebus+ system or an x86-based Futurebus+ system with no firmware changes.
In addition to its use for firmware device drivers, FCode also provides a descriptive capability. Plug-in device cards use it to report their characteristics to the firmware and system software. Such characteristics may include the device name, model, revision level, device type, register locations, interrupt levels, supported features, and any other identification information that makes sense for the particular device. System software may use this information to automatically configure itself for correct operation with particular devices. This information is stored in a processor- and architecture-independent format that may easily be retrieved decoded. Furthermore, this specification is open and extensible, and allows any arbitrary device information to be recorded, providing protection against obsolescence of the interface.
Forward to next feature
Back to Features
Back to FirmWorks Home Page