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.
Wednesday, March 4, 2009
Friday, February 27, 2009
Sunday, December 14, 2008
Debian on iPhone Linux
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.
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.
Saturday, December 6, 2008
Porting drivers to Linux
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.
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.
Sunday, November 30, 2008
Donations...
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.
Saturday, November 29, 2008
Updating and uninstalling openiboot
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
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
Friday, November 28, 2008
Linux on the iPhone!
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.
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.
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.
Subscribe to:
Posts (Atom)