What's up with Planetbeing?

Many of you asked in the past 1 month or so, where is Planetbeing? What is he doing? Has he abandoned the project?

The answer to the last question is a definite NO.

While I don't know enough of his private life to shed you light of exactly what he is doing and his whereabouts but I can tell you that I have been in constant contact with him along with other iphone dev-team members through IRC. Apart from having to look after his academic stuff and a few paid odd jobs to earn him some pocket money, he was recently actively involved in the iOS jailbreak with Comex. He is now indulging himself in the excitement of getting the iPhone 4 baseband unlocked with Musclenerd, as you can tell from his tweets.

Even when he was working on such things, he still has his mind on iPhonelinux as can be seen from the excerpt of the conversation we had on IRC below:

Jun 30 16:23:18 |planetbeing| saurik: CPICH: you might be interested in this: http://RED-ACTED/tfp.c

Jun 30 16:24:01 |planetbeing| This is what I've been using to explore the kernel with the tfp patch. You need a copy of "tense3" (the fixed up iPhone 4 kernel dump) to use some of the page table related commands.

Jun 30 16:24:30 |planetbeing| CPICH: this will be super-useful for like iPhone Linux stuff because we can map in whatever hardware region we want and peek at the current register settings.

Jun 30 16:25:16 |CPICH| ok

Jun 30 16:30:46 |Zf[idling]| once you can boot linux

Jun 30 16:30:47 * Zf[idling] runs

Jun 30 16:34:13 |CPICH| can modify it to work on previous platforms for yet to be ported drivers though

Jun 30 16:35:18 |planetbeing| Yup.

Jun 30 16:36:40 |planetbeing| That's why I wrote a whole program to mess with it easily.

Also, a few other folks on #iphonelinux such as Bluerise, ricky26, nickp6666, Alex, James etc. are making steady progress in making minor improvements such as vibrator on 3g, porting of Ultrasn0w, usb, multitouch accuracy, Froyo on 3g etc. So, while waiting for Planetbeing to provide direction on major items such as PMU and GPU, there are no lack of activities.

Finally, you may ask, what can't Planetbeing provide updates on this blogs, surely it won't take him a few minutes?

Well, there is simply nothing for him to update on the iphonelinux front at this moment, and writing a non-technical update with no technical substance is very "unPlanetbeing", so it is up to n00b like me to provide this "non-update" update.

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

iPhone 3G Multi-touch

I finished writing a driver for the Zephyr2 on the iPhone. It's the same multi-touch solution that Apple has used starting from the first generation iPod touch and up to and including the iPad.

Now, of course this shouldn't be construed as a promise to support the iPad eventually, but this multi-touch driver is definitely a concrete milestone that is important for pretty much all of Apple's mobile Internet devices.

More immediately, this is pretty much the sole remaining blocking issue on the first-gen iPod touch and one of the two major issues on the iPhone 3G. The other issue on the iPhone 3G is baseband SPI. I'm wondering if we can get away with just using the debug uart to make calls (if we don't care about having a fast 3G data connection yet).



Also, I'd like some opinions from this blog's readers: More frequent updates? Or just document the major advances?

The port to the iPhone 3G is coming along. This is a picture of an iPhone 3G booting into a BusyBox / Buildroot shell. As you can see, wireless networking is working great. We can also talk to the baseband over the debugging channel. This might be enough to get calling, etc., working but we may need to figure out the SPI transport.

I'd still like to get the WM8991 codec working for it in openiboot (shouldn't be much trouble since there's a datasheet), just so we can iron out any quirks before testing it inside the kernel. We also need a new multi-touch driver (they've upgraded from Zephyr to Zephyr2). After that, we'll have a working port of Android.

Also, for existing developers and testers, I've implemented the Android wi-fi driver extensions so WLAN should be working better now. I know people had problems associating with WPA protected networks, etc. See if this update helps!

Android repos are up

We've gotten a tremendous response -- far more than I've actually anticipated before the release. I would like to thank the community for their interest. The amount of support and enthusiasm that was displayed was truly humbling to someone used to cynicism about this project.

The thing I'm most excited about is the fact there are now many developers working on several different things... a pretty big change from when I was hacking on the source tree virtually alone. There are developers actively working on the first generation iPod port, the iPhone 3G port, and a second-generation iPod touch port and things are moving much more quickly than I've anticipated. With so many helping hands, I'm sure that we can get these ports to production quality.

To coordinate our efforts, I've setup a series of git repositories on GitHub. You can clone the Android tree using Google's repo tool thus:

repo init -u git://github.com/planetbeing/platform_manifest.git -b android-sdk-1.6_r2-iphone

This command populates the majority of the tree from the main Android kernel.org repositories, with any changed project from my tree.

git://github.com/planetbeing/kernel_common.git branch android-2.6.32-iphone is our kernel tree. It is included in the main repo checkout as well.

git://github.com/planetbeing/iphonelinux.git as always is our openiboot/bootloader tree. New hardware support will be trialled there and then ported into the Linux kernel.

