So the methodology has currently been trying to proceed as quickly as possible, trying to get every device working and aiming for breadth instead of stability. This allows me to do more high-value tasks like reverse engineering, rapidly gaining understanding of the platform instead of just getting bogged down debugging every single thing. Unfortunately, we're paying a bit for it now as I try to get things into gear to put together applications.
First thing is, I don't really trust the current memory structure. For one thing, it's WEIRD. It seems like even if I turn the MMU off, 0x0 is still mapped to 0x18000000. I know the MMU is working, somewhat, because if I allow the heap to run into the place I put my pagetable, bad things happen. =P I understand there's not going to be enough devices or memory to fill out the entire 32-bit address space, though, so maybe there was already some sort of static mapping. I also believe 0x9000000 (the range used by iboot's file transfer facility) is mapped to 0x18100000. That is, 0x0 == 0x80000000 == 0x18000000. The problem is that there are no such mappings in the page table. 0x80000000 to 0x180000000 is set cacheable and bufferable, but is identity mapped. Anyone have enough experience with the hardware to tell me if this makes sense? I mean, maybe it's just that the top 4 bits are just completely ignored by the memory controller.
Second thing is, sometimes I get random freeze-ups and I don't know why. Maybe I'm just hallucinating or screwing up somewhere, or maybe it's just me failing at C (wouldn't be the first time this happened). Anyway, the upshot is, I want to go back through and clean up/refactor the code into its final form. I tried to follow best programming practices as much as possible the first time around, but sometimes it just was too inefficient to do so when dealing with only half-way reverse engineered device drivers.
The third thing is what I'm working on currently. I need openiboot to replace iBoot. I currently have written a pretty simple chainloader. All it does is warm up all the devices as usual, and then load iBoot from NOR and then jumps to it. iBoot is relocateable and should be able to get itself to the right place. Now this works fine from a copy of openiboot that is started from iBoot using "go", but after I flash openiboot onto the "ibot" image in NOR, the device goes straight to DFU. Now either I'm screwing up hardware initialization or there is some additional verification (checksums, probably not signatures) done before LLB wants to load iboot. It may be that the latter is more likely, since I end up in DFU mode rather than a hung device. Not sure if the device is intelligent enough to recognize a failed boot if I don't say, update the powernvram.
After I get this working, the next thing is to see if the gamma table stuff works then (and if not, fix it). After that, the boot menu I talked about can be written. The next thing I want to work on is NAND FTL. That's the last piece before we reach the end of the "openiboot" phase and can move into the Linux phase. Pretty much all the drivers people expect will be ready and the fun can begin.
I know it seems like we're still very far, but I think we've made very concrete and tremendous progress in a fairly reasonable period of time. A lot of things are now clear and the biggest obstacles are not Apple's protections, or a lack of understanding, but merely my own stupid mistakes and typos.
Speaking of horribly stupid mistakes, my next post will be the story of how I almost bricked my phone yesterday night (but not really :P).
Subscribe To
Posts
All Comments
June 6, 2010
comments (0)
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 31, 2010
In the process of testing NOR, I did a pretty lulzy thing. Remember what I said earlier about the memory controller possibly ignoring the first 4 bits? Well, the NOR device ignores the top 12 bits, since it's only 1 MB in total size. This makes a lot of sense. All the designers have to do is basically not wire up some parts of the address bus. So whether you try to address 0x0 or 0x100000 on the NOR, it looks the same to it.
The problem came about because I attemped to add too many images to NOR; a few 140 KB iBoot images can add up pretty quickly. The last one I added ended up shooting into the range reserved for NVRAM (at the end of NOR) and then "wrapping around" to clobber SysCfg, IMG2, and part of the LLB. =P
Hahaha, that's the equivalent of shooting yourself simultaneously in every vital organ. SysCfg stores your SERIAL NUMBER and other unique, irreplaceable pieces of information. The NVRAM contains information iBoot needs to boot up the kernel. The LLB is the thing that securebl tries to load in order to access everything else on NOR and bootstrap iBoot. As the coup de grace, IMG2 contains information that allows the LLB and iBoot to find where the Img2 data starts, so that they can be loaded. This mistake basically was the equivalent of erasing the entire NOR: Every single piece of information on it was rendered unusable. :P
Luckily, as the first test of my NOR driver, I had made a dump of my original NOR, so I was able to restore the SysCfg information. The interesting bit about all this is that you don't even have to do a restore and lose all your data on the NAND even, if you're clever. What I did was let iTunes talk to DFU mode to get into an iBoot. The iPhone actually has a pretty standard DFU mode, as defined by the USB standard. It reports itself as having the correct class, and OpenMoko's dfu-util manages to get, well, something with it. It successfully uploads the iBSS 8900 file (looking at a USB dump, it looks like just the entire file with the 8900 header, signatures, certificates, etc.) but reports that the firmware is corrupted. So at least it seems to use standard status indicators, etc. However, since I couldn't get dfu-util to work, I just used iTunes and pulled the cable out right after it finishes uploading the iBSS. DFU mode doesn't actually change the NOR, it just loads iBSS into memory and executes it. So after this process is done, iBSS will be loaded and you can connect to it via iBooter.
If you had pulled out the cable just a little too late, you can even see the commands iTunes executed on iBSS in the scrollback, Like setpicture and bgcolor. =P
Using the loaded 1.1.4 iBSS, you can bootstrap the necessary actions to restore your NVRAM from backup. I will talk about that in more detail in a future post. But the upshot is, even if you complete kill your "bootloader", and indeed, everything you can possible write to on the iPhone, you can still get things back to normal. :)
Unfortunately, I probably won't have a chance to work on iPhoneLinux stuff much this weekend. I have already been activated by the Dev Team because you-know-what is happening. Time to hax.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
It’s not 100% official but next iPod Touch Generation 4 or iPod Touch 4.0 will have Camera on the back. Checkout the image below! It is a iPod Touch 4.0 Apple Development iPod Touch which was originally displayed for sale on Ebay! Yeah, No kidding! Somebody is selling Development iPod Touch 4.0 on Ebay!
Well if you want to see it on ebay , or maybe even bid on it, go to this Ebay link.
Also thanks to 9to5Mac for news and photos.
May 30, 2010
I'm going to address the two comments I received in this post. This basically has nothing to do with Linux, and more to do with iPhone hacking. There's a lot of confusion around with the jailbreak/unlock. The two comments basically hit upon the main points. The main confusion centers around the fact that when you buy an iPhone, you're not just getting a computer, you're getting TWO computers.
What I'm interested in is the S5L8900, the thing that runs the iPhone software. There is another device called the commboard, which has its own processor, nonvolatile memory, boot sequence and everything. It's barely an oversimplification to state that the system board (the S5L8900) and the commboard can only communicate with each other over a serial UART. That is, the only way the system board can control the commboard is with human-readable AT commands! Not very low level at all; they're not very integrated. Being able to hack kernel mode code like iBoot does not give us any more access than we had through minicom on a jailbroken iPhone.
kavkan asked me if iPhone Linux would obviate the unlocks. He then started talking about putting on third-party applications, etc. Putting third party applications on your iPhone is usually referred to as jailbreaking: stuff we do on the S5L8900. When we say unlock, we're usually mean a SIM-unlock. That necessarily means breaking a whole other, entirely distinct, set of security that's on the commboard. A jailbreak makes it easier to do that (because you can now talk to the commboard with that serial UART I discussed earlier), but it's entirely separate.
marc asked me about "bootloader corruption" as it pertains to basebands. As I said earlier, the bootloader I am talking about is on the S5L8900. The baseband/commboard has its own bootloader and its own non-volatile memory (also NOR flash, probably the same bit of flash its bootloader and firmware sits on too). The recovery mechanism on the baseband is far less robust than the one on the S5L8900. The only sure way seems to be using that hardware testpoint to force it to accept a new bootloader, and even that can be defeated by carefully crafting the NOR contents. In other words, it sucks.
In addition, a lot of the problem is due to bad software overwriting the seczone with bad data, stuff that's unique to your phone. Therefore, information is irretrievably lost and there may not be a way to recover.
The disclaimer is, of course, I'm not a baseband expert. This stuff is only what I've surmised by hanging out with some of them. It's kind of funny. On the dev team, w___ and Zf (they're baseband guys) and I were talking about how little we each know about the others' work. We do pretty much the same work, but on different platforms. After I explained what we do on the S5L8900, I think w___ said that he did the same thing "only on the baseband, you have a man sitting on top that does stuff to you for unknown reasons". And for the S5L8900 people, we have a little black box connected to us that either magically works and lets us call people... or not.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 29, 2010
There is common repertoire for every instrument. Every brass player comes across Arban's Carnival of Venus, every alto saxophonist encounters Parker's licks. For some instruments - piano, guitar - the literature is so extensive that there may not really be anything common for two musicians to share. If you're into country blues or Segovia, you can play guitar for fifty years and never get to learn Purple Haze. On the other hand, every slide guitar player can play Rollin' and Tumblin'. For many other instruments, the book is pretty thin: every banjoist can pick Black Mountain Rag, French horn's got its Mozart Third Concerto and Wagner bits, for harmonica there's My Babe, bagpipers have a handful of Scottish/Irish tunes... and how much is written for gamelan or theremin? It takes a long, long time to build a literature for an instrument - which makes the euphonium situation all the more miraculous.
Euphonium is a wonderful but obscure instrument of the brass family (it's also got a twin brother called a baritone saxhorn - the difference is like trumpet and cornet, i.e. pretty much none). Looking like a dwarf tuba, it is a tenor-pitched instrument with a range similar to that of a trombone. I blame its obscurity on the fact that there was pretty much no repertoire for it - until recently. In the last decade or so, an interesting thing happened: euphonium book spontaneously expanded and engulfed a most unlikely style - the video game music. A cursory search on youtube reveals hundreds of young euphonists (euphonimists? euphists?) bashing out this or that Mario theme, Zelda's Ocarina Of Time etc.etc. It's not like there's a music school somewhere with a particularly geeky/open-minded low brass professor - the players are from all over, Europe, UK, US, wherever. It seems like the idea of picking out a videogame tune on a euphonium or tuba is the most natural one.
Hereby, I present my case:
A one-man brass orchestra:
A one-man euphonium trio:
Final Fantasy 6
Teeeetriiissss!!!!!
Here's one for three tubas
No less than five overdubbed euphonium parts - notice it's the same guy as the first video, euphonium07, Anthony Caillet - check out his youtube channel!
And this one must be the coolest videogame music interpretation ever - not on euphonium, though.
So how did I manage to FIX the problem I mentioned earlier? The reason I was so vague on the details is that I used a confidential iBoot vulnerability that we didn't want Apple to know even existed! This allowed me to bootstrap openiboot directly from a stock iBSS that was loaded through DFU mode. I still can't tell you exactly what it is, but since geohot already leaked the existence of it, I figure I can tell you it exists and is what I used. :)
Then, it was a simple matter of using openiboot's NOR engine to restore everything. I even can use the new image list parser and AES engine to have a very nice high level interface to the image list, allowing me to "pwn" just with openiboot; no ramdisk futzing around!
The AES code has been in SVN for awhile, but to anyone following jailbreaking news, it's probably obvious why I suddenly, out of the blue, decided to reverse it and write it. Haha. So the night that I committed the AES code, is the night the Dev Team first decrypted the new img3.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 28, 2010
Just a post to indicate things are inching forward slightly. I've been working on debugging USB communications and it seems a lot more stable now. I was basically forced to because my old code only works on computers without usb 2.0, so that ruled out being able to easily work on this project with anything approaching a modern computer. The problem was that I avoided reading the official USB specs (those things are usually overly locutious) and tried to learn instead from sites such as USB in a Nutshell. Unfortunately the driver then failed to properly respond to the device qualifier descriptor which led to epic fail in USB 2.0. The embarrassing thing is iBoot does send this descriptor, but I figured it must be a vendor specific one at the time.
Cmw made me a cable that let's me do serial and USB comm at the same time, which helped a lot in working out the bugs. I'd say it's fairly reliable now; enough for other developers without a serial cable to come in. So how about it, guys?
I've also started to scratch the surface of the NAND driver. Unfortunately, even the lowest level functions are enormously complex. The higher level wear leveling code and data structures even aside. A great deal of it seems to belong to Samsung, since I've found some creepily similar C code lurking around online. Unfortunately, I can't find a complete enough copy of it.
And yes, I'm aware of Android and their source release and yes, I know what you're thinking.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
Just a post to indicate things are inching forward slightly. I've been working on debugging USB communications and it seems a lot more stable now. I was basically forced to because my old code only works on computers without usb 2.0, so that ruled out being able to easily work on this project with anything approaching a modern computer. The problem was that I avoided reading the official USB specs (those things are usually overly locutious) and tried to learn instead from sites such as USB in a Nutshell. Unfortunately the driver then failed to properly respond to the device qualifier descriptor which led to epic fail in USB 2.0. The embarrassing thing is iBoot does send this descriptor, but I figured it must be a vendor specific one at the time.
Cmw made me a cable that let's me do serial and USB comm at the same time, which helped a lot in working out the bugs. I'd say it's fairly reliable now; enough for other developers without a serial cable to come in. So how about it, guys?
I've also started to scratch the surface of the NAND driver. Unfortunately, even the lowest level functions are enormously complex. The higher level wear leveling code and data structures even aside. A great deal of it seems to belong to Samsung, since I've found some creepily similar C code lurking around online. Unfortunately, I can't find a complete enough copy of it.
And yes, I'm aware of Android and their source release and yes, I know what you're thinking.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 27, 2010
I'll take his Hot Fives/Sevens to a desert island, no contest. There is no point in sharing them, though: there have been at least three different "complete" reissues, probably more, and all are easily available elsewhere. However, his sideman recordings are more obscure. After coming up to Chicago in 1922 to play with King Oliver and then Fletcher Henderson, Pops was very much in demand as a studio musician and accompanist. I am sure he did not mind making some dough on the side, either, so there is a wealth of his solos backing the famous and not-so-famous blues singers of the day, from Ma Rainey and Bessie Smith on down. In fact, the record execs noticed that the 78s with his solos - even uncredited - often sold better, and that gave them a bright idea to record Armstrong as a leader; the rest, as they say, is history.
Today's share is a collection of tracks with Armstrong's participation, recorded between 1924 and 1927. There are some sublime solos here; my favorites are two Bessie Smith tracks - I Ain't Gonna Play No Second Fiddle and You've Been a Good Ole Wagon; another great track, He Likes It Slow, features the whole Hot Five and so appeared as a part of the "Complete" box sets. I should warn the prospective listeners that some of this is pretty sonically crude. Hot Fives and Sevens were an all-star band and they got all the latest studio gizmos and extra attention from the recording engineers; also, we get to hear the Hot Fives and Sevens after they've been put through the marvels of modern remastering. These tracks, OTOH, have none of the above; what they often do have is a distinctive unrehearsed "let's cut it and go drinking" one-take feel - the balance is all over the place, there are stumbles and rough spots, and the instrumentation is sometimes rather skeletal, such as the vocal-cornet-harmonium trio on the St. Louis Blues. So, for all the historical interest and occasional brilliance of Satchmo's solos, these probably won't be going with me to any desert island unless I'll be taking my 500GB hard drive with me.
A very thorough Armstrong discography can be found here, refer to it for session dates, personnel and instrumentation.
I had a lot of trouble getting the LCD driver to work. Everything seems to be fine except that when I try to write to the memory address range reserved for the LCD's gamma tables, it doesn't register. It's as if some clock or some device hadn't gotten turned on or something. Therefore, after loading openiboot from iBoot, the screen gets all screwed up.
However, if you load iBEC from iBoot, the screen doesn't get screwed up: you can still use bgcolor and everything works. I thought that meant at first there was something wrong with my LCD init code. I spent a frustrating day carefully auditing it for errors, and I did find two bugs that I fixed, but unfortunately it did not have any effect on the main problem. I got as far as I could with static methods so I decided to perform a series of experiments.
First, I had some trouble chainloading iBoot and iBEC from openiboot. There was a series of fails that I fixed along the way: trouble with USB send (just a silly typo in the client), trouble getting the resulting thing to execute in memory (you've gotta turn off the CPU caches, disable MMU and interrupts for it to work properly. It also can't be run as part of an ISR because, well, iBoot expects to be able to receive interrupts, so I had to move the command processor onto the main thread and just have the ISR queue up commands for the main thread to process). Anyway, those were eventually fixed.
My experiments showed that after openiboot did its inits, chainloaded iBoot and iBEC was unable to reinit the LCD properly (they had the same problem). I narrowed the problem down to the place in power.c where I "turn off" the LCD controller. This happened in the 114 iBoot, so I thought it was necessary. Analyzing the newer 2.x iBoots, that routine was actually removed. Since I am reasonably confident that my syrah_init is functionally identical to their merlot_init and this that power init that when present, causes LCD init to fail in all cases and when absent, allows LCD init to succeed in all cases, I'm pretty sure that's the problem.
So I went ahead and removed it. This may or may not mean I am actually depending on the iBoot that I chainloaded openiboot from for the LCD init. We'll see after I try to replace iBoot entirely in the bootchain.
Anyway, USB is solid as a rock now seemingly and chainloading seems to be working quite well. I'm actually able to load iBoot from NOR, patch it in memory, and then execute it from openiboot. This probably means I'm ready to try flashing the thing again.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 26, 2010
Well, it's booting. Sort of.
I had some trouble getting the flashed version of it to work because for some reason, 0x0 was not mapped to 0x18000000 when openiboot was loaded. Since all the exception vectors are at 0x18000000, bad ones were being called whenever there was any sort of interrupt. Basically, I just said screw it and rebased the whole program into 0x0. It will basically overwrite whatever exception vector is currently running without worrying about the MMU and such. However, this basically does imply that I don't really understand how the MMU works, so that will have to be fixed.
The end result is what you see above.
The other major roadblock is that the gamma tables remain broken. Even after I chainload iBEC or iBoot over openiboot (as I have done there). The OS boots and everything... just with some really psychadelic colors. =P
So LCD remains a big problem and so does the MMU. But hey, it boots and works (sort of).
Update: LCD now partially fixed. I still need to figure out how to turn the backlight on, but at least chainloaded iPhone OS has normal colors now. =P
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 25, 2010
After a huge amount of effort and in-situ experimentation with iBoot (basically a binary massive binary search through the code, disabling some functions to see if I could figure out why my LCD driver wasn't working properly), I managed to get it fully working. The problem was two-fold: first, I forgot to write the first and last bytes of my gamma tables: oops, but easily fixed. The second problem was that apparently iBoot changes the SDIV of the clock in the middle of the initialization process. I'm not even sure yet how many devices the change in clock frequency affects. It certainly affected the LCD, because before there was all sorts of flickering scanline weirdness as one would expect from a misconfigured clock.
Anyway, I reversed the routine that changed the SDIV and implemented it. Seems to work fine now. It's been ages since I looked into the clock speed stuff (pretty much right when I first started this) so I can't say for certain, but I'm pretty sure doing this increases the clock speed (which would make sense).
The LCD driver worked after those fixes and I went onto write a simple framebuffer in a couple of hours, so we can finally get text-mode output on the iPhone screen. It was pretty important to me to get the screen working because even if we can boot a kernel, I wanted the layman to feel like a full-fledged OS was running on the device, and that means display and I/O of some sort.
For a final hurrah, I also wrote some code that lets us detect when the physical buttons (Home, Hold, etc.) were being pressed down. From these pieces, it will be possible to construct a graphical boot menu controlled by those buttons. You could have one option to boot into the iPhone OS, and one option to go into openiboot command-line mode with that text-mode display.
The photo I posted is the current development snapshot running on a first generation iPhone, with oibc (openiboot client) connected and running on my desktop computer. If you have a 2G iPhone or a first-gen iPod touch, you can try it out yourself by checking out the code from Github and compiling it (It's only designed to be built on a Linux machine. You'll be missing some Linux headers otherwise). I wrote some basic notes on how to get it running inside the source tree, but this is not something you're expected to work with unless you're a fairly experience programmer yourself.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 24, 2010
Well, that was quick. See, I can actually get things done pretty quickly when it doesn't consisting of banging my head against machine code until it starts making sense. When I actually have the drivers, things like this are easy.
You can use the Hold button to toggle between the menu items (and the option will be highlighted). You can choose the home button to select it. The "openiboot console" option takes you to the command-line interface similar to the one I demonstrated in the last post (you do have to be plugged in via USB and using the openiboot client to talk to it). The "iPhone OS" option chainloads a copy of iBoot stored in NOR under another identifier ('ibot' becomes openiboot and 'ibox' becomes the actual iBoot). I got that set up with a slightly modified version of the QuickPwn ramdisk, but in the future an installer made from a modified version of LogoMe can be run from userland to install openiboot. It's also possible to get openiboot to install openiboot (much like the way GRUB can do it); I'll probably work on that next.
So if anyone likes living on the bleeding edge, they could do that. =P
Most of the hard part was me failing at GIMP putting together the boot menu graphics. I appealed to you blog readers for graphics before, but basically no one responded. Now that there is a working model of what I sort of want, I hope there will be more of a response.
So, please please please redesign the boot menu for me. And possibly come up with a logo for the project we can stick on there. If you're good at this sort of thing, or know someone who is, please put them in touch. This stuff will obviously get a lot of attention in the future and we need nice eye-candy. Thanks!
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
Well, that was quick. See, I can actually get things done pretty quickly when it doesn't consisting of banging my head against machine code until it starts making sense. When I actually have the drivers, things like this are easy.
You can use the Hold button to toggle between the menu items (and the option will be highlighted). You can choose the home button to select it. The "openiboot console" option takes you to the command-line interface similar to the one I demonstrated in the last post (you do have to be plugged in via USB and using the openiboot client to talk to it). The "iPhone OS" option chainloads a copy of iBoot stored in NOR under another identifier ('ibot' becomes openiboot and 'ibox' becomes the actual iBoot). I got that set up with a slightly modified version of the QuickPwn ramdisk, but in the future an installer made from a modified version of LogoMe can be run from userland to install openiboot. It's also possible to get openiboot to install openiboot (much like the way GRUB can do it); I'll probably work on that next.
So if anyone likes living on the bleeding edge, they could do that. =P
Most of the hard part was me failing at GIMP putting together the boot menu graphics. I appealed to you blog readers for graphics before, but basically no one responded. Now that there is a working model of what I sort of want, I hope there will be more of a response.
So, please please please redesign the boot menu for me. And possibly come up with a logo for the project we can stick on there. If you're good at this sort of thing, or know someone who is, please put them in touch. This stuff will obviously get a lot of attention in the future and we need nice eye-candy. Thanks!
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
I've been getting a lot of questions from people that seem to reflect a basic misunderstanding of what it takes to port an operating system onto a new platform. People seem to think that just by writing, say, a boot menu, means that we can stick Android or Windows or whatever onto a device because we can have a menu option for it.
Here's what it takes for an operating system to run on a device:
- The code must be designed for the right CPU. (x86, ARM, PPC)
- The code must be able to interact with the hardware in the way it expects.
Because the code cannot interact with the hardware! That is, there are no Linux drivers or Windows Mobile drivers for the hardware that's on the iPhone. We're not even talking about things like the wi-fi won't work or anything silly like that. We're talking about big things, like not being able to start because it doesn't uncompress itself into RAM properly. We're talking about freezing the first time it has to wait for something to happen because it doesn't know how to run the hardware clocks and timers (which is CRITICAL for computers) and doesn't know when to start again.
Thus , if I tried to take some distribution of Linux or Windows or whatever, stick it in memory and start it, absolutely nothing will happen. That's right: nothing. There will be no output because it doesn't know how to run the display, or the USB, or serial. It probably won't even get to the first line of code that tells it to output something because so many things are broken.
So how can we get Linux to boot on the iPhone?
By teaching it how to run the hardware. We take the knowledge gained from getting that boot menu to display and graft it into the Linux kernel. It took an unbelievable amount of devices just to get the boot menu display: clock, timer, vic, mmu, spi, i2c, gpio, system controller, pmu, nor, uart, usb, lcd, buttons. Some of those may seem obvious to you, some work in the background to support the other devices. But all of those had to be reverse engineered and all of them will have to transplanted into the Linux kernel to even get something half-assed booting.
If all of those devices were required to get something as simple as boot menu up, can you imagine what would happen if you tried to boot an operating system that did not know how to run ANY of those devices?
We cannot modify the Windows Mobile kernel because it's closed source, and so there's no way to get it to run on the iPhone.
The critical misunderstanding, I think, is that people think somehow that the OS "sits on top" of the boot menu, and talks to the hardware through the boot menu. Therefore, you can have an "emulation layer" that lets Windows or Linux or whatever talk to the hardware, without having to alter Windows or Linux itself. This is completely false. An operating system, by definition, has direct access to the hardware. Nothing sits between it and the hardware. Once iBoot has loaded the iPhone OS, you can go ahead and wipe it clean from the NOR and the OS will keep running as usual. It's not "running", it's not used or loaded in any way except during the boot process.
The iPhone will never run Windows Mobile directly (virtualization would be possible albeit it would crawl on the iPhone). It will run Linux once we write the drivers for it based on our knowledge of the hardware. Android uses the Linux kernel, though they do modify it to a certain extent. Since the only really hardware dependent parts of an OS is in the kernel, presumably once we install the necessary drivers, Android will run just as well as Linux runs. However, not having even looked at Android's source yet, I really don't have a truly educated opinion at the moment, but let's just say that it's one of this project's primary goals.
Sorry this is so long, but intelligent explanations tend to be long.
P.S. Another question people ask a lot is how long will it take. I can't truly give a good answer to that, because it's sort of dependent on the schedules of the people who work on it, and it also depends on how fast it'll take to write the Linux drivers, and how many unexpected problems crop up. It could go really unexpectedly fast, or we could hit a roadblock. I think outside observers, just reading the commit logs and reading the blog has as much information as I do on how fast things are progressing, so you're free to come up with your own conclusions on how long it will take.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 23, 2010
This is about ipod errore message and steps to troubleshoot these error. I suggest you to read basic ipod Troubleshooting. Ipod is new device and there are many unknown error messages like “ipod cannot be synced, An unknown error has occurred”, ipod 1418 error or ipod 1429 error and it make user frustrate. ipod error messages whether it's ipod mini or ipod touch or ipod shuffle this is actually communication problem Some error are vary simple and easy to rectify here is solution for
ipod Error 1415, 1417, 1418, or 1428: it also display message that
“Cannot restore or update iPod in itune 7 or later”
Where this problem occurs :-
If you are using itunes 7 and you are updating or restoring you ipod., you may got some error message saying "An unknown error has occurred" it also followed by error number 1415, 1417, 1418, 1428 or 1429. this problem are common for itune u or later with ipod.
Solution
1) try to use different usb port or first remove any other USB Device that you have connected to the computer (don’t remove usb keyboard or usb mouse ). And then try different USB Port.
2) update your itune to the latest version or download the latest version and do fresh installation.
3. Try connecting your iPod to a different USB port and restore.
4) If you are using microsoft Windows operating system, then try to update your usb driver or reinstall Windows USB drivers.
If you have ipod shuffle then you need to use ipod reset utility to restore ipod.
While I was waiting for CPICH to finish the first bits of the NAND FTL reverse engineering work, I've been trying to fill in some of the gaps we had in other places, such as the PMU. As promised, there is also now an easy way to install openiboot onto the iPhone. This is great because it will eventually lead to an even leaner and easier QuickPwn in the future.
One of the annoying parts about iBoot in recovery mode is that the thing refuses to charge the iPhone while sitting in recovery mode. The battery just eventually entirely drains. With the new PMU code, openiboot now recharges the battery, so programmers using it (read: me) can just have it sit on the console screen indefinitely. You can also do neat things like check the current battery voltage and check the power supply type the phone is charging from.
The "installation code" consists of porting over my knowledge of reading and modifying img3 files from working on the jailbreaks. I was too lazy to port over the entire xpwn framework, but I wrote up a "diet" version that is sufficient to read and modify img3 files in a limited fashion. img3 files are sort of the new native format of the main part of the NOR (just a bunch of img3 files concatenated together). The upshot is that you can load openiboot as an img3 through iBoot (just like sending an iBEC image) and then type "install" at the console and openiboot will be a permanent stage in your bootloader chain. =P
You can, of course, keep booting up to the iPhone OS as you always do by selecting the option in the boot menu. Installing openiboot isn't very useful except for hackers wanting to hack openiboot.
I also figured out how to parse and modify the NVRAM banks (storing environment variables like "auto-boot", etc.), which was actually pointless complicated (in my opinion). They have two banks consisting of a bunch of partitions with these headers that Apple uses a pointless one-byte custom checksum on. The entire bank is also checksumed with adler32. When NVRAM is modified, the oldest bank is overwritten with the data and becomes the newest bank (which is tracked by an epoch number on each bank). This is so if one bank becomes corrupted, the other can be used as a backup. However, NVRAM hardly contains anything high value so the value of all this trouble is doubtful. Being able to write to NVRAM, though, makes it possible to set auto-boot on and off within openiboot so that we can easily control whether or not to enter iBoot's recovery mode.
Someone asked me how "safe" it was to do the installation, etc. Well, I've been doing it every time I make an update these days, so it's fairly safe. The worst that can happen in the usual case is that you may be forced into a DFU mode restore. Everything will be undone with a restore. Early on, I did have bugs that really screwed things up so that a DFU mode restore was no longer possible, but even that was recoverable. I'll just go over how briefly:
The important thing is to have a backup of the NOR. As I described in a previous posting, it's possible to really screw things up if you erase the SysCfg section of the NOR. If you do that, the iPhone OS will refuse to boot at all since iBoot cannot properly populate the device tree for the kernel. Since restore ramdisks rely on XNU booting, this is Bad News Bears. In addition, the SysCfg section is device specific, so if you do not have a backup, it will be difficult to ever completely recover from erasing it.
Therefore, before you proceed, MAKE A BACKUP OF YOUR NOR. openiboot can do this for you (and subsequently restore your backup if things go wrong).
Load openiboot via loadibec and select the console. Connect with the oibc client. Type in: nor_read 0x09000000 0x0 0x100000
This will read all of NOR into memory. Then type: ~nordump.bin:0x100000
This will transfer the dump over USB onto your computer and save it as nordump.bin.
Supposing you filled the entire NOR with garbage somehow and are unable to boot. You have to get into openiboot to restore the NOR. The problem is that openiboot is only designed to operate in a post-LLB or post-Recovery Mode context, so it cannot be directly booted from DFU mode. Basically, you've got to load a pwned WTF, then a pwned iBSS, and then a pwned iBEC (all of which is available from a custom IPSW). After that, you can use loadibec to load openiboot. Then, you can restore the NOR thus:
!nordump.bin
nor_write 0x09000000 0x0 0x100000
After that, you can reboot and everything should be normal.
Also, I received a few responses for people volunteering to do the art. I'm not sure what the best thing would be, since I don't want anyone putting in effort for nothing, but we do want the best possible results. So, I'll be getting back to you guys about that.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 22, 2010
This is a post I wrote a long time ago, when this blog was first conceived. I decided to hold off on posting it, because I thought it'd be better to do some technical posts before waxing philosophically. I think it is still appropriate, so as we work on reverse engineering the NAND FTL, here's some food for thought.
Porting Linux to the iPhone is an arduous project. We will be trying to develop an entire suite of device drivers for undocumented hardware and then attempt to run a full-fledged operating system on it. This thread speculates "10 days" or "3 hours" as the amount of time it'd take to get Linux up and running on the iPhone. Perhaps this figure would be accurate on a x86 platform, or other platforms with hardware for which device drivers are already written or for which at least documentation is available, but we have no such luck on the iPhone.
This comment on a O'Reilly Radar article about NerveGas's iPhone Open Application Development book says, with perhaps a little too much vitriol for my taste, that developers should not waste time on the iPhone, a closed platform, and spend time more productively on OpenMoko or Android: truly open platforms. Apple should thus be punished for not making the iPhone open. His point is well-taken though. Reverse engineering Apple's code is inefficient and ought to be unnecessary. Why do I bother when I can just develop on an open platform instead with no such wasted effort?
Finally, I have faced skepticism even from my fellow Dev Team members when I first talked about this project. The iPhone already has a perfectly serviceable operating system that we can develop on. Why does it need another one? Sure, Linux might be cool, but what practical use would it have? How does it justify the tremendous amount of effort that would need to be put in?
So. Why do I bother? Why should we bother?
Part of the answer is that I don't choose which platform I hack on based on how hackable it is. I choose it based on how much I like it. I don't own an OpenMoko device; it simply doesn't look as polished as the iPhone, and support is lacking for it. It wouldn't make sense to buy it to use it, only to buy it to hack on it. While this may work for other people, it's simply not the way a (relatively) starving college student does things. As for the Android, I'm not too convinced about how amazing it will be from the videos I've seen and besides: It doesn't even exist yet! In general, the more people use a device, the more hackers use it, and thus the more it is hacked on. Usability frankly trumps hackability.
The other part of the answer is that iPhone Linux will actually be of tremendous value. There will be no more need to port applications over: The applications already run on the iPhone! Also, with a familiar kernel, we can do all kinds of things I've wanted to do: doing security related work with the wi-fi for example. Plus, knowledge that we are gaining/will have gained about the iPhone hardware will be of incredible practical value to the homebrew iPhone community. We've always wanted to be able to plug in the iPhone as a simple USB mass storage device. With USB and NAND FTL drivers, we can actually implement this ourselves.
Perhaps my most important point is how iPhone Linux will affect the various open platforms in development. The iPhone has revolutionized the way the market thinks about mobile computing and now several mobile platforms are in development: OpenMoko, Google's Android, and Mobile Ubuntu (thought the last is not targeted for phones). All of these projects are based on Linux, and "based on Linux" means that, by definition, they "use the Linux kernel" and the Linux kernel is exactly what we're porting. As long as the kernel works, the rest of the operating system will barely need to be touched at all! (fine print: provided that the working configuration of the kernel can support all the features the userland requires).
Imagine OpenMoko on the iPhone. Android on the iPhone. Ubuntu Mobile on the iPhone. Consumers will have choice, and not some Linux-hippie idealistic choice-for-the-sake-of-choice choice: All of these platforms have major momentum behind them and it is very possible they will end up being better than the iPhone's platform (have better UI, more application support, etc.). Also, imagine what it will mean for the developers of these platforms: A ready userbase of millions of users. If many people can already install and try out one of these platforms, it'll be far easier to attract users to buy the hardware, and developers to develop for the platform. Thus, I do not believe we are harming the open platforms by developing on the iPhone. In fact, if all goes well, we will be allowing them to conquer the Apple iPhone.
Of course, I know the reply to all of this. "That sounds good, now show me the code." It's important not to overpromise and underdeliver, so I will be very cautious. What I have just said is the hope, the best possible outcome. But just having that as a possibility is tantalizing enough to justify working on this project. However, to be honest, my original justification (as stated to the dev team) for working on iPhone Linux was "for Skillz.app", our facetious term for working on something merely to hone one's skill or to satisfy one's curiosity. But honestly, what did you expect from a "hacker"? :)
We have already made more progress with openiboot than many people have anticipated would ever happen. Reverse engineering drivers is a laborious process, but one that doesn't require the luck of finding a security vulnerability: It just happens slowly and steadily, rather than unpredictably. Presumably after the drivers are in place, the Linux kernel will "just work" without too many other changes, since it is designed to be relatively portable, so we ought not to have many problems. After the kernel works, I hope enough developers will become interested and a nice userland can be developed without too much trouble. The userland work is much less risky from a time-investment point of view.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 21, 2010
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.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
May 20, 2010
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.
Labels:
Adsense,
Apple,
Blogger News,
Computer Hardware,
DSL,
Footballkawa,
Google,
Intel,
Internet,
iPhone,
iPod,
iTune,
Microsoft,
Mobile,
Network Engineer,
USA iPhone,
Web,
Wireless
Subscribe to:
Posts (Atom)