Skip to main content

skip to main content

developerWorks  >  Power Architecture technology  >

Standards and specs: Open Firmware -- the bridge between power-up and OS

Why open bootware may be more practical than the proprietary

developerWorks
Document options

Document options requiring JavaScript are not displayed


Rate this page

Help us improve this content


Level: Introductory

Peter Seebach (crankyuser@seebs.plethora.net), Author, Freelance

26 Oct 2004

Open Firmware provides a reasonably standardized way for computers to find hardware, configure it, and boot an operating system. In this month's Standards and specs, author Peter Seebach looks at the Open Firmware spec, traces its history as a standard, examines how it works and some of its components, and discusses the benefits it offers.

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.

Firmware, Open Firmware

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).



Back to top


What does OF do?

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).



Back to top


Of what practical use is OF?

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.

Features, FCode booting

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.



Back to top


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.



Back to top


Hierarchical dev-info tree

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.



Back to top


Conclusion

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.



Resources



About the author

Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though. You can contact Peter at crankyuser@seebs.plethora.net.




Rate this page


Please take a moment to complete this form to help us better serve you.



YesNoDon't know
 


 


12345
Not
useful		Extremely
useful
 


Back to top