FirmWorks has developed a powerful implementation of IEEE Std. 1275-1994 "Open Firmware" boot firmware that has many advantages over other available implementations. Among others, the FirmWorks Open Firmware implementation (OFW) supports booting:
The FirmWorks OFW includes a robust suite of bringup and debug tools that contribute to reduced new product development cycles and quick time to market. Its compact size permits the use of smaller ROM parts resulting in reduced manufacturing cost.
A primary design goal of the FirmWorks OFW has been development of a technology that will reduce the cost of firmware development, deployment, maintenance and support for products incorporating this OFW.
The FirmWorks OFW provides key benefits including the following:
These two benefits are made possible by:
Due to the small size of FirmWorks's compressed ROM image and its ability to decompress itself "on the fly" at boot time, our customers are able to minimize their ROM size resulting in significant hardware cost savings on every unit shipped.
The most important features and functions of this code base, beyond basic system/OS booting, are outlined below. An additional feature list follows.
Breakpoint, single-step and trace high-level Forth code. (Unlike some public-domain Forth debuggers, this one works well and reliably).
Debug and trace FCode as it is being detokenized from device ROMs.
Used to find out what happened after something goes wrong.
patch
utility
Instead of requiring a re-compilation to correct errors in Forth words,
patch
is an extremely useful way to correct Forth dictionary errors "in place". This enables fast debugging and experimental changes in the development lab as well as enabling correction of OFW ROM errors in the field.
Under control of a (software and/or hardware) diagnostic switch, the firmware reports its progress through its initialization sequence.
Under control of a (software and/or hardware) diagnostic switch, the firmware gives the developer interactive control at a very early stage of the initialization sequence, allowing easy debugging of start-up problems.
This feature enables the firmware to locate the desired device node even though the user entered an abbreviated pathname. This saves significant time and frustration for developers. The use of abbreviated pathnames also helps with code portability, because the user can specify partial pathnames in source code so the code doesn't have to change if the parent structure of a device changes.
FirmWorks's ROM images consist of a set of self-identifying independently-compiled "drop-in modules" which are pieced together by concatenation. This allows FirmWorks to separate the platform-dependent bridge and memory start-up 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 the source base while still doing the necessary platform-specific adaptations.
gunzip
auto-inflation for load images and drop-in modulesLoad images and drop-in modules can be compressed or not, and are automatically decompressed at boot-time if necessary. The decompressor is itself a module. This can speed up the OS load time, because the decompressor is faster than many I/O devices.
builder
with integrated tokenizer
The firmware build process is totally self-contained, requiring no outside programs.
builder
includes a Forth cross-compiler, incremental compiler, FCode tokenizer, dependency manager (like
make
, but dependency management is automatic), release list support, compressor, and drop-in manager.
builder
is easily portable and runs on a wide variety of different CPUs and host OSes. (It is an extension of the same Forth core toolset that is embedded in the firmware). It also has an instruction set simulator that allows execution of a compiled firmware image on CPUs that are different from the target CPU (e.g. run PowerPC firmware on a SPARC processor).
Additional beneficial features and functions of the FirmWorks OFW implementation.
Enables the user to recall a previously entered command (like the
doskey
utility) and to re-execute the command, before or after modifying it with the command line editor. Using a simplified collection of editing keystrokes based upon the
emacs
editor, the user can easily modify even long commands lines. A real time saver in the development lab.
Enables user to type the beginning of a command and then press a single key to instruct the firmware to type the balance of the command. If multiple completion possibilities exist, the firmware can display all possibilities to assist the user in selecting the correct choice.
Breakpoint, single-step and trace machine language code.
Find out what happened after a non-existent method was called.
Create custom machine code sequences for hardware testing. (Includes both PowerPC and 68K assemblers on CHRP platforms.)
Inspect code sequences in the firmware and OS.
Inspect code sequences inside the OS.
Find all the places where a Forth word is called.
Find all the Forth words with a given substring in their names.
Find all the device methods with a given substring in their names.
Search disks and partitions to locate a particular file (by name or other criteria).
Include tools to use during compilation that are then removed prior to final delivery.
Restore removed word names for after-the-fact debugging.
Simple exercisers for sanity-checking various devices.
alarm
displayInspect the list of functions that are executed periodically.
The hierarchical help system for firmware functions is stored in a ROM drop-in module so it consumes very little RAM space.
Platform-specific bridge/memory start-up code is stored in a separate ROM drop-in module so the base firmware module is identical across platforms.
A suite of memory tests that can be directed at any memory-like device.
The initialization sequence is structured in such a way that the sequence is automatically modified whenever a functional module or driver is added to or removed from a given system.
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. Through the use of FirmWorks's instruction set simulator, the host system need not even be the same processor type as the target system (e.g. run StrongARM code on a SPARC processor).
Debug problems with the network setup by tracing the progress of the network booting protocols.
Direct console output to multiple devices at the same time. Collect console input from multiple devices.
Collect diagnostic output into a buffer for later display (e.g. in a dialog box).
General-purpose wildcard string matching package (e.g. used with file management commands).
Support for multiple screen fonts (different glyphs, different sizes).
General-purpose list management package which makes it easier to maintain memory and address space managers.
General-purpose extensible mechanism for handling typed data like configuration variables and property values.
Makes it easy to support multiple NVRAM formats (e.g. PR*P and CHRP) and to migrate to new formats as needed.
As described in IEEE Std. 1275-1994, the security functions prevent unauthorized use of firmware to compromise network security.
Debug/maintenance feature that allows code fragments to "trigger" on the creation of specific properties or specific property values. Useful for creating device-specific bug workarounds.
Speeds the development and debugging of new drivers and features.
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 (e.g. EEPROM or spare FLASH).
For convenient editing of the NVRAM script.
Instead of having to delete an existing configuration variable and re-enter it completely,
editenv
enables the user to modify an existing variable definition using the same editing keystrokes as the command line editor.
Allows automatic insertion of workarounds in NVRAM under program control.
Allows execution of arbitrary code for each device node within the device tree or any subtree thereof.
Makes a list of pathnames of devices that match some criterion, and lets the user choose one and paste the full name in a command.
Lets the user direct the debugger console to a serial port even though the "real" console is going somewhere else, like to the screen. This is useful for debugging the interaction between the OS and the firmware.
begin-select
and
iselect
Extremely handy tools for debugging device drivers with broken
open
methods. Automatically perform all device setup except for the (broken)
open
method which the user can then debug with the Forth source level debugger.
Lets the user execute arbitrary code during the process of calling methods. Useful for debugging, profiling, and so forth.
Displays a trace of all method calls.
The output of
.properties
is "pretty printed" in a format that shows the user the structure (i.e. data types) of most common property values.
Allows the Forth dictionary to consume only as much RAM space as it actually needs, instead of having to pre-allocate enough to handle the maximum I/O configuration
Note: To date, this feature has been turned off for PowerPC, because it can't work in real mode, but it could be turned on if one were to give up on real mode (which Mac OS doesn't need).
There are versions of the memory allocators that handle system buses with 32-bit and 64-bit address spaces.
The assembly language debugger has some (not very elaborate) support for setting breakpoints on ROM locations, which is useful for debugging early start-up problems with Mac OS.
Whenever the firmware is displaying information on the screen, the display process is paused after every screenful of data. The user may then display the next line, the next screen or may terminate the display process.
Increases developer productivity by enabling the interactive use of control structures that normally may only be used inside Forth definitions.
.wav
file player.
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. Currently supported types include:
Support for a many different image formats including:
Support for some remote C source-level debuggers.
The firmware and the build system both contain tools to manage drop-in modules.
builder
knows how to create, list, and splice them together. The firmware knows how to locate, list, load, and execute them.
The firmware has a convenient mechanism for storing FCode drivers in the system ROM and then binding those drivers to plug-in devices that do not have their own FCode ROM. This mechanism is integrated with the drop-in module structure, so the system manufacturer can add such drivers to a system's firmware image without recompiling anything.
The firmware can program FLASH ROMs (both boot ROMs and Mac OS toolbox ROMs) from an image that can be loaded from any device or file (e.g. disk, CD-ROM, network, etc.).
The FirmWorks code structure and firmware build process attempt to maximize the commonality between different platforms. FirmWorks maintains a single code base across many different CPUs, system architectures, and platforms.
The 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:
The early stages of the OFW build hardly ever change, and are absolutely identical across different platforms within a family.
For systems with multiple copies of identical devices, such as server configurations with multiple host bridges or disk farms, we have a space-saving feature that allows multiple device nodes to share the same copy of their method code while still maintaining some node-specific data and methods.
The user can embed executable reminders in the code which will provide notice at build time that something needs to be added or removed or fixed.
obp-tftp
automatically supports both DHCP and BOOTP serversThe network protocol stack supports not only BOOTP/TFTP, but also the DHCP extension to BOOTP, which allows the server to dynamically assign IP addresses (this is especially useful for mobile computers).
Using the GUI toolkit, FirmWorks has created a simple graphical user interface with buttons for common operations like booting and installation. Customers can use this GUI, or can use it as example code for the construction of their own versions using the GUI toolkit.
A variety of tools to assist in installing or upgrading an operating system, so an installation can be done "from scratch" on a bare system.
Support for 620-class (PowerPC 64-bit architecture) processors.
For CHRP platforms, the RTAS implementation is small and efficient. It is built using the same builder tools that build the firmware.
On CHRP platforms, debug the interaction between the OS and the firmware.