A long time ago I talked on IRC to someone who seemed to have a lot of design-level knowledge on PalmOS despite being totally clueless about programming. He claimed that PalmOS kernel was really a true multitasking OS’es kernel with lots of features like desktop OS kernels have and that it was a descendant of some other proprietary OS, of which I think this person was a great fan (funny how every, even the dumbest of OSes must have a sort of cult around them). But as far I can tell this person was right and PalmOS really has a full-blown kernel, making it a royal PITA to debug or disassemble. Despite the complete OS being so dumb and looking even dumber than it is, in the kernel there’s a scheduler, there are mutexes, semaphores, completions, locks, memory pools and other nasties. Figuring out what a process is waiting for in a given moment is very difficult.
How do we know there are semaphores etc.? This is the cool part: with a little scripting you can get a full trace of all instructions that are executed and see what functions are being called. That wouldn’t tell you much if not for the PalmOS symbol tables that were leaked a couple of years ago (not sure what they are really, it’s like a long list of all standard calls with only the name and number for every syscall and it applies to every device because there’s a standard way of invoking the syscalls across all PalmOS versions on ARM. There are only a few device-specific calls). How they leaked was also an interesting story that I was once told by someone but don’t remember well, but the plot involved elements like spies, a microfiche, Russia (maybe not exactly, but close). Here’s a heavily stripped sample of the execution tree cut out of a PalmOS run with the symbols inserted where appropriate, and non-branch instructions removed (the program that generated the tree got it slightly wrong because it assumes that the log begins at reboot, not somewhere in the middle – the whole trace would count in terabytes – according to the script there were 1172429829 instruction executed in the boot-up, but only 96183 unique, i.e. 96183 different r15 values – which is not to say that all the 117… were loops – the script detects loops and “rolls” them back into a loop form). You can see calls like WinPaintRectangle towards the bottom.
Another interesting detail about PalmOS is in the UI it uses DMA to draw solid rectangles and other shapes. For example the boot-up animated logo is all done by the DMA and the CPU only waits for the DMA to finish between calls (imho defeating the whole point of using DMA, but it’s still an interesting idea). The animation is visible in the emulator screen and you can even appreciate some artistic details that are not seen on the real hardware, or I didn’t notice them before. Everyone knows that the animated Tungsten logo is the only reason people still use PalmOS.
To draw a rectangle it sets the DMA frame size to be the width of the rectangle in bytes and sets the frame index to be the difference between the addresses in the framebuffer of the right edge pixel of a rectangle and the left edge pixel on the next row. The channel’s source is constant-addressed and points to the variable that holds the pixel’s colour value.
I still haven’t had much time to play with the stuff. The most tricky information we can get from PalmOS is probably what it does during suspend/resume because that’s what’s difficult to get right without documentation, and even with it. Linux battery-life-in-suspend is currently drastically shorter on this device than in PalmOS.
For some reason during boot-up, its kernel also reads some three values from a place in memory that’s part of Flash chip-select 2 area, and afaict there is no chip there. I made some tests on the real hardware, from under Linux and I couldn’t read any sane values from there, but I will keep looking. It would be nice if there were more peripherals connected that we didn’t know about. The way MMU is set up by PalmOS also suggests that there’s something there. (Maybe left over from an older devince or from a development ROM.)
That’s about it. First thing I did after PalmOS booted successfully, which was about 3am Monday two weeks ago, I started looking at how PalmOS manages the MMU tables because it appears to perform some funny MMU-acrobatics when it boots,.. but I was interrupted by the Second thing.
Second thing I did after PalmOS booted successfully was throwing stuff into my backpack in a great hurry and getting the hell out of my home and running to the airport where I planned to be at 4am to catch the 6am flight to Birmingham for GUADEC 2007 where I spent that whole week. The flight was, of course, delayed by some 4 hours and I only got some sleep after finally getting onboard, and then later after a nice dinner with Nokia and the rest of OpenedHand.