After many frustrating hours debugging all the pieces that fit into this LCD driver, it now behaves as expected. Unfortunately, I still can't get the gamma table to install from a clean start-up (where openiboot powers down everything that iboot powers down before starting them back up). I think this is probably because the gamma table installation code that I reversed from iBoot is only designed to work in situations where the code is directly loaded from LLB. The other possibility is that I made a mistake somewhere in merlot_init. I know that the rest of my code is good because it generates the exact same register configuration that iBoot does. merlot_init is more difficult to diagnose because of all the SPI commands flying around. Most of them just read and write to registers on the LCD panel, though.
What's interesting about the gamma table installation function in iBoot is that it uses a custom, rudimentary form of compression. The gamma table is just a mapping from every R, G and B value (0 - 0xFF) to a range from 0 - 0x3FF. There are three table, one for red, one for green and one for blue. Each table has 0x100 4-byte values. That adds up to 3 kilobytes worth of tables! Since space on the NOR is at a premium, it's sensible that Apple use some kind of fast compression to store the gamma table data. Their compression encodes values two bits at a time, and takes advantage of the fact that each entry in the gamma table will be fairly close to the value of the last entry, just offset a little. They use the two bit control codes to select how to manipulate the differences. Iā??m not sure if this is any sort of standard compression, but I thought it was amusing that they had this in here. You can look in the iPhone Linux SVN for the code.
Still, we have working code and just a relatively minor problem! I think that means we could probably start some sort of logo contest. Here's how I think it will work: We need art for the bootloader menu interface. The art will naturally have to feature iPhone Linux, so that means that we also require a logo for this project. So we need the following things: A logo for iPhone Linux, and a logo (could be just a variant of the iPhone Linux logo) for openiboot (not sure what the canonical capitalization of that should be; we will probably use the logo as the reference). We also need art for the bootloader based on those logos. What I'm envisioning is just the logos, bracketed by arrows to make it obvious that you can select between them. Then, the standby key can be used to toggle through the various choices, and the home key will boot the selected one.
The winning set of artwork will be selected by community consensus. The community is very small as of yet, so I'm sure it'll be easy to just to talk it over with everyone and decide what people like. It's important to note that even if your logo is chosen, if someone offers us something prettier, we will switch, so don't do this if your feelings are easily hurt. =P
I really appreciate what artists do and the care and craftsmanship that they put into their work. You guys have a skill that I will never have and I know that it is a lot to ask to have you put that kind of work into something that might not even be used. However, I and many others have put analogous care into crafting the code for this project, and that is our salute to the community. So let's make something beautiful together.
To submit an entry, just contact me or cmw with it in some way, shape or form. Either on my gmail account (take a wild guess what my gmail address is :P), or on IRC, or here in the comments, or whatever. We'll see to it that everyone gets a chance to take a look at it.
Tagi: gamma table, th project, menu interface, byte values, iboot, lcd panel, two bits, kilobytes, svn, spi, init, linux
I've been getting a lot of questions from people that seem to reflect a basic misunderstanding of what it takes to port an operating system onto a new platform. People seem to think that just by writing, say, a boot menu, means that we can stick Android or Windows or whatever onto a device because we can have a menu option for it.
Here's what it takes for an operating system to run on a device:
The code must be designed for the right CPU. (x86, ARM, PPC)
The code must be able to interact with the hardware in the way it expects.
Now, there are versions of Linux compiled in ARM (which the iPhone uses), there are even versions of Windows Mobile that are compiled in ARM. Why can't I, then, just stick Windows Mobile or Android (or another flavor of Linux) onto the iPhone and give it a whirl?
Because the code cannot interact with the hardware! That is, there are no Linux drivers or Windows Mobile drivers for the hardware that's on the iPhone. We're not even talking about things like the wi-fi won't work or anything silly like that. We're talking about big things, like not being able to start because it doesn't uncompress itself into RAM properly. We're talking about freezing the first time it has to wait for something to happen because it doesn't know how to run the hardware clocks and timers (which is CRITICAL for computers) and doesn't know when to start again.
Thus , if I tried to take some distribution of Linux or Windows or whatever, stick it in memory and start it, absolutely nothing will happen. That's right: nothing. There will be no output because it doesn't know how to run the display, or the USB, or serial. It probably won't even get to the first line of code that tells it to output something because so many things are broken.
So how can we get Linux to boot on the iPhone?
By teaching it how to run the hardware. We take the knowledge gained from getting that boot menu to display and graft it into the Linux kernel. It took an unbelievable amount of devices just to get the boot menu display: clock, timer, vic, mmu, spi, i2c, gpio, system controller, pmu, nor, uart, usb, lcd, buttons. Some of those may seem obvious to you, some work in the background to support the other devices. But all of those had to be reverse engineered and all of them will have to transplanted into the Linux kernel to even get something half-assed booting.
If all of those devices were required to get something as simple as boot menu up, can you imagine what would happen if you tried to boot an operating system that did not know how to run ANY of those devices?
We cannot modify the Windows Mobile kernel because it's closed source, and so there's no way to get it to run on the iPhone.
The critical misunderstanding, I think, is that people think somehow that the OS "sits on top" of the boot menu, and talks to the hardware through the boot menu. Therefore, you can have an "emulation layer" that lets Windows or Linux or whatever talk to the hardware, without having to alter Windows or Linux itself. This is completely false. An operating system, by definition, has direct access to the hardware. Nothing sits between it and the hardware. Once iBoot has loaded the iPhone OS, you can go ahead and wipe it clean from the NOR and the OS will keep running as usual. It's not "running", it's not used or loaded in any way except during the boot process.
The iPhone will never run Windows Mobile directly (virtualization would be possible albeit it would crawl on the iPhone). It will run Linux once we write the drivers for it based on our knowledge of the hardware. Android uses the Linux kernel, though they do modify it to a certain extent. Since the only really hardware dependent parts of an OS is in the kernel, presumably once we install the necessary drivers, Android will run just as well as Linux runs. However, not having even looked at Android's source yet, I really don't have a truly educated opinion at the moment, but let's just say that it's one of this project's primary goals.
Sorry this is so long, but intelligent explanations tend to be long.
P.S. Another question people ask a lot is how long will it take. I can't truly give a good answer to that, because it's sort of dependent on the schedules of the people who work on it, and it also depends on how fast it'll take to write the Linux drivers, and how many unexpected problems crop up. It could go really unexpectedly fast, or we could hit a roadblock. I think outside observers, just reading the commit logs and reading the blog has as much information as I do on how fast things are progressing, so you're free to come up with your own conclusions on how long it will take.
Tagi: clock timer, iphe, day clock, versis, linux kernel, cpu x86, boot menu, linux drivers, mmu, android, opti, whirl, wi fi, graft, spi, knowledge gained from, many things, timers, vic, clocks
I finished writing a driver for the Zephyr2 on the iPhone. It's the same multi-touch solution that Apple has used starting from the first generation iPod touch and up to and including the iPad.
Now, of course this shouldn't be construed as a promise to support the iPad eventually, but this multi-touch driver is definitely a concrete milestone that is important for pretty much all of Apple's mobile Internet devices.
More immediately, this is pretty much the sole remaining blocking issue on the first-gen iPod touch and one of the two major issues on the iPhone 3G. The other issue on the iPhone 3G is baseband SPI. I'm wondering if we can get away with just using the debug uart to make calls (if we don't care about having a fast 3G data connection yet).
Also, I'd like some opinions from this blog's readers: More frequent updates? Or just document the major advances?
Tagi: mobile internet devices, iphe, ipad, prome, iphone, frequent updates, ipod touch, uart, spi
After many frustrating hours debugging all the pieces that fit into this LCD driver, it now behaves as expected. Unfortunately, I still can't get the gamma table to install from a clean start-up (where openiboot powers down everything that iboot powers down before starting them back up). I think this is probably because the gamma table installation code that I reversed from iBoot is only designed to work in situations where the code is directly loaded from LLB. The other possibility is that I made a mistake somewhere in merlot_init. I know that the rest of my code is good because it generates the exact same register configuration that iBoot does. merlot_init is more difficult to diagnose because of all the SPI commands flying around. Most of them just read and write to registers on the LCD panel, though.
