Linux on the iPhone

What's up with Planetbeing?

2010-07-05T06:58:00.001-07:00

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

2010-05-22T17:06:00.001-07:00

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!

2010-05-20T16:25:00.001-07:00

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

2010-05-14T14:21:00.000-07:00

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

2010-05-06T16:37:00.000-07:00

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

2010-05-04T15:55:00.000-07:00

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

2010-05-02T11:25:00.000-07:00

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

2010-04-30T16:44:00.000-07:00

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?

2010-04-26T16:57:00.000-07:00

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

2010-04-24T01:53:00.000-07:00

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

2010-04-22T19:49:00.001-07:00

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!

2010-04-21T17:32:00.000-07:00

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

2010-03-20T22:09:00.000-07:00

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

2010-03-04T00:45:00.001-08:00

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."

QuickOIB

2009-03-04T13:32:00.000-08:00

Hey, I would just like to tell you about a project pH is working on called QuickOIB. It is an installer for openiboot that works on Mac OS and Linux. He also tells me that he is working on a Windows version.

I'm sure it'll be very useful to people wanting a quick way to get past the OpeniBoot stage and get directly to working with the Linux environment.

Still Alive

2009-02-27T22:39:00.001-08:00

Been busy lately, but we'll be back at it soon. Stay tuned for updates!

Debian on iPhone Linux

2008-12-14T23:24:00.000-08:00

NAND writing is now semi-reliable (although one has to be VERY careful not to interrupt the device in the middle of a write operation), but it is enough to have something akin to a full-functional OS, backed by non-volatile storage.

People interested in the project should be familiar with the myriads of Linux "distributions" floating around. An operating system consists of two major domains: one is the kernel, which is what manages the hardware, and one is the userland which contains things like shells and other UIs, package managers, etc. Software that help users install and run useful programs. Ubuntu is a popular distribution that I run on my personal machine. Android could also be considered a distribution (though I believe it has some apparently messy kernel patches).

I decided that Debian would be an interesting thing to try, since we would then instantly have a userland and a pool of ready-compiled applications. Using a slightly dated root filesystem here: http://lists.debian.org/debian-arm/2007/01/msg00034.html, a initrd and further kernel configurations were sufficient to get it to run. Thus, we can now compile programs for iPhone Linux on iPhone Linux. The process is rather slow due to the processor and inefficient NAND device driver (pending a real FTL), but at least theoretically, iPhone Linux is now self-hosting.

This should be pretty much enough for those who are more into the userland development side of things to come in, possibly using Debian as a base to build anything else (as I believe it is standard enough).

I will be offering instructions on how to get this all to work soon. The (modified for gadget serial terminal) rootfs is fairly hefty (around 130 MB), so I'm not sure how we'll handle distribution of that.

Porting drivers to Linux

2008-12-06T01:27:00.000-08:00

We've made some progress on the USB gadget driver for Linux, and we're now running a generic serial gadget for communication. This implementation is important because USB is now a lot less laggy and things like ethernet over USB, etc., can eventually be supported, easing access.

We've also got pretty far with porting the NAND driver to Linux. Most of the read support is now there, and we've isolated the routines in the iPhone kernel where the raw hardware write occurs. CPICH and c1de0x are working on reversing it. Hopefully, it will be analogous enough to reads that it won't take a huge amount of time to work out.

This is different from reversing their FTL, however, which is a complicated slew of data structures, merge buffers and other exotic algorithms that take care of evenly distributing writes throughout the device and also making writes take less time.

I think reversing all of that would take too much time and effort. Instead, my proposal is to just reverse the hardware NAND writes. Instead of using a partition, we would have a loop-mounted root filesystem (similar to how Wubi is setup), with the root filesystem being a file on the Media partition. Since there's a non-empty file at that location, the FTL system, whatever it is, must create a one-to-one mapping from logical sectors to physical NAND pages. We can already read the mapping it creates (we have already reversed the read-side FTL code), and so all we have to do to alter the data is to write to the same pages we would've read from. Of course, this means that wear-leveling and bad block handling is not performed. However, if we use a filesystem that's aware of bad blocks and can wear-level (YAFFS or JFFS2), then it amounts to the same thing. The wear-leveling would then take place over the particular physical pages belonging to the rootfs image, rather than the entirety of the NAND. This would make the physical pages belonging to the rootfs image wear out a little faster than the rest of the NAND, but the actual effect of this should be inconsequential.

The additional benefit of this setup is that there's no repartitioning required, so setup is cinch. See this wiki document for specific proposed implementation details.

Donations...

2008-11-30T23:45:00.001-08:00

A couple of people asked for a donate button of some sort. I hesitate because of the sudden complexity of things when money is involved. Here is what I think would be best:

