I lied, this is not the "Why iPhone Linux?" post; it's boring and philosophical anyway. Instead, I've got some hacking news!
So I've been putting off the LCD driver because I always thought it would be big and complicated. A long time ago, before I looked at all the USB code, I took one look at merlot_init and got scared off, but upon revisiting it, it really doesn't look that bad. I also was afraid of it possibly needing complicated interrupt routines, but now I can see that it only uses interrupts to dispatch spi and possibly gpio i/o, which is generic and not too bad.
I also was wondering why openiboot, as it is, makes the screen fade to (nearly) white in what pytey has called "disco lights" behavior. openiboot is obviously breaking the already initialized LCD driver somewhere. At first I thought it was because iBoot has stopped responding to interrupts necessary for the upkeep of the LCD, but an infinite loop before anything has happened will cause the LCD to remain the same. Therefore, I put a bunch of rudimentary "breakpoints" (infinite while-loops really) around the beginning of openiboot, and discovered that the LCD breaks when I initialize the system controller's power feature, which just turns off most devices. If I don't do that, the LCD stays initialized. What's more, I can just write raw ARGB (well, from the perspective that I am writing little-endian integers that are 0xAARRGGBB, it's actually BGRA in memory) into the vram range (as labeled here) and it'll show up on screen! This is without any sort of interrupt support or depending on any other memory resident code. So apparently, all that is needed is the initialization routine for basic functionality!
This is great news, and the upshot is that I think I can finish the LCD driver by the end of this weekend. In addition, cmw has already written a framebuffer that can be used after driver init, so we can display text and whatever we want.
