FirmWorks Open Firmware Features

The Open Firmware provides a very powerful set of tools for OS support, firmware developers, OS debugging and end users. Most of the following features can be included in the ROM during early development and later omitted from the production image to save ROM space. If need be, removed features can easily be reloaded later as needed.

Supported Architectures

Open Firmware runs on many different architectures:

BIOS Can Be Eliminated

Open Firmware takes care of all machine initialization, no other BIOS code is required, not even on x86 machines.

Kernel Loading

Open Firmware supports the loading of the Linux kernel from any number of storage devices connected directly to the hardware (hard disks [IDE or SCSI], compact flash, flash) or from over a network interface (ethernet, token-ring).

File System Support

The user-level file management commands are coded using an abstract interface to file-system-specific support routines, so the same file commands apply across different file system types:

Protocol Support

Open Firmware has an extensive TCP/IP stack with many supported interfaces: With HTTP, the firmware can not only use HTTP protocols to fetch files for booting using URL specifiers, but we can also configure the firmware to respond to HTTP requests and send HTML responses. This feature can be used for remote, via the WEB, hardware testing and administration.

The same is true for Telnet. We can setup the firmware as a Telnet server so that all IO to and from the firmware user interface can be directed over the network.

Modular Load Format Support

We have support for many different image formats:

Debugging Features

Open Firmware provides a rich array of debugging features:


NanoForth, is an interactive subset of Forth that uses only registers - no memory is needed. For I/O, it uses either a serial port or the emulated serial port inside a Grammar Engines "PROMICE" ROM emulator. This gives you the ability to do interactive debugging on hardware where the only thing that works is the CPU and ROM. We find that this tool can shave a LOT of time from the early phases of hardware bringup. It includes a large set of interactive memory tests that help you discover problems like address and data line shorts, cache burst problems, etc. It has a scripting facility that lets you construct "canned" initialization sequences.


Open Firmware supports many standard PC and CHRP devices:


There is a simple graphical user interface with buttons for common operations like booting and installation.

OS Installation Tools

There are a variety of tools to assist in installing or upgrading an operating system, so you can do an installation "from scratch" on a bare system.

Modular Help

Hierarchical help system for firmware functions; stored in a ROM dropin module so it consumes very little RAM space.

Modular Chained Initialization

The initialization sequence is structured in such a way that functional modules or drivers can be omitted without having to edit a global initialization function.

Run/Debug Firmware Images Under an OS

The bulk of the firmware image can be executed in an OS environment, allowing easy debugging of device-independent code and inspection of build results.

Net load Debugger

Debug problems with the network setup by tracing the progress of the network booting protocols.

Multiple Font Support

Support for multiple fonts (different glyphs, different sizes).

Format-independent NVRAM Support

Makes it easy to support multiple NVRAM formats (PR*P and CHRP) and to migrate to new formats as needed.

Password Security

As described in 1275-1994; prevents unauthorized use of firmware to compromise network security.

Support for Multiple Simultaneously-active Displays

The terminal emulator code can be instantiated on several different displays at the same time.

NVRAM Caching

Makes NVRAM accesses fast even if NVRAM is implemented in a slow hardware technology (like EEPROM or spare FLASH).

NVRAM Script Full-screen Editor

For convenient editing of NVRAM script.

Configuration Variable Editor

For convenient modification of long configuration variables.

Support for 32-bit and 64-bit Memory Addressing

There are versions of our memory allocators that handle system buses with >32-bit address spaces.

GDB and DBX Interfaces

We have support for some remote C source-level debuggers.

"Dropin module" ROM Structure

Our ROM images consist of a set of self-identifying independently- compiled "dropin modules" which are pieced together by concatenation. This allows us to separate the platform-dependent bridge and memory startup code from the generic part of the firmware, and makes it easy to add or delete FCode drivers and optional modules. This structure makes it easy to maintain consistency in our source base while still doing the necessary platform-specific adaptations.

Dropin Manager

The firmware and the build system both contain tools to manage dropin modules. The builder knows how to create, list, and splice them together. The firmware knows how to locate, list, load, and execute them.

"gunzip" Auto-inflation for Load Images and Dropin Modules

Dropin modules can be compressed or not, and are automatically decompressed if necessary. The decompressor is itself a module. Load images can also be compressed, and will be automatically decompressed if necessary. This can speed up the OS load time, because the decompressor is faster than many I/O devices.

Builtin-driver Manager

The firmware has a convenient mechanism for including and binding surrogate FCode drivers for devices that do not have their own FCode. This mechanism is integrated with the dropin module structure, so you can add such drivers to a firmware image without recompiling anything.

FLASH Programming Utility

The firmware can program FLASH ROMs from an image that can be loaded from any device or file (disk, CD-ROM, network, ...).

Modular Builds Maximize Platform-independent Code Set

Our code structure and firmware build process attempt to maximize the commonality between different platforms. We have maintained a single code base across many different CPUs, system architectures, and platforms.

Self-consistent Incremental Builds

Our build process proceeds in a series of self-consistent phases. The output of each phase is a functional firmware image that can be executed and tested interactively. The phases are: Forth kernel, extended Forth toolset, basic 1275 firmware core, system architecture (e.g. CHRP) generic firmware, complete platform-enhanced firmware. The early stages of the build hardly ever change, and are absolutely identical across different platforms within a family.

Self-hosting, OS-independent Builder with Integrated Tokenizer

Our firmware build process is totally self-contained, requiring no outside programs. The builder includes a Forth cross-compiler, incremental compiler, FCode tokenizer, dependency manager (like "make" but dependency management is automatic), release list support, compressor, and dropin manager. The builder is easily portable and runs on a wide variety of different CPUs and host OSs (it is an extension of the exact same Forth core toolset that is embedded in the firmware). It also has a PowerPC instruction set simulator that will let you execute the compiled PowerPC firmware images on other CPUs.

Small, Efficient RTAS Implementation (with self-hosted compilation)

The RTAS implementation is small and efficient. It is built using the same builder tools that build the firmware.