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. ;)
