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.

Steps for booting from drives other than the primary CD/DVD

The following is a small variation of the method from the first article:
Instead of assuming that the Mac OS X Install DVD can be booted from the built-in optical drive connected in the standard location the following code (downloadable as 867MHz.txt) brings up the systems boot menu to start the installation from any accessible boot device, including for example external DVD drives, FireWire hard drives and even NetInstall servers.

\ Claim first CPU runs at 867 MHz, and let the user select the Install DVD:
dev /cpus/@0 d# 867000000 encode-int " clock-frequency" property
multi-boot

boot cd:,\\:tbxi has been replaced by multi-boot; the other changes are purely cosmetic.

Steps to perform (as previously described):

1. Move the file 867MHz.txt to the root of the primary partition on your master drive (originally Macintosh HD, where the System folder usually resides).
2. Reboot
3. Press and hold Command-Option-O-F until you enter the Open Firmware monitor.
4. At the Open Firmware command prompt ("0>") enter boot hd:\867MHz.txt.
5. Now it is your responsibility to select the Mac OS X Install DVD, wherever you placed it.

I still recommend the first method in most cases, but the steps here can be helpful when your Mac doesn't have an internal DVD drive.

I'm convinced that any changes to the nvrams content should be avoided for the application of this technique because they carry the risk of complications, might not be removable as clean as it seems on the first sight and the installer on the DVD only has to be fooled once — keep a simple trick easy !
(This modification will never survive the next reboot.)

PS: I don't think an adjustment is necessary for dual CPU systems as any Apple-supplied configuration has both CPUs running at the same clock so I expect the installer to only check the first one. Has anybody tried this ?
(Otherwise see the first article.)

Using 128 GiB or Larger ATA Hard Drives

Mac OS X has been able to use parallel ATA disks larger than 128 GiB using the extended 48-bit Logical Block Addressing (LBA) since version 10.2, if it is also supported in the Open Firmware for booting the OS (Apple support article 86178, but xlr8yourmac.com lists more systems with native support).

Open Firmware signals this capability by the presence of a simple property in the device tree at the ATA controllers node. Since this is not a hardware limitation adding this property will enable certain older Macs to use large hard disks using the driver included in Mac OS X.

The following script (available for download as enable-lba48) can be launched from the Finder and will insert the required FCode (shown in single quotes after nvramrc=) in front of the nvramrc, as this property must be set on every system start:
(An administrator password is required to set nvram variables.)

#! /bin/bash -

[[ `kextstat -lb com.apple.driver.KeyLargoATA` = *KeyLargoATA* &&
   `ioreg -p IODeviceTree -n ata-4 -w0`  != *lba-48* ]] || exit

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

sudo nvram 'use-nvramrc?=true' \
nvramrc='dev mac-io/ata-4 0 0 " lba-48" property device-end'" $nvramrc" &&
echo '48-bit LBA support will be enabled on the next reboot.'
sudo -k