Donate your time and skills if you can rather than money.
If you cannot do so, please consider sponsoring something we could directly use: Such as a USB serial cable (about $45 for parts from Sparkfun), or perhaps upgrading the Slicehost slice we're borrowing from pumpkin ($60 per month, though it would only be useful if we could get enough money for at least six months), used or broken devices for testing, etc. Or something like a pizza for one of our contributors on a late night hacking binge (we will distribute food donations on a round-robin basis =P)
My paypal address is my gmail e-mail address (planetbeing). If you do make a donation, please specify exactly what it is for. A gigantic slush fund is something that I wish to avoid.

For the record, contrary to what was published by some media sources, the iphonelinux group is not associated with the group commonly known as the "iPhone Dev Team". I'm a member of the Dev Team, and other members sometimes lends assistance or advice, but this is an entirely separate project. The Dev Team does not accept any donations whereas this project tentatively will.

Updating and uninstalling openiboot

2008-11-29T19:31:00.000-08:00

It's actually slightly problematic to use the "Update Firmware" feature of iTunes with openiboot installed, so I updated openiboot with an uninstall facility.

I uploaded the binaries and instructions necessary to update openiboot (and then uninstall it if you wish) to: http://www.iphone-dev.org/planetbeing/openiboot-uninstall.tar.gz

Linux on the iPhone!

2008-11-28T14:50:00.000-08:00

I'm pleased to announce that the Linux 2.6 kernel has been ported to Apple's iPhone platform, with support for the first and second generation iPhones as well as the first generation iPod touch. This is a rough first draft of the port, and many drivers are still missing, but it's enough that a real alternative operating system is running on the iPhone.

&amp;amp;amp;amp;amp;lt;br&amp;amp;amp;amp;gt;

What we have:

- Framebuffer driver
- Serial driver
- Serial over USB driver
- Interrupts, MMU, clock, etc.

