Nothing much new

As you guys can probably tell, I've been mostly busy with other real life stuff and I haven't been working on Android much. That will be changing pretty soon however.

I was able to have a lot of fun doing an interview on This Week in Android. Hopefully I wasn't too geeky for them!

There's nothing else new, I think. I'll try to integrate in the backlight stuff first and some of the cleanup that Bluerise did on the layout for the Android tree. That will be very important moving forward.

After that, there's a possibility that before moving onto the power management (which might be a fairly lengthy battle), I can whip up an installer and updater for current and future revisions that works through Cydia. Do you guys think I should work on that first or dive straight into the power management stuff?

iPhone 3G binaries!

I wrote up a how-to for PC World on how to put Android on the iPhone 3G and the iPhone 2G and it went up today. I wanted to be there to tweet about it when it went up, but I've been keeping really strange hours lately and I wasn't awake for it when it went up.

But here are the binaries (for iPhone 3G, and for iPhone 2G), graciously hosted by PC World!

Please read the how-to that I wrote for PC World to on installing it. The steps are basically the same as before, except you can put the firmware in a directory on the iPhone OS data partition. This means that you don't have to modify the ext2 partition as before.

One thing I didn't mention is that you could perform the installation on OS X without a Linux VM if you recompile loadibec and oibc. Otherwise, the directions are the same.

Status update

I know the binaries for the iPhone 3G are taking a while. Everything is basically done and all the code I have is in the source repositories so people are free to build it for themselves. However, I wanted to improve the packaging slightly to ease installation (no longer requiring people to modify ext2 partitions). The release of the binaries (and a how-to) will be sometime within the next week.

The binaries will have more features than the iPhone 3G demo showed: It will have full calling and sound support. The code for that (and everything else) is already finished and is in my github if you would like to check it out.

Meanwhile, I am working on some stuff that is slightly more fun. Last night, I brought openiboot for the first-generation iPod touch up to scratch so that it supports all the features the other ports of openiboot support: sound, multitouch and SDIO (for WLAN) are the notable things I had to fix. Earlier today, I figured out how to drive the piezoelectric tweeter on the iPod touch.

Hopefully, we'll be able to roll out the iPod touch binaries with the 3G binaries and get on with the real work: power management and the little details that will make Android a truly viable alternative on our three early ports.

In the meantime, I hope to find some time to play with the piezoelectric buzzer on the iPod. Two neat projects I think I or some other enterprising person should do with it:

The first one is implementing an interface for it that is compatible with QBASIC's PLAY statement. QBASIC was my first experience with computer programming. In fact, I learned the language exactly concurrently with English.

The second is taking the considerable body of knowledge people have about programming PC Speakers and getting them to output PCM sounds from them and adapting them to the iPhone. It would be an awesome hack to get the iPod touch speaker playing some real music! I am reading this page for some hints, but I would love suggestions or help from people who may have had more experience.

One of the things I have always really wanted to do is to create a demoscene-style demo on the iPhone. I've always admired the demoscene and I want to be cool like them but I don't have the right skillset to do the "graphix" and music. It would be cool if we can get a group together (if any of my readers are demosceners!) and create the first iPhone demo to run on bare metal.

P.S. I switched over to IntenseDebate for the comments. One of the reasons is that blogger lets a lot of spam comments through, forcing me to do moderation on older posts (I only filter comments that are clearly spam: I let anything else through, including flames, trolling, etc.). I would rather not have to perform moderation so I'm hoping IntenseDebate will do a better job. Also, some of these posts get a huge volume of comments and I think IntenseDebate would do a better job organizing the comments.

Android on iPhone 3G

I wrote a piece about this that PC World was nice enough to run.

Click here to read the PC World article for more details!

Here's the video demo that I put up:



Thanks to ricky26 and bluerise for their time on the multitouch, many others who worked on openiboot, and my friend Alisa for the graphical changes (visit her site at galiaxy.net)

Creating a WM8991 driver

Thought it might be interesting for people to take a peek at how we work.

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!

Cell network association and SMS on iPhone 3G

This is just a small, incremental update. It looks like we're currently blocked on a driver for the WM8991 codec. This is because instead of sound data that should come out of the speakers directly to the baseband, the Wolfson codec now controls the speaker as well on the 3G. This is a significantly more sane design than what the 2G had, but it causes us some complications.

First, now a WM8991 driver has to be written before we can get any sound out of the device. This is contrary to the 2G where we can test the i2s functionality of the SoC relatively independently.

Second, in order to make or receive calls with the iPhone 3G, the WM8991 driver must be written and cooperating with the baseband. This is a significantly more complex arrangement than on the 2G, where that functionality can be controlled entirely through the baseband.

However, this is still all not very hard. If we had a timetable, I'd say we're "on track". But we don't so don't ask. :P

Also, as a result of this investigation, I can associate to the cell network and send and receive text messages from the 3G now. Of course, I had to port ultrasn0w into openiboot to do it... I had forgotten all about the fact that my phone was unlocked by ultrasn0w until now. :)