Which sources to choose ?When it comes to the Linux kernel, there are many alternatives. For example, many PDAs running Linux use a heavily-patched version of the Linux kernel (such as uClinux for example). Since the OMAP processor is a full-featured CPU, and since we're not that short on memory (32 Mb of RAM is far enough), we decided to use plain vanilla kernel (available from the well-known kernel.org website). However, it appeared that there was an OMAP-development tree being maintained. This tree is pushed up to the mainline kernel, so it doesn't really matter which one we use. The later just let us benefit earlier from the latest patches.
How to build a kernel image ?Unless you're working on an ARM-powered machine you'll first need to install a cross-compilation environment. Basically the idea is to build a specific version of GCC that will run on your platform (say PowerPC or x86 for example) and that will produce ARM binary code. Once you've installed this environment, you should have a lot of binaries starting by "arm-linux-" somewhere in your $PATH. When you're done with this, just put "ARCH=arm CROSS_COMPILE=arm-linux-" before any "make" invocation.
Booting your kernel imageOnce you've built your kernel image, just fetch the file arch/arm/boot/Image, and copy it into the garux directory. Then cd to garux root folder, and "make". You'll obtain a nice .prc containing your image plus its associated bootloader. Please just make sure you're Image is not bigger than a megabyte, otherwise Garux may have problems booting it.
What we're working onThe most important part now is to get some output out of the kernel. That is extremly important, since we cannot debug the kernel nor the bootloader till we haven't figured this. An easy way to do it is to use a serial console. But here is the big problem : the Tungsten E doesn't have such an output :-(. Here are the choices we have :
- Using the IrDA port : If we cannot use a serial line, then why not using the IrDA module ? It might be a good idea. However setting an IrDA communication is more complicated than with a simple serial line. We haven't worked much in that direction, and actually it might be a solution.
- Using the sound module : Er... well, it's possible. But seriously, who will want to use this ? :-)
- Using the USB port : We tried working on it. I built a kernel with USB gadget support, and ran it with my Palm attached to my iBook running an USB logger. The logger didn't receive anything, and the USB port of my iBook even turned itself off to save battery. Actually the USB wasn't expected at all to work out-of-the-box, so this failure was predictable.
- Using the LCD : this is what I've worked the most on. The LCD controller is embedded in the OMAP, so thanks to the work of the folks working on the OMAP linux tree, it should be possible to get it to work. I tried two approaches : either get the LCD not to be intialized by the kernel, or either fetch the right initilization values from the PalmOS. I tried disabling the LCD initialization, but it didn't work. So I tried the other solution. According to the OMAP LCD Controller guide (the title of this guide says OMAP5910 but all of this is also true for the OMAP310), most of the LCD initialization parameters are stored at FFFE:C000 - FFFE:C014. I dumped these memory locations using a small program on my Palm (the program was compiled in native ARM, of course), and here is what I got :
Memory Location Data Contained Interpretation FFFE:C000 0xFE810CE5 FFFE:C004 0x1B070D3F HSW (Horizontal Sync pulse Width) = 4, HFP (Horizontal Front Porch) = 8, HBP (Horizontal Back Porch) = 28, and PPL (Pixels per line) = 320 FFFE:C008 0x0708013F VSW (Vertical Sync pulse Width) = 1, VFP (Vertical Front Porch) = 8, VBP (Vertical Back Porch) = 7, and LPP (Lines Per Panel) = 320 FFFE:C00C 0xFF300005 PCD (Pixel Clock Divisor) = 5 FFFE:C010 0xFFFFFF92 FFFE:C014 0x5C00F000