The next change is due to a request from Taki asking for tangogps to be preconfigured to use the sd card for map and track storage. So now, by default, maps on my builds are stored in:

/media/card/tangogps/Maps/OSM/


and track logs are stored in

/media/card/tangogps/logs/


This should be a little more useful and wont fill up your flash with tiles.

Next up we have a little script that starts on boot, checks to see if you have the gllin ipk ( gllin_1.0+r350-r0_fic-gta01.ipk ) in the root of your sd card. If it’s there it will automatically get installed for you – Very useful post-flash. The script will also replace the standard gllin script with the one from the tangogps site. Why? Well, because tangogps and gpsd are in the image too! Shortly, I’m hoping to provide a pre-downloaded series of tiles for download too. The good news is now you can have gps and a gps application ready for you immediately. Oh one last thing. If you create a directory on your sd card called local you can create bin and/or sbin directories and have applications run straight from there – all those little utils you need to install again after each flash now have a permanent home.

All of these are part of the image, you do not need to install anything extra, unless you want to

Update: The bluetooth keyboard script is much more wizzy now that I’ve added Zenity to the image and use that so you can now pick the keyboard you want to connect to from the list of devices. I’ve also added some notify calls so that you can see what is going on during the script.

I have decided to move my original OM-2007.2 directory to OLD-OM2007.2-FIC so that you can still get old files if you run older images. The OM-2007.2 directory on my buildhost will now be for om-gta0* images and packages.

The theme is fairly basic, but removes most of the images which should help with resources and I think, make the Neo more responsive.

The theme itself is based on “Clearlooks-DarkCoffee” by Franco Gotusso (sorry no link). Essentially I’ve merged bits from the original Openmoko theme and the Clearlooks-DarkCoffee themes picking the parts I wanted from each, but with the primary goal of making thinks work faster.

update: I’ve been getting requests for the theme so I am making is available for download, although it is a work in progress so will change in the future. When you untar the archive it will create an openmoko-standard-2 folder, replace the existing one in /usr/share/themes/ on your Neo1973.

“We have carefully reconsidered how to best serve the OpenMoko community in supporting our PCF50633 product, and our decision has been to allow you to publish the full User Manual on the OpenMoko website. This is more effective for the development community then having to reference to 2 documents, being the DS already sent to you and the addendum containing the register description. We therefore prefer that the full UM get’s published. The Company Confidential notice has been removed. We hope to see the successful application of our device and hope to see many OpenMoko products in the market, using our PCF50633.”

So really, we should have hundreds of pairs of eyes looking at this for the GTA02. Anyway, in the meantime I’ve been testing out a little battery pack, supplied by Portable Power Supplies in the UK, which is charged and charges via USB ports. Just the ticket for the Neo GTA01. The unit takes an initial, approximate 6 hours to charge and can be done from a standard USB port on a desktop or laptop. There is also a wall charger available but this obviously bumps up the price. Once charged the unit will happily sit there for months at a time doing nothing, which makes for a good emergency backup. Of course the battery pack will not indicate to the Neo that it can do fast charging but it is capable of doing so – indeed it can serve up a healthy 700ma – but that problem is solved by Bobby Martin (wurp2 irc nick) who has produced a python application to help out. This little application allows you to force the Neo to do fast charging (draw 500ma). Obviously by doing this you override the safety checks, but as I already know that the battery pack is capable of serving more than the Neo will take there’s really no risk here. So far my Neo has been running off it for more than 24 hours and I’d expect it to go on for a lot longer too. This is going to mean that I don’t have to turn off my Neo to save power, especially when I do those overnight trips to and from The Netherlands. I’ll update here when the battery eventually dies, I’m expecting at least 3 or 4 days but we’ll see.

update: at about 4am this morning the Neo had managed to suck the life out of the battery pack and its own battery. This is horrific, showing just how thirsty a Neo is. The total time ended up at about 30 hours, but I’m going to rerun the test to be sure.

