LaForge's home page (Posts about mobile)

Osmocom Berlin meetings

Harald Welte — Sat, 07 Nov 2015 16:00:00 GMT

Back in 2012, I started the idea of having a regular, bi-weekly meeting of people interested in mobile communications technology, not only strictly related to the Osmocom projects and software. This was initially called the Osmocom User Group Berlin. The meetings were held twice per month in the rooms of the Chaos Computer Club Berlin.

There are plenty of people that were or still are involved with Osmocom one way or another in Berlin. Think of zecke, alphaone, 2b-as, kevin, nion, max, prom, dexter, myself - just to name a few.

Over the years, I got "too busy" and was no longer able to attend regularly. Some people kept it alive (thanks to dexter!), but eventually they were discontinued in 2013.

Starting in October 2015, I started a revival of the meetings, two have been held already, the third is coming up next week on November 11.

I'm happy that I had the idea of re-starting the meeting. It's good to meet old friends and new people alike. Both times there actually were some new faces around, most of which even had a classic professional telecom background.

In order to emphasize the focus is strictly not on Osmocom alone ( particularly not about its users only), I decided to rename the event to the Osmocom Meeting Berlin.

If you're in Berlin and are interested in mobile communications technology on the protocol and radio side of things, feel free to join us next Wednesday.

Progress on the Linux kernel GTP code

Harald Welte — Sat, 07 Nov 2015 16:00:00 GMT

It is always sad if you start to develop some project and then never get around finishing it, as there are too many things to take care in parallel. But then, days only have 24 hours...

Back in 2012 I started to write some generic Linux kernel GTP tunneling code. GTP is the GPRS Tunneling Protocol, a protocol between core network elements in GPRS networks, later extended to be used in UMTS and even LTE networks.

GTP is split in a control plane for management and the user plane carrying the actual user IP traffic of a mobile subscriber. So if you're reading this blog via a cellular interent connection, your data is carried in GTP-U within the cellular core network.

To me as a former Linux kernel networking developer, the user plane of GTP (GTP-U) had always belonged into kernel space. It is a tunneling protocol not too different from many other tunneling protocols that already exist (GRE, IPIP, L2TP, PPP, ...) and for the user plane, all it does is basically add a header in one direction and remove the header in the other direction. User data, particularly in networks with many subscribers and/or high bandwidth use.

Also, unlike many other telecom / cellular protocols, GTP is an IP-only protocol with no E1, Frame Relay or ATM legacy. It also has nothing to do with SS7, nor does it use ASN.1 syntax and/or some exotic encoding rules. In summary, it is nothing like any other GSM/3GPP protocol, and looks much more of what you're used from the IETF/Internet world.

Unfortunately I didn't get very far with my code back in 2012, but luckily Pablo Neira (one of my colleagues from netfilter/iptables days) picked it up and brought it along. However, for some time it has been stalled until recently it was thankfully picked up by Andreas Schultz and now receives some attention and discussion, with the clear intention to finish + submit it for mainline inclusion.

The code is now kept in a git repository at http://git.osmocom.org/osmo-gtp-kernel/

Thanks to Pablo and Andreas for picking this up, let's hope this is the last coding sprint before it goes mainline and gets actually used in production.

What I've been busy with

Harald Welte — Tue, 27 Oct 2015 16:00:00 GMT

Those who don't know me personally and/or stay in touch more closely might be wondering what on earth happened to Harald in the last >= 1 year?

The answer would be long, but I can summarize it to I disappeared into sysmocom. You know, the company that Holger and I founded four years ago, in order to commercially support OpenBSC and related projects, and to build products around it.

In recent years, the team has been growing to the point where in 2015 we had suddenly 9 employees and a handful of freelancers working for us.

But then, that's still a small company, and based on the projects we're involved, that team has to cover a variety of topics (next to the actual GSM/GPRS related work), including

mechanical engineering (enclosure design)
all types of electrical engineering
- AC/electrical wiring/fusing on DIN rails
- AC/DC and isolated DC/DC power supplies (based on modules)
- digital design
- analog design
- RF design
prototype manufacturing and testing
software development
- bare-iron bootloader/os/application on Cortex-M0
- NuttX on Cortex-M3
- OpenAT applications on Sierra Wireless
- custom flavors of Linux on several different ARM architectures (TI DaVinci, TI Sitara)
- drivers for various peripherals including Ethernet Switches, PoE PSE controller
- lots of system-level software for management, maintenance, control

I've been involved in literally all of those topics, with most of my time spent on the electronics side than on the software side. And if software, the more on the bootloader/RTOS side, than on applications.

So what did we actually build? It's unfortunately still not possible to disclose fully at this point, but it was all related to marine communications technology. GSM being one part of it, but only one of many in the overall picture.

Given the quite challenging breadth/width of the tasks at hand and problem to solve, I'm actually surprised how much we could achieve with such a small team in a limited amount of time. But then, there's virtually no time left, which meant no gpl-violations.org work, no blogging, no progress on the various Osmocom Erlang projects for core network protocols, and last but not least no Taiwan holidays this year.

ately I see light at the end of the tunnel, and there is again a bit ore time to get back to old habits, and thus I

resurrected this blog from the dead
resurrected various project homepages that have disappeared
started some more work on actual telecom stuff (osmo-iuh, for example)
restarted the Osmocom Berlin Meeting

HTC announcement about no more locked-down phones

Harald Welte — Sun, 29 May 2011 19:00:00 GMT

As it has been covered at various news site, HTC has apparently announced that they will not be shipping Android phones with locked-down bootloaders.

If this is really true, it would mean that more people not only have the theoretical freedom to run modified versions of Linux (granted by GPLv2), but also the practical freedom. If there is no cryptographic restriction on only booting HTC-supplied versions of the Linux kernel (and other software), this is good news!

