Planet OpenEZX

Antonio Ospite: On USB projectors, linux and libam7xxx

Wed, 18 Jan 2012 15:50:21 +0000

I was looking into compact/mini/pico/handheld projectors, and I obviously wanted something I could use under GNU/linux, there were basically two choices:

Pick up a projector with VGA/HDMI: Operating System independent.
Pick up a USB projector: shipped only with drivers for MS Windows (and sometimes for MacOSX too).

Since the first choice was more expensive and I verified that writing a driver for the second case wasn't too hard, I picked up an Acer C110, I paid it about 160 €, but you can find it even cheaper somewhere else, grr.

AM7X or AM7XXX

The C110 is based on an Actions Micro AM7212P IC and uses USB bulk transfers with a simple packet based protocol on top to exchange data and commands to and from a host system and the AM7XXX chip.

Other projectors using the same protocol are:

These projectors use the USB Vendor and Product IDs 1de1:1101 in mass storage mode and 1de1:c101 in display mode.

Some DPFs too (from Hannspree for instance) are known to use these chips but I don't know yet if they can be put in USB display mode.

I will refer to these devices as either AM7X or AM7XXX devices.

Open Source driver for AM7XXX devices

Reto Schneider and I are reverse engineering the USB protocol used by these devices, using USB dumps and disassembling the Windows device driver, and a basic but already usable library to communicate with those AM7x based projectors can be found in libam7xxx. Reto was the first to start working on that, in the form of acerc11xdrv.

So you can now get these projectors to work wherever libusb-1.0 works, that means you can use them with your phone if it can run GNU/Linux for instance, or even Android/Linux but I don't have an Android device to verify that.

For now all the communication about the development is happening on the #am7xxx IRC Channel on the Freenode Network, come find us, and let us know if you want to help: like hosting a mailing list for us, or sponsoring some hardware (USB projectors you want to use freely or devices you want to use these projectors with).

Side note: the user manuals of these devices sometimes refer to the functionality of displaying images over USB as Display over USB (or DoUSB), this definition is used on a lot of projectors but I don't know if it refers always to the same protocol/mechanism to send images over USB.

Linux running ON other projectors

Incidentally, when I was doing my pre-purchase market research, I ran into several projectors which —unsurprisingly— are running a Linux system themselves (linux kernel, busybox, etc.), here is a summary of what I found out:

Samsung SP-H03 (not based on AM7X): the firmware image can be downloaded here, and Samsung is providing the source code for the Free Software used in it, you can find it on opensource.samsung.com (AFAIR Harald Welte gave them some directions about GPL compliance, right?).

This could be an interesting device if you want to run your own code on a projector.
Acer K330: based on a chip of the same am7x family as the C110.

The firmware image is available for download and it does contain the Linux kernel and other Open Source software, but the source code is not available, neither Linux or the GPL are mentioned in the downloadable documentation; I am going to do more research on this later to see if Acer is in compliance with the GPL.

Open Projectors?

Having the ability of processing an image before projecting it —either on an external system, or on the projector itself— opens up to a lot of possibilities, and I can foresee an increase of AR applications using projectors; so, do you think there is enough interest for an Open Projectors project? A place where we can share the techniques (keystone correction, or some more sophisticate anamorphic transformations by the means of a Camera-Projector system) and the Open Source software implementing them, all in a single place.

Get in touch if you have any ideas about that.

Antonio Ospite: AOSP?

Sat, 14 Jan 2012 23:27:17 +0000

Every time I read AOSP in the news I think something is not quite right. Here is a faint attempt to set things straight —with some humor, don't take it too seriously—: here is aosp.it.

And I don't even have an Android device... yet.

But seriously, if anyone is interested in the aosp.it domain for some Android/Linux, Open Source related community site (maybe the very Italian one?), just let me know, I may be willing to concede it, if I decide not to start one myself.

Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License

Attached images:

Michael Lauer: IT has seen a crazy year

Tue, 13 Dec 2011 07:55:07 +0000

Information Technology has seen a really crazy year. Among all the smaller incidents, the big bangs involved Nokia partnering with Microsoft, abandoning Maemo, HP driving with WebOS against the wall, patent lawsuits everywhere.

What that means for FOSS-lovers is clear… you can’t trust any company to continue working on anything. Business demands are what counts in the world of mass markets. If you want longterm support for a platform, your best bet is to build a community around it. But you will also want to work on hardware support otherwise you’ll run into the next dead end.

To be honest, right now I don’t see much of a future for any mobile Linux-inspired platform other than the mutation called Android. But that’s not much of a problem per se. The smartphone market is crazy. To compete in that world, you have to give up on freedom. But is the mass market really what we want? Is it what mobile Linux needs?

I don’t think so. There are still huge opportunities for using Linux-based mobile software platforms in niches such as machine2machine communication, home automation, research, teaching, and more. That’s where a service-based middleware like FSO comes into the game: for special interests. However, even niche-adoption is hindered without a minimal set of applications. And that is where we still lack: Even special interest people want to use their smartphones to manage contacts, browse the web, send mails, play media, etc. We don’t have an integrated software stack with a complete set of UI applications that would cover these needs. Openmoko worked on one, but failed. Nokia worked on multiple ones, but gave up (multiple times). What else do we have?

With HP’s recent announcement about releasing WebOS as open source, the game may have changed. If we could use the WebOS application stack on top of the FSO middleware, we may have a real chance to get something great and usable – and complete – soon. I have always liked the WebOS UI. If it’s a bit slower than other UIs, who cares as long as it is free?

Michael Lauer: Towards the end of 2011

Fri, 09 Dec 2011 08:10:31 +0000

Tempus fugit. I can tell you. Even more so, if you have a baby. I must confess I somewhat underestimated the impact the baby would have on my spare time. In some weird mindset I really thought I could continue working as usual on my open source projects… as we know now I couldn’t. I completely lost track and have to catch up with all changes that happened over the last 6 months.

The first bunch of weeks with the baby were really demanding. I mean, really. She screamed a lot and could only sleep in our arms. Boy, were we tired. We carried her around so much we have Schwarzenegger arms now. But it’s great to see her developing, err… growing up, of course. With 6 months now she is a very interested baby, eager to learn new things and always trying to become more mobile.

Luckily both my wife and me are self-employed. It so much easier when you can skip some hours at the usual start of the workday and also at the usual end. Of course, the work needs to be done, so we have to compensate when she’s in bed. But still, it’s very satisfying being able to see her twice a day for a couple of hours — not all families have this luxury. Plus the existence of our two invaluable grandmas… it’s great.

Company-wise, the Lauer & Teuber GbR had an amazing year with many interesting iOS (and some Android) projects. We have reached the maximum we can do with the two guys we are, so we decided to grow and hire our first regular employee who’s going to start in 2012. We also rented another office and are already moving.

I’m slowly getting back into some of my beloved open source projects… it’s great that work on e.g. FSO did not stall at all, but continued while I was “away”. Last week, I attended the 3rd installment of the Open Hard- and Software Workshop in munich, where the latest development of the very promising GTA04 mobile phone was presented. I had a talk about Vala which was well received. By the way, my Vala-book plans are not dead yet… just in parking position

Next week I’m attending the FSOSHRCON, a joined conference with the people working on the freesmartphone.org middleware and the SHR software. It’s going to be great seeing all the folks again, concentrating a full weekend to agree on some important issues laying the path forward for the next year. Can’t wait to be there.

What’s left is the feeling that an extremely busy year has passed by, spiced with incredibly intense emotions. I’m a happy man and I love my life. I’m given exciting opportunities, but also challenges – and I plan to accept everything

All the best to you guys!

Antonio Ospite: Gnome 3: go to Shell? Not just yet, thanks.

Wed, 19 Oct 2011 21:37:27 +0000

In Debian Unstable the transition to Gnome 3 is taking place; when Gnome 3.0 firstly came out some unnamed geeky users complained loudly about the design decisions of the development team to push strongly towards gnome-shell as a new default UI; gnome-shell was designed focusing on usability (usability is a metric relative to a certain target audience BTW) and simplicity, hiding a lot of details from the users. Obviously you can never make everyone happy so some of us simply happened to be “out of target”: you know us computer people (*cough cough*), we like to be in charge and control The Machine... I must admit I still don't have a definitive opinion about the gnome-shell concept, for now I just know that it does not suit me; I am going to try it eventually, maybe I'll get used to it, but in the mean time I need my desktop back just like I shaped it through the years; can this be done without loosing all the good Gnome technologies (Empathy over all of them)?

To be completely fair I have to say that there is little to complain about with Gnome developers, we can still get our good old GNOME desktop fully back by using the fall-back mode based on gnome-panel and live happily ever after, let's take a look at how this can be accomplished.

NOTE: GNOME people state that the fall-back mode is meant for systems with older graphic cards which cannot run gnome-shell, however it can very well be seen as a good opportunity for those who do not want to run gnome-shell just yet.

Getting back to the topic: some minor touches are needed to make the panel look more like what we are used to, maybe some of these settings could even become default for fall-back mode, we'll see.

First, enable fall-back mode (on Debian there is a dedicated session you can choose from the Log-in Manager for that) and change some desktop settings, in a terminal type:

$ gsettings set org.gnome.desktop.session session-name 'gnome-fallback'
$ gsettings set org.gnome.desktop.interface 'menus-have-icons' true
$ gsettings set org.gnome.desktop.interface 'buttons-have-icons' true
$ gsettings set org.gnome.desktop.background 'show-desktop-icons' true

gnome-tweak-tool can be used for some of these settings like shown in the attached images.

Then rearrange the applets on the panel as you please (use Alt-RightClick to access the panel properties), and fix the theming using this patch to have a light panel again (against gnome-themes-standard=3.0.2-1):

$ mkdir $HOME/.themes
$ cd $HOME/.themes
$ cp -r /usr/share/themes/Adwaita Adwaita-fallback
$ cd Adwaita-fallback
$ patch -p1 < $HOME/adwaita-fallback-panel-theme.patch
$ gsettings set org.gnome.desktop.interface 'gtk-theme' 'Adwaita-fallback'

Some final touches for the Metacity window manager and to the clock applet, and we are all set:

$ gconftool-2 --type string --set /apps/metacity/general/focus_mode mouse
$ gconftool-2 --type boolean --set /apps/metacity/general/compositing_manager true
$ gconftool-2 --type string --set /apps/panel3-applets/clock/custom_format '<span color="#333">%a %d %b</span> <b>%H:%M</b>'
$ gconftool-2 --type string --set /apps/panel3-applets/clock/format custom