What we have in openiboot (but hasn't been ported yet):

- Read-only support for the NAND

What we don't have (yet!):

- Write support for the NAND
- Wireless networking
- Touchscreen
- Sound
- Accelerometer
- Baseband support

The current userland we're using, in the interest of expedience, is a Busybox installation created with buildroot, but glibc works fine as well, and we're going to build a more permanent userland solution.

A demonstration video can be seen here: http://www.vimeo.com/2373142

Instructions here: http://www.iphone-dev.org/planetbeing/LINUX-README.txt

Download here: http://91.186.26.18/iphone/files/iphonelinux-demo.tar.gz (look for mirrors in the comments)

EDIT: The instructions are missing the step that you have to select openiboot console from the menu before performing the "sudo ./oibc" step. Just be aware you have to do that if it seems like you're not getting a response from the oibc client.

Project lead: planetbeing

Contributors: CPICH, cmw, poorlad, ius, saurik

If you're experienced with hacking/porting Linux and especially if you're experienced with porting Android, I'd definitely like to hear from you. Come chill in the #iphonelinux channel on irc.osx86.hu. Thanks. :)

EDIT: I was asked a couple times by people who wanted to donate (financially) to the project. I made a post discussing this possibility, if you are interested.

Poorlad's menu implemented; Porting issues resolved

2008-11-18T08:40:00.000-08:00

Yesterday night, I merged in a branch I was working on for poorlad's menu. A version of that beautiful menu is now in Git. His menu included a version string at the bottom. We didn't have any way to keep track of versions and builds before, so this was actually a good idea that I had to implement. Because I didn't want to implement support for non-fixed width fonts, or add another space-consuming font, I just used the console font I was already using for that part. I also had to brighten the gradient on the bottom of the screen, since it was basically invisible due to gamma issues otherwise.

The border between the gradient and the "black" is clearly visible on my device. This is probably because of a gamma issue. When poorlad comes back, we can ask him to calibrate it more.

Otherwise, it looks pretty good! In order to make this possible, I added in stb_images.c, a great tiny little image library that can read PNG, JPEGs and even PSD files and does zlib decompression as an added bonus. This will be a great help if we decide to change things or need to add more stuff that consumes a lot of space. I also added in a basic function to perform alpha blending (albeit comparatively slowly).

Sadly, while I was busy making these changes, ius from IRC actually begun to implement poorlad's menu without me knowing about it, so we ened up duplicating each other's efforts. He was able to compile in zlib and libpng, but the cost was to inflate the final binary to 347 KB. Whereas taking out the old menu images, and adding small, compressed PNGs and the stb_images library instead actually made openiboot smaller than it was before! His decision to preblend the images, rather than attempt alpha blending on the device, was probably more optimal from a performance perspective.

Steven Troughton-Smith told me on Twitter that he has actually implemented his own boot menu as well. I'm not sure if he used the new PNG code or not, but the new code makes it pretty easy for a competent programmer to add in whatever menu they would like. I'd tell everyone to skin away, but we should keep as few wild branches of this project as possible, since everyone randomly installing openiboot just for kicks (especially a modified version) and then coming to us (read: me, ultimately) for support is something we don't have the resources to handle at this moment.

On the porting side, the issues with installation, optimizing NOR access on iPhone 3G, NAND access on a few devices all seem to have been fixed, so we can basically scratch the first two items off of the list I put up in the last post. I'm pleasantly surprised at how relatively easy it was.

Anyway, now for the kernel. Well, if I don't get distracted by writing to NAND.

Porting to iPhone 3G and iPod touch

2008-11-16T12:16:00.001-08:00

Hey guys,

The lack of updates for the past few days is because many of you decided to visit us in IRC, thus enabling work to be done on porting openiboot to the iPod touch and the iPhone 3G (in particular because I don't have an iPod touch at the moment).

I'm pleased to report that everything now seems to be working on the iPhone 2G and the iPhone 3G (albeit NOR read/write on the iPhone 3G is unoptimized and is unacceptably slow). There is apparently an outstanding issue with the NAND ECC on some (?) iPod touchs, and also some people can't seem to actually install openiboot to NOR on both iPhone 2G and iPod touch. Unfortunately, the problem is that these things happen on devices that I don't have physical access to, and IRC is often a frustrating medium for communicating with testers. I'm confident these issues will be resolved soon, though.

So, current simultaneous projects:

1. Resolve openiboot porting issues
2. Implement poorlad's boot menu
3. Work on write support for FTL

After at least one of those things are done, we'll be working on the Linux kernel.

NAND filesystem now readable!

2008-11-12T18:31:00.000-08:00

Amazingly enough, the FTL_Read stuff from last night was pretty much correct! After that, it was relatively trivial to port over the HFS+ code I've already written (which was in pure C... finally that [fail] design decision has been vindicated =P).

As you can see in the screenshot below, with the latest Git revision, you can browse the filesystem from openiboot!

Next on the list is to port openiboot over to the iPod touch and iPhone 3G. It's probably just a matter of putting in different numbers for the GPIO ports, but we'll see.

After that, I will implement poorlad's bootmenu (which everyone seems to like).

After that, well... We have pretty much all the devices now, so we'll start looking at the Linux kernel. If you're a Linux kernel guy who would be willing to help (preferrably you have experience porting Linux to new ARM platforms), please leave a comment here. I can do most of the muscle work, but it'd be nice if someone can show me how to set up the source tree properly for the new port.

FTL

2008-11-11T04:43:00.001-08:00

I don't know how I was talked into reversing a FTL, but we're actually on our way. I've managed to enlist the aid of CPICH (who has been helping with the lower layers as well, he's our human HexRays) and just recently, pumpkin, who you will know from the Dev Team. pumpkin will be the heavy support that's necessary to take down _FTLRestore, which is the most complex function I've seen in 1.1.4 iBoot (and I've pretty much have seen all of it). pumpkin is very good, so this task should be now be cut down to "fairly difficult" from "completely impossible".

The strategy so far has been me methodically hacking through the functions in the order that they are called, completely decompiling them, understanding them, and assimilating them into openiboot. Toward this end, I've been working on FTL_Open, which is a fairly large (but as it turns out, boring) function, but has been useful in enlightening us on several of the large data structures FTL uses.

Meanwhile, CPICH works on functions ahead of me, so that when I reach them, a lot of the thorny underbrush has been cleared out and my job becomes much easier and faster. Toward this end, he has been working on FTL_Read, which uses the data structures that the now-completed FTL_Open should populate.

_FTLRestore is sort of a "bonus", since it's not normally called if the iPhone was shut down normally and everything is cleaned up. However, since recovering faulty data structures require all redundancies to be exploited, reversing this would let us gain a lot of insight into how the FTL works. It's also, naturally, an enormously complex function, and hence I wisely delegated it to pumpkin. =P (We will probably end up working on it together)

The one thing that troubled me was that the code we were reversing is for 1.1.4 whereas we primarily need it to work on 2.0. However, due to the fact that I had it better mapped out than the 2.0 iBoot, and the fact that the equivalent 2.0 code was much more complex (lots of function pointers flying around, and a weird switch idiom I haven't quite figured out yet), We decided to stick to the 1.1.4 iBoot.

After completing FTL_Open, I had a bit of a panic when I discovered it did not work at all on my 2.1 phone, and I could not find any obvious bugs with it. This might've meant that all our work on 1.1.4's FTL was for naught. Forgoing sleep, I tore through the 2.1 iBoot, locating the analogues to my already reversed 1.1.4 functions (I had given up trying to trace through the function pointers the first time around), and called them directly with my special version of iBoot (patched so that one of the commands was able to call arbitrary iBoot functions with arbitrary arguments). I managed to find a couple of bugs with my VFL code, and after having fixed them, FTL_Open appears to have worked. I think. It just finds and reads several data structures from NAND. It remains to be seen if I'm even reading the right thing.

Now for some sleep.