FireWire Target Disk Mode talks to SCSI (and SATA too ?)

As already suggested back in April the implementation of the FireWire Target Disk Mode is generic enough to serve any bootable hard disk drive, if you ask it politely using the second script named Set HD to start volume in OF.

To verify this I've dug out my SyQuest removable hard disk drive that hasn't been in use for several years, set it up as target on a Power Mac G4 with an Adaptec 2930 CU Ultra SCSI PCI card and gained full access to it from a Mac Book Pro using FireWire, as if the drive and the notebook (which of course doesn't have any SCSI interface) had been directly connected.

Therefore target-mode should also be able to address drives on SATA PCI controllers, despite any contrary claims often repeated but never challenged.

Trying to access an (ATAPI) optical drive instead of a hard disk failed — all of the CDs and DVDs I've checked out didn't show up on the host, or without their contents. Newer incarnations of the target disk mode offer the hard disk and the optical drive at the same time, as two units. Does somebody know which was the first version (in a Power Mac G4) to implement this ?

Leos Little Helper: Script to install Leopard below 867 MHz

The following AppleScript (available for download) is an aggregation of the first two articles on this subject, condensed into a double-clickable application that might even work on PowerBook G4 computers in need of it.
The PowerBook support is a contribution from an article at InsanelyMac authored by their member rdemby (as far as I can tell — at least it's the oldest reference I found using max-clock-frequency).

-- The required FCode gets executed as part of the "boot-command". Its first action is to reset this variable to its default value so the change of the perceived CPU frequency will never survive the next restart – no permanent settings are made.
(A similar technique is used by the "Target Disk Mode" option in the "Startup Disk" pane of the "System Preferences".)

-- "max-clock-frequency" is preferred over "clock-frequency" as it seems to be used by older PowerBooks to describe the nominal CPU speed. No tests have been run yet on such hardware in the given form.

do shell script "nvram boot-command='set-default boot-command dev /cpus/@0

d# 867000000 encode-int \" max-clock-frequency\" 2dup active-package find-property

0= if 2drop \" clock-frequency\" then property device-end multi-boot'" with administrator privileges

tell application "System Events" to restart

PS: On a dual CPU system the clock-frequency will be duplicated by the OS from the first to the second CPU so this script is sufficient to satisfy the installer regardless of the number of G4s.

Exchange HD and CD in Open Firmware

Open Firmware uses a table of device aliases to abstract from the machine-specific and long nomenclature derived from the device tree. screen for example is defined as the first display of the first graphics card found and is used for any output from the boot ROM (as the Open Firmware console or the gray Apple logo shown when booting Mac OS X). The device aliases can be seen using devalias at the Open Firmware command prompt or ioreg -bp IODeviceTree -n aliases in the Terminal.

In a Cube hd and cd are predefined as the master respectively slave ATA drive and are used by most components accessing those drives, including FireWire Target Disk Mode and booting or ejecting a CD. There is no automatism to adapt these aliases when master and slave are exchanged, but devalias can be used to update them.

At the Open Firmware command prompt two commands like devalias hd /pci@…/disk@1 and devalias cd /pci@…/disk@0 (using the complete path as determined above) can be used to temporarily correct the situation; nvalias … instead of devalias … would add the new values to the nvramrc making them a part of every system start.

I've wrapped a portable variant of the required statements in a script called Exchange HD and CD in OF (available for download as target-mode.zip) that can be launched from the Finder. Before extending the nvramrc it verifies that

1. Mac OS X has been booted from a slave drive,
2. hard disk and optical drive are on the same ATA bus and
3. devalias hd still names a master drive

to protect the innocent (but don't run it twice in a row):

#! /bin/bash -

[[ `ioreg -p IODeviceTree -n chosen -w0 | fgrep bootpath` = *@1:* ]] || exit

while IFS=\" read -ra devalias; do
    [ "${devalias[1]}" = hd ] && hd="${devalias[3]}"
    [ "${devalias[1]}" = cd ] && cd="${devalias[3]}"
done << aliases
`ioreg -p IODeviceTree -n aliases -w0`
aliases

[ "${hd%@*}" = "${cd%@*}" -a "${hd##*@}" = 0 ] || exit

echo '
This script tells Open Firmware that your optical drive is configured
as master and your hard disk drive as slave instead. This information
is needed by the FireWire Target Disk Mode as well as the keys for
booting or ejecting a CD.'

read -rd $'\0' nvram nvramrc << nvramrc
`nvram nvramrc 2>&-`
nvramrc

sudo nvram 'use-nvramrc?=true' nvramrc='dev /aliases
" hd" active-package get-package-property 0= if
" cd" active-package get-package-property 0= if
" hd" property " cd" property then then device-end'" $nvramrc" &&
echo 'Target Disk Mode & friends can be used again.'
sudo -k

I've thrown in a second script Set HD to start volume in OF as a free bonus that redefines devalias hd to the device Mac OS X has been started from if both differ, but performs no further checking. It is intended for PowerMacs other than a Cube (because the definition of cd remains unchanged); my Sawtooth happens to boot from the second hard disk. Judging from a glance at the code I expect the Target Disk Mode to be able to work with any drive that could also be booted from, like SCSI or SATA drives connected to a PCI card:

#! /bin/bash -

IFS=\": bootpath=(`ioreg -p IODeviceTree -n chosen  -w0 | fgrep bootpath`)
IFS=\"       hd=(`ioreg -p IODeviceTree -n aliases -w0 | fgrep \"hd\"  `)
unset IFS

[ "${bootpath[3]}" != "${hd[3]}" ] || exit

echo '
This script tells Open Firmware to access your boot disk drive through
FireWire Target Disk Mode (instead of the ATA master).'

read -rd $'\0' nvram nvramrc << nvramrc
`nvram nvramrc 2>&-`
nvramrc

sudo nvram 'use-nvramrc?=true' nvramrc="devalias hd ${bootpath[3]}
$nvramrc" &&
echo 'Target Disk Mode can be now used to access the boot disk drive.'
sudo -k

Target Disk Mode can work if HDD is set to Slave

Target Disk Mode uses the device specified by the "hd" devalias of the Open Firmware which defaults to the master on the (primary) IDE controller. Similarly the boot keys "c" (for starting from the optical drive), the eject key as well as the mouse button rely on the "cd" devalias to name the CD/DVD drive; therefore a Cube predefines this as the slave drive on the same cable as the hard drive (whereas most other Mac types use the master on the secondary IDE bus).

When both drive types get exchanged (HD addressed as slave and CD as master) the (contents of the) corresponding devaliases have to be redefined too using for example nvalias to store the new definitions permanently into the nvramrc to keep Target Disk Mode & friends working. This is of course optional as the Mac OS itself doesn't care about the devaliases.

Given the drives work together in this setup there will be no further need for the hardware modification of pin 28.

Uninstalling Firmware

With the given script it is possible to reflash the same (or even an older) version of a plain Apple firmware and thereby remove any patches by third-party vendors.

It is important that this must only be done on a system without a CPU upgrade (using the 7447 and 7448) that requires firmware patches. The Mac would be dead until the reinstallation of an original G4 or other type of accelerator !

NVRAMRC patches for booting into Mac OS 9 will survive a flash, but can get cleared using Command-Option-P-R. Other similar patches (as the lba-48 property) would have to be reapplied.

Retro-fitting old FirmWare and re-installing the newer

Searching through my CD archive I've found two different versions of the firmware updaters for the PowerMac G4 and the Cube (as well as the iMac, iBook, PowerBook and even a G3) on Mac OS install CDs:

Mac OS	PowerMac	Cube
9.2.1	4.1.8	4.1.8
10.1	4.1.8	4.1.8
10.2	4.2.8	4.1.9
	(both are still current)

Using them I successfully downgraded the firmware of a Sawtooth from the current 4.2.8 to the older 4.1.8 and back to 4.2.8 again. Further analysis of the code shows that it will only flash a firmware with the same major version as in the ROM (or upgrade from 3 to 4 as a special case). Even the firmware from another model would be accepted — Never ever try such a crossflash as it will most likely leave the motherboard completely dead and therefore without a possibility to correct the flash !

The firmware NVRAM variables will survive the flash, including any NVRAMRC patches (as the lba-48 property), but do NOT flash a plain firmware with a (7447 or 7448 based) CPU upgrade that requires its own patches.

While at it I also tested manually booting the flasher from the Open Firmware command prompt. With one of the CDs from the table above (or a CD-R with just the "Firmware" file) it is possible to upgrade or reflash the firmware without any Mac OS on the system !

No Macintosh was harmed during the making of this post.

Running Firmware Updaters from Mac OS X

Judging from my analysis of the Firmware Updaters for various G4 (including the cube) it should be surprisingly easy to run those flashers officially "requiring" Mac OS 9 from OS X instead !

The "Firmware Updater" included in such a download does NOT perform the flashing, but only checks if the update can be applied ("Firmware" file supports the Mac model and has a newer version) and arranges to restart the Mac into the "Firmware" file. This file not only contains the new firmware image, but in front of it also the complete program required to flash the ROM. The flasher is written (mostly) in FCode source allowing deep insights into its inner workings (if Forth is your kind of bedtime reading).
All of this means that the flasher runs in the context of the Open Firmware before any part of (any) Mac OS is even loaded and does NOT depend on a specific version. It should therefore be possible to simply boot a copy of the "Firmware" file on a hard disk from the Open Firmware command prompt.

In order to make this process painless to comply with I've created a short script (available for download as fwupdater):

#! /bin/bash -

flasher='/Volumes/G4 Cube Firmware Update/G4 Cube Firmware'

cp -ip "$flasher" /TrashMe || exit

 preferred=(`nvram boot-device`)
IFS=\",  bootpath=(`ioreg -p IODeviceTree -n chosen -w0 | fgrep bootpath`)

sudo nvram boot-command=mac-boot boot-device="${bootpath[3]},\\TrashMe" \
 preferred-boot-device="${preferred[1]}" &&
osascript -e 'tell application "System Events" to shut down'
sudo -k

It first copies the "Firmware" file to the root of the boot disk and carefully sets it up as boot-device so the flasher will run on the next system start, even it is on a slave ATA disk or maybe an external firewire drive. The flasher will restore the former boot-device after it's done. No verification is performed, but the flasher will roughly test for compatibility on its own.

Steps to follow while logged in as an administrator:

1. Download the updater. English is assumed, but the firmware itself is not language dependent.
2. Print the instructions while still on this page.
3. Open the disk image so it will appear on the desktop.
4. Open fwupdater from the Finder. It will launch in a Terminal window and ask for your password so the boot device can be set. After that the Mac will be shut down.
5. Closely obey the printed instruction on turning on again while holding the programmer's button (beginning with step 4).
6. The flasher will restart the Mac after the update. Use the System Profiler to verify the new Boot ROM Version.
7. Delete "TrashMe" from the root of the boot disk.

The script can be used for other PowerMacs with Mac OS 9-based firmware updaters, if the pathname at the top is set to the correct "Firmware" file.

IMPORTANT: I don't have a PowerMac requiring an update anywhere near me, so my tests couldn't include the flashing itself, and were only performed under Leopard. I'm confident that the method described here does work (under any version of Mac OS X), and it eliminates the need to "borrow" (or buy) and install Mac OS 9 when a firmware update is all that is needed.
Volunteers ?

Myths that won't die …

Mac OS X virtualizes video RAM and will NOT partition it between two monitors, even if some older tools claim otherwise. Video RAM gets assigned to whatever needs it, so with two monitors connected an application can still use nearly all of your 256 MiB (minus the frame buffer for the second monitor, a few window images from Quartz Extreme, etc). Core Image and Quartz GL should be able to make good use of all the free VRAM.

MacOS 9 did split the VRAM between two active monitors. These different behaviors can be seen with "ATI Displays" on Radeon cards under both systems.