LCD status

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

Boot menu project is a go!

Posted by planetbeing on under command line mode, development snapshot, clock frequency, clock speed, lcd driver, coue, boot menu, ipod touch, binary search, current development, would make sense, framebuffer, text mode, opti, weirdness, layman, iphe, desktop computer, iboot, butts |

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.
Tagi: command line mode, development snapshot, clock frequency, clock speed, lcd driver, coue, boot menu, ipod touch, binary search, current development, would make sense, framebuffer, text mode, opti, weirdness, layman, iphe, desktop computer, iboot, butts