Enabling CPU Power Management on Dual G4 Systems

Napping is a power saving feature on most PowerPCs that can be used whenever the CPU is idle even for the fraction of a second.

Mac OS X doesn't activate it on Dual G4¹ systems but can be overridden using the Live and Let Nap script which will save the selection into the non-volatile NVRAM of your computer by adding (or removing) the fn ("forcenap") kernel parameter² to the boot-args variable.

A reboot is required for a change to take effect.

There is another approach for enabling Nap, but it requires installation of an old version of the CHUD toolset. Recent versions of the Xcode development environment also include (and require) a recent CHUD³, and two different versions of CHUD can't be installed together.

How much energy can be saved while taking a nap ?
In table 7 of the Hardware Specifications for the MPC 7448 Freescale states a drop from about 26 W running at 1.7 GHZ to 13 W in Nap mode generating 50% less heat⁴.
Actual measurements with a power meter connected to a Gigabit Ethernet PowerMac G4 running an inactive Finder from Leopard on the original two 7400 at 500 MHz show a total difference of 16 W in favor of Napping.
A fully loaded system will not nap, and further benchmarks such as Power Fractal showed no deterioration using Nap (as expected).

1. On my test mule automatic use of Napping was regained by disabling the second CPU using the kernel parameter cpus=1, i.e. running the command line sudo nvram boot-args=cpus=1.
2. This option is available starting with Mac OS X 10.3.
3. No version of CHUD can change Nap when forcenap has been set but I've verified the setting with a modified copy of the hwprefs command.
4. Using Dynamic Frequency Switching (DFS) to half the clock rate in situations without maximum performance requirements (but not idling) will only save about a quarter according to the formula given in section 9.7.5.1.

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.

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.