It comes as a bit of surprise though. "Traditionally", HTC is known for behaving unfriendly towards the community. Not only due to their source code releases being constantly too late, but also due to the fact that their phones were some of the first to use cryptographic signatures to keep people from installing their own versions of Linux (and Android).

The other surprising move has come from Motorola, who probably has the longest tradition of shipping Linux-based phones (in various degrees of GPL compliance), but then using technical means to deprive their customers of the Freedoms the GPL wants to grant to them, i.e. the freedom to run modified versions of the Software (Linux in this case). They did this with the later models of the EZX range, with their MAGX phones, as well as now with their Android phones over the last couple of years. So it was very puzzling to see the same Motorola announce a 180 degree turn in policy at least for their Xoom tablet.

Also, in recent news, Sony Ericsson made a similar announcement that at least some of their Xperia models can be bootloader unlocked.

It's really striking. During the least seven years, I used to be involved in a number of projects that tried to enable the user of mobile smartphones to have the full source code for (at least) the Linux kernel, and to be able to modify, tinker and re-program it any way they want. Now some of the vendors seem to be moving in the right direction.

What's sad is that Samsung is not capitalizing on their potential here. They have always had very timely and complete source code releases for all their Linux based phones at http://opensource.samsung.com/, and they have very rarely tried to lock any of the bootloaders. I don't know if this is intentional or not. But now the other vendors are getting good PR for stopping to do something that (to my knowledge) Samsung has not done, at least not to the extent of the others.

In any case, I still think the Nexus S is the best choice for anyone who wants to have a developer friendly device. It is fully supported in the main AOSP tree, everything in the kernel is GPLv2, and those binary userspace blobs that are required are distributed independently at https://code.google.com/android/nexus/drivers.html so they can be integrated into custom builds. This is by no means perfect, but the best compromise that seems available at this point. I still don't understand why the userspace drivers for the GSM/3G modem, Wifi, Bluetooth and GPS would need to be proprietary. Or even the NFC par, it's sort-of ridiculous to have that proprietary with Free Software RFID stacks like libnfc and librfid around...

ST-Ericsson releases (and submits) Android GStreamer code

Harald Welte — Tue, 07 Dec 2010 19:00:00 GMT

Back in October I blogged about ST Ericsson hooking gstreamer into Android but apparently making that code proprietary. I may have been a bit opinionated at the time. The reasons for not disclosing the code allegedly were that it is assumed to be of no general use. However, it still felt very bad that two Free Software projects are interacting with each other through a proprietary layer.

I've since had a very pleasant contact with the Head of MeeGo Business Development at ST-Ericsson and they have now released and submitted the respective code-bases, like the gst-android git repository and the Audioflinger sink in the gst-plugins-bad repository as well as Android makefiles for all parts of gstreamer.

It is great to see this kind of development, and see that ST-Ericsson is trying hard to do the right thing: Not only releasing their extensions of gstreamer under a GPL-compatible license to their customers, but even actively pushing those changes upstream. Thanks to everyone involved, particularly Andrea Gallo and Benjamin Gaignard.

Motorola announces "Ming" phone with Android

Harald Welte — Wed, 01 Sep 2010 19:00:00 GMT

For those who don't know: The Motorola Ming was the A1200, a commercially very successful Linux-based phone in China and other parts of Asia, using the EZX software platform, i.e. the kind of hardware that we once built the OpenEZX software.

Motorola has recently announced that they will follow-up with some android based ming phones. It is my suspicion that apart from some mechanical design aspects, those phones will not resemble the ming in any way, neither on the baseband hardware side, nor on the application processor side, and particularly not on the software side.

So it's probably nothing than a marketing coup, trying to connect to successes of the past. Not interesting from the OpenEZX point of view, I guess.

Convert RSS feed subscriptions from N810 feed reader to Android com.meecal.feedreader

Harald Welte — Tue, 24 Aug 2010 19:00:00 GMT

I'm subscribed to a considerable number of RSS feeds, and so far I actually used to read them all on my Nokia N810, which is more or less permanently located at the bedside table

Now I wanted to import all the subscriptions into an Android RSS feed reader on the Galaxy S. Unfortunately the feed reader that I found most useable doesn't have OPML import. However, looking at its sqlite3 database for feed subscriptions, it was pretty easy to come up with a small perl script to generate "INSERT" statements for all the feeds from the N810 OPML file. In case anyone is interested, the script is available from here.

If you have any suggestions on a good Android RSS reader that can manage large number of subscriptions and put them into a tree/hierarchy of groups, feel free to let me know.

Started to play with the Galaxy S (GT-I9000) phone

Harald Welte — Fri, 20 Aug 2010 19:00:00 GMT

For many years I'm on a more or less consistent hunt for finding a reasonably open and free mobile phone. This started in 2004 with OpenEZX, has continued with Openmoko, project gnufiish and has resulted in a bit of peeking and poking in the Palm Pre. However, none of those projects ever had the success I was hoping for:

