Posted by planetbeing on under wine fest, spring beer, iphe, pain in the butt, th step, funny name, pmu, hande, framerate, sime, management unit, chip sets, lcd panel, framebuffer, power management, init, two steps, award winner, general purpose, many things | 
Looks like the LCD initialization stuff wasn't as simple as I thought. Depending on the way you look at it, there are three or four major initialization steps for the display. The first step initializes the display controller chip, sets the clock and everything. The could of messages you see about the framerate and clock are from this step. The second step ought to initialize the framebuffer for the display controller. I've reverse engineered and implemented those two steps so far.
The third step is to communicate with the LCD panel itself, and likely configure it and configure the display controller for it as well. This is the infamous "merlot_init" function. I have no idea what merlot is (other than a wine variety). Could be the codename for the driver, or the display controller. Can't be for the LCD itself, since its design to hande many different panel types. It's a pretty funny name, though, so I've started working on syrah_init. Syrah, because the 2005
Dalla Vina vintage was an award-winner at the Spring Beer & Wine Fest that I went to last year.
The problem with merlot_init is that it uses GPIO, SPI, IÂ?C as well as memory mapped registers to communicate with the panel and/or the display controller. That's almost every single bus on the iPhone, so basically I had to write drivers for those controllers as well before I could start on merlot_init. Those are now written; no idea if they work, but they're written. It's going to be a big pain in the butt to debug such a complicated driver. There's just too many things that can go wrong.
It's possible I might start implementing some of the PCF50633 (iPhone's power management unit) functionality. I can at least access powernvram (the general purpose memory registers on the PMU, really) pretty simply using IÂ?C and I ought to be able to test that piece out anyway.
On another note, for the longest time I couldn't figure out what those gpmem registers did on the PMU. I reversed some code that manipulated them, but I couldn't figure out where the data was being used, etc. However, I didn't spend much time on it because I didn't think they were going to be very important for what I was doing (since their values don't affect the initialization of any of the other drivers). Well, last night I told MuscleNerd about this for some reason, and he pointed out that there's a command called "powernvram" in iBoot that, no less, attaches descriptions to every single one of those registers! They just keep track of boot failures and stupid stuff like that. It just goes to show that you can't spend TOO much time just doing static RCE. Sometimes you've got to fire up the actual application, or at least give the old ztringz a go. ;)
Tagi: wine fest, spring beer, iphe, pain in the butt, th step, funny name, pmu, hande, framerate, sime, management unit, chip sets, lcd panel, framebuffer, power management, init, two steps, award winner, general purpose, many things
Posted by on under technical snapshot, spi bus, baseband, unsigned code, software hacking, memtest, hardware problem, reas, sime, ipod touch, jailbreak, snag, two steps, attempts |
â?? one step back.
Disclaimer!! This is a purely technical post with no pragmatic use! There is no 3G unlock in this post. There is no iPod Touch 2G jailbreak in this post. Itâ??s just a random technical post related to the 3G unlock.
Weâ??ve been exploring different ideas with the 3G unlock, but this past weekend one of us hit a big snag. For whatever reason, all of our poking and prodding of the 3G baseband caused it to finally have a breakdown. After one specific exploit run, all of a sudden our baseband stopped responding to the OS. Even after multiple restore attempts, we were plagued with errors like this:
Somehow our software hacking had caused the baseband chipâ??s SPI bus to stop responding (so it looked like a hardware problem). Even though BBUpdaterExtreme reported the correct baseband version, it failed basic tests like memtest:
If youâ??re familiar with the baseband revision history for the 3G iPhone, you may have noticed that the above captures were done at the original 01.45 baseband. As dire (and hardware-related) as these messages sounded, though, there was a simple solution. We just updated to 01.46 and then downgraded again (because we can run unsigned code on the baseband CPU) to 01.45.
We tried to recreate the problem by using the same exploit over again, but it doesnâ??t appear to be reproducible (which is actually disappointing, as it might have been exploitable).
Anyway, there you goâ??a random, technical snapshot of dev team work.
Tagi: technical snapshot, spi bus, baseband, unsigned code, software hacking, memtest, hardware problem, reas, sime, ipod touch, jailbreak, snag, two steps, attempts
Posted by on under technical snapshot, spi bus, baseband, unsigned code, software hacking, memtest, hardware problem, reas, sime, ipod touch, jailbreak, snag, two steps, attempts |
â?? one step back.
Disclaimer!! This is a purely technical post with no pragmatic use! There is no 3G unlock in this post. There is no iPod Touch 2G jailbreak in this post. Itâ??s just a random technical post related to the 3G unlock.
Weâ??ve been exploring different ideas with the 3G unlock, but this past weekend one of us hit a big snag. For whatever reason, all of our poking and prodding of the 3G baseband caused it to finally have a breakdown. After one specific exploit run, all of a sudden our baseband stopped responding to the OS. Even after multiple restore attempts, we were plagued with errors like this:
Somehow our software hacking had caused the baseband chipâ??s SPI bus to stop responding (so it looked like a hardware problem). Even though BBUpdaterExtreme reported the correct baseband version, it failed basic tests like memtest:
If youâ??re familiar with the baseband revision history for the 3G iPhone, you may have noticed that the above captures were done at the original 01.45 baseband. As dire (and hardware-related) as these messages sounded, though, there was a simple solution. We just updated to 01.46 and then downgraded again (because we can run unsigned code on the baseband CPU) to 01.45.
We tried to recreate the problem by using the same exploit over again, but it doesnâ??t appear to be reproducible (which is actually disappointing, as it might have been exploitable).
Anyway, there you goâ??a random, technical snapshot of dev team work.
Tagi: technical snapshot, spi bus, baseband, unsigned code, software hacking, memtest, hardware problem, reas, sime, ipod touch, jailbreak, snag, two steps, attempts