update 2: I’ve repeated the test 2 more times now and the results are very similar, sadly.

“First of all OpenEmbedded based systems are harder to build, due to the dependency of monotone and the properitary, OE-only, bitbake, and then even another MokoMakefile build wrapper.”

First of all any system that you know nothing about it hard to use. The use of monotone is not an issue, I use a version just for building my OE stuff. Calling bitbake propriatory is like suggesting that every kernel module is propriatory. Bitbake is used to ‘bake’ (make) the recipes (.bb files) and is “derived from Portage, which is the package management system used by the Gentoo Linux distribution.” The source is freely available at berlios – why is there an issue here? It also appears that this author doesn’t understand the role that the MokoMakefile plays. The MokoMakefile was developed by Rod Whitby to help people who are new to OE and OM build and setup it is not part of Openmoko or OpenEmbedded. Really, if they had even bothered to read the wiki entry for it they would have seen this. I guess it’s easier to spout bile than be accurate.

“OpenMoko also is glibc and sysvinit based…”

Ok, I’ll let this slide since it’s true and just the author’s opinion on what is or is not suitable. I’ll come to the speed issue later.

“Forthermore OpenMoko comes with custom Gtk+ widgets and custom Moko libraries and applications, where Gtk+ PDA / phone applications are already available”

For a start “So what?”. Are you suggesting that no one develops anything that already exists? Should we have one email application, one word processor? What about one operating system? Clearly that gripe at Openmoko is just irrelavant. Furthermore you can actually build gpe applications for the Openmoko platform if you want. Take a quick look at what’s installed and you’ll even see that gpe-scap – what we use for screenshots is installed by default.

“yet another Gtk+ PDA / phone application stack equals reinventing the wheel.”

Actually, this is how progress is made. Take a look at the recent work on the moko underground stuff for an example. What’s more in the very next paragraph…

“We therefore started to create a saner, smaller, fully functional T2 based target”

So you decided to reinvent the wheel? Now to your bullet points

“T2 based, no bitbake…”

So you swapped one ‘propriatory’ build system for another?

“uClibC based, frees your phone’s…”

This, we agree on, but it does make building applications outside the tree a lot easier to not use uclibc.

“not sysvinit, bootup in less than 2 minutes…”

My Neo boots in less that 2 minutes all the time.

“GPE based GUI, to re-use existing applications…”

Did you actually write anything yourself then?

“focus on UI functionality early, no endless tinkering and rewriting, “

Wow, someone who writes perfect code and a perfect interface straight off! Oh, wait.. you’re actually using other people’s code so you’re not really doing anything yourself.

“includes just one embeded scripting language…”

Openmoko doesn’t include a scripting language by default, unless you count the shell, but you can install any number of them – including lua.

“just one… …webkit.”

Openmoko uses webkit.

Nothing you have said would inspire me to even take a look at your ‘T2 based’ project, least of all your attitude. Your main gripe seems to be that FIC didn’t use your T2 build system – that and a belief that everything not written by you is crap, as evidenced by your faq.

There’s an awful lot of work gone into this by emdete (irc nick) for which he should be congratulated. Not only is it a working prototype but he has been thinking outside the box – more of this is needed for new opensource devices to make it in the marketplace. I’ve chatted to emdete on irc and he is aware of some of the shortcomings of this first release. Primarily he was keen to get a working version to demonstrate at FOSDEM, which makes sense. In the future we can look forward to a more modular approach and of course, for those of us who don’t speak German, localization.

These new images also serve as a test-bed for Mickey Lauer’s gsm mux daemon which, wonderfully, has a dbus interface, something I really would like to see in all the daemons in Openmoko.

