Articles from The Mac Elite, CubeOwner & more

Saturday, December 22, 2007

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

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.)

Sunday, December 16, 2007

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 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` = *KeyLargoATA* &&
   `ioreg -p IODeviceTree -n ata-4 -w0`  != *lba-48* ]] || exit

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

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.


  • (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.

Saturday, December 15, 2007

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:


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.