A fellow with the nickname of "konaya" on IRC has volunteered to administer a website for us at http://www.idroidproject.org. We can use the wiki to document iPhone Linux/iDroid and the forums to provide help to newcomers. We also have a developer mailing list (please ask in IRC if you wish to get added to that).

A to-do list

I'm gratified at a lot of the developers that want to help! This is the only way this project can stay alive. That being said, let's start to get a little organized. Here's a to-do list:

http://theiphonewiki.com/wiki/index.php?title=IPhoneLinux_To-Do

I'm proposing that unless someone wants to step in to host and administer an iPhone Linux website/wiki/forums, we use the iPhone Wiki to exchange information since it's there already. That said, Be Bold and work on whatever you like! If you have patches to openiboot, send them using git. If you have patches for the kernel or Android stuff, just contact me with it (IRC preferred, e-mail is okay) and I'll see about how we can publish them.

I'll personally be focusing on the first gen iPod touch and 3G port since I think I have a comparative advantage in that area.

Android running on iPhone!

I've been working on this quietly in the background. Sorry about the initial video quality, but YouTube promises that the quality will get better as the video gets processed more. The back part of the version I uploaded to Vimeo was cut off.



I think that says it all, really. Donations via paypal to planetbeing at gmail.com. If you'd like to help, come join #iphonelinux on irc.osx86.hu.

Thanks to CPICH for reversing support, harmn1, posixninja, jean, marcan and saurik for patches, and last but not least, TheSeven for his work on the FTL.

Pre-built images and sources at http://graphite.sandslott.org:4080/pub/idroid/idroid-release-0.1a.tar.bz. Read the README. For generic openiboot instructions, there's plenty now that you can search for.

It should be pretty simple to port forward to the iPhone 3G. The 3GS will take more work. Hopefully with all this groundwork laid out, we can make Android a real alternative or supplement for iPhone users. Maybe we can finally get Flash. ;)

EDIT: Apparently on some iPhones, the installation of openiboot appears to be failing (THIS MEANS IT WON'T BOOT UP AGAIN). This is being investigated (I can't reproduce it on my own phone), but meanwhile you can just do a "tethered boot". In openiboot console, don't install but do !zImage, kernel, !android.img.gz, ramdisk, boot "console=tty root=/dev/ram0 init=/init rw" (after installing the other images to the second partition). If your phone won't boot up again, a DFU restore will get it back to normal. Take a deep breath. Calm down. There's nothing to worry about. :) We'll get this sorted out by tomorrow.

EDIT2: Fixed! It was previously only working on phones that used PwnageTool due to some assumption I made. Thanks geohot! Redownload the archive or just openiboot.img3

Porting Guide