../../libkoto/libkoto.a(koto-task-view.o): In function `on_note_activated’:
/builder/newBuild/build/tmp/work/armv4t-angstrom-linux-gnueabi/
openmoko-tasks2-0.1.0+svnr379-r1/trunk/libkoto/koto-task-view.c:261:
undefined reference to `koto_platform_edit_task’

(just in case someone feels the need to fix it – hint hint )

but that has given me a chance to start poking about with other things. One of those things happened to be smstools3. SMS Server Tools 3 (smstools3) can take an ordinary phone or gsm modem and turn it into an SMS gateway that can send and receive SMS messages. Now, I don’t have a gsm modem but I do have a Neo 1973. Within 5 minutes I had SMS Tools compiled using the Openmoko toolchain. I’ve taken to using the toolchain quite a bit for testing before I create the .bb files so I can do proper building. Once I’d got a compiled smsd, I put together a simple /etc/smsd.conf file for the Neo (listed below).

devices = NEO
logfile = /var/log/smsd.log
loglevel = 6
outgoing = /var/spool/sms/outgoing
checked = /var/spool/sms/checked
failed = /var/spool/sms/failed
incoming = /var/spool/sms/incoming

[NEO]
device = /dev/ttySAC0
baudrate=115200
incoming = yes
regular_run_interval=3600
regular_run_cmd=AT+CFUN=1
regular_run_cmd=AT+COPS
pin = 1234

Obviously the /var/spool/sms directories needed to be created too. Before you start up smsd though you need to kill off gsmd by simply issuing the command

/etc/init.d/gsmd stop

gsmd will then stop and, from what I gather, power off the gsm chip. This bit is fairly important to know, since you actually need the chip to be powered up. We can do this simply by using the command

echo 1 > /sys/devices/platform/neo1973-pm-gsm.0/power_on

smsd can then be started, if you want to stop it forking use the -t switch on the command line. Incidentally, if you want to use the regular_run_xxx commands in your configuration you need to use the latest beta of smstools3. I needed to use them to get the Neo to register with the network, particularly as I’m actually roaming while doing this. To send an sms you simply copy a text file into the /var/spool/sms/outgoing directory – The format of the file in its simplest form is

To: destination-number

message-text

That’s its most basic form, you can get much more complex. There are some very nice features in smstools particularly that you can trigger actions on the receipt of SMS messages.

This should only affect people who build from oe dev and not the om version and should be fixed at some point. Although I am unsure as to why Openmoko is depending on gpsd anyway, at least at this stage.

Update: This should now be fixed. I’ll be rebuilding today’s build and making them available soon (busybox currently broken). Thanks go to Michael “mickeyl” Lauer…

I did wonder if the application should have an interface at all or if it should just run in the background, ‘secretly’ so that if someone stole your Neo you might actually be able to trace it.

The one thing that this did show me, however, is that you can’t actually run gllin for a particularly long time. I think it’s a minor fix but it does tend to fill up the free space on the Neo with its log data. I guess just disabling this might help, though I haven’t actually bothered to poke around with that just yet.

The other news is that to build this application I used the new toolchain and I have to say it makes life a whole lot easier. As a result I will also be building the toolchain at regular intervals and providing downloads via my buildhost. Sorry, but I can only build 32 bit versions at this time.

Aside from all the shouting at the end of the EULA, there is one sentence that did catch my eye and it was fairly early on.

“…removal of the Software from a country in which it is licensed shall automatically terminate this license.”

Notwithstanding the fact that I could pretty much guarentee that neither you or I would happen to know in which countries it is licensed in, apparently if you happen to wander into a country that is not on this list you just lost the right to use the software. I think it’s only fair to know the boundaries, can we have the list please.

Since the EULA doesn’t allow the distribution of the binary .ipk file I’m afraid that you aren’t going to see this in any non-official images either. I’m not even sure that it’s practical for the official images to contain it. What would be useful, however, is if the ‘firstboot’ scripts checked your SD card for the .ipk and automatically installed it for you. I’m fairly certain that I’ll start putting this into my images shortly.

