Open Firmware is software that is used after powering a machine to bring the operating system online (most visibly on PowerPC® and SPARC systems). And it's not such an esoteric bit of software that most users have never seen it -- all modern Macintosh systems use it.
Open Firmware, written in Forth, is an open standard rather than a proprietary one, still in use even though it has been officially withdrawn by IEEE, the standards body that first published it.
And it does bear a unique claim: It is believed to be the only firmware standard in the world to have its own song (see Resources).
If that intrigues you, then take a look at Open Firmware, see what it does and how you can make use of that, examine the role extensions play, and determine how it reacts with devices.
Open Firmware (OF) has been around a fairly long time, and it is just what the name suggests -- it's open and it's firmware.
OF is "Open" in the sense that it's a published standard that multiple vendors can use and participate in the development of. You can get complete specifications for it and can write things that are compatible with it. Multiple vendors distribute compatible versions of OF.
OF is "Firmware" in the sense that it is "boot firmware," the code that runs in a machine between when power first hits the CPU and when the OS gets loaded. It's similar to the BIOS of an x86-based PC, but unlike the BIOS of an x86 system (which is just plain machine code), OF is written in ANSI Forth. This means that the boot code can be hardware independent. For OF code to drive a SCSI controller, it doesn't need to know whether it's in a PCI Power Macintosh, an RS/6000, or a Sun SPARCStation.
That's a big step. My old Alpha system has an x86 emulator in its boot ROM because it needs some way of handling expansion cards whose boot ROMs are designed for 80x86 systems. If you ask me, that's just another point of failure, to put it mildly. Some video cards can't be used on that system because they depend on x86 features which weren't provided in the minimal CPU emulator.
Unfortunately, this also means that an x86 port of Open Firmware wouldn't help most users, who would still have machine code built to be backwards-compatible with the original IBM PC. Oops.
OF was developed originally by Sun. Work on it under the name "OpenBoot" started in 1987. The first machine to ship with OpenBoot was the SPARCstation-1, in 1989. OpenBoot version 2 shipped on the SPARCstation-2 and was fairly close to the initial OF standard. Some differences included:
- factoring out SPARC and Sun dependencies (which moved into "binding" documents as extensions to the standard used only on appropriate hardware) and
- switching from Forth 83 to ANSI Forth.
The Open Firmware Working Group started in 1991 with input from Apple and IBM. In 1994, IEEE 1275, the first official standard, came out and then was withdrawn in 1999 when the Working Group decided that the procedural effort of a formal reaffirmation was too high for the benefit of having formal organizational blessings. Nonetheless, the Working Group is still active producing documentation, confirming standards, and keeping everything compatible. IBM, Apple, and Sun still ship Open Firmware systems, as do many users of embedded systems based on ARM and Power Architecture CPUs. Sun's systems, which use OpenBoot 3.x, comply with Open Firmware.
Vendor sites differ in their claims that the original standard is still available from IEEE or that it isn't, but casual Web searching turns up what may (or may not) be legal copies of the document in PostScript format. The IEEE site has it for download, but requires a current subscription to access it; however, you can buy the standard (the cheapest subscription is the US$855 "Bus Architecture Standards Subscription," but the standard alone costs US$156).
The simplest answer is that OF prepares the machine to boot. It also lets the user change settings or issue simple commands before booting.
Generally, you can get to a prompt where you can issue OF commands. OF defines a basic set of necessary instructions, such as a way to get input from the user and a way to print messages. The code for getting input or printing messages will usually be device-dependent and is part of the read-only memory (ROM) associated with a given computer. However, code written to use these primitive operations is then completely portable; as long as you provide those basic tools, the rest follows.
OF also allows the system to enumerate devices attached to it. Normally, device enumeration takes the form of a tree, with each branch (node) representing a device. The operating system uses the device tree as a quick way to identify available hardware. Furthermore, during boot time, OF code might directly use devices if they have provided suitable access methods.
Each node provides at least one property (its name) and may optionally provide additional properties and methods. The specification defines some properties and methods that, if present, must have specific functions. For example, the most obvious issue is that the "name" property should contain the device's name.
A device node should at least contain enough information for the
operating system to load any driver it has for the device. Some device
nodes provide the necessary methods (open,
close, read, and
write) to use the device during boot. These
methods are effectively a primitive device driver -- they don't do
multitasking and they don't use interrupts. They might, however, be enough
of a drive to allow you to load a kernel off a disk using a SCSI
controller that has been added to the system (for which the ROM installed
in the machine has no drivers).
Computers spend a lot more time running than booting, and boot code isn't all that large. You might wonder why OF is useful and what advantages it offers over other boot firmware systems.
For system vendors, using OF instead of a proprietary boot ROM obviously gives you a significant time-to-market advantage, but it also gives you other advantages that might matter more, such as:
- Your boot ROM will be relatively bug-free and usable.
- You gain instant access to the big world of third-party devices with OF code in them.
- You can make potential device buyers quite happy (for more on this, see the last subsection in this section).
Bring the kernel up in no time
With OF, your boot ROM will actually be usable -- it won't be three or four hastily strung-together commands replete with bugs. The world is full of people who think that a boot ROM is so simple that they can write their own without thinking about it.
Most of them are wrong. Thinking is a prerequisite, especially when you've got an extremely limited number of commands in which to do the job. And more brains contributing (as with open development) can often keep lousy code from surviving past the basic rounds.
OF gives you access to a broad variety of third-party devices that have OF code in them. Because it's open, it also makes it easier for more people to develop devices for your system.
Of course, you'll want to supplement device-driver authoring with copious documentation. Still, OF means that you don't have to write 30 different sets of boot ROMs for a SCSI controller just because you want it to be bootable on 30 different systems.
Imagine, an enjoyable user experience thanks to OF
The people who buy systems and devices often use OF. "What do you mean?," you ask. "Users using the bootware?"
For example, the Internet is full of documents describing ways to make Macintosh systems do things that users want by setting preferences in OF. The ability to set permanent environment variables in memory makes users happy. As an illustration, it's OF that sets the preferred boot device or tells a machine from which disk or partition to boot. On the Macintosh, OF can set a system running OS X into a verbose mode where console messages are printed.
The user probably doesn't really need to learn much Forth to use OF, but this isn't to say some won't. Someone once wrote an implementation of Pong for the Macintosh using OF. (Not the same Pong in DisplayPostscript that was available for the NeXT.)
Now that you have a reason for using OF, look at some of the elements that give OF its distinctive flavor.
What's a standard without extensions?
A standard without extensions is a boring standard, that's what. In OF, the main extensions have to do with CPU types and bus types. For instance, OF systems running on ARM processors (yes, it runs on those, too) have a different set of requirements than OF systems running on PowerPC. Obviously, device code should not be dependent on any of these features!
Likewise, there are bus supplements. For instance, there is a standard for PCI on OF systems and a standard for USB.
The extensions are half-optional -- the requirement is that if you have the bus or processor in question, you implement the corresponding supplement. Of course, it's somewhat like being half-dead: The optional extensions really aren't optional. Why? A system with a PCI bus that doesn't use the standard PCI supplement isn't going to win you any friends. It is optional in that you aren't expected to implement full support for the SBus supplement to the OF standard on a machine that doesn't have any SBus devices.
Some practices that have been found workable and reasonable are documented as recommended practice extensions, which are not strictly required but are recommended to implementors. As an example, there are extensions to support text in color. (For more, see a complete list of recommended practice extensions on the Apple mirror of the OF Working Group site, listed in Resources with a reference to Bloom County.)
A particularly interesting extension is the "device support extensions" document that describes sound devices, NVRAM (non-volatile memory) devices, keyboards, and other common features. While this is an optional extension, it would be pretty weird for a desktop system not to have and use many of these devices. To be fair, not everyone has a SCSI bus, but most desktop systems have a keyboard. The NVRAM device is particularly useful -- it provides a standard way to store key user preferences. And this isn't just a desktop feature; an embedded system might benefit greatly from a standard way to store information about preferred serial baud rates, for instance.
You'll also find extensions for such specific devices as ISA serial ports and VGA cards.
Now look closer at the real user of the code -- the device.
OF lets you put devices in a tree. That's great. Uh, what's in the tree? Device nodes, or packages, or something. The terminology is not as clear as you might like. In the words of IEEE-1275:
A package is the combination of a device node's properties, methods and private data. In most cases, the terms "package" and "device node" may be used interchangeably. "Device node" is typically used when the emphasis is on the node as a part of the device tree, and "package" is used with emphasis on the use of the node's driver methods.
For experienced Forth users, this is substituting for the normal Forth concept of dictionaries. While this may seem strange, it works well when you're mostly interacting with devices.
Users who have looked at the device list in nearly any operating system often find the notion of a device tree familiar. The Windows Device Manager can show you a device tree (look on the View menu for Devices by connection). The Apple System Profiler on OS X shows you a device tree. For that matter, if you read the boot output of a BSD kernel carefully, you will see a lot of lines like this:
pci0 at mainbus0 bus 0: configuration mode 1 ppb0 at pci0 dev 1 function 0: vendor 0x8086 product 0x1a31 (rev. 0x04) pci1 at ppb0 bus 1 vga0 at pci1 dev 0 function 0: vendor 0x1002 product 0x4c58 (rev. 0x00) |
That's a device tree, too.
To make it a bit more exciting, a node exists in the OF device tree
called /packages that contains special packages that are opened
with open-package instead of open-device. They also do not correspond to actual
hardware. The OF spec has a complete list of standard, root-level,
non-hardware nodes.
What happens when a device is plugged in? If you want OF to do anything with it, it must have a chunk of compiled bytecode on it. This code is written in a dialect of Forth based on the 1994 ANSI standard for Forth, although the OF environment is not a "Standard System" as defined by that standard. What's happening is that the device contains a chunk of code which is run in the OF environment and if all goes well, it'll create a new device node in the device tree.
The exact way in which the device is first identified might vary from system to system. In general terms, a higher-level device node representing a bus will have a procedure to allow it to probe for child devices, at which point its code will be run and it will be attached to the bus. This process might be recursive; for instance, a USB controller might be found on a PCI bus, but the USB controller might have further devices attached to it. (The IEEE specification's example of a VME bus attached to an SBus adapter might seem a little less commonplace to readers.)
The nice part is that the code loaded into a device's ROM does not need to vary from system to system. OF uses a compiled bytecode called FCode, based on the Forth standard. The code to locate it and load it is either in the ROM for the device of which it is a child or in the system's own ROM. All the device needs to do is run correctly within a standardized environment and all will be well.
If you need a buzzword to pitch this, OF's design uses encapsulation. It's crucial that a PCI SCSI card is allowed access to the routines provided by the PCI bus device it's attached to, but that it has no direct knowledge of the system architecture. So, as long as your PCI bus driver complies with the standard, the card works!
OF also steals the idea of instantiation from the object-oriented world. A device may be reused in a few places; for instance, a PCI bus device is likely to be used in more than one place. Each time a package is opened, a new "instance" is created. Each variable within a package can be shared among all instances or have a separate copy in each instance.
This article highlighted what Open Firmware is, what it does, and why it can be a practical choice for a variety of users. It also discussed the role extensions play in OF, and illuminated how it works in devices.
The best way to learn more about OF is to practice, to get a Mac, hold down command-option-O-F when you turn it on, and just start typing.
The Resources section for this column is unusually large. A special favorite is Apple's technotes on the topic of Open Firmware. In particular, the "Fundamentals of Open Firmware" series covers a great deal of what you need to know to use or develop Open Firmware. The fundamentals are similar enough between different OF systems that the guide to using OF for device initialization and driver development is moderately portable. The standard itself is large and well-written; it is the only IEEE standard I have ever seen that contains a smiley face.
The Working Group maintains a Web site that's a little out of date (only those with a time machine and nothing to do on a Tuesday night will be able to make it to the meeting scheduled for September 14, 1999). Still, the e-mail addresses work and the people are friendly. There is also a mailing list open to people with an interest in the topic. Membership is open to "interested parties," with voting privileges available to people who participate actively.
I would like to thank Mitch Bradley for his advice and clarification of a few points in the Open Firmware spec. Errors that remain are my own.
-
The Open Firmware Working Group is a good bet for information about Open Firmware.
-
Bloom County fans will recognize the URL used for Apple's mirror of the Open Firmware material at bananajr6000.apple.com.
-
I wasn't kidding about the song either.
-
Here's where you find Pong in Forth for the Mac.
-
Apple's Fundamentals of Open Firmware technotes (Part 1, Part 2, and Part 3) give a great overview of Open Firmware.
- See the ANS Forth standard at Taygeta, which features what they call the largest collection of Forth information anywhere -- and they are probably right!
-
Like a roundup of the different types of firmware? This Wikipedia page links to resources on PC BIOS, Open Firmware, programs in ROM, and EPROM software.
-
"Linux on Mac: a POWER programmer's primer" offers insights on the differences in the way partitioning and bootstrapping works between BIOS (from x86s) and Open Firmware (Macs) (developerWorks, January 2004).
-
"Hacking Open Firmware" is a discussion group on altering Open Firmware on the Mac (August 2003).
-
The NetBSD/macppc FAQ provides a substantial Q&A on Open Firmware, booting, and boot problems.
-
For a smaller version of OF, examine Tiny Open Firmware, a Forth-based development system for ultra-flexible embedded firmware that features run-time compilation of add-on code and fine-grained patchability that enable a new class of applications.
-
"Standards and specs: Standards" introduces the specifications involved in Power Architecture technology (developerWorks, September 2004).
- Have experience you'd be willing to share with Power Architecture zone
readers? Article submissions on all aspects of Power Architecture technology from authors inside and outside
IBM are welcomed. Check out the Power Architecture author
FAQ to learn more.
- Have a question or comment on this story, or
on Power Architecture technology in general?
Post it in the Power Architecture technical forum
or send in a letter to the editors.
-
Get a subscription to the Power Architecture Community Newsletter when
you Join the Power Architecture community.
- All things Power are chronicled in the developerWorks Power
Architecture editors' blog, which is just one of many developerWorks
blogs.
- Find more articles and resources on Power Architecture
technology and all things
related in the developerWorks Power
Architecture technology content area.
- Download a IBM PowerPC 405 Evaluation Kit to demo a SoC in a simulated
environment, or just to explore the fully licensed version of
Power Architecture technology. This and other fine Power Architecture-related downloads are listed in
the developerWorks Power Architecture technology content area's downloads section.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
