First Motorbike defect in ten years

I've always had a BMW F650ST ever since turning 18. It never let me down so far, apart from one minor problem two years ago, when the carburetor was stuck and the bike was leaking fuel.

Yesterday, the starter motor apparently broke. Waiting for the replacement parts right now. Let's hope this is a one-time defect and not an indication that I should get rid of the bike before a long series of "bike is getting old" repairs.

Porting Motorola's TS07.10 MUX driver to 2.6.x

Since Motorola has finally released the source code for the mux_cli.o and gprsv.o modules of their 2.4.17 kernel on opensource.motorola.com, I've started to clean them up and port them to 2.6.x.

Due to the questionable coding style of that original source code, and the many interface changes in the TTY layer between 2.4.x and 2.6.x, this turns out to be a bigger task than expected. With some luck, I'll find some time tomorrow at ph-neutral to finish the initial port.

Once that code works on 2.6.x, I already have a quite long list of TODO's. First of all, the lower-layer interface needs to be cleaned up. Ideally, the whole TS 07.10 implementation is a TTY line discipline that can be stacked on top of any UART, together with a virtual/fake UART that makes use of the Motorola specific TS07.10 USB transport.

Some more librfid hacking

Today I fixed a number of long-standing bugs in librfid, resulting mainly from the conversion to autoconf/automake. Now, finally, users can actually use the native CCID driver again, rather than using OpenCT.

Also updated the README, added a udev rules file and started to make the librfid-tool program (formerly OpenCT-escape) a bit more flexible and user-accessible. It's my sincere hope that some other users (i.e. from the CCC) will write the missing user interface stuff and fix some remaining bugs...

Touch-screen driver for A780/E680, lots of other progress

As of today, the OpenEZX project has a working touch screen driver. I've been testing this with the Kdrive X11 server of OpenEmbedded, and it seems to work nicely on my A780 after calibrating with ts_calibrate.

This is such a major step forward, since the touch-screen driver requires a functional PCAP2 driver, which in turn comprises working SPI support, as well as some tricky SPI-during-hardirq for interrupt chaining.

If you're interested in giving it a try, there's the the -ezx6 quilt patchset including all this work.

Also, thanks to the work by Michael 'mickey' Lauer, I've managed to set up an OpenEmbedded environment to build a distribution for OpenEZX. You can find the first bunch of packages as well as a root filesystem that you can put on TransFlash on my OpenEZX developer pages.

The availability of a OE based root filesystem, a kernel with keypad, touch-screen, usbnet and framebuffer support actually means that all the [G]UI people can now start to work on making their favourite UI system work on OpenEZX. Given the amount of interest I've seen in this area, I'm confident that I still don't (yet) need to dive into UI development myself but can stay with the more technical low-level stuff.

Speaking of which, I've also hacked a nice tool called gpiotool, using which you can read/write GPIO configuration as well as individual GPIO pins from userspace. If I had written this earlier on, it would have saved a lot of time and hassle. But then, it's always hard pushing yourself to develop code that _just_ aids development and doesn't really add any functionality itself.

Using this tool I'm now investigating the AP/BP interaction (handshake). Let's hope that we can actually use the phone as a phone really soon.

Software for paleeograpy of Indic scripts

Those of you who know me a bit better will know that my now ex-{fiance,girlfriend} is studying indian philology and indian cultural history at Freie Universitaet Berlin. Now when you think about philology, you will probably think of old people wading through books and paper.

To the contrary. I've always been amazed how much software development they actually do (or have made) there. Some years back, I learned about Sanskritreader, an OCR (optical character recognition) software package for devanagari script.

Now their latest software is IndoSkript, a Palaeograpy software. It comes with a ~600MB database of scans of anciend Indic handwritings, where evey glyph in those scripts has been individually separated, and the scripts are annotated, etc.

