Open Firmware runs on many different architectures:
- x86
- PowerPC
- StrongARM
- SPARC
- MIPS
- Alpha
- 68000
Open Firmware takes care of all machine initialization, no other BIOS code is required, not even on x86 machines.
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).
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:
- EXT2
- Mac HFS
- ISO 9660 CD-ROM file system
- DOS file system
- Unix file system
- NFS
- "ROM dropin" file system
- Macintosh partition format
- FDISK partition format
- Unix partition format
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.
- TFTP
- HTTP
- NFS
- BOOTP
- DHCP
- TELNET
- PPP
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.
We have support for many different image formats:
- ELF
- PE
- FCode
- Forth source
- bootinfo
- a.out
- raw binary
- AIF
Open Firmware provides a rich array of debugging features:
- Source level debugger
Breakpoint, single-step and trace high-level Forth code. Unlike some public-domain Forth debuggers, this one works well and reliably.- Assembly Language Debugger
Breakpoint, single-step and trace machine language code.- FCode debugger
Debug and trace FCode as it is being detokenized from device ROMs.- Forth stack tracing after an exception
Find out what happened after something goes wrong.- Missing method reporting
Find out what happened after a non-existent method was called.- Client service debugging and tracing
Debug the interaction between the OS and the firmware.- RTAS call tracing
Debug the interaction between the OS and the firmware.- Patch utility
Extremely useful for fast debugging, experimental changes, and NVRAM-based workarounds.- Architecture specific interactive assembler
Create custom machine code sequences for hardware testing. Each implementation comes with a native assembler built into the firmware.- Architecture specific disassembler.
Inspect code sequences in the firmware and OS. We also have support hooks to do symbol table lookups.- Startup tracing
Under control of a (software or hardware) diagnostic switch, the the firmware reports its progress through its initialization sequence.- Early startup interruption/debugging
Under control of a (software or hardware) diagnostic switch, the firmware gives the developer interactive control at a very early stage of the initialization sequence, allowing easy debugging of startup problems.
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:
- Super-driver supports many video chips
- Various SCSI host adapters
- Various Ethernet chips
- Various sound chips
- PCMCIA/Cardbus bridges
- Most common ISA devices
- Various NVRAM and EEPROM devices
- Various PCI host bridges
- Various FLASH parts
- ADB and PC keyboards
- ADB, PS/2, and serial mice/trackballs
There is a simple graphical user interface with buttons for common operations like booting and installation.
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.
Hierarchical help system for firmware functions; stored in a ROM dropin module so it consumes very little RAM space.
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.
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.
Debug problems with the network setup by tracing the progress of the network booting protocols.
Support for multiple fonts (different glyphs, different sizes).
Makes it easy to support multiple NVRAM formats (PR*P and CHRP) and to migrate to new formats as needed.
As described in 1275-1994; prevents unauthorized use of firmware to compromise network security.
The terminal emulator code can be instantiated on several different displays at the same time.
Makes NVRAM accesses fast even if NVRAM is implemented in a slow hardware technology (like EEPROM or spare FLASH).
For convenient editing of NVRAM script.
For convenient modification of long configuration variables.
There are versions of our memory allocators that handle system buses with >32-bit address spaces.
We have support for some remote C source-level debuggers.
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.
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.
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.
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.
The firmware can program FLASH ROMs from an image that can be loaded from any device or file (disk, CD-ROM, network, ...).
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.
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.
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.
The RTAS implementation is small and efficient. It is built using the same builder tools that build the firmware.