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.