Ah, in the new gnome-panel based on Gtk3 there are still some details to take care of, I hope issues like that will be addressed and that the panel will be supported for quite some time.

Attached images:

Attached files:

Adwaita theme patch for fall-back mode

Michael Lauer: The Eagle Has Landed!

Thu, 09 Jun 2011 16:06:10 +0000

After letting us wait for a bit longer than scheduled (13 days), the hospital initiated the contractions. For the first couple of hours, everything went just perfect, but then the little one got stuck on the way and we had to resort to a cesarean section. Lara Marie Lauer was born 8th of June at 04:41 (AM) with 3460 gramms and 49 cm.

Mummy was still on intensive care and so they gave her to me. I can’t express the feelings I had in this very moment. I’m still kind of overwhelmed every time I see her. Thanks for all of you who waited anxiously with me and those who prayed for us. The most important tasks for the near future is getting Mummy to recover and Lara Marie to become accustomed to us and the rest of the outside world.

Please bear with me if in the next time I’m not as responsive as usually

Michael Lauer: German Post on time!

Mon, 30 May 2011 08:54:43 +0000

And now for something completely different… while we are all waiting for my baby to arrive (who was scheduled for 25th of May), she just received her first greeting card – together with a personalized bib and a towel (with integrated hood – pretty fancy!) from my good friends at #openmoko-cdevel.

Guys, seeing this card was very heartwarming – it means a lot to me that you share my anticipation, thanks a lot! And I’m 100% sure she will appreciate her gifts… now let’s cross fingers it won’t take much longer… waiting is the hardest part of it

Yours,

Mickey.

Antonio Ospite: On git clone failing and tweaking object repack

Fri, 06 May 2011 10:41:37 +0000

I had been experiencing errors when cloning the OpenEZX kernel with git and I was finally able to solve the issue on the server, I am putting some notes here to save some time to someone else. Here's how the story started:

ao2@jcn:~$ git clone git://git.openezx.org/openezx.git
Cloning into openezx...
remote: Counting objects: 1954118, done.
remote: fatal: unable to create thread: Resource temporarily unavailable
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

Looking at the server statistics with htop confirmed this was happening because git was running out of memory on the server; it is worth noticing that the issue was not present when cloning other projects from the same server (Linux kernel projects as well, hence with a comparable size in principle).

With the following points in mind:

The server hosting the remote repository has about 1.6 GiB of RAM, but no swap space;
In OpenEZX we are using TopGit to track topic branches, which generates tons of merge commits and makes the git repository heavier;

my thoughts went like:

during a clone operation some compression of git objects occurs;
because of the lack of swap space the compression operation must fit in memory;
because of TopGit the compression operation on this repository was more onerous than on the other projects, causing the memory outage.

So some optimization on the repository about objects compression was needed.

The first thing that came to mind was git-gc but that was failing as well:

openezx:~# cd /home/git/repositories/openezx.git
openezx:/home/git/repositories/openezx.git# git gc --aggressive
Counting objects: 1954118, done.
Delta compression using up to 2 threads.
warning: suboptimal pack - out of memory02)   
fatal: Out of memory, malloc failed (tried to allocate 602234 bytes)
error: failed to run repack

The repack operation is performed by git-pack-objects, so after Reading The Fine Manual I was able to make git-gc run successfully using these steps:

openezx:/home/git/repositories/openezx.git# git config pack.thread 1
openezx:/home/git/repositories/openezx.git# git gc --aggressive
Counting objects: 1954118, done.
Compressing objects: 100% (1936802/1936802), done.
Writing objects: 100% (1954118/1954118), done.
Total 1954118 (delta 1618716), reused 0 (delta 0)

note that using only one thread makes the process quite slow.

In some other cases it could be useful to change also the pack.windowMemory config option, but a relation involving the address space, the available memory and the number of threads has to be found, so since just using one thread worked fine for me, I took that as the minimal fix for my problem.

Bottom line: cloning the repository is now back working:

ao2@jcn:~$ git clone git://git.openezx.org/openezx.git
Cloning into openezx...
remote: Counting objects: 1954118, done.
remote: Compressing objects: 100% (318086/318086), done.
remote: Total 1954118 (delta 1618716), reused 1954118 (delta 1618716)
Receiving objects: 100% (1954118/1954118), 377.38 MiB | 738 KiB/s, done.
Resolving deltas: 100% (1618716/1618716), done.

Side note: the more attentive reader would have noticed a cosmetic defect in the output when git-gc fails (more precisely from git-pack-objects: warning: suboptimal pack - out of memory02)), well don't loose any sleep over it :) it has been reported and there is a workaround for that already.

Antonio Ospite: Kinect linux kernel driver

Mon, 06 Dec 2010 21:12:09 +0000

It looks like Santa came early this year.

KernelLabs sponsored me for a Kinect sensor device unit so I can experiment writing a Linux kernel driver for it.

So in the next weeks I'll be working on a gspca driver for this device. For now the code is going to be hosted in the gspca_kinect repository, as an out of kernel module, this will ease compile/test cycle; if it comes out that changes are needed to gspca itself, then I'll decide whether hosting these changes as patches, or switching to a kernel clone repository; suggestions will be welcome. The driver is working already, but currently you can just use the sensor as a normal WebCam.

About the Kinect

The Kinect sensor is a device used by Microsoft for its Kinect project, which is a system for controller-less Human-Computer interaction firstly targeted for Xbox 360, but rumors say MS could be integrating this technology into its future operating systems; the hardware is only part of the system of course, the software does most of the interpretation work figuring out how many users there are and assigning a meaning to their actions.

Great part of the Kinect communication protocol has been already figured out, thanks to the adafruit people who dumped the communication stream with the Xbox using an usb bus analyzer, and to Héctor Martín Cantero (marcan) who started analyzing the trace for the libfreenect driver. Marcan is also the guy who won the adafruit bounty for a kinect opensource driver, and the one behind AsbestOS. All these efforts have flowed into the OpenKinect project, wisely guided by Joshua Blake.

For an overview about the hardware you can see the IFixit teardown, the part I am interested in for now is the integration of the video capturing sub-device which provides what is usually called RGBD data (Red, Green, Blue, Depth), the Depth component gives spatial information about the captured scene, easing out the process of image segmentation. Just to give an idea, background subtraction is one step of the segmentation process, and can be achieved quite robustly with techniques like Depth keying (the spatial version of Chroma keying). But I am really not an expert in this area.

In the Kinect device, RGBD data is captured from two distinct sensors: a regular RGB sensor and a monochrome sensor which, with the aid of a IR structured light, captures what is finally exposed as a depth map; so what we have is basically a Structured-light 3D scanner.

Kernel driver development

I don't know yet if the gspca driver is going to define two video devices, one for each sensor, or if a combined format would be preferred, I am asking for advice from others more expert in this field.

This is the plan:

Stabilize the first version of the driver which does device registration/initialization and allows capturing the RGB data with fixed resolution and fixed framerate using a video device node. The RGB data comes as a raw Bayer pattern, precisely in the V4L2_PIX_FMT_SGRBG8 pixelformat.
Add support for capturing the Depth map data somehow. Each depth value has 11-bit precision, and the data is transferred as a packed array, I still don't know how such format should be presented to userspace.

Follow the discussion on the OpenKinect mailing list or on linux-media.

Thinking outside the (X)box

Ah, don't forget to check out all the fancy stuff people are doing with this toy.

Antonio Ospite: Bug hunting in Linux kernel land: an unpretentious primer

Tue, 02 Nov 2010 21:18:26 +0000

Lately I've been fixing some defects in the hidraw interface in the Linux kernel (commits d20d5ff and e42dee9), simple issues like these NULL pointer dereference are a good example to show how to analyze a Linux bug trace in order to spot the defective code. So let's take a look. The steps to fix any defect are basically:

reproduce the problem (a quick introduction to the concept of “Observability” of software faults is in: Dissecting The Bug)
find the offending code/policy
elaborate a solution
implement and test the solution is working

Reproducing the problem

If the problem is in some userspace/kernelspace interface then writing a test program which triggers the bug may be the quickest way to reproduce it. The test program should be as simple as possible, doing the minimum required to expose the defect, as it will be used also as a proof that the bug has been solved in the right way; just like when proving a theorem we don't want to have more hypotheses than are necessary. The test program for one of the issues above looks like this:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

#include <linux/hidraw.h>

int main(int argc, char *argv[])
{
	int fd = -1;
	unsigned char report[2] = {0x01, 0x00};
	int ret;

	if (argc != 2) {
		fprintf(stderr, "usage: %s </dev/hidrawX>\n", argv[0]);
		exit(1);
	}

	fd = open(argv[1], O_RDWR);
	if (fd < 0) {
		perror("hidraw open");
		exit(1);
	}

	while (1) {
		ret = write(fd, report, sizeof(report));
		printf("ret: %d\n", ret);
	}

	close(fd);
	exit(0);
}

That gives me the occasion for an observation about one aspect of testing procedures: as you can see the test program above uses deliberately some bad practice, namely it does not check the return value of the write() call in order to exit the while loop; we know this is generally bad from a programming point of view, however it turns out to be good from another point of view: bad programs can spot cases we didn't think of in our code paths; it goes without saying that this is no excuse for “uncontrolled” bad practices, nor for the bug we had in the first place :).

Anyhow, the code above exposes the defect on kernels up to 2.6.35, just run the program and unplug the (USB) device (a Sony Sixaxis in my case):

BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
IP: [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]
PGD 37082067 PUD 3701f067 PMD 0 
Oops: 0000 [#1] SMP 
last sysfs file: /sys/devices/pci0000:00/0000:00:04.0/usb4/idVendor
CPU 0 
Modules linked in: hid_sony usbhid hid kvm_amd kvm powernow_k8 mperf cpufreq_powersave cpufreq_conservative cpufreq_stats cpufreq_userspace ipt_MASQUERADE lirc_serial(C) lirc_dev bridge stp ppdev lp sco bnep rfcomm l2cap crc16 tun sit tunnel4 binfmt_misc uinput fuse ip6table_raw ip6table_mangle ip6t_REJECT ip6t_LOG nf_conntrack_ipv6 ip6table_filter ip6_tables xt_tcpudp ipt_REJECT ipt_ULOG xt_limit xt_state xt_multiport iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_raw ip_tables x_tables nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc hwmon_vid loop snd_hda_codec_nvhdmi snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi nvidia(P) snd_seq_midi_event snd_seq snd_timer snd_seq_device btusb bluetooth joydev snd edac_core shpchp video tpm_tis tpm evdev rfkill parport_pc parport tpm_bios pcspkr asus_atk0110 processor output edac_mce_amd soundcore snd_page_alloc i2c_nforce2 pci_hotplug k8temp wmi i2c_core button ext3 jbd mbcache dm_mod sg sd_mod sr_mod cdrom crc_t10dif ata_generic usb_storage ahci libahci pata_amd ohci_hcd libata ehci_hcd scsi_mod usbcore forcedeth floppy nls_base thermal thermal_sys [last unloaded: hid]

Pid: 4818, comm: test_hidraw_wri Tainted: P         C  2.6.35-ao2 #2 M3N78-VM/System Product Name
RIP: 0010:[<ffffffffa0f0a625>]  [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]
RSP: 0018:ffff880037081ee8  EFLAGS: 00010202
RAX: 0000000000000000 RBX: 0000000000000002 RCX: ffff880037081f58
RDX: 0000000100000000 RSI: 0000000000000008 RDI: ffffffffa0f128b0
RBP: 0000000000000001 R08: ffffffffa0f0a5ea R09: 000000000040087a
R10: 0000000000000000 R11: ffffffff81150c83 R12: ffff880037081f58
R13: 00007fff1b34cab0 R14: 00000000ffffffed R15: 0000000000000000
FS:  00007fa946870700(0000) GS:ffff880001a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000028 CR3: 000000005ad24000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process test_hidraw_wri (pid: 4818, threadinfo ffff880037080000, task ffff88006003e630)
Stack:
 ffff88005ad95000 00007fff1b34cab0 ffff880037081f58 00007fff1b34cba0
<0> 0000000000000000 ffffffff810ea46f 0000000000000003 0000000000000008
<0> ffff88005ad95000 00007fff1b34cab0 00000000004005c0 ffffffff810ea57e
Call Trace:
 [<ffffffff810ea46f>] ? vfs_write+0xa4/0x100
 [<ffffffff810ea57e>] ? sys_write+0x45/0x6b
 [<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
Code: 53 48 8b 47 18 48 c7 c7 b0 28 f1 a0 48 89 d3 48 8b 40 10 8b 68 58 e8 07 9a 3f e0 81 e5 ff ff 0f 00 89 ed 48 8b 04 ed c0 2b f1 a0 <4c> 8b 60 28 49 83 bc 24 50 1c 00 00 00 0f 84 af 00 00 00 48 81 
RIP  [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]
 RSP <ffff880037081ee8>
CR2: 0000000000000028
---[ end trace 06cb2d01ded47cc4 ]---

The most important info in this message is highlighted above in line two, that is:

IP: [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]

This tells us the last instruction executed, the one triggering the bug; the format is symbol_name+offset/symbol_size [module_name] as can be seen in mm/slab.c.

Finding the offending code

To find where the offending instruction is, we can disassemble the object code with objdump, here's the interesting function:

00000000000008e5 <hidraw_write>:
 8e5:	41 56                	push   %r14
 8e7:	41 be ed ff ff ff    	mov    $0xffffffed,%r14d
 8ed:	41 55                	push   %r13
 8ef:	49 89 f5             	mov    %rsi,%r13
 8f2:	41 54                	push   %r12
 8f4:	55                   	push   %rbp
 8f5:	53                   	push   %rbx
 8f6:	48 8b 47 18          	mov    0x18(%rdi),%rax
 8fa:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
 901:	48 89 d3             	mov    %rdx,%rbx
 904:	48 8b 40 10          	mov    0x10(%rax),%rax
 908:	8b 68 58             	mov    0x58(%rax),%ebp
 90b:	e8 00 00 00 00       	callq  910 <hidraw_write+0x2b>
 910:	81 e5 ff ff 0f 00    	and    $0xfffff,%ebp
 916:	89 ed                	mov    %ebp,%ebp
 918:	48 8b 04 ed 00 00 00 	mov    0x0(,%rbp,8),%rax
 91f:	00 
 920:	4c 8b 60 28          	mov    0x28(%rax),%r12
 924:	49 83 bc 24 30 1c 00 	cmpq   $0x0,0x1c30(%r12)
 92b:	00 00 
 92d:	0f 84 af 00 00 00    	je     9e2 <hidraw_write+0xfd>
 933:	48 81 fb 00 10 00 00 	cmp    $0x1000,%rbx
 93a:	76 25                	jbe    961 <hidraw_write+0x7c>
 93c:	65 48 8b 04 25 00 00 	mov    %gs:0x0,%rax
 943:	00 00 
 945:	8b b0 c8 01 00 00    	mov    0x1c8(%rax),%esi
 94b:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
 952:	31 c0                	xor    %eax,%eax
 954:	41 b6 ea             	mov    $0xea,%r14b
 957:	e8 00 00 00 00       	callq  95c <hidraw_write+0x77>
 95c:	e9 81 00 00 00       	jmpq   9e2 <hidraw_write+0xfd>
 961:	48 83 fb 01          	cmp    $0x1,%rbx
 965:	77 25                	ja     98c <hidraw_write+0xa7>
 967:	65 48 8b 04 25 00 00 	mov    %gs:0x0,%rax
 96e:	00 00 
 970:	8b b0 c8 01 00 00    	mov    0x1c8(%rax),%esi
 976:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
 97d:	31 c0                	xor    %eax,%eax
 97f:	41 be ea ff ff ff    	mov    $0xffffffea,%r14d
 985:	e8 00 00 00 00       	callq  98a <hidraw_write+0xa5>
 98a:	eb 56                	jmp    9e2 <hidraw_write+0xfd>
 98c:	be d0 00 00 00       	mov    $0xd0,%esi
 991:	48 89 df             	mov    %rbx,%rdi
 994:	41 be f4 ff ff ff    	mov    $0xfffffff4,%r14d
 99a:	e8 00 00 00 00       	callq  99f <hidraw_write+0xba>
 99f:	48 85 c0             	test   %rax,%rax
 9a2:	48 89 c5             	mov    %rax,%rbp
 9a5:	74 3b                	je     9e2 <hidraw_write+0xfd>
 9a7:	e8 00 00 00 00       	callq  9ac <hidraw_write+0xc7>
 9ac:	89 da                	mov    %ebx,%edx
 9ae:	4c 89 ee             	mov    %r13,%rsi
 9b1:	48 89 ef             	mov    %rbp,%rdi
 9b4:	e8 00 00 00 00       	callq  9b9 <hidraw_write+0xd4>
 9b9:	48 85 c0             	test   %rax,%rax
 9bc:	41 b6 f2             	mov    $0xf2,%r14b
 9bf:	75 19                	jne    9da <hidraw_write+0xf5>
 9c1:	b9 01 00 00 00       	mov    $0x1,%ecx
 9c6:	48 89 da             	mov    %rbx,%rdx
 9c9:	48 89 ee             	mov    %rbp,%rsi
 9cc:	4c 89 e7             	mov    %r12,%rdi
 9cf:	41 ff 94 24 30 1c 00 	callq  *0x1c30(%r12)
 9d6:	00 
 9d7:	41 89 c6             	mov    %eax,%r14d
 9da:	48 89 ef             	mov    %rbp,%rdi
 9dd:	e8 00 00 00 00       	callq  9e2 <hidraw_write+0xfd>
 9e2:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
 9e9:	e8 00 00 00 00       	callq  9ee <hidraw_write+0x109>
 9ee:	5b                   	pop    %rbx
 9ef:	5d                   	pop    %rbp
 9f0:	41 5c                	pop    %r12
 9f2:	41 5d                	pop    %r13
 9f4:	49 63 c6             	movslq %r14d,%rax
 9f7:	41 5e                	pop    %r14
 9f9:	c3                   	retq

The instruction we are interested in is at hidraw_write+0x3b which is at address 0x8e5+0x3b that is 0x920:

 918:   48 8b 04 ed 00 00 00    mov    0x0(,%rbp,8),%rax
 91f:   00
 920:   4c 8b 60 28             mov    0x28(%rax),%r12
 924:   49 83 bc 24 30 1c 00    cmpq   $0x0,0x1c30(%r12)
 92b:

Now, how do we find the correspondent instruction in the source code? If we don't want to do that the hard way we can use the -S option of objdump like mentioned also in Documentation/BUG-HUNTING in the kernel tree, which interleaves source code with the disassembled listing, here's the excerpt we need:

	dev = hidraw_table[minor]->hid;
 916:	89 ed                	mov    %ebp,%ebp
 918:	48 8b 04 ed 00 00 00 	mov    0x0(,%rbp,8),%rax
 91f:	00 
 920:	4c 8b 60 28          	mov    0x28(%rax),%r12

So in this case the problem is that the code is trying to dereference hidraw_table[minor], but this entry could be NULL if we disconnect the device while performing the write() in a loop without checking return values.

Finding out the exact line could be a little harder when macros and inlined functions are used, but once we know how to deal with a simple scenario like the one proposed the complicated cases become someway doable too.

Elaborating a solution

The fix is trivial is this case: check the pointer is not NULL before dereferencing it, bail out otherwise.

Implementing and testing the solution

This is the actual patch which solves the issue:

diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
index 9eaf6ae..a3866b5 100644
--- a/drivers/hid/hidraw.c
+++ b/drivers/hid/hidraw.c
@@ -109,6 +109,12 @@ static ssize_t hidraw_write(struct file *file, const char __user *buffer, size_t
 	int ret = 0;
 
 	mutex_lock(&minors_lock);
+
+	if (!hidraw_table[minor]) {
+		ret = -ENODEV;
+		goto out;
+	}
+
 	dev = hidraw_table[minor]->hid;
 
 	if (!dev->hid_output_raw_report) {

Now, using the fixed hid module, if we run the test program again and disconnect the device we won't hurt the kernel anymore.

Michael Lauer: Towards the end of 2010

Sat, 16 Oct 2010 16:34:47 +0000

Howdy, dear reader!

It’s been a while on this blog, mainly due to the fact that many short status updates are better twittered than blogged. Then again, as promised / threatened in last year’s installment of this column, I had to spend most of the time this year with iOS development, rather than with FOSS — and it doesn’t look like this will change much (you know, food and things…). Still I do care a lot about projects like OpenEmbedded, Vala, freesmartphone.org, and the like, so here’s what has been going on this year:

OpenEmbedded (www.openembedded.org)

OE moved along quite well this year. I did not have much time for it — other than taking care about a couple of Vala and FSO recipes — but I’m especially pleased that the community finally embraced major clean up. Thanks to Frans, Richard, and all others involved, OE is improving heavily — although it wasn’t easy: Over the last couple of years, the OE core contributors developed a resistance against any changes affecting more than a handfull of recipes, however in order to make OE handle even more contributors and various use cases, we had to do some substantial cleanups. This will reduce maintenance and improve the overall quality of recipes in OE, which is the #1 complaint I hear.

Vala (www.vala-project.org)

During the first half of the year, Vala went through some extremely tiring phases of non-activity, which improved vastly when its main developers opened up a bit, i.e. giving more developers access to the tree, adding branches, etc. There have been many changes in the Dova profile, but also the GLib profile has seen an incredible amount of work, bugfixes, some new features, and more.

The pace of changes that affect basic things had also impact on my vala-book plans; apart from a severe lack of time on my side, I think it’s better to wait until Vala is closer to 1.0. Otherwise I risk describing a moving target, which — considering the time I have to work on that project — would effectively kill it. That said, it’s great to see that Vala is getting better every day and gains more and more popularity from all kinds of developers.

FSO (freesmartphone.org)

The progress on freesmartphone.org is two-fold; on one hand, we have seen quite a nice amount of work to support more devices. On the other hand though, in contrast to all the work I did in 2009, there has been a severe lack of development of the core in 2010. This I plan to change as soon as possible. For 2011, I see myself continuing to develop FSO in the following three dimensions; internal, external, and integration.

Internal | FSO is a heavy DBus consumer. I think by now we are one of the largest projects using DBus, at least considering the amount of API and running processes that communicate with each other via DBus. We always had our share of problems with DBus, especially some concurrency problems and race conditions are still haunting us. Both libdbus and dbus-glib exhibit their own share of problems, obviously this is not much of an issue on the desktop, but it turns out to be a major PITA on embedded systems, such as a phone. That’s why I have been excited since I heard that the glib team planned to write their own DBus backend and put it right into the glib. This work has now been released as of glib 2.26. Over the next weeks, I will port FSO to using gdbus in a branch.
External | DBus-signals have some problems. That’s why some big projects (BlueZ and ConnMan, to name two of them) adopted an agent-style of API, where the clients have to implement a server API which is being called by the actual servers. While this means some more work for client developers, it has major benefits. I’m going to change some of our APIs to adopt this style.
Integration | To deliver an integrated solution for today’s mobile phones, FSO needs to add more glue to work with existing services, such as BlueZ (bluetooth connectivity), Connman (ethernet and wifi connectivity), and some VoIP services. While these services work fine on their own, FSO lacks an API that uses these individual services in combination to achieve higher level tasks.

All this means that I will not be working much on the actual ports, but rather use my — very limited, did I say that yet? — time to drive the core forwards. I still believe that we will have full FOSS phones — other than the Openmoko devices — soon. Please help to make this dream a reality. (And no, please don’t talk to me about Android…)

Cheers,

:M:

Antonio Ospite: User-aware scheduling

Tue, 21 Sep 2010 20:01:46 +0000

Recently both OSnews and Slashdot pointed out some experiments about context-aware UIs done by Christian Giordano at Canonical (the company behind Ubuntu GNU/Linux), and the first results are somewhat interesting. As you can see in the good video demo from the original article the effects are nothing mind blowing, but they serve greatly to illustrate the concept, and by building on that something more useful would come out eventually.

That reminds me of another (never realized) old idea of mine from when I was attending the Operating System course at the university, I wanted to bind system responsiveness —at a lower level— to user presence, by tuning scheduler parameters according to the user being at his/her computer or not. Imagine a desktop computer which is encoding a video in background, when the user is interacting with the system then the interactive tasks must be more important, but when he/she leaves, then the system could assign to the background job all the resources it needs to run “at its best”.

The parameters to change system responsiveness could be, just for instance, process niceness, swappiness (some report that less swapping results in more responsiveness, but I don't have numbers either to agree or disagree on that), or the whole scheduler could be changed on the fly if there is any system allowing that.

The mechanisms to detect user presence could be the usual: proximity sensors, video from a webcam or audio form a mic (humor alert), some measure of mouse and keyboard activity, a pillow/button on the seat (that would tell butt-on / butt-off... ehm).

In my original thoughts I wanted to detect when the monitor was manually switched off, that's because I usually switch it off when I leave the computer in order to save some power; on a laptop we have the lid button which could be abused, but I couldn't find a way to detect when an external monitor is turned off, anyone?

Antonio Ospite: Supercool Linux

Tue, 20 Jul 2010 09:42:24 +0000

We all know linux is cool, don't we? However these people at SuperFreddo make it supercool (freddo is the Italian word for cool/cold).

SuperFreddo is a frozen food chain here in Naples Italy, and the penguin in their logo has an interesting resemblance to Tux, the linux kernel mascot: the contour is not exact and it is wearing a hat and a scarf, but you just look at the feet —at their inclination— and you have no more doubts.

I am not on Facebook, so maybe some of you could point out to them where the designer of their logo could have taken inspiration from.
Could there be also a legal case here? I don't know.

I attach a couple of pictures of their shopping bags, just for the records, and to remind people that from 2011 plastic bags are banned in Italy.

Attached images:

Antonio Ospite: Write access to OpenEmbedded

Fri, 04 Jun 2010 15:02:11 +0000

Since late May 2010 I've been given write access to the OpenEmbedded repository.

Thanks to the OE devs who supported me.

Antonio Ospite: Neat compile/run cycle with git and OpenEmbedded

Thu, 27 May 2010 08:46:09 +0000

No matter how much careful we are when writing code, whatever changes we are making to a piece of software we must test them before production, even Donald Knuth once said: Beware of bugs in the above code; I have only proved it correct, not tried it. :).

Moreover, if the software we are working on is targeting an embedded system and needs cross-compilation and depends on other software, then testing can be more tedious: we have to prepare patches/archives and instruct the target SDK to pick our latest code, or we could code directly in the SDK working tree, but that would not be very clean. If you use git and OpenEmbedded there is a very neat way to build directly from our own working directory on the filesystem. By developing with git from the start, your changes are ready to be sent upstream as soon as they are proven to be OK.

Git cloning from filesystem

I am not going to repeat how nice, sleek and whatnot git is, just let me show you again how flexible it is: you can easily “re-clone” from a git clone on the filesystem, no need to have any servers around:

$ cd /tmp
$ git clone file:///home/ao2/Proj/EZX/OE/framework

See? By only using the file:// URI scheme we fetch from a git (working) directory: a git directory is a valid git repository, there's some beauty in this regularity.

Fetching the latest code from our git working dir with OpenEmbedded

OpenEmbedded uses the bitbake task executor, .bb files (called recipes) are used to describe bitbake tasks, they are generally used to define packages for distributing some software, and the source code of the software can be fetched in many different ways; in this case we are editing a recipe which uses the git fetcher, let's take a look at the original recipes/freesmartphone/frameworkd_git.bb:

DESCRIPTION = "The reference implementation of the freesmartphone.org framework APIs"
HOMEPAGE = "http://www.freesmartphone.org"
AUTHOR = "FreeSmartphone.Org Development Team"
SECTION = "console/network"
DEPENDS = "python-cython-native python-pyrex-native"
LICENSE = "GPL"
SRCREV = "93673aa09cafc8fb5cfc3cb4055a73e25e595b70"
PV = "0.9.5.9+gitr${SRCPV}"
PR = "r3"
PE = "1"

inherit distutils update-rc.d python-dir

INITSCRIPT_NAME = "frameworkd"
INITSCRIPT_PARAMS = "defaults 29"

SRC_URI = "${FREESMARTPHONE_GIT}/framework.git;protocol=git;branch=master \
           file://frameworkd \
           file://frameworkd.conf \
	   "
SRC_URI_append_shr = "file://oeventsd-use-opimd-signals.patch;patch=1"

S = "${WORKDIR}/git"
...
...

we can change the path in SRC_URI to a directory on the filesystem, and change the protocol to file so that git uses our working copy to fetch the code for the package, we can also specify our development branch here. Note that we still have to use the git:// scheme, because that's what tells bitbake which fetcher to use.

diff --git a/recipes/freesmartphone/frameworkd_git.bb b/recipes/freesmartphone/frameworkd_git.bb
index dac7fe9..ddae81d 100644
--- a/recipes/freesmartphone/frameworkd_git.bb
+++ b/recipes/freesmartphone/frameworkd_git.bb
@@ -4,9 +4,9 @@ AUTHOR = "FreeSmartphone.Org Development Team"
 SECTION = "console/network"
 DEPENDS = "python-cython-native python-pyrex-native"
 LICENSE = "GPL"
-SRCREV = "93673aa09cafc8fb5cfc3cb4055a73e25e595b70"
+SRCREV = "${AUTOREV}"
 PV = "0.9.5.9+gitr${SRCPV}"
-PR = "r3"
+PR = "r4"
 PE = "1"

 inherit distutils update-rc.d python-dir
@@ -14,7 +14,7 @@ inherit distutils update-rc.d python-dir
 INITSCRIPT_NAME = "frameworkd"
 INITSCRIPT_PARAMS = "defaults 29"

-SRC_URI = "${FREESMARTPHONE_GIT}/framework.git;protocol=git;branch=master \
+SRC_URI = "git:///home/ao2/Proj/EZX/OE/framework;protocol=file;branch=freescale_neptune \
            file://frameworkd \
            file://frameworkd.conf \
           "

Now we are set, we can build packages as usual and test our local changes on the target system:

$ bitbake -c clean recipes/freesmartphone/frameworkd_git.bb
$ bitbake recipes/freesmartphone/frameworkd_git.bb

Michael Lauer: Joining twitter

Sun, 04 Apr 2010 14:59:21 +0000

I’m now on twitter. I’ll use that for small status updates on the various open source related work I’m doing, e.g. FSO, OpenEmbedded, Vala, and the like.

Follow me, if you can

Michael Lauer: Qt suddenly got interesting again

Sat, 27 Feb 2010 15:44:17 +0000

After Trolltech dropping the ball with the community back in the old days of Opie, I pretty much gave up on Qt (and C++) apart from accepting some contract work, so my C++/Qt skills would not get too rusty. Since my nightmares with getting something fluid out of Gtk+ (back in the Openmoko days), I did not have the chance to do much UI work — the freesmartphone.org middleware kept me busy enough.

I have been watching Qt progressing though, and ever since they introduced Qt Kinetic and QML it became very interesting for me again. QML looks like EFL’s Edje been thought through — don’t get me wrong, Edje was groundbreaking (as most of Rasterman’s work) when it made its debut, however in my opinion it got stuck in the middle and never lived up to what I was expecting from it.

Once QML ships with Qt — hopefully in the next minor or at least major version of Qt, I will get back on doing some FOSS work on application level to complete creating a smart phone stack. That’s going to be fun!

Michael Lauer: F(SO|OS)DEM 2010

Mon, 08 Feb 2010 19:56:25 +0000

Just came back from FOSDEM 2010, which — after skipping the last incarnation — was a great inspiring and productive event. The Openmoko devroom we originally requested was declined, however thanks to the initiative of Serdar Dere, it turned out we could snatch a last minute 3 hours timeslot that was left open by the Xorg guys. Very shortly we prepared a schedule and managed to get a nice program which was very well received.

Due to the short notice, we could not manage to create a video recording infrastructure, so I’m afraid this year we can only provide the slides — which are a notoriously bad substitute for real talks though. We try to improve for next year — if we can get a devroom again. The pictures you are seeing are courtesy Dr. Nikolaus Schaller from Goldelico, btw. — thanks!

The FOSDEM team did certainly improve its organization over the last years, I was very pleased to see some of my criticism being taken into account. Apart from the lack of good coffee in Brussels (which the FOSDEM team probably is unguilty for), I can’t complain about anything. Even WiFi worked tremendously well on saturday. I still think due to the size of the ever growing interest in this conference that the ULB as location should seriously be reconsidered though. The special service transport on sunday to the main station is a great idea, folks — thanks a lot! Funnily enough, half of the ICE that took me to/from Frankfurt/Main to Brussels Zuid was filled with hackers, btw.

I have met some interesting people working on mobile devices, such as dcordes, leviathan, GNUtoo, cr2, larsc, heinervdm, etc. It’s great to see there is still momentum in real mobile FOSS architectures (i.e. something besides the Android, Maemo, or WebOS systems). I’m glad to tell you that this year we will see an exciting breakthrough in freesmartphone.org middleware supporting new platforms, i.e. progress on the HTC Dream and the Palm Pre is looking _very_ well. Stay tuned for more details appearing here soon.

I wish every conference would be like that. The only slightly disappointing thing was the cross-buildsystem-session in the embedded room. Just when I was expecting the discussion about the problems and potential collaboration to start, the time for the session was over. Rather than wasting time watching Andy Green telling us that our projects will die soon and we should all start using Fedora/Embedded now, we could have had some progress… Oh well, perhaps next year.

Michael Lauer: FOSDEM 2010

Wed, 03 Feb 2010 12:14:56 +0000

Due to some lucky coincidences, we got a devroom at this year’s FOSDEM. I’ll be there, presenting a short overview about the history of the Openmoko project as well as a wrap-up of the latest work on the freesmartphone.org mobile devices middleware.

Hope to see you there!

Michael Lauer: fso-boot

Mon, 01 Feb 2010 23:59:51 +0000

I’m fed up with booting my Linux-based smartphones like desktop-systems. Two major developments will help me accomplish enormous improvements in boot speed:

devtmpfs — kernel support for the /dev file system
dbus system activation — on-demand launching of dbus-based services

I’m going to carry out the following two tasks in OE:

Writing fso-boot, a small executable written in C, which mounts the filesystems, brings up DBus and (optionally) launches X11
Setting fso-boot as new init process, that way you still have sysvinit and udev in your root file system, but they’re not active unless explicitly asked for

I’ll do that for the freesmartphone.org adaptation for the HTC Dream (T-Mobile G1, Google ADP-1), which I’m running on 2.6.32 (necessary for devtmpfs) — stay tuned for the first benchmarks.

Antonio Ospite: Branding patches with git and vim

Tue, 05 Jan 2010 22:53:31 +0000

In linux kernel development there are informal, and yet quite solid, conventions which apply when sharing patches and collaborating during the —public and undisclosed— phase of code peer-review.

As some of you may know, all the communications about kernel development happen via e-mail, and there are some tools to ease the task of preparing and sending patches; these tools allow some degree of customization, or “branding” like I am calling it in this case. Let's see how to decorate our patches so that their author is more easily recognizable (and acknowledgeable). Obviously all this doesn't apply only to linux, that's just where my experience come from.

Let's step back to summarize a common work-flow used when preparing patches with the git SCM:

# clone some repository
git clone git://git.example.com/repo.git
cd repo.git

# create a new development branch and work on it
git branch new-dev-branch
git checkout new-dev-branch

# Commit operation is inexpensive in git, use it
$EDITOR fileA
$EDITOR fileB
git commit fileA fileB
$EDITOR fileA
git commit fileA

# Prepare patches to be sent
git format-patch -s --cover-letter master..new-dev-branch

# Edit patches to:
#   - add Cc recipients
#   - add annotations after the '---' separator,
#      this does not interfere with commit messages
$EDITOR *.patch
git send-email --to "Some MailingList <some@mailinglist>" *.patch

# When the patches are accepted upstream we can delete
# our local development branch
git checkout master
git branch -D new-dev-branch

Now, the patches we are producing this way have the author figuring as the sender, and are signed off according to the Developer Certificate of Origin, but we can still make them more “personal”, for instance we can:

Add some custom email headers, like Organization or X-Face.
Appending a signature to the cover letter.

Adding custom headers

Using the format.headers option in git you can add any header conforming to RFC2822 into the patches you generate with git format-patch.

I am adding an X-Face header (the source image is attached at the end of the post):

X-Face: z*RaLf`X<@C75u6Ig9}{oW$H;1_\2t5)({*|jhM<pyWR#k60!#=#>/Vb;]yA5<GWI5`6u&+
 ;6b'@y|8w"wB;4/e!7wYYrcqdJFY,~%Gk_4]cq$Ei/7<j&N3ah(m`ku?pX.&+~:_/wC~dwn^)MizBG
 !pE^+iDQQ1yC6^,)YDKkxDd!T>\I~93>J<_`<4)A{':UrE

To set this you can do:

git config --global --add format.headers ''
git config --global --edit

and then add the string in double quotes, remembering to escape characters in the X-Face as git-config(1) Manual Page says:

Double quote " and backslash \ characters in variable values must be escaped: use \" for " and \\ for \.

The following escape sequences (beside \" and \\) are recognized: \n for newline character (NL), \t for horizontal tabulation (HT, TAB) and \b for backspace (BS). No other char escape sequence, nor octal char sequences are valid.

Which in my case gives:

[format]
	headers = "X-Face: z*RaLf`X<@C75u6Ig9}{oW$H;1_\\2t5)({*|jhM<pyWR#k60!#=#>/Vb;]yA5<GWI5`6u&+\n ;6b'@y|8w\"wB;4/e!7wYYrcqdJFY,~%Gk_4]cq$Ei/7<j&N3ah(m`ku?pX.&+~:_/wC~dwn^)MizBG\n !pE^+iDQQ1yC6^,)YDKkxDd!T>\\I~93>J<_`<4)A{':UrE\n"

Now the recipients can see my X-Face in my patches, provided that their MUA can decode it...

Note: please don't copy and paste this X-Face blindly, this is my X-Face, you want to have your very own.

Appending a signature to the cover letter

If you are using the Vim editor to compose the cover letter and annotate patches it is very easy to make it add your signature to the first mail in your patchset.

Download my signature_block.vim into ~/.vim/plugin/ and add these lines to your ~/.vimrc:

  " Append a signature block to cover letters generated with git-format-patch
  autocmd BufRead 0000-cover-letter.patch silent call AddSignature('~/.signature') | w
  autocmd BufRead 0000-cover-letter.patch autocmd! BufRead 0000-cover-letter.patch

Now the first time you open a file named 0000-cover-letter.patch your signature (any text in ~/.signature, in this case) will be appended automatically.

Attached images:

Michael Lauer: GSM Palm Pre on the horizon

Fri, 25 Sep 2009 17:18:50 +0000

As mentioned, the freesmartphone.org team and community has taken the challenge to put the FSO stack on the Palm Pre which is out next month. The goal is to manage a voice call with the FSO stack within four weeks.

The idea behind this is a very important one. With only the Openmoko FreeRunner as a platform, the FSO stack is doomed into oblivion sooner or later, since its a very limited hardware platform — in quantity, but considering the closed alternatives also in quality. Hence, we need to proof that FSO can run on current, competitive hardware — to embrace companies that want to adopt FSO in their niche.

The Palm Pre is currently our major hope — all other hardware being either too closed (yes, this includes the Nokia N900) or already outdated.

Michael Lauer: Vala gains support for server-side async dbus

Sun, 13 Sep 2009 17:44:23 +0000

Something wonderful has happened! Jürg Billeter — mastermind of Vala — pushed support for server-side async dbus into Vala. I hope I didn’t annoy him too much (having continuesly pestered for almost a year now), but the net effect is that we can now continue working on fsogsmd, the Vala implementation of our dbus GSM server (see http://docs.freesmartphone.org for an overview of the API). Yay!

Michael Lauer: LinuxTag 2009

Wed, 24 Jun 2009 05:34:30 +0000

I’m on my way to LinuxTag 2009. Instead of a “real booth” like last year, we settled on a developer table in the hacking area — there we can present our Linux on mobile projects such as

in a more relaxed way — giving room to dive into some technical issues, when interested folks come around.

Find me there, if you’re interested in any of the aforementioned projects. I’ll be there until Friday afternoon.

Michael Lauer: Catching up and plans for 2009

Tue, 17 Feb 2009 18:36:13 +0000

I felt it’s time to recap the stuff that kept me busy the last months and give you an overview over the achievements planned for this year — always focusing the free software movement, of course.

freesmartphone.org

Let’s start with the major project I’ve been working on, the freesmartphone.org project, funded by Openmoko, Inc. FSO grows, and it grows in the right directions. We get more API customers — notably the SHR project and the Paroli project — and refine our API and the reference implementation. The 5th milestone has just been released and apart from a major foobar with read-only partitions, it’s pretty good. We are going to fix this OE-inheritance and release a milestone 5.1 in a couple of days.

fso-abyss (GSM 07.10 Multiplexing)

For some modems — e.g. the TI Calypso (see my previous post on ogsmd and its modems) — until now we have relied on pyneo’s gsm0710muxd. Over the last weeks we found some severe problems (race conditions, buffer overflows) with this though, so I thought I have a shot at developing my own GSM 07.10 Multiplexer.

The result is called fso-abyss and is — as with all our software — available at git.freesmartphone.org under a free software license. The major difference to gsm0710muxd is the architecture (and maintainability). While gsm0710muxd combines talking to the serial ports, the pty’s, handling dbus queries, and doing modem specific things, fso-abyss went a different route.

At the heart there is a minimal protocol engine implementing GSM 07.10. Since there was already something available in Qtopia — even nicely seperated without any external dependencies — I took that one and factored it out in a dedicated project called libgsm0710 (available in git as well). The idea here is that different interest groups can collaborate on getting the protocol engine right, since not everyone wants a DBus frontend such as implemented in fso-abyss. The next step was writing a VAPI file for glueing the protocol engine to Vala (more about that one in a bit), which has been used to develop the upper layers of fso-abyss.

Last but not least, there was the pty implementation, the serial port communications abstraction, and finally the dbus server. The DBus API originally designed in cooperation with pyneo has been enhanced to feature the additional features (only) present in fso-abyss. Apart from the architecture, fso-abyss also can handle virtual serial port signalling, 07.10 test commands, automatic session handling, has a wakeup service, and more. Next up is adding support for the Cinterion mc75i which has some proprietary extensions to GSM 07.10 Basic Multiplexing.

dbus-hlid (DBus High Level Introspection Daemon

Modern DBus APIs are pretty dynamic, i.e. objects can come and go at any time. Depending on the hardware, you may find more or less objects of a certain kind. You can now add infrastructure to query the objects (essentially a duplication of what DBus should provide), or just rely on the existing DBus introspection API. Unfortunately this API is missing some critical features to make it really usable, such as querying objects that implement a certain interface.

So I took the plunge and factored this out of the freesmartphone.org frameworkd, since it has broader use. This is the API for it (as introspected by mdbus):
root@om-gta02:~# mdbus -s org.freesmartphone.DBus /org/freesmartphone/DBus [METHOD] org.freesmartphone.DBus.ListBusNames() -> ( as:result ) [METHOD] org.freesmartphone.DBus.ListObjectPaths( s:busname ) -> ( ao:result ) [METHOD] org.freesmartphone.DBus.ListObjectsByInterface( s:busname, s:iface ) -> ( ao:result )

Here are examples of how you can use it (demonstrated within a Python shell):
>>> hlid.ListBusNames() [ 'org.freedesktop.DBus', 'org.freesmartphone.omuxerd', ':1.21', 'org.bluez', 'org.tichy.launcher', ':1.13', ':1.0', 'org.freesmartphone.frameworkd', ':1.14', ':1.1', ':1.2', ':1.3', ':1.4', 'org.freesmartphone.ogsmd', ':1.6', 'org.freesmartphone.DBus']

>>> hlid.ListObjectPaths("org.freesmartphone.ogsmd") ['/org/freesmartphone/GSM/Device', '/org/freesmartphone/GSM/Server']

>>> hlid.ListObjectPaths("org.freesmartphone.odeviced") [ '/org/freesmartphone/Device/Audio', '/org/freesmartphone/Device/CPU', '/org/freesmartphone/Device/Display', '/org/freesmartphone/Device/Display/0', '/org/freesmartphone/Device/Display/gta02_bl', '/org/freesmartphone/Device/IdleNotifier/0', '/org/freesmartphone/Device/Info', '/org/freesmartphone/Device/Input', '/org/freesmartphone/Device/LED/gta02_aux_red', '/org/freesmartphone/Device/LED/gta02_power_blue', '/org/freesmartphone/Device/LED/gta02_power_orange', '/org/freesmartphone/Device/LED/neo1973_vibrator', '/org/freesmartphone/Device/PowerControl/Bluetooth', '/org/freesmartphone/Device/PowerControl/UsbHost', '/org/freesmartphone/Device/PowerControl/WiFi', '/org/freesmartphone/Device/PowerSupply/ac', '/org/freesmartphone/Device/PowerSupply/adapter', '/org/freesmartphone/Device/PowerSupply/apm', '/org/freesmartphone/Device/PowerSupply/battery', '/org/freesmartphone/Device/PowerSupply/usb', '/org/freesmartphone/Device/RealTimeClock/0', '/org/freesmartphone/Device/RealTimeClock/rtc0']

>>> hlid.ListObjectsByInterface("org.freesmartphone.odeviced", "org.freesmartphone.Device.LED") [ '/org/freesmartphone/Device/LED/gta02_aux_red', '/org/freesmartphone/Device/LED/gta02_power_blue', '/org/freesmartphone/Device/LED/gta02_power_orange', '/org/freesmartphone/Device/LED/neo1973_vibrator']

fso-monitord

While working on implementing GSM time(zone) support for ogsmd, we found we had too few samples, especially since time(zone) information are only sent by few providers all over the world. Moreoever, we missed a generic means to record all the data the frameworkd is sending out via its signals, such as:

Usage statistics
Location Updates
Diagnostic Data

To support this (and more), we came up with fso-monitord, which is available from git as well. fso-monitord logs its data to a flat file format that you can send to us to improve our databases or for debugging. We also figured this would be the best place to add a generic frameworkd watchdog — monitoring all fso components — shutting down or restarting components as necessary and also logging incidents such as API violations.

What’s next in FSO?

For milestone 5.5 (due end of march), we have two major features on the roadmap, namely bluetooth networking (headset profile) and extended PIM support. Milestone 6 will then sport full-fledged networking.

Beyond milestone 6 — apart from one major thing, which I’ll cover in a second — we only have some rough plans, such as revamping or refining the subsystems we’re not perfectly happy with (oeventsd and opreferencesd come to mind). Also, alsa audio scenario handling is broken by design, but this is something we have to take up with upstream.

The freesmartphone.org reference implementation has been progressing incredibly fast. This is partly due to choosing Python as the implementation language (which has been a wise choice) of our DBus APIs. Now you all know that although I truely love Python (I even wrote a book about it) and try to use it everywhere it fits, I’m very well aware that for the future of the freesmartphone.org project, it might be important to come up with a frameworkd reimplementation in a compiled language — to reduce the footprint and squeak every possible bit of performance out of the (embedded) system.

This is why I have decided to encourage a second reference implementation. This one will be written in Vala (I might have mentioned it before, did I?) which is an incredible combination of elegance and performance, featuring a complete lack of any runtime penalties and additional dependencies. It’s simply amazing and I’m seriously thinking about writing an introductionary book about Vala later this year.

Anyways, back to the topic, the first bits of this Vala implementation has landed in the freesmartphone.org git in the form of the very successful GSoC project odeviced, written by Sudarshan S. Stay tuned for some amazing FSO runtime speedups coming in autumn and winter this year to your device.

XeTex

Next to writing software for the freesmartphone.org project, I also found some time to pick up working with my favourite writing tool LyX. LyX, which could be described as a LaTeX frontend, nowadays features integration with the new LaTeX variant XeTex. In contrast to other incarnations such as pdfLaTeX, XeTeX can utilize system fonts such as AAT or OpenType, which are the latest technology in computer-assisted typesetting.

I can now use my “corporate” fonts FF Meta and FF Meta Serif from LyX — amazing!

Conferences

Although still working on cutting down my travelling, I can’t miss some conferences this year. I managed to skip FOSDEM, which made me a bit sad, but I’ll be compensated by attending

and possible some more… This year my main topics will be OpenEmbedded and freesmartphone.org — both dedicated to reducing the fragmentation of Linux-based embedded systems and to ease writing software for mobile devices running free and open source software. I hope we’ll bump into each other at one of these occasions.

Stay tuned!

Michael Lauer: Visiting 25c3 for one day

Sat, 27 Dec 2008 01:29:29 +0000

Although traditionally the Chaos Computer Congress’ schedule is slightly suboptimal for me (12/26th is my birthday), I’m going to be in Berlin from 12/28th to 12/30th and will visit CCC on the 3th day (12/29th). I’m going to attend Harald’s talk about GSM base stations, so if you want to talk to me, just pick me up afterwards.

Stefan Schmidt: TechWeek in Vachdorf

Thu, 12 Jun 2008 15:28:43 +0000

Over the last week, directly after LinuxTag, I was in Vachdorf. If you like to know more about this small village take a look at OSM. Of course we mapped the whole village while being there.

The reason for being there was the TechWeek from Pengutronix, a company from my area doing a lot linux embedded projects for the industry. I already known some of the people working there privately. While being there I got known to the other ones. I must admit that it is a nice bunch of smart people loving what they are doing. What I actually appreciate a lot is their work to get their patches into mainline, even if it costs a lot of time and money. This is a not-so-common practice in the industry linux embedded world.

While hanging out there and having good talks about git, patch handling and submission workflows I spend most of my time working on geting some of the EZX patches mainline ready. We now have a svn branch that contains patches sitting directly on top of the arm git tree pxa branch. While working on this I also started to submit three one-line fixes upstream to get used to the arm-linux workflow. 2 Are already in the git tree, one is acked and waiting in incoming.

I enjoyed the week. Smart people, good food and hacking on stuff you like. Life could be that easy...

Stefan Schmidt: Talk and Radio Interview at the LinuxTag 2008

Thu, 22 May 2008 22:37:09 +0000

Next tuesday I'll be on my way to Berlin for the LinuxTag. It will be some busy days between giving a talk, an interview for Radio Tux and hanging out at the booth of my ex-employer.

Still I'm looking forward to it. This time I hopefully have some time to attend the technically talks. I look at you kernel track. And let Harald de-mystify the security of the micro waves around us.

Stefan Schmidt: SCM changes

Fri, 09 May 2008 14:24:40 +0000

Over the last days I did some changes to the SCMs for my private projects. Some got migrated from svn to git. Also some git repos changed the location. Please refer to the overview websites if you run into trouble:

http://svn.datenfreihafen.org/$PROJECT_NAME

http://git.datenfreihafen.org/

Stefan Schmidt: Recent OpenEZX progress

Thu, 08 May 2008 23:27:11 +0000

Since I left OpenMoko I have found some time to work on OpenEZX again. There are two nice things that happened since then.

The first one was that I got an 18bpp patch for all the second generation devices working. At least pxafb and fbcon are working fine now. I still need to test X more. :) The patch was from the gumstix patchset. Thank you guys.

The second was the boot_usb 0.2.0 release. We use this little tool a lot and SVN is stable most of the time. Especially after Daniel Ribeiro added support for initrd, commandline and setting the machine ID a release was needed.

Stefan Schmidt: OpenMoko Framework Initiative goes live

Thu, 08 May 2008 22:40:32 +0000

Mickey already blogged about it. This is something we talked about a lot lately. Sometimes frustrated sometimes with hope. It is something we never got right since the beginning.

Ease the development of new applications and services. Build your kick ass stuff on top of a good fundament. And if it does not give you what you need, extend it. It's not like other commercial frameworks where you have to deal with what you get. It's open, take it, extend it, send patches. :)

Let's hope the framework team get the resources they need for getting it done. I also have some private ideas how to contribute here. Once I have something ready I let you know.

As code is better then words, take a look at their git repos.

Stefan Schmidt: Which wifi chip drives the Spectec SDW-82{1,2,3} SDIO cards?

Mon, 10 Dec 2007 16:28:12 +0000

Dear Lazyweb,

I'm interested in SDIO wifi cards that could be supported within a 2.6 linux kernel. Using them to add wifi connectivity to my EZX devices would be nice. EZX devices are based on PXA270 with full SD or microSD slots.

It would now be interesting to know if the Spectec SDIO cards are based on the Atheros 6000 SDIO chip. OpenMoko is working on a GPL driver for this chip. That would hopefully reduce the amount of work to get it running on other devices.

So anybody knows more about the chip Spectec use?

regards

Stefan Schmidt

Stefan Schmidt: Navilock BT-451 under linux and navit

Thu, 15 Nov 2007 20:58:34 +0000

Bluetooth GPS reciever just rock. Small, easy to use, no cables and useable with different devices. Once my day-by-day gadgets and notebook have all one build-in I can get it of it, but that will take some time.

So the toy is called BT-451 and has a u-blox ANTARIS4 SuperSense chip build-in. Getting it to work is easy:

hcitool scan
rfcomm connect hci0

After this you have a serial port (perhaps /dev/bluetooth/rfcomm/0) where all the NMEA data comes in. Just give this one to gpsd and you can use it in multiple applications. I also heard that this is even easier with gypsy. No more need to deal with rfcomm yourself. That screams for a test once it is in debian.

There is some more stuff I like about the BT-451. Once it had a fix I was able to put it in a pocket of my jacket, sit in my car and it still gets the position. Tested with driving home with my notebook on the seat next to be and tracking the drive with navit. Daniel also discovered that the USB plug is not only for charging, but also shows up as ACM modem and spies out the NMEA on /dev/ttyACM0. And once connected via USB it also works without a battery.

The above mentioned navit is one of the most promising stuff I like to use regulary with the GPS. It's a navigation system with a routing engine. Not only download maps and show them, but do real routing with vector based maps. As we all know maps are problematic. OpenStreetMap is working on this problem. Until this is useable everywhere I like to have some commercial maps I can route with on my linux system. Don't expect some vendor has got this ready. :(

But FOSS has, as almost, an answer for me. Navit support different vector maps for commercial CDs. Just buy such one, copy the files and navit handles the rest. Great.

No I just need to test the navit setup on my Neos. :)

Stefan Schmidt: Catching up with OpenEZX again

Mon, 03 Sep 2007 12:15:44 +0000

It's a long time since I really spent some hours on doing OpenEZX only work. A lot great stuff happened since then:

Alex Zhang worked out some of the differences on the sweet A1200 device. He offered patches to get at least usbnet working with the EOC chip and better support for the 18bpp framebuffer and touchscreen.
Daniel Ribeiro finally got the ezx-asoc driver working and was able to do a voice call. The first with our 2.6 based kernel.
Antonio Ospite made some nice progress in getting the GPS information on the gps-enabled A780's from mux14 and worked out the used protocol. This mean we are close before having full NMEA output from it and feed it into gpsd which makes the whole informations available to other applications.

Motivated from all this great work Mickey and me spent more or less a full day with OpenEZX work. Catching up with the newest stuff and getting OpenEmbedded integration into an even better shape as it already was. (Thanks for koen on taking care of this most of the time).

Besides this there was some ongoing work to make OpenMoko more useful on devices with QVGA screens. Based on the work Philipp Zabel we started an QVGA theme. Some artwork still needs a bit rework but it looks already pretty good. Mickey made some pictures and will link them from his on blog entry I guess.

Once wyrm has merged the outstanding patches into the svn and we have done more work on the QVGA theme we will go for an snapshot release for with kernel and rootfs.

Stefan Schmidt: Mobile Developer Days 2007 are over

Mon, 03 Sep 2007 11:53:16 +0000

Currently I'm with Mickey in a train back to Germany from Denmark. The last days I participated the Mobile Developer Days 2007. In contrast to the most other conferences I attend this one was not only about FOSS but more about developing software for mobile devices. Write applications in Python, Java, Open C, examples for location enabled applications, VoIP and rapid prototyping for artist are just a small extract of the program.

Mickey and me gave our talks about Open{Moko,EZX} and presented the community view in discussions.

Besides the different focus the event was also a lot smaller then the ones I usually attend. Around 40 people. So most of the attendees were speaker as well. Mixed up with the fact that many of the people are doing research in this area gave the conference a academic touch.

In the last weeks Mickey and me pondered if we really should attend as our travel and working schedules are pretty full, we did not got plane tickets and had to go two 10 hours train rides, etc.

In the end I'm happy we decided to go. Besides the talks especially the small group of people was a good place for interesting and informative discussions. Coming from the FOSS world and doing not much business besides OpenMoko it was quite interesting for me what people with a more commercial background are doing with mobile devices and what benefits and drawbacks they see in using FOSS for example.

During the days and nights we had some working session with normal OpenMoko stuff but also some hours on catching up with OpenEZX stuff. But that's another blogpost.

Stefan Schmidt: Conferences ahead. Going to RMLL and GUADEC.

Sat, 07 Jul 2007 17:02:08 +0000

After having a busy time with university, OpenMoko and getting my partime freelance going I now are getting more relaxed and looking forward to the next two weeks which I will spend mostly on two conferences.

Next week starts with my flight to France. I'm giving a talk about free software on mobile phones. It covers mostly OpenEZX and OpenMoko, but also tries to give an overview about other projects in this area. As my talk is at the first day I'm looking forward for the other talks, visit Amiens and doing having some time for OpenMoko related work.

Coming back from France means having a half day and a night at home and jumping over to England again. GUADEC will be full of meeting people, having fun and making plans for the upcoming month. I'll fly together with Daniel and his girlfriend and meet up Mickey in Birmingham. But besides OpenMoko related discussions I really looking forward to meet people behind Gnome.

Harald Welte: My reason for being away from OpenEZX

Mon, 04 Dec 2006 01:00:00 +0000

This post should have been posted months ago, but only since very recently I'm allowed to talk about the real reason. You might have read about it, if you read my full blog, but I'm posting this again in the 'a780' category to make it appear on planet.openezx.org

I've been hired to be key element in the design and implementation of the OpenMoko platform and the first device it supports: The Neo1973 phone. While there is no provision in the contract preventing me from working on the OpenEZX project at all, this assignment has just sucked up all available time like a vacuum cleaner.

To OpenEZX developers, users and supporters: Please be assured that most of the work done on OpenMoko will eventually benefit OpenEZX quite a lot. So please stay tuned, and concentrate on the low-leve device-specific issues that need to be resolved with the Motorola EZX hardware :)

Harald Welte: A1200 LSM / SELinux update

Fri, 15 Sep 2006 02:00:00 +0000

James Morris got quite interested when I told him that the A1200 uses SELinux to lock out the users (owners!) from their own phone ;) So we both did some further analysis, and it turned out that Motorola had actually released the source code to their own policy engine (MotoAC) with the A1200 kernel sources on opensource.motorola.com, whcih is good.

Still we didn't understand why you would use an unmaintained, at least three years old version of SELinux to base a forked policy engine on it - but obviously this is the world of Free Software and everybody is allowed to make his own decisions.

I've also catched up with the A1200 in general and found out that people have already managed to flash their own kernel into it, whcih is great. I wish I had more time to put into OpenEZX at this point, turning it into something that is actually useful. HINT: Skilled volunteers needed.

Pavel Machek apparently got one and is annoyed by the restrictive SELinux policies. By now I'm quite sure that it's not all too difficult to get rid of them ;)

Harald Welte: ROKR E2 Linux Phone review

Fri, 01 Sep 2006 02:00:00 +0000

There has been an extensive review of the Linux based Motorola ROKR E2 phone at osnews.com.

Harald Welte: Wanted: Author and/or sources for EZX "qonsole" application

Tue, 29 Aug 2006 02:00:00 +0000

The original author of the KDE "Konsole" program, Lars Doelle, is actively looking for the Author and/or the source code of the "qonsole" program, a terminal program for the Motorola EZX platform that is apparently derived from GPL licensed Konsole.

Since the legal status of qonsole never was clear, I always refused to host it on any of the OpenEZX project resources. I didn't really know of any GPL violation going on, but had a somewhat strange feeling.

If any of you has information on where the qonsole program originates, please make sure to inform either Lars or me about it. We know by now that it appears to originate from some chinese or singapore mobile phone forums.

It's good to see more software authors of GPL licensed programs actually caring about enforcement of their license :) I sincerely hope this can be resolved and qonsole either distributed in gpl-compliant way, or a re-implementation be found/made.

Harald Welte: Motorola ROKR E2

Mon, 10 Jul 2006 02:00:00 +0000

I've found the ROKR E2, which is yet another Motorola Linux GSM/GPRS phone exclusively sold in china so far. Apparently since June 22nd, so it's a quite new thing. It's very different from the A7xx/E680x series in that it doesn't have a touch screen, but many more buttons. Also, it features a full-size SD card slot, which makes it theoretically SDIO compatible (I'm pretty sure they use some SDIO compatible SD host controller in there).

Let's see whether I can work with the Chinese language firmware. I already found out how to get it into boot-loader flash mode (by pressing the camera button on the upper right side while powering the device up). It looks completely different than the blob on the A780/E680, but that doesn't really mean anything.

As of now, I don't have any technical proof that the device runs Linux. I'll probably not find time to play with this toy before I get back to Germany. But if anyone has hints or further information on how to dig deeper into the ROKR E2, don't hesitate to send me an email about your findings.

Harald Welte: Motorola A728 and A732

Sat, 08 Jul 2006 02:00:00 +0000

Just next to my hotel, there is a book store that also sells mobile phones. Among the Motorola models are the A728 and A732, both Linux based. They're about 160EUR each. I don't yet know whether that is a good price, but now after checking with some online shops I think it is.

So I guess I'll get one of each in order to investigate whether we can hack them from an OpenEZX point of view. Also, this finally allows me to obtain proof whether they're still shipping GPL incompliant or not.

I'll continue to look for an A768 and E895. Let's see whether I'll find some time to do some more serious 'shop browsing'.

Harald Welte: Some small A780 progress

Fri, 23 Jun 2006 02:00:00 +0000

I've continued my work on porting the ts07.10 from Motorola's mux_cli to 2.6.x. It now compiles, although I have no idea whether it actually works as expected.

Since Linux 2.5/2.6 has undergone quite some sophisticated changes in both scheduling/context area (no more struct task_queue) as well as the tty layer (dynamically allocated and managed flip buffers, etc), the task has been a bit more challenging than the usual copy+paste+minor_fixup task.

I'll also be releasing the -ezx6 kernel soon (2.6.17 based) in the next couple of days, where I plan to merge mickey's various driver bits (LED, backlight, keypad fixes) and the above-mentioned mux_cli.

Harald Welte: Interview on OpenEZX at LWN.net

Mon, 12 Jun 2006 02:00:00 +0000

For those interested, lwn.net is featuring the first part of an interview withe me on the status of the OpenEZX project. The way longer pert of the interview on gpl-violations.org will be posted within the next two weeks.

Now let's hope that I'll be able to fix that nasty netfilter bug that I'm hunting for weeks now and get back to OpenEZX kernel hacking...

Harald Welte: Not working on OpenEZX at the moment

Wed, 07 Jun 2006 02:00:00 +0000

Due to lots of other "real life" and "real work" constraints, I'm not able to work on OpenEZX for at least another week :(

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

Sat, 27 May 2006 02:00:00 +0000

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.

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

Fri, 19 May 2006 02:00:00 +0000

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.

Harald Welte: Motorola launching opensource.motorola.com

Mon, 15 May 2006 02:00:00 +0000

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)
Power Management
Minor differences in boot loader / kernel handover
SE Linux

Harald Welte: A full day of EZX driver development

Sun, 14 May 2006 02:00:00 +0000

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.

Harald Welte: Debian sarge root filesystem image for EZX phones

Fri, 12 May 2006 02:00:00 +0000

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.

Harald Welte: OpenEZX virtual host running

Thu, 11 May 2006 02:00:00 +0000

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.

Harald Welte: Working on Bluetooth and GPRS/GSM support

Thu, 11 May 2006 02:00:00 +0000

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.

Harald Welte: A780/E680: SPI driver using hardware SPI controllers working

Sat, 29 Apr 2006 02:00:00 +0000

So apparently there is no obvious reason for Motorola's driver using bit-banging rather than the controllers inside the PXA270. I now have a modified Motorola driver on 2.6.16.5 running that uses the SPI controller for the bus to PCAP2. Getting my own driver running should therefore be quite fast now.

I've also hacked a bit on the keyboard side, although it's not working yet.

Harald Welte: Working on new SPI/SSP drivers for OpenEZX kernel

Thu, 27 Apr 2006 02:00:00 +0000

One of the fundamental interfaces on the Motorola EZX phones is SPI, which interconnects (among others) the PCAP2 peripheral with the PXA270. Motorola ships their 2.4.20 kernel with some ugly piece of spaghetti code driver for it. Apparently they've had difficulties driving the PXA27x SPI controller, and in the end decided to just 'bit-bang' the signals over GPIO. Obviously that's inefficient and CPU-intensive. I hope there is no real hardware problem preventing the use of the embedded SPI controllers.

First I started writing a driver against arch/arm/mach-pxa/ssp.c, only to discover later that this code actually predates (and therefore doesn't use) the generic drivers/spi/ interface. Since I'm a fan of generic interfaces, I chose to write a PXA generic driver for the drivers/spi interface, plus some EZX specific glue code for it.

One of the interesting bits is that the PCAP2 can interrupt the PXA, and it then acts as an external interrupt controller, whose registers you can access over SPI. So a PCAP2 interrupt can mean that some touch-screen event happened, that the headphone, USB or microphone jack state has changed, etc. All those various real interrupt sources need to be fed to individual distinct drivers (audio, touch-screen, USB). The Motorola kernel uses an ugly kludge of callback functions that those drivers can register with the SSP/SPI driver.

So in my new driver, I choose to actually model that bit of PCAP2 functionality as an external interrupt controller. This way the actual sound/touch-screen driver can just do request_interrupt() like they usually do. However, this means that I need to access SPI from within hardirq context, which again doesn't mix well with the architecture of the drivers/spi code (which is asynchronous and queues requests). So I need to implement a couple of synchronous SPI functions in addition to that.

This is now a lot of code, and I'm about to test and debug it, which is expected to be time-consuming and boring. I'll post a status update as soon as there's more information.

Harald Welte: OpenEZX: USB Ethernet support working

Sat, 22 Apr 2006 02:00:00 +0000

After lots of hacking at FISL 7.0 in Porto Alegre, I've managed to get the PXA27x USB device controller to work in USB Ethernet emulation to work. I can now actually ping and telnet to the 2.6.16.5-running E680, using a debootstrapped Debian/ARM on SD-Card.

I'll publish the patches in one or two days, when everything has stabilized a bit, and the debugging code has been removed.

Also, at the event here, I've managed to convince quite a number of Free Software people that those Linux smartphones are actually quite interesting toys. Most notably, Keith Packard of Xorg fame has indicated he would probably be getting one and working on a lightweight UI. This motivates me even more to have a stable and fully working kernel environment finished soon.

Harald Welte: State of OpenEZX 2.6.x kernel development

Mon, 17 Apr 2006 02:00:00 +0000

During my two days of EZX phone hacking, I've made significant progress. Probably the most important discovery was how to get a serial console on the USB plug, enabling other people to do further kernel development without physically modifying the phone - but it's still a long way to go.

A current list of TODO's:

find out why kernel doesn't boot with CONFIG_IWMMXT
find out why E680 SD/MMC works, but not A780 TransFlash
debug and fix pxa27x_udc in order to provide usbnet (nfsroot!)
debug and fix mtd support in order to be able to access system flash
port and cleanup video and sound drivers
port Motorola-specific SSP/SPI drivers into 2.6.x generic SPI stack
port all the driver specific dpm bits from Motorola's 2.4.20 to 2.6.x
clean up the already working keypad drivers
finish re-implementation of mux_cli and grpsv modules
look into re-implementing the proprietary flash fs drivers, though I don't think that is particularly important, we could run our code 100% on SD/TransFlash
create a modified bootloader that allows for multi-boot configurations. It could actually include SD/TF support for booting kernels from there.
check how the other (later) Motorola Linux smartphones differ and merge their device-specific code into our 2.6.x kernel tree
last, but not least, we need to do something about userspace. I'm not a GUI guy at all, and I haven't yet thoroughly investigated all the existing projects like OPIE, etc. I'm sure once the hardware support is there, some more GUI-savvy people will do something in that area, though.

So why am I stating this here? Because it's up to _you_ to help and take care of one of these tasks if we want to see the dream of having a fully-free software E680/A780 before they get phased out ;)

Harald Welte: 2.6.16.5 boots on EZX phones

Mon, 17 Apr 2006 02:00:00 +0000

I've finally managed to get a 2.6.x kernel running on the Motorola A780 and E680. Apparently the problems I encountered are part of 2.6.14 (which was current mainline when I started the port). After merging my patches into 2.6.16.5, everything suddenly worked fine ;)

So what I've got now:

kernel 2.6.16.5 booting on both A780 and E680
USB host controller towards Neptune BP working
USB device controller partially working
MTD support for all flash partitions
SD/MMC support on E680 (TransFlash on A780 not working yet)
Framebuffer working on both models, with nice 4x6 tiny font

The main obstacle now is that TransFlash on the A780 is not working yet. The A780 is actually more important than the E680. For some strange reason, all the response bytes from the TF card appear to be zero (at least that's what the response FIFO of the PXA27x embedded SD/MMC controller reports). I've already tried a lot, but am a bit clueless after many hours of trial and error :(

Harald Welte: Running a serial console on the A780

Sun, 16 Apr 2006 02:00:00 +0000

After about half a day of trial and error (which was related to a totally different problem, as it turned out), I now have a 2.4.20-based kernel with working serial console for my A780. Unfortunately the console requires soldering four wires onto test pads of the PCB - something that I achieved with 0.1mm diameter magnet wire (Kupferlackdraht for you Germans). The magnet wires are thin enough to get them through the TransFlash slot to the outside, without having to modify the case.

If you're interested in a bootup log captured from the STUART, check this one.

The rest of the day was spent debugging why my (still 2.6.14 based) kernel doesn't want to boot on the machine. As it turns out, booting stops somewhere in the early initialization after head.S has called decompress_kernel(). Debugging this problem has also caused me to actually write some ARM assembly code. For years I'm reading and debugging ARM code, but I've never actually written ARM asm from scratch. So my assembly code now prints one character for every stage of the booting process (ABCDEFGHI) and then stops. At the time the C code should print its first character, the device is already gone. So maybe something with the setup of the registers according to C calling convention, or setup of stack/heap is erroneous.

Interestingly, that startup code has not really changed all that much from 2.4.20 (which runs) and my 2.6.14 based kernel.

It's not unlikely that I'm [again] hunting a totally different problem. I'll probably merge my patches into 2.6.17-rc1 and see whether that works...

Harald Welte: Obtaining Asian Motorola EZX phones in Europe

Tue, 11 Apr 2006 02:00:00 +0000

A couple of days ago, I was looking for a way to obtain Motorola Linux Smartphones in Europe, i.e. those plenty of models that are not officially sold anywhere but China and other areas of Asia.

I've now found a suitable importer specialized in importing Asian phones into the European market. In case you're interested, feel free to contact me for more details. The phones range between EUR 180 and EUR 300, but there's a minimum order of five phones. I'll probably be ordering around early may.

Harald Welte: planet.openezx.org launched

Sat, 08 Apr 2006 02:00:00 +0000

In the tradition of my main project netfilter (which has a planet.netfilter.org, I've now also opened a planet site for the OpenEZX project at planet.openezx.org.

This should give users the ability to stay up to date with current developments in the Motorola Linux smartphone hacking community.

If you know of any feeds that I should add to this planet, please let me know