Rick Grehan
Suppose for a moment that you're an adapter card. You get plugged into a PCI (Peripheral Component Interconnect) bus and powered up. You have no idea what kind of CPU your host is, but you're expected to (among other things) provide code to the CPU so it can initialize whatever device you're controlling, determine characteristics of the device, and perhaps even boot from the device. What are you gonna do?
Well, you could have your ROM crammed with executable code for every conceivable processor and provide a table that tells the host: "If you're an Intel 80x86, your code is over there; if you're a Mips, your code is over there; if you're an Alpha, your code is over there," and so on. What happens, however, when you get plugged into a system with a brand-new
CPU (they're appearing all the time these days) that your designers didn't know about when they burned your ROM?
The above scenario describes precisely the problem that is facing peripheral designers today:They're confronted with platforms hosted by a growing diversity of CPUs. The answer, of course, would be a kind of CPU-independent machine code that can be placed into the adapter's ROM. Right?
Actually, CPU-independent code is only part of the solution, although it's an important part. Both CPU motherboard and adapter-card designers need a clear, agreed-upon set of specifications describing not only the CPU-independent software's syntax, but what services should be provided by code written in that software so that the host has all it needs to get devices up and running.
An Open Solution
One solution is nearing completion even as this article is being written. The IEEE P1275 Standard for Boot Firmware working group, called Open Firmware for short, is chaired by Mitch Bradley of Firm
Works, who did much of the early work on what is now the Open Firmware specification while working for Sun Microsystems. A prototype Open Firmware system first appeared in the SparcStation 1.
The Open Firmware specification consists of three interface definitions: a device interface, which defines the CPU-independent code described above; a client interface, which defines procedures that start-up code (usually an operating system or an operating-system loader) can call to acquire firmware services (e.g., reading data from a boot device); and a user interface, which allows human interaction with the firmware for the purposes of altering the booting process or performing device testing and debugging functions.
The device interface is perhaps Open Firmware's most interesting component. Not only does it provide the mechanism whereby adapter cards achieve CPU independence, but it is made possible thanks to a language that only longtime BYTE readers may be familiar with: Forth.
Why Forth?
Fo
rth is a programming language developed by Charles Moore in 1971. At the lowest level, you can think of Forth as the "assembly language" for an abstract stack-based machine. A small set of primitive instructions take their arguments from and leave their results on a stack; Forth's abstract machine has no registers.
Forth source code is a sequence of text words that list, in left-to-right order, the operations to be performed. You can define new words as sequences of existing words. This ability to extend Forth makes it difficult to characterize it as either a high-level language or a low-level language. Rather, Forth is a language that scales to fit a wide range of needs. In addition to the primitive words, a typical Forth system includes utility words for console and mass-storage I/O, command parsing, memory display, and so forth.
Forth is interactive; you simply type a series of Forth words and they will be executed. By using Forth as the firmware's command interpreter, a complete integrated t
oolkit can fit easily in a typical ROM. The Open Firmware user interface specifies Forth words for hardware and software debugging, system configuration management, and support packages for various communications protocols. Because these functions are integrated seamlessly into the Forth environment, you can use Forth language facilities to write macros to automate sequences of these operations.
The code in an adapter ROM is a predigested form of Forth source code called FCode, in which the text words are replaced by integers encoded as 1 or 2 bytes each. The execution of an FCode program is functionally equivalent to interpreting Forth source code. The Forth interpreter resides on the host CPU.
How It Works
In response to a hard reset--usually just after power is applied--the host CPU begins executing Open Firmware code stored in ROM on the motherboard. This code initializes the system's internal environment (e.g., checks for available memory, initializes stacks, and determines the configura
tion of on-board hardware devices).
Next, the code directs the system to explore the devices attached to the expansion bus. The system examines each device's ROM, looking for a signature that indicates the presence and location of FCode. Note that a single ROM might contain multiple code components of differing nature. Typical AT-style BIOS code can be stored alongside FCode, enabling a single board to operate in either an AT-architecture system or a system supporting Open Firmware.
Once the host locates FCode, the FCode interpreter within the host's system ROM begins executing the FCode program. In function, the FCode is just a general-purpose program. It isn't restricted to any particular activity. In most cases, however, the code will probably initialize the board to some state, identify and describe the board, create driver routines for controlling the board, and make those routines available to the system firmware.
This process continues for all adapters attached to the host. In fact
, it can even extend to adapters not directly attached. Specifically, Open Firmware lets designers build bridge cards that link one bus to another and thereby permit expandable bus architectures. In practice, the host is directly connected to one bus, but that bus is straddled by a bridge card that links it to another bus. The bridge acts as an intermediary, passing information back and forth between the buses and allowing the secondary bus to be "booted from a distance." This structure can be arbitrarily complex, with a primary bus bridged to secondary buses bridged to tertiary buses, and so on.
Ultimately, the success of Open Firmware depends on its ability to gain a foothold as a standard. Currently, Apple, IBM, Motorola, and Sun head the list of corporations jumping on the Open Firmware bandwagon. Although Open Firmware has been in use on SBus cards for some time now, and there's no reason it can't be applied to other bus architectures (e.g., Futurebus), it appears that real success hinges on how w
ell the PCI architecture fares. The PCI specification for adapter-card ROM contents includes Open Firmware's FCode as one of the possibilities, and the only possibility that provides real CPU independence.
ACKNOWLEDGMENT
Thanks to Mitch Bradley, chairman of the IEEE P1275 working group and founder of FirmWorks (Mountain View, CA), for his help.
Open Firmware Highlights
-- Expansion devices contain processor-independent configuration information.
-- Forth interpreter in system ROM interrogates the expansion devices, configures the system, and boots the operating system.
-- User interface lets you interact with the system ROM to select the boot device or perform system testing.
Rick Grehan is technical director of the BYTE Lab. You can reach him on the Internet or BIX at
rick_g@bix.com
.
Open Firmware Provides CPU Independence