Something helpful for those who are interested (but don't know where to start) in the "porting openiboot to other devices" task under "Jobs for Reverse Engineers".....

Base addresses, GPIO ports, i2c slave addresses, interrupt numbers, clock gates, etc. will all be available from ioreg -l on your jailbroken device. Check your ioreg -l output with the ioreg -l / device tree outputs of already ported platforms to see quickly which drivers are likely to be compatible with merely some constants changed, and which will need to be rewritten.

If you have an iPhone uart cable, you can port the uart driver early… it’s very simple. This will save you a lot of pain debugging.

Step 1. Figure out how to reboot the device. This is usually done by writing a value into a WDT register, but could be verified by reversing cmd_reboot in iBoot.

Step 2. Change the “Constants” in includes/hardware/s5l8900.h to reflect the basic memory layout of your hardware if necessary. Most likely this does not need to be changed provided the MIU was properly configured before openiboot is called.

Step 3. Make sure PeripheralPort in includes/hardware/s5l8900.h is set to the right place. You can find out by reversing iBoot and finding where it sets the peripheral port remap register early on.

Step 4. Figure out where the MIU configuration register is and which MIU setting to use to make sure SDRAM is mapped to 0×0. This can also be most likely found in iBoot. The MIU is one of the devices labeled /arm-io/clkrstgen in the iPhone’s device tree. Change the instructions at the beginning of entry.S, miu_setup, and clock_set_bottom_bits_38100000 with this new information. You may attempt to make the assumption that the MIU is still at the same place and/or has the same register offsets/values.

Step 5. Put a reboot early on in entry.S and progressively move it back, troubleshooting as you go, until you reach C code (OpenIBootStart). This is the first major landmark.

Step 6. Port over clock.c, power.c, timer.c, interrupt.c and the interrupt handling code in entry.S. Most likely you just need to change the base addresses in their respective includes/hardware/*.h. Use the event.c code (which is platform independent) to try to schedule a reboot 10 seconds after you launch openiboot. (make sure you comment out everything you haven’t ported and add a while(1); at the end of your code). If this works, the timer, clock and interrupts all work. These are very important basic services for the other drivers. Use a combination of the reboot code you worked out in step 1 and while(1)s to troubleshoot, they will be your only form of feedback for now.

Step 7. Port over usb.c. Again, you can probably just change the base address of the USB code and it will work. Once that is done, you can re-enable all the command line parsing code. If the openiboot command line code works, then you have a basic bring-up!

Step 8. Port over the GPIO driver. You can test its workings by checking the button states. You need this for a whole bunch of devices.

Step 9. Port over the i2c driver. Test with the accelerometer. This is needed for the PMU and LCD among other things.

Step 10. Port over the pmu driver. This is a good application of the i2c driver, and you need it to control the backlight.

Step 11. Port over the SPI driver. Most notably, this is used for the LCD driver and probably NOR on new ports. No easy way to test this in isolation so you’ll want to do it concurrently with step 13.

Step 13. Port over the NOR driver. It might “just work” when the SPI driver does.

Step 14. Port over the LCD driver. This is probably one of the trickier parts. I had to check the actual iBoot disassembly for my ports here. However, it only took an hour or so to get working.

Step 15. Port over the DMA controller. There probably won’t be any changes, but who knows.

Step 16. Port the rest. There aren’t any surprise dependencies. sdio → wan, radio → uart and that’s about it.

iPhonelinux Wishlist

Planetbeing's words from the iphonelinux github:
"This is just my personal WISHLIST. You might have different priorities. If you want to help, just submit patches that you think are helpful. If you need ideas, just refer to this list. Take it off the list in your patch when you finish something off the list. I'll try to give as much help and guidance as I have time to (which may not be much). 

This is not an exhaustive list, but just stuff I think people can actually deliver on reasonable timescales. For example, notice the conspicuous absence of "figure out how to make phone calls". It's roughly divided based on skillset.  
Jobs for C coders that may not have much RE or driver experience:  
1. Simplify driver code: An early goal of this project is to remain faithful to how the iPhone firmware operates the hardware. Some of it does not actually make sense or is otherwise not very efficient. We have a better understanding of the hardware now and can afford to write better drivers with that understanding. This is essentially refactoring.  
2. Refactor openiboot: I'm not sure I like the way openiboot is laid out right now. There's got to be a neater way to organize this. I'd like something that has less messy defines and a more consistent style so it's easier to read, perhaps individual folders for each module, and the ability to easily include or not include any individual module. An emphasis should be put on ease of porting. 
3. Add multitasking: A great project for students in or just out of OS classes. I've been too lazy to add true multithreading primitives: mutexes, semaphores, condition variables, and also multitasking in general. A lot of stuff is run in interrupt contexes or interrupt-disabled contexes. Writing drivers requiring blocking I/O is a pain. It's time for a true multitasking kernel. Should be done in coordination with #2.  
4. Write a gdb stub for openiboot: Those things are tiny and it shouldn't be that bad. Just have it communicate over the existing USB driver now. We wouldn't be able to debug interrupt contexts for now, but it's better than nothing.  
5. Someone needs to MAINTAIN the build script for the toolchain. Or else figure out if/how we can just build everything using Apple's or the community's iPhone OS toolchain. I'm pretty sure we can. It's not like we use the elf wrapper currently.  
6. It might be cool to be able to parse the iPhone's own device tree for some of base addresses. Might make porting less of a pain.  
7. With help from CPICH, we've determined the vibrator and speaker controls are in the baseband, both controlled through the at+xdrv command. Knowing this, the next step is to make sure we can talk to the baseband through the UARTs. This shouldn't be that bad since iBoot used to do it, and we already have UART code.  
8. I've implemented the firmware upload part of Libertas WLAN driver for Marvell 8686 to test out the SDIO functionality. It appears to work. Therefore, we have validated readb, writeb and writesb. More of it should be implemented to validate SDIO device interrupt handling and also readsb. After that, we will definitely have enough to support working wi-fi in the Linux kernel!  
Jobs for people who want to get their hands dirty with drivers:  
1. Look at TheSeven's NAND FTL code in Rockbox and CPICH's reverse engineering efforts to figure out the FTL write code and get it working.  
2. Write a new USB driver: I hate the current one. TheSeven might have some better code.  
3. Can we steal some code from that userland bluetooth stack and put it on top of our UART code? It might be even cleaner than USB, ironically, since we can probably do it all without interrupts.  
Jobs for reverse engineers:  
1. Port openiboot to unsupported platforms like ipt2g, ipt3g and iPhone 3GS.  
 2. For some reason, the NAND chips stop working after the iPhone is on for a long time. They're fine after a reboot. Figure out why that's happening.  
3. Get multitouch working for Zephyr2. It's a subclass of the Zephyr1 that I investigated, and at least some functions are shared, so it shouldn't be terrible.  
4. Figure out how to talk to the light sensor. It's a TSL2561 according to the ioreg. The slave address is 0x92/0x93 according to the ioreg "reg" setting and is one of the slave addresses allowed on the TSL2561. It's on i2c0 according to ioreg. It all looks good except for the fact I cannot get a response out of this part. I even bruteforced all the slave addresses on i2c0 and only got responses from the PMU, the accelerometer and the Wolfson, stuff we already know how to talk to. What's going on? Is it just my 2G is broken?  
5. Figure out the new FTL they're using on the newer devices. That's going to be a pain.  
Thanks for reading all this. I'm impressed."