FreeBSD and the Apple USB SuperDrive
Apple,
FreeBSD,
Hack
I've noticed the Apple USB SuperDrive from my Mac doesn't work on the ThinkPad running FreeBSD. This is odd, since the drive is recognized and responds to CAM commands. Here's what I've learned today.
First, plug the drive in:
ugen0.6: <Apple Inc.> at usbus0
umass0: <Apple Inc. MacBook Air SuperDrive, class 0/0, rev 2.00/2.00, addr 6> on usbus0
umass0: SCSI over Bulk-Only; quirks = 0x4000
umass0:4:0:-1: Attached to scbus4
cd0 at umass-sim0 bus 0 scbus4 target 0 lun 0
cd0: <Apple SuperDrive 2.00> Removable CD-ROM SCSI-0 device
cd0: 40.000MB/s transfers
cd0: cd present [1 x 0 byte records]
cd0: quirks=0x10<10_BYTE_ONLY>
The drive is recognized, but will refuse to swallow a disc. When plugging the same drive into a MacBook Pro, it swallows just fine.
Turns out this is because Apple have elected to make the drive (or more specifically, the USB to IDE bridge) wait for a special, non-standard command from their driver to enable it, presumably with the intention of preventing use on non-Apple computers. Good job guys, at least if your goal was to piss off people.
I found the magic byte sequence to awaken the drive from its slumber here. On FreeBSD, it's sent to the drive using camcontrol:
camcontrol cmd cd0 -c "EA 00 00 00 00 00 01"
Now the drive will happily ingest the disc and read it too. Thanks to whoever figured that one out, and no thanks to Apple for making it necessary.
Since it's annoying doing this manually every time you use the drive, let's automate it using devd(8)
. Just drop this into a file named /etc/devd/superdrive.conf
and then restart devd:
# Enable Apple USB SuperDrive
notify 100 {
match "system" "DEVFS";
match "subsystem" "CDEV";
match "type" "CREATE";
match "cdev" "cd[0-9]+";
# These aren't available for DEVFS notifications,
# else it would be good to check them:
#match "vendor" "0x05ac";
#match "product" "0x1500";
action "camcontrol cmd $cdev -c 'EA 00 00 00 00 00 01'";
};
Now whenever a cd
device appears, it's sent the magical command. It would be cleverer to only send that command to Apple devices, but devd doesn't have the USB vendor/product ids available when receiving the devfs notification and camcontrol wants a CAM device to talk to, not the umass that comes with the vendor/product id. There's probably some way to look up the CAM device from the umass device name, but as I only have one drive anyways it wasn't worth bothering.