OpenEZX was never really finished, and only for the 1st generation phones (A780) by the time they were long end of life
OpenMoko Neo1973 and FreeRunner were a great project, and they are still the most open+free mobile phones that ever existed. However, they're GPRS only and the hardware is even more outdated now then it was when we created it.
gnufiish was an attempt of running software from the Openmoko days (such as freesmartphone.org) on some E-TEN glofiish phones. However, we never could make the SPI-based modem communication work from our re-engineered Linux driver :(
Palm Pre is an interesting device, in that Palm provides easy root access, does not attempt to lock the device down with cryptographic signatures and provides full recovery flashing tools by means of WebOS Doctor. But once again, the proprietary communication protocol with the 3G Modem was the big blocker item for using real custom software and not the WebOS stuff they ship.

So I've constantly been on the watch for new devices that are coming out. Most of the phones you can buy in recent years are either running proprietary software like Windows Mobile, Symbian, Apples iPhone-OSX - or they run Android but then use some integrated Qualcomm Smartphone-on-a-chip product. The problem with the latter (from a Free Software point of view) is that Qualcomm is very secretive about their products, does not provide any kind of public documentation, and the ever-increasing integration between application processor and baseband processor makes it more difficult to run custom software on them.

The Samsung Galaxy S (GT-I9000) seemed like a good candidate to me, for several reasons:

Samsung does not use cryptographic signature techniques and gaining root as well as flashing the AP software is relatively easy
The phone is based on a traditional separate application processor (AP) and baseband processor (BP) design. The AP is a Samsung S5PC110, the BP is some Qualcomm MSM6xxx.
High-end hardware, with the S5PC110 running at 1GHz and 512MB RAM
Samsung provides excellent "GPL source code offers" containing the Linux kernel used in their firmware - including detailed instructions in how to build it. Also, many of the drivers are included under GPL, such as drivers for all the integrated peripherals of the SoC, some custom components like the USB multiplexor ASIC, etc. as well as the driver for the dual-ported RAM between the AP and BP for the 3G Modem communication
The Android RIL shipped by Samsung contains lots of debugging/decoding/dumping code that can make reverse engineering the AP/BP protocol.

So right now I'm in the exploration phase, making myself familiar with the bootloader, the flashing process, the userspace ABI of the custom (GPL licensed) kernel drivers, etc. It's a fairly pleasant experience so far, and I now have a debootstrap'ed Debian lenny on an additional ext2 partition on the SD card. This provides me with an actually useful userland I can chroot() into, such as lsof, strace, ltrace, tcpdump, etc. to do some more exploration of the phone.

The only real ugliness on the software side so far is the use of proprietary Samsung filesystems (RFS/TFS4). The only reason those filesystems existed, as far as I can tell, was to run legacy filesystems like FAT on top of raw NAND or OneNAND flash. This is mainly necessary if you want to export e.g. a FAT partition via USB Mass Storage to a Windows PC. However, the GT-I9000 doesn't have any OneNAND, but only an internal moviNAND (basically a SD-Card in a BGA package that you can solder on the board). MMC/SD cards already include the wear leveling algorithm, so there is absolutely no point (from what I can tell) in running the RFS/TFS4 stack.

In fact, in several forums people are complaining about the slow I/O performance of the Galaxy S, and they have a much better performance when using ext2/ext3 directly on that moviNAND device.

More musings on locked-down mobile phones

Harald Welte — Fri, 16 Jul 2010 19:00:00 GMT

In recent days, the story about Motorola locking out its users (and developers) from their more recent Droid phones has made big news. As it seems, the exact functionality implemented by eFuses remains unclear, and the behavior of Motorola might thus not be too different from what has more or less become the industry standard.

For those of you who are not following the mobile world as close on a technical level as people like me do: In the last five years, more and more cellphone manufacturers have used cryptographic code signing to lock-down the software that you can run on the phone. Major parts of the system including the software update mechanism and the bootloader on the device contain a verification process of those cryptographic signatures to ensure that you can only software signed by the phone manufacturer.

I have seen this with the MotoMAGX phones like the ROKR2 v8, various Windows Mobile handhelds from HTC, The non-developer (non-ADP) version of the Google/Android G1 and many other phones.

This puts the user into a strange situation where he buys some hardware from the manufacturer, but yet doesn't have control over what this device does. Just imagine buying a computer, but being limited to run Windows 98 and Office 97 on it. You could not update to a later version of the operating system, and you could not install an alternative operating system such as a version of GNU/Linux. If the computer vendor decides that he will drop support for it, you will not even be able to install security updates to the operating system.

From my point of view, this is an abusive, anti-competitive behavior by the manufacturer. For no reason but his ever-growing hunger for power he makes you completely dependent on his decision. It is not in the control of the user, what operating system or even applications you can install. It is under the control of the manufacturer.

I would accept this if the phone was rented. In this case, I would only pay a small rental fee, but the phone is the property of the manufacturer and I am only using it. But the manufacturer actually sells the device. He wants to be paid the full price, but still not actually hand control over to the buyer.

Compare this with buying a CD-player that has arbitrary restrictions so it would only play CDs from one of the major music labels/distributors like EMI, but not CDs from any of the other publishers, for no technical reason whatsoever. Or buying a TV set that is locked down so you can only watch one TV channel, while you need to buy another TV for a different channel.

I actually think the antitrust authorities should investigate this behavior of the mobile phone industry. Simply compare it with the PC situation and look at the fact how often Microsoft has been judged in some kind of anti-competitive behavior in the PC world. In the mobile phone industry, the situation is worse than it ever was in the PC world, yet we do not see big antitrust cases being brought forward.

And please don't buy those pseudo-arguments that this has any relation to regulatory/FCC approval or the safety of mobile networks themselves. The entire software stack interacting with the mobile network runs on a separate processor (the baseband processor) anyway. It doesn't matter what you install on the application processor. Once again, compare it to laptops: You can insert a 3G miniPCI, expressCard or USB dongle. Inside this dongle you run the communications stack on a processor that is completely different from your main processor that runs your regular OS (be it GNU/Linux, OS X, Windows, Solaris or whatever makes you happy).

Motorola locking down the DroidX and Droid2 in a nasty way

Harald Welte — Thu, 15 Jul 2010 19:00:00 GMT

There are plenty of reports in recent days about the level of locking-down that Motorola is apparently doing on their most recent Android products, the Droid 2 and the Droid X.

This goes as far as to an (I believe unconfirmed) slashdot.org report claiming that not only there is the more or less typical DRM on software (i.e. cryptographic signature validation chain), but there also is an eFuse that that is blown if something happens wrong during the booting process.

To the best of my knowledge (and I'm doing mobile phone reverse engineering for about 6 years now), this is the first time I hear of something like this. If true, it sounds pretty dangerous to me. What if something goes wrong during an update (such as a power failure during software update)? What if you really have a non-correctable multi-bit error in your NAND Flash? In that case, cryptographic verification of the firmware fails and the eFuse would be blown, resulting in your device being a brick. This could eventually backfire massively to Motorola.

The best comment from the slashdot.org thread:
You can legally buy a gun that only shoots in the direction of the person pulling the trigger, but it doesn't mean it's a good idea.

Reading something like this almost makes me very depressed. Motorola is benefitting from the billions-of-dollar-worth development of existing Free Software projects like the Linux kernel, but they now want to take away the fundamental right to run modified versions of that very software. Somebody needs to slap them with a very large trout.

I'm not really surprised that they are doing it, though. Motorola has shown that direction even years ago when they first used SELinux as part of their later pre-Android Linux phones (EZX and MAGX). They didn't use it to enhance the security of the user, but to enhance the security _from_ the user.

Please also note this great post by Bradley M. Kuhn on the subject matter. If you don't know Bradley, he's been doing GPL enforcement for the last 12 years - for the Free Software Foundation and the Software Freedom Law Center. In his post, he actually thanks Motorola to publicly state that they actually want to lock their phones down (as opposed to Apple).

What's even more interesting though is his elaboration on the scripts to control compilation and installation clause of GPLv2. This is indeed something that most people tend to overlook when it comes to GPL[v2] compliance and we see this a lot during our gpl-violations.org work.

And in fact, for a very long time, I have been teaching and educating this fact during my GPL related talks and trainings: In software specific for embedded devices, the scripts to control installation are incomplete, if you do not provide a means to install the software onto the actual device. Where else would you be reasonably install the Linux kernel image that is made specifically to work on such a particular mobile phone model? Due to the custom nature of Linux kernels for embedded targets, it wouldn't even run anywhere else.

I've never taken any such issue to court so far - but it was a frequent dispute in out-of-court GPL enforcement we've been doing at gpl-violations.org. I'm definitely curious to see what will be the first court case addressing that issue. The ever power-hungry manufacturers of mobile phones seem like they deserve it.

UPDATE:
Apparently Motorola has released some statement that denies they use eFuses to brick the device. All it does is to render the device unable to boot until some Motorola-certified/signed/authorized software is loaded on the device again. They did not specify how that could be done, though. Still, even without the eFuse bricking, I find it outrageous that the Industry (including Motorola) expect their customers pay hundreds of dollars for a device that is then still owned by Motorola rather than that very customer. It's like selling something but still retaining ownership of it. Doesn't that make you feel strange, too?

The mid-term future of WebOS seems safe

Harald Welte — Wed, 28 Apr 2010 19:00:00 GMT

After HP announced its acquisition of Palm, I think we can be sure that the mid-time future of WebOS seems quite safe. I also expect mechanically much better hardware among the devices they will ship.

However, the acquisition could also mean a shift in politics, i.e. cause the new devices to be locked down with cryptographically signed kernel images. One of the big advantages of the existing Pre and Pixi is that they are not locked down and that as a user you can take full control over the device.

Another policy that might come under re-evaluation is the relationship between the WebOS Application Market and the third-party application installers like Preware.

Lets hope the managers responsible for WebOS future realize that their chance is to be less restrictive and more open than most of the competition - including most Android devices. At least, one could hope, HP has quite some experience with Linux and the Open Source community in other areas of their business.

Palm's failure with the App Catalog / Preware to the rescue

Harald Welte — Thu, 03 Dec 2009 19:00:00 GMT

Especially since the 1.3.1 WebOS release, you can easily see the lack of success of the official Palm App Catalog: Only about 60 Applications are available to me from there. Why is that? Because the default setting in the app catalog for any developer uploading the application is "US Only", i.e. people who bought their Pre in other countries like Germany will not see the majority of applications. That's really weird considering how much effort Palm is spending in trying to convince people to write applications for WebOS to increase the attractivity of their product. Now they artificially reduce that for everyone outside the US.

So that's even one more reason to use the alternative package installer called Preware which is available from webos-internals.org. This alternative installer supports any number of feeds. It removes the single-point of failure that an official Palm App catalog creates, and replaces it with a proper community-driven approach. Anyone can write and publish applications, anyone can distribute them to the users, just like anyone is able to distribute/install MacOS, Windows or Linux applications on the PC!

Android Mythbusters (Matt Porter)

Harald Welte — Tue, 03 Nov 2009 19:00:00 GMT

Some weeks ago I was attending Embedded Linux Conference Europe. My personal highlight at this event was the excellent Android Mythbusters presentation given by Matt Porter.

As you may know, Matt Porter was heavily involved in the MIPS and PPC ports of Android, so he and his team have seen the lowest levels of Android, more and deeper than even cellphone manufacturers ever have to look into it.

The slides of his presentation are now available for download. I would personally recommend this as mandatory reading material for everyone who has some interest in Android.

The presentation explains in detail why Android is not what most people refer to when they say Linux. What most people mean when they say Linux is the GNU/Linux system with it's standard userspace tools, not only the kernel.

The presentation shows how Google has simply thrown 5-10 years of Linux userspace evolution into the trashcan and re-implemented it partially for no reason. Things like hard-coded device lists/permissions in object code rather than config files, the lack of support for hot-plugging devices (udev), the lack of kernel headers. A libc that throws away System V IPC that every unix/Linux software developer takes for granted. The lack of complete POSIX threads. I could continue this list, but hey, you should read those slides. now!

Just one more practical example: You cannot even plug a USB drive to an android system, since /dev/sd* is not an expected device name in their hardcoded hotplug management.

Executive summary: Android is a screwed, hard-coded, non-portable abomination.

I can't wait until somebody rips it apart and replaces the system layer with a standard GNU/Linux distribution with Dalvik and some Android API simulation layer on top. To me, that seems the only way to thoroughly fix the problem...

Palm Pre: Nice UI, severe lack of functionality

Harald Welte — Sun, 25 Oct 2009 19:00:00 GMT

Using the Palm Pre: Everything but an exciting experience :(

During the last week I've started to use my new Palm Pre (for those of you who're living under a rock: The Palm Pre is a smartphone powered by an Operating System called WebOS, which is in turn powered by the Linux kernel and lots of other "standard" Linux programs like glibc, alsa, udev, ...

This adherence to a more standard Linux userland makes the Pre much more attractive than the Android based products out there. Android is reinventing the wheel everywhere, and things that Linux users and developers have been taking for granted during the last five to ten years simply don't exist on Android.

To be honest, the experience was everything but exciting. More about that later. Lets' start with the positive side of things. Yes, I like the device for the following facts:

it's using a not-too-ancient Linux kernel
it uses a fairly standard Linux userland, that
the development tools are also running on Linux (albeit proprietary)
there is an easy way to access the command line of the device via USB
there is software for re-flashing the phone in case it is bricked
the WebOS "distribution" is built using OE and uses the ipk packet format
they did not try to lock the device down from their users. You can easily be root on your phone, install additional ipks from third parties and own your phone

Which is what got me excited and made me buy one of those expensive devices.

However, looking at it from a strict user point of view, I am not very happy with it. It simply lacks so much in functionality that it is not even funny.

No RSS reader

The Nokia web tablets had a working, built-in RSS reader even many years ago when the n770 was released. Given the importance of RSS feeds and blogs in todays web, I'm surprised that webOS does not ship with a RSS reader. To make it even worse, I could not find any third-party RSS reader for it!

No Jabber / ICQ / AIM support

The messenger supports only SMS and Google Talk. WTF?!? What about the millions of Jabber, ICQ, YIM, MSN and other users? Don't you think they want to use their default messenger application with those accounts? This is particularly funny, since they're using libpurple for the actual messenger protocols, which is a LGPL'd library of the pidgin chat client. So the library has all those capabilities, but Palm decided to arbitrarily remove them in their LibpurpleAdapter program. Luckily that one is LGPL'd too, so removing the restriction is relatively easy. But not for a regular user!

Some applications always want to use the cellular network, even when wifi is available

This is particularly stupid when using their e-mail client. While I'm at home or in some other area with wifi coverage, I don't want to squeeze every bit through a high-latency cellular network. Why not simply make that decision a per-application property that the user can set?

Cheap mechanical quality

The mechanical quality is really disappointing for a device that sells for EUR 481. It's much lower than what one is used to from Nokia, Blackberry or HTC devices in a similar price range. As one example, the entire plastic of the device squeaks every time I carefully push one of the keys on the keyboard.

E-Mail client does not support pre-downloaded messages in subscribed IMAP folders

A standard feature that every desktop e-mail program has: Pre-download and cache the message headers for fast listing / browsing through a mailbox. Not on the Palm Pre, where the interactivity of the mail program is close to zero, fetching every bit over a high-latency link. The entire point of using IMAP is to have local copies/caches and to not suffer the latency/interactivity penalty of e.g. webmail!

Calendar offers no integration with standard calendar formats/servers

There is no way how you can simply feed data from ical or xcal calender data into the Palm Pre calendar. You can synchronize with Google and Exchange. WTF? Why do we have [more or less] standard file formats for calendar data? Exactly for enabling interoperability.

No support for standards-compliant address books

You can import your contacts from Facebook, but you cannot import contacts from vcard files, or let's say from a LDAP based address book. Great. So I first need to disclose all the personal contact details from all my contacts, put those into Facebook (into the US jurisdiction and a company that I don't trust) to simply get my contacts on the phone ?!?

Too low battery life

I can barely make it through one day even without making phone calls, simply having the e-mail client running. The battery is too small. I would not mind a bigger/heavier device in exchange for more power!

That is simply the user point of view. I also have many more technical points from a developer perspective, but that is probably better kept for another post. Meanwhile I'm not sure if the Pre was all that much of a good idea. The N900 is coming up next, and will be much closer to the standard Linux userland stack (including X11, GTK, Qt, ...) than the Palm Pre is.

Qualcomm launches Open Source subsidiary

Harald Welte — Sun, 25 Oct 2009 19:00:00 GMT

As several news sites have been reporting (here a report from LinuxDevices.com), Qualcomm has announced the launch of an Open Source Subsidiary.

As usual, I very much welcome such a move. Qualcomm is one of those companies who have a very bad reputation in the Open Source and particularly Linux community. They have so far failed to provide user manuals or other reference documentation for any of their parts. They haven't even managed to publish reference documentation on the external interfaces such as the AT command dialect or the binary shared memory protocols that are used to interface the GSM/CDMA/WCDMA baseband in their product.

So when it comes to an Open Source project that wants to interoperate with Qualcomms hardware, they have so far been doing everything to make that as hard as possible. Neither the community as large has access to the information that it needs, nor do the Qualcomm customers get the respective document under a license that allows them to actually contribute to Open Source projects.

If that documentation was available, or if Qualcomm was actually working on FOSS licensed drivers and contributing those mainline, the support for Qualcomm's hardware in Linux would be much better - resulting in less time to market for companies interested in using Qualcomms parts in their products.

The actual press release does not indicate that this newly-founded subsidiary truly understands this. It speaks of hardware-optimizing the performance of mobile operating systems. That sounds like "we'll take the existing code, make a fork, do non-portable micro-optimizations and ship that to our customers". It does not mention actually contributing to the community or understanding the benefit that the Open Source development model.

I remain to be convinced. Let's hope Qualcomm has scored somebody with a lot of actual hands-on Open Source community experience to advise them properly.

Symbian kernel Open Source release and Tanenbaum

Harald Welte — Sat, 24 Oct 2009 19:00:00 GMT

As most people have noticed by now, The Symbian Foundation has released the source code of their microcernel under an open source license. While any open source release of formerly proprietary software is something I warmly welcome, I doubt that it will take of as an actual open source project.

There's a difference between releasing software under a FOSS license and running a successful FOSS project. The latter involves a sufficiently large community of developers, ways how they can contribute, ...

Especially with special purpose code such as an operating system (kernel) for mobile devices, very few people will show interest as long as there is no actual hardware where they can run the software, without or with custom modifications. Sure, there will be academic interest and people who will look at the source code to find ways to exploit potentially existing security weaknesses, but no community of people who work on it since they will practically use it on their own device.

So what I'd do if I was the Symbian Foundation: I would release an actual mobile phone which is open enough for people to run (modified or unmodified) recompiled parts of the Symbian codebase which are now available as open source. This way it will be much more appealing. However, even at that point, many other parts of the system are (or even will forever be?) closed, limiting the amount of impact. Furthermore, since modified versions cannot be installed on any other regular non-developer phones, the impact of any contribution to the codebase can not be to the benefit of many people. Just compare that with contributing to the mainline Linux kernel, where a contribution will be used on at least almost every server/workstation/laptop after the next distribution (and thus kernel) update.

Another issue that I really was shocked is the following quote by Andrew S. Tanenbaum: 'I would like to congratulate Symbian for not only making the source code of its kernel open source, but also the compiler and simulation environment,' said Andrew S. Tanenbaum'

However, the compiler was not made open source. It is released as proprietary binary code, and is only "free as in beer" for organizations up to 20 employees. So either Tanenbaum did not really look at the hard facts of what was being released, or he was misquoted in a really bad way! That should not have made it into the final release, as it's now a damaging statement for both the Symbian Foundation and Mr. Tanenbaum.

By the way, according to a lwn.net comment thread, they're working on making it able to compile under gcc, and they're actually accepting patches, which is of course great.

Despite my negative comments: I wish them as much luck and success as possible with their new open source Symbian kernel. I personally just am not seeing it turning into a vibrant, community-maintained project - and I hope the founders of the Symbian Foundation did not start the project based on that assumption and will in the end perceive it as a negative experience when evaluating the open source move some years down the road.

One final note: The fact that they chose the EPL as license is really strange, as it prevents exchange of code with the major existing FOSS kernel projects (Linux, *BSD). Not that I think there is much to be exchanged, given the microkernel approach...

Palm Pre privacy invasion

Harald Welte — Tue, 13 Oct 2009 19:00:00 GMT

One great example of why we need more open source based mobile phones is that we can actually discover all the undocumented "features" of the devices that we use every day.

If I use a device for personal things like my private communication, my scheduling, contact information and similar, then I have to put a certain amount of trust into that device. I trust that the vendor selling this device will provide a device that is safe for me to use and where my information is stored securely.

However, the amount of closedness and control that equipment vendors and GSM operators traditionally have in the mobile world is a big conflict with my personal interest for privacy and security.

You can see this reflected by SIM Toolkit specifications that allow the operator to read and modify your phonebook, or with flash over the air where the operator is able to modify the software on your device.

In fact, in such cases the operators treat the device like they own the device, when in fact the customer has bought the device and owns it.

Since Palm's WebOS is [to a large extend] based on Free / Open Source software, we can analyze in more detail what they are doing. As it was pointed out in this blog post two months ago, they seem to regularly receive information when you were using which application, as well as the GPS coordinates of the phone!

This is outrageous, especially without any way for the user to switch it off - or even better: Have an opt-in, i.e. off by default but who wants it can enable it.

Palm has responded to it, but as that very same posting indicates: The Palm Privacy Policy is not even completely listing the information for which it is applicable.

I don't think Palm is particularly worse than other companies. But the question is: How do we know? How does the user know what his phone wants to communicate to the operator or the manufacturer without his knowledge or authorization? The only two ways I can imagine are:

by having more open source software on the phone, so users can study the code, determine what it is doing and then modify the software to remove such privacy invading surveillance features
by having more people with their own GSM/GPRS networks with projects like OpenBSC, where we can actually see from the network side what the phone is trying to do. Unfortunately GPRS support is still not finished in OpenBSC, but work is ongoing.

Since the Palm Pre units so far (CDMA and GSM) are not locked down, i.e. you can become root and modify the software, it will be much easier to have "custom ROMs" (where the name ROM is stupid since it is flash, ...)

I can only hope that people will quickly come up with custom Linux based firmware images for the Palm excluding the surveillance features.

In addition, everyone should write a letter to Palm, complaining about those features and the fact there is no way to opt out of them.

The txtr e-book reader hardware architecture released

Harald Welte — Tue, 13 Oct 2009 19:00:00 GMT

Today, the Berlin-baased start-up txtr has released more technical details on their first e-book reader.

They have also released their developer website including a wiki and access to a svn server with sources as well as fedora11 based source and binary RPM's.

What's also interesting is that they have disclosed a hardware block diagram and a PCB footprint on their developer website before the product even starts shipping to the mass market.

As few of you will know, some my friends and colleagues are behind the system-level software and hardware R&D. The electrical engineering is done by Milosch and Brita of bitmanufaktur, with whom I've had the pleasure to work on OpenOCD, OpenPICC, OpenBeacon as well as for a dedicated assignment inside Openmoko. Andy Green of Openmoko kernel + bootloader hacking fame has also been involved... last but not least for porting Qi (originally developed for the never manufactured Openmoko GTA03 based on the Samsung S3C6410) to the Freescale i.MX31.

Palm has noticed their mistakes

Harald Welte — Mon, 05 Oct 2009 19:00:00 GMT

As has been described at TechCrunch, Palm has announced to fix their most prominent issues that many bloggers, including myself, palm has realized that they need to fix some issues with the way they are trying to over-control webOs development.

According to the TechCrunch article, Palm will allow people to write and distribute their own applications (though still you need some kind of URL forward from Palm), and there will be no registration or other fees for people who write open source software for webOs.

This is definitely good news. Let's hope the respective changes will be implemented soon.

Palm gives us a demonstration how they have _not_ understood Open Source

Harald Welte — Tue, 29 Sep 2009 19:00:00 GMT

As you can see in this post by Jamie Zawinski, Palm is doing as much as they can to prevent any Free / Open Source application development on their WebOS.

One really has to ask himself whether they have completely lost their mind. This very Free Software and Open Source development model has created the kernel, libc and many other components of their software stack. So Palm can clearly see and experience the benefit this model has to them.

Yet they chose to deprive all third party developers and their users from that very same freedom by

Not providing a way to install applications from third party websites or even physical storage media, thus
forcing all application programmers to use their application store, and
requiring that those application programmers do not disclose the software source or object code on any other website

This is so screwed, I literally want to bang my head on the wall for this level of stupidity. Can somebody please get some sense into Palm? They seem to have not only forgotten what has made their old PalmOS so successful (thousands of 3rd party apps that anyone could write + distribute), but also seem to lack any understanding of Free and Open Source software.

LiMo foundation analysis explains business value to merge changes upstream

Harald Welte — Thu, 17 Sep 2009 19:00:00 GMT

The LiMo foundation has released an economic analysis that (among other things) explains business and economic reasons for 'deforking', i.e. contributing vendor-specific changes back into the upstream projects.

If you don't want to read the full paper, skip to Chapter 4.3 (Page 20) where they say things like: It is important that mobile industry platform providers engage with the open source communities as early as possible so that platform maintenance strategy is fully aligned with the upstream development agenda of these communities, which is far more cost efficient than managing the entire maintenance burden in-house.

Palm Pre wanted for FOSS hackers

Harald Welte — Fri, 19 Jun 2009 19:00:00 GMT

A number of people from the various community-based Linux mobile phone projects (OpenEZX, gnufiish, freesmartphone.org, openmoko, openembedded) are interested in adopting the Palm Pre into the portfolio of supported devices.

If anyone wants to support those communities with Palm Pre hardware, please let me know. Right now, all the people I know are in Europe. Yes, we don't have CDMA hare - but those hackers don't care. All they want is to make sure you can build a number of different distributions on the application processor, and to support everything _but_ the CDMA modem in preparation for the GSM variant that is to be released at some future point.

Palm has released sources for WebOS 1.0.1

Harald Welte — Wed, 17 Jun 2009 19:00:00 GMT

On this page, Palm has started to release source code + patches for a number of FOSS programs that they use in the Pre. I suppose the page is only an interim solution, since the entire site (nor the page URL) doesn't yet really seem to consider the fact of OS updates, etc.

Of course I have no idea yet if those sources can be considered complete and corresponding, but at least an initial look seems quite promising.

I've spent about 10 minutes looking at their 9 MByte (!) kernel patch against vanilla 2.6.24. The modem interface seems to be a UART + USB. The UART is required for stuff like waking up the OMAP3 from the baseband, and then you use it to set up a USB connection to the modem, where a hacked/extended version of the cdc-acm driver appears to be used.

I don't have time to look further into it, but I'm sure somebody with actual device hardware will - now that the source is out there.

Palm Pre supposed to be closer to traditional Linux than Android

Harald Welte — Tue, 09 Jun 2009 19:00:00 GMT

As you can read here, it seems that based on initial analysis the Palm Pre seems to be closer to what mainline Linux is doing that Android. That's not really surprising, but still definitely great to hear.

I can't wait to get my hands on the actual source code. If anyone has seen the written offer as provided by Palm, please forward me the contact information indicated in it so I can request the source code.

If anyone already has their complete corresponding source code (as per GPL), please upload to ftp://ftp.gpl-devices.org/incoming (write-only) and drop me an e-mail.

Openmoko announces Freerunner transitions fully into the hands of the community

Harald Welte — Tue, 02 Jun 2009 19:00:00 GMT

As the CEO of Openmoko Inc. (Sean Moss-Pultz) has announced yesterday, there have been layoffs last week and the further development of the Openmoko FreeRunner (GTA02) will be tunred over to the community.

Openmoko Inc. will continue to provide funding for operating the infrastructure such as wiki/git/mailinglists/etc. Furthermore, the community explicitly has permission to use the Openmoko brand/trademark for their efforts.

I'd like to thank Openmoko Inc. and specifically Sean for all their support over the last years. It makes me happy to see a friendly transition into a pure community-based project.

Intel (and Nokia) announces not-invented-here-syndrome

Harald Welte — Mon, 11 May 2009 19:00:00 GMT

So Intel has co-announced ofono.org. It's clearly a sign that they are preparing themselves for times where we will see x86 SoC based smartphones or other mobile connected devices, which is good.

However, it just looks like a complete not invented here syndrome. It would be great to understand why on earth Intel did not just base on freesmartphone.org (FSO). Even if you don't want to use FSO's [current] implementations, they have spent man-years designing the d-bus based telephony API's and gathering experience with actual use cases as well as a variety of different GSM modems.

Neither on the ophone.org website, nor in their announcement I can see an explanatin of "how this compares to FSO and why FSO doesn't work for us". There might be valid reasons, but they would probably do good at publicizing them. I could also not see them publicly participating at the FSO lists raising those concerns and trying to get a compromise worked out.

So rather than working with an existing community of experts in the Linux telephony field, Intel and Nokia chose to create their own project. Is it desire for control? I'm really surprised of it, and would have thought better of both companies :(

Marvell PXA310/PXA320 SoC manuals public

Harald Welte — Sat, 09 May 2009 19:00:00 GMT

As it seems, Marvell has released the PXA310 and PXA320 developer manuals. They can now be downloaded and used by anyone, without a need for a NDA. This is great, as it removes one major obstacle for Free Software developers to write code (e.g. Linux kernel / driver code) for those System on a chip (SoC) devices. Marvell also re-released the PXA27x manuals, but this is of less significance considering that back when the PXA was still with Intel, Intel had the full manuals public.

Ti has done something similar, at least for the OMAP3530: Publicly releasing their Technical Reference Manual without any requirement for an NDA. Sure, it is only one of their many products. But I think they have been showing progress even on one of the older OMAP24xx product, as far as I remember.

Now the only major vendor of ARM SoC's for mobile handheld devices like smartphones that has currently no reference manuals public is Samsung. This is really sad, as their S3C2410/2440 manuals always used to be publicly available from their website. Now the S3C6400 and S3C6410 manuals are under NDA, effectively preventing anyone to develop Open Source (and specifically Linux) code for their systems. I sincirely hope they understand what a competitive disadvantage they are now facing in the Linux market.

Without words

Harald Welte — Sat, 25 Apr 2009 19:00:00 GMT

$ dig -t MX openmoko.com

Some updates on the gnufiish project

Harald Welte — Mon, 20 Apr 2009 19:00:00 GMT

Over the last weekend, Stefan, Zecke and myself have been focusing on getting some work done for the gnufiish project. As usual with this kind of reverse engineering project, you never really know how long you need until you've cracked all the major difficulties.

The biggest issue with gnufiish is the lack of working support for the 3.5G modem in the device. Obviously, without such support the device is nothing else but a nice PDA. Disconnected from the rest of the world.

We still don't have a working 3.5G modem under Linux, but we have made the following progress:

confirmed that the modem is attached over UART in addition to SPI
learned that the modem uses some kind of binary protocol on the UART at least for firmware updates
discovered the meaning of quite a number of additional pins on the debug connector, including the serial console. Almost all pins should be known by now.
a preliminary u-boot port has been produced. It can be loaded via OpenOCD/JTAG and accessed over serial console or USB serial emulation. It doesn't yet have the full feature set as people are used from Openmoko GTA01/GTA02, but NAND and SD card access are working
ported Werners Linux userspace s3c24xx-gpio tool into u-boot. This makes it much more convenient to play with the GPIO's without computing boolean bit masking operators in your head. And since booting into Linux userspace takes way too long right now, having this in u-boot really is the right thing.
learned more about the various programs installed in the E-TEN ROM image, i.e. their initial loader, usb downloader as well as the Empire/Knight test environment.
we discovered some bug in OpenOCD leading to problems with breakpoints, Zecke cooked up a patch for this.

If you're interested in the intermediate results / notes, feel free to check the M800 as well as 3.5G modem related pages in the wiki.

Samsung Omnia: A phone suitable for (Linux) hacking?

Harald Welte — Tue, 14 Apr 2009 19:00:00 GMT

Samsung is currently shipping a phone called Omnia, or more precisely, the SGH-i900. It is a touch screen only phone shipping with Windows Mobile. Recently at Mobile World Congress, Samsung has shown that there is a LiMo port to the Omnia. Obviously, this port is not available publicly, so there's no easy way to just re-flash any other Omnia.

However, as it seems some folks at xda-developers.com have booted a generic PXA3xx kernel on the device, which shows us two things: One, there appears to be no cryptographic lockdown, i.e. we can execute what we want on the CPU. Second, that at least a core kernel with framebuffer is already working.

I did some more research today, and put most of the findings at this page in the gnufiish wiki. Among other things, apparently a service manual has leaked, containing schematics excerpts, component placement and similar useful information. I've linked various data sheets of components that are used in the device.

As it seems, the big unknown part is the GSM Modem interface. It uses dual-ported RAM to communicate with a Qualcomm MSM6281 3.5G modem. Now maybe the shared memory protocol is similar or even the same to what Android/HTC/Google G1 uses. At least typically, if you roll out an architecture of a chipset like the 3.5G chipset, then all members of that architecture are likely to speak more or less the same protocol. Of course this is just guesswork, it yet remains to be confirmed.

With some luck I should receive one of those devices soon to do my share of reverse engineering.

Meanwhile, I'm looking forward to the upcoming weekend, where Stefan Schmidt and myself will try to finally get the SPI based 3G/3.5G modem interface of the E-TEN glofiish devices implemented on Linux.

New "linux/mobile" section

Harald Welte — Mon, 06 Apr 2009 19:00:00 GMT

This is where I will write about stuff that happens with regard to Linux mobile devices after closing the linux/opemoko section.

Maemo / Mobiln / Meego

Harald Welte — Sun, 15 Feb 2009 19:00:00 GMT

Every reader of this blog will already have read the news about Nokia + Intel merging their Maemo and Moblin projects to form what's now called MeeGo.

I am not quite sure what to think of it. Of course, two big players teaming together to reduce fragmentation of the "true Linux" mobile software stacks (as opposed to Android) is a good move. There can be a lot of synergies from the combined effort of the Nokia and Intel Linux teams...

Maemo always seemed to be heading in the right direction, embracing and growing a developer community. Moblin on the other hand always felt much more like an industry kind of thing. Sure, there were/are lots of well-known developers from the community working on Moblin, but the involvement of the larger Linux/FOSS community seemed to be quite little. So I hope the new MeeGo project doesn't loose the increasingly good community interaction that that Maemo.org was showing.

On the other hand, Maemo was troubled by political decisions such as the move from GTK to Qt (following Nokias acquisition of Trolltech). No matter what you believe is the better technology, changing the UI stack from one version to another inevitably confuses and disappoints all 3rd party application developers.

What puzzled me most about the announcement was this post by well-known kernel hacker Arjan van de Ven, showing an architecture diagram where the Linux kernel is called "MeeGo Kernel". I almost wonder how much they had to pay him to use that diagram in a public article. If they use the Linux kernel, they should simply call it a Linux kernel, even in marketing-oriented architecture diagrams. Everything else is nothing but an attempt at misleading people. Both the Maemo 5 Software architecture and Android Architecture diagrams clearly indicate it is Linux!

Also, the diagram claims to have a Hardware Adaption Software layer below the kernel, which I am quite sure it won't have. No self-respecting Linux Kernel developer believes in hardware abstraction layers.