Using that software (it's mainly a database software) you can for example check how a particular glyph was written in a certain timeframe in a specific dynasty in the Mysore area. Or you can draw [or import a scan?] a glyph and have it do pattern-matching, giving you a probabilistic analysis of which already-known glyphs match your new one the most.

As of now, it ships with a database of Brahmi, consisting more than 700 scriptures of more than 170,000 glyphs total.

It's great that they develop these tools, and it's even better that they are published as public domain software. What would be even better, is if they made their software Free Software and publicized the source code. This way other people could contribute and e.g. add a much-needed non-German localization, a precondition for any kind of international (e.g. Indian) use of it.

Maybe I can find a minute (and a minute of their time) to explain to them the marvels of Free Software.

Swades

I've had the chance to watch Swades at the home cinema of a friend. Swades is a quite impressive film, and definitely [for me] one of the best recent Bollywood films.

I think the most interesting aspect is the way how they display the transformation process of an initially extremely alienated NRI (officially "Non Resident Indian", in the movie jokingly referred-to as "Non Returning Indian") back ti a "true Indian".

Motorola launching opensource.motorola.com

Motorola seems to be making some progress internally. Today they've announced the availability of opensource.motorola.com, a web site dedicated to free and open source software used and developed in/by Motorola. This is apparently also the portal where they are starting to publicize the source code for their Linux based Smartphones.

While the source code there is not complete in any way [yet], it actually includes the kernel sources for the A1200 phone, too. After a quick read through it, it seems to be very similar to the A780 code (because of a very similar hardware architecture).

Some of the differences are:

• FOTA (Flash on-the-air)
Basically a function by which network operators can modify the flash memory of your phone, thereby forcing software updates onto you. Not something completely new in the GSM world, but something that always gives me the creeps as a security professional.
• Power Management
Apparently the power management capabilities were extended to provide better battery life time.
• Minor differences in boot loader / kernel handover
• SE Linux
Yes, they're actually using SE Linux features on a phone. I haven't yet tried to figure out for what, but usually you would assume that the mobile phone vendors/operators use it to lock their users out of the phone, rather than protecting the users from the evil outside world.

A full day of EZX driver development

Today wasn't exactly the most efficient day of development I ever had. Basically, the amount of progress made after 13 hours of hacking in the area of EZX device drivers is extremely slow. It didn't even help to not eat, not cook, and not get out of the bed for the whole day. Basically I started with "let's fix this quickly before breakfast", but it wasn't fixed even when I stopped working at 11pm.

My new SPI driver seems to be working fine, but I have massive problems with all the PCAP drivers. This is mainly touch-screen, but also ADC for reading battery voltage, etc. Somehow I cannot get it to produce any IRQ's.

Debian sarge root filesystem image for EZX phones

In order to get other developers going quickly, I have now provided a Debian sarge (arm) root filesystem and a corresponding kernel plus instructions.

Anyone who wants to see a stock Debian installation boot on his EZX phone, have a look at the files published here.

OpenEZX virtual host running

I've finally found the time to configure the OpenEZX virtual host. This means that I now have absolutely no problems to hand out developer accounts on openezx.org. I've also moved the EZX related subversion repository from gnumonks.org to this machine.

If you're working on free software for Motorola EZX smartphones, and are interested in getting some account where you can host your project(s) in svn / git, dump some code on http/ftp or just want a openezx.org email address, please let me know.

Working on Bluetooth and GPRS/GSM support

I've been working a bit on getting Bluetooth and GPRS/GSM support into my 2.6.x based kernel for the A780. Both are quite a bit challenging, even more than I initially thought so.

As for Bluetooth: In theory there is a bcm2035 chip, compatible to the Bluetooth HCI specification, attached to ttyS1 (BTUART) of the PXA270. However, there are some power management related additional signals hooked up to GPIO signals. I think I'm configuring them right, though. Also, there is some indication that the bcm2035 actually requires a bit of firmware loaded into it. Without a vendor data sheet and with only some stripped proprietary Motorola dload program this will require quite a bit more of investigation.

My initial 'demand' for Bluetooth would have been the possibility to use my Apple BT keyboard with the framebuffer console, providing a local console in case telnet dies for some reason.

On the GSM/GPRS front (yes, we actually want to use the phone as a phone sometimes), I've been wading through disassembled gprsv.o and mux_cli.o code. Both re-implementations are progressing slowly, but steadily.

The easier part seems to be mux_cli.o. I've now started to write some libusb based userspace code to test a ts07.10 implementation in userspace via the USB endpoints to the BP. Once the userspace code seems to be working, I can work on a kernel level implementation. The good thing about this is that there are actually quite a few GSM phones that support this multiplex on their serial port. So the resulting mux/demux driver will actually be useful for more people, not just Motorola Linux smartphone owners.

Developing a 2.4GHz active RFID system

Together with Milosch from bitmanufaktur.de, I've spent a couple of days and nights working on building our own 2.4GHz active RFID system. The parameters are: Battery powered, small transponders based on the Nordic Semiconductor nRF24L01 and a ultra-low-power PIC micro-controller. Base-stations have the same nRF chip, plus an Ethernet-enabled micro-controller. Operational range is ~10 meters, we even made it through two walls in our preliminary tests.

So what's the point of all this? The goal is to have that system in operation at the HOPE Nr.6, and to give a practical demonstration on how feasible it is to track people, make protocols on who has spent how much time in which lecture hall, etc.

I'm not involved with HOPE at all, but was only involved in writing firmware and higher-level code for the two embedded systems involved, as well as some testing.

I'm looking forward to learn how the system will perform with several hundreds/thousands of transponders at its first real-world test at HOPE. With some luck, we can have the same system at 23C3 in December this year in Berlin.

Until then I'm certainly going to try to implement my idea for peer-to-peer time slot synchronization of the transponders. I had that idea as a solution to avoid collisions between transponders while working on the project. Unfortunately, the current transponder hardware doesn't have a low-power timing source that is precise enough for such a protocol. Adding a 32.768kHz low-power quartz should do the trick - but will inevitably also make the transponder more costly.

Kudos to bitmanufaktur. I wouldn't even dare to try to design a PCB for 2.4GHz RF...

Back from Brazil

Yes, I survived. Now I need to address that backlog of real world issues and emails...