Technote RTN001The Rhapsody Boot ProcessApple Worldwide Developer Technical Support |
CONTENTS
Open Firmware |
The Rhapsody Developer Release modifies the Macintosh boot process to allow both MacOS and Rhapsody to coexist on the same machine. This note details the modifications that were made to the Open Firmware configuration to support Rhapsody, and documents the process taken to load the Mach kernel. Finally, this note documents the problems of running the developer release on unsupported hardware. The information in this technote applies only to the first Developer Release of Rhapsody, and is therefore of a short term usefulness. Developer Release 2 will change a number of pieces in the boot process, and many other pieces will be altered as Rhapsody continues to evolve. This information is provided primarily to assist in debugging a Rhapsody machine that isn't booting correctly. Do not base a product on this information. The surgeon general has proven that this information causes cancer in lab rats. Caveat emptor. This note assumes some knowledge of Open Firmware. Macintosh Technotes 1044, 1061, and 1062 provide an introduction to Open Firmware on the Macintosh. |
Open FirmwareThe standard Open Firmware configuration variables are stored in non-volatile RAM (henceforth known as 'nvram'). When the machine is powered on, these variables are used to configure the machine and to boot the machine into a particular OS. Only a few of them are useful in this discussion, however.
A standard Open Firmware boot process would follow the following steps:
On Rhapsody, nvramrc has been modified to fix a few
critical driver commands and to define a new command,
If the machine is booting into Rhapsody,
If the machine boots into the MacOS, it replaces the Open Firmware configuration with the default values (which boots from the Mac ROM, and looks for a bootable MacOS drive). This has some important implications. If you do not have a bootable MacOS drive connected to the machine, the machine will halt at the flashing question mark. Worse, because the Rhapsody configuration has been wiped from NVRAM, the machine will no longer be able to boot into Rhapsody. The current solution to this problem is to always have a bootable MacOS partition on a Rhapsody development machine, and a Rhapsody control panel to write the Open Firmware configuration on startup. For detailed instructions on configuring a machine with multiple partitions, see Rhapsody technical note RTN0002: Dual Boot Installation. |
Secondary LoaderThe SecondaryLoader can be much larger than the bootr script, so it loads a more complete set of drivers and bug fixes, and loads the first actual graphic to show you that Rhapsody is being loaded. It then loads the kernel boot file, copies it into memory, and executes it. The kernel, like other executables on Rhapsody is in Mach-O format. If the secondary loader fails to find the kernel file at
the location specified by While any partition could theoretically be specified for the boot file, the current build of Rhapsody is only aware of the first Apple_Rhapsody_UFS partition it finds. Currently, you should not place multiple UFS partitions on the same device. The SecondaryLoader picks up the kernel command line arguments from open firmware. The SecondaryLoader also checks for the 's' key (single-user) and 'v' key (verbose), booting the kernel with those additional parameters as necessary. The 'v' key will also cause the SecondaryLoader to print out some additional debugging messages to the output device. Here are some commands the SecondaryLoader recognizes:
And settable values:
Finally, the SecondaryLoader changes the boot-command to
|
The KernelThe kernel treats the video device as a large frame buffer, and uses its own graphics code and fonts to present a terminal showing the status as the kernel loads. If the kernel is loaded in "verbose" mode, then it will provided detailed explanations as it searches out the various devices attached to the machine. Overall, verbose booting is recommended when doing development or diagnosing problems on a Rhapsody system. Currently, the PPC build loads a fixed set of drivers to configure the hardware. As the new driver model evolves, the PPC version of Rhapsody will dynamically load drivers as necessary. As devices are scanned, they are assigned an abbreviation
that can be used to refer to the device. The two most common
abbreviations are In most cases, the root device is going to be
|
Appendix - Unsupported HardwareThe following list of PowerMacintosh compatibles are based off of the PowerMac 9500, and may be able to run the Rhapsody developer release. Some clones used different CD-ROM drives, SCSI controllers or other incompatible hardware. The table below provides some information about specific configurations that have been used in the past; others are listed, but have never been tested. While it may be possible to get DR1 to work on unsupported configurations, there are limitations to the level of support that can be provided. Many bugs were fixed between DR1 and DR2, so any bugs found in DR1 should also be tested on a supported machine running DR2 before being reported. IXMicro Video CompatibilityMany of the compatibles are using variations of the IXMicro Twin Turbo card. In some cases, the initial console window will come up with an alternating display of garbage and console data. Once the machine finishes loading the kernel and initializing all of the processes, it will switch to the correct mode and everything should appear fine. Power Macintosh Compatibles
|
Thanks to Dan Peterson, Michael Prichard, Deborah Grits, Eric Simenel, Quinn "The Eskimo" and Eryk Vershen