Matthew Garrett (mjg59) wrote,
Matthew Garrett

Palm Pre

I'm in the UK and even if I weren't I wouldn't be using a CDMA phone, but the Palm Pre is undoubtedly an interesting device and so I've spent a short while looking at the root filesystem that can be extracted from the downloadable ROM image. There's some interesting things there. Bear in mind that this could be some QA internal image, so chunks of what I talk about may be wrong - on the other hand it seems to have been produced in May, so it's probably pretty close to what's shipping.


As others have figured out by now, the Pre is codenamed Castle and there's some references to another device called Pixie. This is presumably the Eos device that's expected to end up with AT&T. The other interesting thing is that the image contains modem firmware for both CDMA and UMTS. They're shipped as tarballs - extracting them gives you something that looks awfully like the firmware for the Qualcomm Gobi dual-CDMA/HSDPA chipset used in a bunch of modern laptops. The core firmware is an ELF object for 32-bit ARM. It's got references to Qualcomm in it and it's also got an embedded RSA signature which presumably cuts back on the potential for interesting hacking. The

/usr/bin/PmModemUpdater -e < /usr/lib/modem/castleumtsfw.tar

command, executed as root, should flash the UMTS firmware to the modem (castlecdma_evt1_fw.tar is the CDMA firmware). However it should be noted that the MSM6801A baseband used on the Pre seems to be a CDMA-only chip and there's no obvious place on the board for a SIM socket. My assumption is that the GSM models will have a very similar baseband with different radios. Unlocking the device will presumably be similarly difficult to the iphone - someone will need to find a flaw in the Qualcomm firmware that allows the network lock to be skipped. The PmModemFactory command will let you unlock the phone, but you'll need the appropriate code to do so and can (I guess) permanently lock it if you enter the wrong code too often.

The internal flash appears to present as mmc for some reason.


A lot of the software on the Pre is GPLed, and Palm are therefore obliged to provide copies of the appropriate source code to anyone who receives the software (note that receiving the device is not required - if the software is downloadable then the source offer must be made available to anyone who receives the software). The source code is not currently downloadable - instead Palm have included a written offer to supply the source code on request. This satisfies the GPL, but I can't be bothered doing that for the moment so all of this is purely based on examining the binaries.

The full list of applications extracted from the open source information documented included is here.


The Pre appears to be an OpenEmbedded-based system. It uses ipkg for package management and the majority of the basic userspace apps are all from Busybox.


The Pre's running 2.6.24, and there's various references to Windriver. There's an internal git repository codenamed rockhopper, which is a little odd - rockhopper's the codename for a MIPS-based NEC evaluation board. It's probably coincidental, given that there's only so many species of penguin available. The version string includes "joplin" - there's evidence of this in mailing list posts dating back to last year, so it's not clear whether "joplin" is the entire WebOS kernel project or a codename that covers both the castle and pixie platforms.

The hardware-specific drivers look well-integrated, for the most part using the standard kernel interfaces (backlight, led and so on) - this is a marked contrast to Android, which tends to go its own way in this respect. There's a driver for the OMAP DSP, the exmap code for analysing application memory usage, oprofile for detailed profiling analysis, some crypto code, a driver for an SDIO-attached Marvell wifi chipset and support for being a USB gadget (ie, something that appears as a USB device when plugged into a USB host). Side note - depending on whether the system is a castle or a pixie, the g_composite gadget driver is given a different ID to let the host OS differentiate between the two. castle will appear with a USB id of 0x8002, and pixie 0x8012.

There's nothing else very interesting looking about the kernel. The source code should reveal more.


The Pre uses upstart as its init application. In contrast to mainstream Linux distributions that still mostly use upstart in sysvinit emulation mode, the Pre appears to be almost entirely based on native upstart events. One of the things they've used this for is to automatically stop various services when the update service is started. Beyond that there's nothing exceptional here, but looking at etc/event.d does give insight into what's running on the device.


In contast to Android, the Pre uses the standard GNU C library and associated userland. Filesystem layout is pretty typical Linux, with / containing the low level binaries and /usr containing the rest of the OS. The only slightly weird thing is that various utilities exist in both their busybox and full forms, and I'm not entirely clear on why it's shipping things like fsck.ext4 though I guess you could use an ext4 sd card or something.

Audio is handled through pulseaudio, while media is handled by gstreamer. There's a large collection of codecs for the DSP including WMA and h.264, but no obvious ogg support despite libogg and libvorbis being mentioned in the list of open source software shipped. Future plans? Pulled partway through development? Unclear.

ipod emulation

The Pre pretends to be an ipod by switching into a different USB profile (and thus giving the right USB information) and setting up a filesystem that looks like an ipod. It provides a SysInfoExtended file that looks like an ipod. The only terribly interesting things about this are the list of formats (AIFF, MP3, WAV, AAC, AppleLossless, Audible, H.264, MPEG4 and H.264LC), the fact that it supports album art, the fact that it doesn't support Apple's DRM and that the firewire GUID looks like it's probably the same on all Pres. Could Apple break this support in a future version of itunes? Yes, but none of this support is hardcoded in the Pre's hardware - Palm could provide an update that matches. I don't see any real benefit to Apple in breaking the support, and if it could be shown that they were doing it deliberately then there could be potential legal issues.

The code actually looks generic enough that it could probably be made to emulate other USB mass-storage based media players if you wanted to. I have no idea why you'd want to.


There's a PalmOS ROM image for use in the emulator. usr/share/accountservices contains some files with interesting links in - one of them gives a full dump of the PHP setup on a Palm server, which gives some indications of their internal network setup and other things that are probably harmless but companies usually get paranoid over. The flasher application is called Trenchcoat. There's setup code for traffic shaping support - I haven't checked whether this is for application QoS on the device or whether it's intended for use with tethering.

Binutils is shipped. The Pre has an ARM assembler installed by default. The mind faintly boggles. It looks like there's tethering support via the Bluetooth PAN profile (see usr/bin/PmConnectionManager) as well as via USB. IPC is dbus-based rather than using something custom like Android's binder.


I'm impressed. There's a few rough edges and some obvious short-term hacks, but overall the Pre has the appearance of being a well-engineered distribution. It's recognisably Linux in a way the Android isn't. Since it seems to be possible to gain root by entering the developer mode, I suspect that modifying the firmware image isn't especially difficult. It'll be interesting to see what happens when GSM ones appear.

There's some more information at the pre dev wiki.
Tags: advogato, fedora

  • Not here

    For anyone still trying to read this, I am now here.

  • Supporting UEFI secure boot on Linux: the details

    (Update January 18th 2012 - you probably want to read this for details on why the technical details described below are not the difficult bit of the…

  • UEFI secure booting (part 2)

    Updated: Three things happened to defuse this situation: Microsoft mandated that it be possible to disable Secure Boot on any Windows certified…


Comments for this post were locked by the author

  • Not here

    For anyone still trying to read this, I am now here.

  • Supporting UEFI secure boot on Linux: the details

    (Update January 18th 2012 - you probably want to read this for details on why the technical details described below are not the difficult bit of the…

  • UEFI secure booting (part 2)

    Updated: Three things happened to defuse this situation: Microsoft mandated that it be possible to disable Secure Boot on any Windows certified…