The script first verifies that the KeyLargoATA driver is used (the Key Largo south bridge hosting two ATA controllers was first introduced in the Sawtooth) and the property named lba-48 has not been set so far (indicating an older firmware limited to 28-bit LBA). It will only do this for the ATA-5 Ultra DMA/66 bus (where the hard disks are usually connected); replacing both ata-4 with ata-3 should enable support for large hard disks on the secondary bus used for optical and zip drives (although running large disks on the slow bus doesn't really make sense).

After a reboot large drives will get tagged with a property named extended LBA capacity and the full number of blocks as its value. The command line

ioreg -c ATADeviceNub | fgrep -1 "extended LBA capacity"

can be used to show the recognized drives which must be repartioned in Disk Utility to use the full capacity.
CAUTION: This will erase all data on those drives !

I'm running this configuration with a new WD 500 GB drive in a Sawtooth under Mac OS X 10.4.11 and 10.5.1 for a few weeks now without any problem. It should also work on other Macs without 48-bit LBA support built before 2002 as the PowerMac G4 or the Cube, maybe even the latest PowerBook G3. I'd like to see some feedback on this topic.

Advantages of this method:

• The required driver is already installed with Mac OS X (and has been there since 10.2).
• Future system updates won't break the systems own driver.
• Even the installation CD/DVD has the driver and can be used for a volume check or a restore from a Time Machine backup.

Disadvantages:

• (Native) MacOS 9 doesn't know (and care about) the lba-48 property so it will NOT be enabled to recognize storage beyond 128 GiB (the limit of 28-bit LBA) — I didn't mind, but Apple hints in the support article given above that the MDD comes with an enhanced version of MacOS 9.2.2 that can access partions up to 200 GB in size. Intech offers the Hard Disk SpeedTools For MacOS Classic as an alternative.
• Clearing the parameter RAM (weak batterie, Command-Option-P-R on reboot, other installers overwriting the nvramrc) will limit the drives to 128 GiB again until the script is rerun and the system is rebooted; this poses a risk of file system corruption (but see below).
• Booting fails if any system file needed in the early boot process extends beyond the first 128 GiB as the Open Firmware can't access it¹. This is the prime reason why Apple limits the driver on older systems. Even if it works on a fresh install it will fail when the disk gets filled up and the next system update relocates a critical system file above the limit. It is therefore strongly recommended to follow Intechs Safe Partitioning guidelines in the SpeedTools ATA Hi-Cap Support Driver User's Guide.
  ⑴ FireWire target disk mode is also implemented in the BootROM and will be limited to 128 GiB.
• The partition table can't be easily extended if there are already files on a drive; again Intech seems to include an utility named Hi-Cap Extender for this purpose with its SpeedTools ATA Hi-Capacity Driver.

Some technical details can be learned from the open source of Leopards drivers:

• In KeyLargoATA-111.3.1/KeyLargoATA.cpp, method KeyLargoATA::probe tests for the lba-48 property.This leads to a second approach: Recompile the driver without this test and there will be no need for the nvramrc (but it has to be done for every new release).
• In KeyLargoATA::provideBusInfo the maximum transfer size at the driver level is raised for large drives from 128 KiB to 1 MiB to optimize the throughput of modern hard disks.
• IOATADevConfig::sDriveSupports48BitLBA in IOATAFamily-202.0.1/IOATADevConfig.cpp tests drives for 48-bit LBA capability (as they are all required to be 28-bit LBA compliant as well), used by ATADeviceNub::publishVendorProperties in IOATAFamily-202.0.1/ATADeviceNub.cpp to publish the extended LBA capacity property.
• Finally IOATAController::issueCommand in IOATAFamily-202.0.1/IOATAController.cpp splits an Extended LBA into two halves and sends them one after the other. This shows that 48-bit addressing is just a protocol extension designed to be compatible with older hardware.

MacBook Pro 15" (Santa Rosa based) @ 2,2 GHz

Recently I had access to a new MacBook Pro which is capable of running the enhanced OpenGL test:

CINEBENCH R10.1
****************************************************

Tester           : Pareis

Processor        : MacBook Pro 15": Core 2 Duo T7500, 3 GiB 667 MHz DDR2 SDRAM
MHz              : 2200 (running on power adapter with better performance)
Number of CPUs   : 2
Operating System : Mac OS X 10.5.4 (9E17) -- [updated results with small improvements]

Graphics Card    : NVIDIA GeForce 8600M GT, 128 MiB
Resolution       : 1440x900
Color Depth      : 32 bpp

****************************************************

Rendering (Single   CPU): 2407 CB-CPU 
Rendering (Multiple CPU): 4520 CB-CPU 

Multiprocessor Speedup: 1.88

Shading (CINEMA 4D)                :  427 CB-GFX 
Shading (OpenGL Software Lighting) :  718 CB-GFX 
Shading (OpenGL Standard)          : 4388 CB-GFX 
Shading (OpenGL Enhanced)          : 1025 CB-GFX

OpenGL Speedup: 10.28

****************************************************

OpenGL Enhanced Test
40.597 sec; 9.0 fps

OpenGL Standard Test
9.480 sec; 38.5 fps

OpenGL Software Lighting Test
57.949 sec; 6.3 fps

CINEMA 4D Shading Test
97.492 sec; 3.7 fps

Single CPU Render Test
367.4 sec

Multiple CPU Render Test
195.6 sec

OpenGL Enhanced uses hardware shaders to render the scene with realistic lighting. Its requirements can be verified in the benchmark under File / Preferences… / Viewport / Show OpenGL Capabilities.

The added tests and verbose output (copied from the Console pane) require modifications to the file Bench.cof (available for download). This file belongs into the plugins subdirectory of CineBench R10. A diff will show that most of my changes are nothing but uncommenting inactive instructions.

Using Open Firmware to install Leopard below 867 MHz

It is easy to fake the CPU frequency in the device tree and make the installer happy. Just copy the following code into a file called fastG4.txt, place it in the root of the primary partition on your master drive (originally Macintosh HD, where the System folder usually resides) and reboot into the Open Firmware monitor (holding down Command-Option-O-F).

\ Claim first G4 runs at 867 MHz, and boot from CD/DVD:
dev /cpus/PowerPC,G4@0
d# 867000000 encode-int " clock-frequency" property
boot cd:,\\:tbxi

After inserting the installation DVD execute the new file at the command prompt using boot hd:\fastG4.txt.
The use of a file is only intended to ease the command entry, especially when needed more than once, i.e. the code can be input directly at the prompt as well.

This might also be helpful in testing other software excluding slower CPUs.
I don't know if this is sufficient for a dual CPU system. Repeating the sequence of line 2 & 3 with @1 instead of @0 will set the property for both CPUs.

Note that the device tree is only a volatile inventory of the hardware found by the Open Firmware during the system start sequence, so these entries will be reset at the next reboot, and (before somebody gets this wrong) we are not talking about overclocking here at all !

PS: A modified file can be used if the Mac OS X Install DVD can't be booted from the built-in optical drive.