As I stated in the previous blog post, it's necessary for us to figure out the WM8991 audio codec before we can call from the baseband (or listen to music). This is an interesting task because while there are datasheets for the WM8991 codec, and a Linux driver for it, those cannot be used immediately since it doesn't tell us where the inputs and outputs of the chip are connected to, and what protocol and clock divider settings the iPhone uses to talk to the chip (and must be configured on the chip). Those things are purely implementation specific.
In order to extract those settings, we need to be able to see those settings while the iPhone OS kernel is up and running and sound is playing. The chip does not use MMIO, so the register settings cannot be directly peeked at through
/dev/kmem... but we're on the right track. Instead, I2C is used to communicate with the codec for setting those registers. It turns out that since some Wolfson codecs do not allow reading from the codec registers (only writing), the operating system has to "remember" what values registers are currently set to. That is, they are cached by operating system?Where are they cached? Well, a quick look at the disassembly shows us some code that does the following (in pseudo-C)
if register > *(this + 0xA0)
return 0
return *((uint16_t*)(*(this + 0xA8) + register * 2))
Basically, we see that the class member at offset 0xA0 contains the total number of registers accessible on the Wolfson codec, while member 0xA8 is a pointer to an array of 16-bit values that represent the current values of those registers!
Now we seem to be home free... except for the fact that IO Kit C++ objects are dynamically allocated on the heap at runtime and there is no way to tell using static analysis where they will be during a particular boot of an operating system. How will we find the location of this C++ class (AppleWM8991Audio) so that we can peek at those values?
The answer is that every object in the IOKit subsystem is anchored to the IORegistry tree. You can actually take a peek at the tree from userland with the
ioreg -l command. Every single node you see corresponds to a C++ object. However, the trouble is that there is no userland call to extract the in-kernel addresses of those objects... and that's what we need to be able to use /dev/kmem to peek at the right places.Fortunately, the root of the IORegistry is pointed to by a constant, and it is possible to traverse the IORegistry manually from the root (provided you know the layout of all the C++ classes!). This is exactly what I wrote a utility called spelunk to perform: use
/dev/kmem to manually traverse the IORegistry and find the in-memory instance, instance size, and vtable location of all of the objects in the IORegistry. Armed with this information, one can use dd and /dev/kmem to peek at the state of any of the objects inside kernel memory.I made a series of dumps:
registers-call-headphones, registers-call-speakers, registers-max-headphones, registers-max-speakers, registers-min-headphones, registers-min-speakers. Here is a diff of min-speakers and max-speakers, just to show you what we're looking for:
--- hex-registers-min-speakers 2010-05-04 15:44:19.000000000 -0700
+++ hex-registers-max-speakers 2010-05-04 15:45:39.000000000 -0700
@@ -2,7 +2,7 @@
00000010 20 80 20 80 00 00 c0 00 c0 01 00 00 00 01 c0 00 | . .............|
00000020 c0 00 00 00 01 00 00 17 00 10 40 10 00 00 04 08 |..........@.....|
00000030 8b 00 8b 00 8b 00 8b 00 b0 00 b0 01 66 00 22 00 |............f.".|
-00000040 f9 00 f9 01 00 00 03 01 57 00 00 01 ec 01 00 00 |........W.......|
+00000040 f9 00 f9 01 00 00 03 01 57 00 00 01 ff 01 00 00 |........W.......|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 80 01 00 00 00 00 03 00 00 00 |................|
00000070 00 00 08 00 00 00 00 00 87 00 85 00 fc 00 00 00 |................|
So it's fairly obvious how volume control for the speakers are done. Anyway, hopefully we can plug in these values, use the current i2s drivers, and audio will work!
