Skip to content

Accessories and iAP

The dock connector is how the iPod talks to the world outside itself - chargers, car head units, speakers, remotes, the FM accessory. Two things travel over that connector: a serial protocol Apple calls the Accessory Protocol (iAP), and USB. Chikuma reproduces the parts of both that the firmware actually carries, and declares the rest as its own or as best-effort. Most of this is still young; the honest state is marked throughout.

iAP, and where it runs

iAP is a framed command protocol. On the iPod classic it runs over two transports: the dock connector's serial line (an on-chip UART), and a transport carried over the USB HID interface. Commands are grouped into lingoes - a general lingo, a display-remote lingo, an extended-interface lingo for browsing the library, digital-audio, and so on - and this device speaks most of them.

iAP 1 is reproduced first, from the firmware as oracle, because that is what the device carries. iAP 2 is Chikuma's own planned addition: it postdates this firmware, there is nothing in the image to recover, and so anything built for it is declared OURS and worked out from public, non-NDA sources. The two are told apart on the same wire by their framing: an iAP 1 frame and an iAP 2 frame begin with different lead bytes (FF 55 against FF 5A), so a link can offer both and route by the header. Asking this firmware to speak iAP 2 gets a polite refusal, which is the measured confirmation that it does not.

The conversation you can observe

The dock serial line is exposed as a socket on the emulated machine, which makes the original a live iAP oracle: send it a frame, read its answer. The general-lingo conversation is reproduced and gated against the original's measured replies - asking the device its name returns iPod, asking its software version returns the version the image reports, asking a lingo's protocol version returns that lingo's version. qemu-ipod/tools/iap.py drives this and qemu-ipod/gates/iap_dock_gate.py holds the answers.

One capability worth naming because it is reproduced end to end in chikuma/drivers/iap/: the extended-interface command that pushes an image to the device's screen (the "now playing" art a car stereo shows). The reassembly, the pixel formats and the draw window are reproduced and pass host tests; drawing it onto Chikuma's own panel is the remaining stand-in.

Detecting what is plugged in

Before any serial conversation, the iPod identifies an accessory by a resistor: the accessory ties the dock's identify pin to ground through a known resistance, and the device reads it through the PMU's analog input and maps it to one of a handful of bands. An open circuit means nothing is attached. This scheme is not only recovered from the firmware; it matches Apple's published iPod Interface Specification, whose identity table names the bands (a simple dock, a diagnostic dock, a battery pack, a UART dock, a car charger, and so on). Two separate accessory tasks handle the two halves - one owns the resistor-based detection that gates features, the other owns the serial conversation. Nothing here is exercised, though: the emulated machine has no accessory attached, so every observation so far is of the absent case.

The accessory board (a design, not a build)

There is a design in the reports for a physical accessory board - a 30-pin dock plug, an analog multiplexer that selects an identity resistance in hardware the way the emulator selects it in software, a small microcontroller speaking iAP over the serial line, and USB to a host. It has not been built or tested, and it carries an open hardware question (the identify-pin numbering disagrees between Apple's specification and community pinouts and must be metered on a real connector first) and a safety note (the FireWire power pins must be left unconnected). See reports/accessory_board.md.

USB

The USB controller is the Synopsys DWC2 OTG block, modelled as the device half. The model is at an early stage - a working register file, not yet a full data path.

What the descriptors define, observed from outside, is a device that presents an audio function and an HID/iAP function together as its active configuration. The audio streaming interface has a zero-bandwidth default and an active alternate with an isochronous IN endpoint; the device begins streaming 16-bit stereo 44.1 kHz PCM only after the host selects that alternate, which resolves a long-standing question about whether the audio path was live (it is, and it is assembled at run time rather than sitting in the image as a fixed descriptor).

The next target is mass storage - disk mode. A car head unit that plays from the device wants mass storage, not iAP, and it is a reproduction job rather than an invention because the descriptors already define a mass-storage function (SCSI-transparent, Bulk-Only Transport) and the device already answers a recognisable set of SCSI commands. Chikuma's own USB disk stack is being written against a fake transport in chikuma/drivers/usb/, with the standard command-and-status wrappers, ahead of the DWC2 data path being finished.

What is reproduced, OURS, or best-effort

  • Reproduced from the firmware: iAP 1 message decoding and routing, the dock-serial and USB-HID transports, the general-lingo conversation, and the push-image command.
  • OURS, declared additions with nothing to recover: iAP 2 in its entirety, and the I2C bus lock the serial path shares.
  • Open: iAP 1 accessory authentication. The image carries an authentication certificate, but the rules that decide which commands a given accessory is permitted are not yet tied to it. iAP 2 authentication, if built, would be mandatory and therefore OURS.
  • Best-effort, only if the hardware can be modelled from what the firmware actually uses: the FM radio accessory (the radio row is what led into this work) and Nike+ / Sports, which this device does not run.

The full account is in reports/iap.md, reports/usb_stack.md and reports/accessories.md.