Although it’s a binary only .ipk it is at least a step in the right direction and at least GTA01 owners can now legally use their gps.

At the moment I’m selling my house in The Netherlands and moving back to the UK. Until the house sells I flit between the UK and Holland every couple of weeks. I’ve taken to using the Chunnel for this because it means I can drive through the night rather than have to bend to the ferry or flight schedules. The trouble is, my wife gets worried that I’m going to crash and burn. She does this every time I do the trip, in either direction. She wont go to bed until she knows that I’ve at least got to the Tunnel.

I brought the original code out of my archive and started looking at it, removing anything that was TomTom specific. I’m pretty sure that I’ll have a workable solution fairly soon, I may butcher the openmoko-agpsui2 application a bit too, just to add a face to the tracker application code. Obviously, it will need a network connection of some sort so I’ll be looking at starting and stopping a gprs connection, or using wifi when the GTA02 arrives.

On the topic of gprs and network connections, I was mulling over some points in my mind about this. Nobody wants their Neo to pull an iPhone, and give us all large bills because of roaming, so there needs to be some mechanism where the user can deny or allow access to things like gprs connections. These could be based on dates, times, even locations with the built in gps. The problem is not that it is difficult to do, the problem is that we need to be able to force applications to use an API to open gprs and wifi conections, and possibly even access the gps. There’s a whole kettle of fish here. Openmoko is opensource, not the Google kind of ‘opensouce’, the real kind. That in itself poses a few questions and perhaps some not so nice answers.

If we want to force people to use an API, then we have to make sure that they can only use the API and not bypass it. If they can bypass it, it’s useless because the malicious ‘l33t h4x0r’ is going to abuse your connection. The problem is, since we are opensource, the same abuser can simply replace the API. Sure you still have to install the application, but just think about it. Right now how many places do you update your Neo from with ipkg? If any one of those gets compromised or the owner deliberately alters packages, the first you’ll know of it is when you bill hits the mat with a thud rather than the usual ‘ftht’.

We can think about signed images or signed packages etc but that is not really going to help, this is opensource. As an application developer I’m going to want to publish applications, I don’t really want to have to get them certified or signed by someone else just so other people can use them. If you alert the user that an application or package is not signed, you know that they’ll just click ‘ok install it anyway’ and ignore it.

I think I’m going to have to ponder this one a little longer.

If you ssh into your Neo and you are running one of my builds, then you will also find a file called

/etc/release

with the release date and time of the image, for example

ScaredyCat release qtopia-image-200711181035

The file appears in both my Qtopia and ScaredyCat builds but, as always, the standard Openmoko builds I do are unaltered so do not contain anything other than what is normally there – at this point that’s nothing, but may change in the future.

If you want to change the picture it’s a fairly simple procedure, either replace the file

/usr/share/pixmaps/wallpaper.png

with the file you want or change the gconf entry

/desktop/poky/interface/wallpaper

and make it point to the file you want to use. For example,

gconftool-2 –config-source=xml::/etc/gconf/gconf.xml.defaults –direct –type string –set /desktop/poky/interface/wallpaper /media/card/mypicture.png

You will need to restart the Openmoko-Today application which, for most people, will mean a reboot of ther Neo.

The good news is that I now have a dual booting Neo with Qtopia and Openmoko, although I don’t know how badly booting like this this will affect the current very poor battery life. At least I can now test either as I want without flashing I might even buy myself a bigger SD card and partition it off and have a number of bootable versions, who knows maybe Android will get on there.

showing the download bandwidth used, in MB for my buildhost. It’s worth noting that the figures for October are to the end of yesterday, whereas August and September are for the entire months.

The last time something like this happened was when I released the very first asterisk live cd although my guide did dramatically increase my hit rate – incidentally you can get PXE boot and CF card booting editions from the same page as the live cd.

I found it much better to use the snapshots rather than the official images.