Getting to the console of your TomTom

Your TomTom runs linux. It wouldn’t be linux if it had no shell console, would it?

The problem is that TomTom won’t allow you to see it by default. Its screen is bound to a frame buffer device, which is not used to display text.

There are several ways to access the linux shell on TomTom. You can rebuild kernel and make it use fbconn to use frame buffer for console. Or you can try serial connection to attach through the docking/service contacts. Just search the web for these variants if you want to, I won’t bother, because the easiest way is to attach via Bluetooth.

Bluetooth shell

(Just in case, make sure you have a Bluetooth adapter on your PC)

First off, download this small archive. It contains all the needed shell scripts and the rfcomm program. Now, put the contents of the archive to the root of your TomTom flash card. Note that you might already have a ttn script there. This script is executed when TomTom boots up, so you’ll need to merge your one with that in the archive.

Ok, now reboot your TomTom. Don’t forget to detach it from USB. It should boot and freeze with two hands on the display. That’s it; it’s in the console mode.

Now, search for Bluetooth devices from your PC. It should discover a device named like Debug One V4. This device should have a COM-port service running. Attach to this service, this will create a virtual serial port on your PC.

Use your favorite terminal application to connect through that port. I personally prefer Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/). HyperTerminal, which is built into Windows, can also be used, but it’s buggy.

Once attached, hit Enter several times. And some more several times. And… after all it should show you a login prompt. Login as root with no password (huh, anyone to hack into my TomTom?).

Ok, you’re there, in the shell. TomTom uses BusyBox, which is a fat-free implementation of most standard linux command, but it is still very usable.

The navigator application is not started automatically with my ttn script, so you’re stuck with the console. To launch the navigator, key in ttn& command. To launch the navigator on startup you can add ttn& to the end of the ttn script if you wish to.

File transfers (over console)

This is not what I’d recommend you to do, because it’s slow, error-prone and dumb after all. My choice is to use a card reader and put the files on the card directly. However, there is a way to transfer a file using your terminal application. Given that your terminal app supports ZModem protocol of course (Putty doesn’t, HyperTerminal does!).

First, on the TomTom, cd to a directory where you want to store your file. Execute lrz command, it will enter listening mode. (Delete the file manually first if you plan to overwrite it – for some reason lrz won’t do it for you even if you force it to).

Next, from you terminal start a file transfer using ZModem protocol. This should be it.

Easy card access

As a developer, you’ll probably need to transfer files to your TomTom zillions of times a day. If you have a card reader, transferring files to the TomTom appears to be easy enough.

From the TomTom’s linux point of view, the flash card is just a removable block device. So you can mount and unmount it if you like to. However, in order to unmount it, there should be no processes run from the card, and also your current working directory (pwd) should not be on the card.

If you look into the ttn script from the archive that you downloaded, you should see that I copy all the stuff I need to run to the /bin directory and run in from there. This allowed me not to have processes started from a card. Though, the pwd thing still bugged me, so I ended up writing the mo and um scripts (in the archive also). You run the scripts like . um (dot space um) from the console, and it cds to the root and unmounts the card. The . mo (dot space mo) mounts the card back and cds to the root of it. The dot-space stuff is required to make it work.

So that’s it, unmount the card, put it into your card reader, write something to it, put it back into TomTom and mount it.

Note that if the navigator application is running, it may reboot if you eject the card. Be warned.

Conclusion

What would I do without this shell access? Hm, dunno.

Cons: Bluetooth is good, but it’s slow. I’m currently trying to get the USB support up and working. My plans are to enable full time serial access over USB and full time card access over USB. The first option should allow fast shell to the device and possibly the fast FTPing. The second option speaks for itself. The hardware is capable of this, but the kernel is built with no USB support by default. Ok, more on this later.

There is more stuff I have dug out already. The cool things are TCP/IP access to the TomTom, and the on-device debugging. Read on.