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

QuickOIB

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

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