When the bootloader is not the bootloader...

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.