Hacking the Palm Pre from Fedora

My work machine is a Fedora 11 (F11) X86_64 system. The palm development SDK is distributed as a series of .deb packages, specifically targeted at an 32 bit Ubuntu 8 system. While I have the advantage of having a 32bit Debian system at home, so I was able to run through the setup process for development, ideally I would be able to attach to and control the Pre from my work machine.

The first step is to download the .deb files onto the F11 machine. I actually only needed the novacom deb, which in my case is novacom_1.0.38_i386.deb. Deb files are accessable using ar (happy talk like a pirate day!).

In a new and empty directory, run
ar -vxf ~/novacom_1.0.38_i386.deb

And you will see the three contained files:

control.tar.gz data.tar.gz debian-binary

Extract the data file using tar

tar -zxf data.tar.g

This will add a usr directory with the binaries in

usr/local/bin/novacom{d}

Novacom is a two piece effort: a daemon an a client. First make sure you can run the daemon.

First, lets see the file type:

file novacomd

novacomd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped

Let’s see what libraries it requires:

ldd novacomd
linux-gate.so.1 => (0x008f1000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0078a000)
libusb-0.1.so.4 => not found
libc.so.6 => /lib/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x006ae000)

Note that the USB library is missing. I have it installed on my system, but only the 64 bit version. To get the 32 bit version, first, figure out what the 32 bit vversion is named.

yum search libusb

libusb.i586

And install

sudo yum install libusb.i586

F11 and the RHEL based approach for running 32bit apps on 64 makes this fairly easy to do. Unlike Debian based system which pretty much require you building a chroot if you are going to run a significant amount of 32 bit binaries, Red Hat based systems put 64 bit libraries into /usr/lib64 and 32 bit libraries int /usr/lib, so they don’t conflict. Now lddd shows we have everything:

ldd novacomd
linux-gate.so.1 => (0x00262000)
libpthread.so.0 => /lib/libpthread.so.0 (0x008a5000)
libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0x00770000)
libc.so.6 => /lib/libc.so.6 (0x00263000)
/lib/ld-linux.so.2 (0x006ae00)

And we can now run this. Since it is talking straight to hardware, it insists on running as root:

./novacomd
[2009/9/22 11:40:48] novacomd version novacomd-62 starting…
[2009/9/22 11:40:48] novacomctl socket ready to accept
[2009/9/22 11:40:48] need to run as super user to access usb

so:

sudo ./novacomd
[2009/9/22 11:41:11] novacomd version novacomd-62 starting…
[2009/9/22 11:41:11] novacomctl socket ready to accept
[2009/9/22 11:41:11] sending rst
[2009/9/22 11:41:11] sending rst
[2009/9/22 11:41:11] sending rst
[2009/9/22 11:41:11] going online
[2009/9/22 11:41:11] novacom_register_device:188: dev ‘e851588c804e8caa722490a0314ce9782dd4d9a4’ via usb type castle-linux

No we turn our attention to the client piece.

file novacom
novacom: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
[ayoung@ayoung novacom]$ ldd novacom
linux-gate.so.1 =>  (0x00173000)
libc.so.6 => /lib/libc.so.6 (0x006d2000)
/lib/ld-linux.so.2 (0x006ae000)

So we are ready to run.  There is no novaterm in this deb.  Instead, you run novacom in terminal mode.  A little noted line in that I will make big here is:

./novacom $* -t open tty://0