Hackable 1

khorben: What's going on?

khorben@defora.org (khorben) — Mon, 30 May 2011 11:59:10 +0000

Almost two months without a post?

Well, actually, I meant to post a few notes about how the Gtk+ 2.0 to 3.0 migration went for the DeforaOS project, but ended up forgetting about it. On the other hand, I've been busy debugging and polishing the user interface, and hope to release and package these changes soon.

Speaking of which, I haven't given up on releasing hackable:1 dse2, the smartphone environment based on DeforaOS for the GSM stack and user interface. It's just been a pain to iron out the different issues encountered, with a new one appearing every time I managed to fix something. Regardless, it's looking promising, and I've been able to give and receive phone calls again.

On the security front, the asm project (and its disassembler) is now waiting to be integrated into UWfirmforce, which would also benefit from an updated user interface (and reporting facility even). It'll take a few more coding nights though.

This is also because according to the DeforaOS roadmap, I am focusing on a (re-)implementation of its main functionality: the distributed computing framework. Getting the design right is a challenge in itself already, but I am fairly confident to be able to commit the first working lines of code within a few more weeks.

Looking forward to all of these :)

khorben: Calibrating the HTC TouchPro's touchscreen

khorben@defora.org (khorben) — Wed, 06 Apr 2011 13:21:48 +0000

For the record, and because it gave me a hard time, here is how I could finally calibrate the touchscreen of an HTC TouchPro running hackable:1:

# rm -f /etc/pointercal
# export TSLIB_FBDEVICE=/dev/fb0
# export TSLIB_TSDEVICE=/dev/input/event3
# export TSLIB_CALIBFILE=/etc/pointercal
# export TSLIB_CONFFILE=/etc/ts.conf
# ts_calibrate

And the winner is:

# cat /etc/pointercal
-626 -42507 37731912 53487 254 -5420672 65536

I had to do this while running X, otherwise I only got trash on the framebuffer at best, and then nothing seemed to really happen.

Initially, I tried to find a way to understand and convert Android's data to the values expected by tslib. I started with the latter, and eventually gave up as these values seemed poorly documented at best: it essentially consisted in a couple mailing-list posts basically saying that "no, you should not generate calibration values yourself". But what if I have known, valid data?

Anyway, I could finally find some hints there:
http://doc.trolltech.com/4.3/qwscalibratedmousehandler.html#transform

And then in the source code for tslib:

plugins/linear.c, struct tslib_linear:
25 struct tslib_linear {
26         struct tslib_module_info module;
27         int     swap_xy;
28 
29 // Linear scaling and offset parameters for pressure
30         int     p_offset;
31         int     p_mult;
32         int     p_div;
34 // Linear scaling and offset parameters for x,y (can include rotation)
35         int     a[7];
36 };

plugins/linear.c, mod_init():
132         /*
133          * Check calibration file
134          */
135         if( (calfile = getenv("TSLIB_CALIBFILE")) == NULL) calfile = defaultcalfile;
136         if(stat(calfile,&sbuf)==0) {
137                 pcal_fd = open(calfile,O_RDONLY);
138                 read(pcal_fd,pcalbuf,200);
139                 lin->a[0] = atoi(strtok(pcalbuf," "));
140                 index=1;
141                 while(index<7) {
142                         tokptr = strtok(NULL," ");
143                         if(*tokptr!='\0') {
144                                 lin->a[index] = atoi(tokptr);
145                                 index++;
146                         }
147                 }

plugins/linear.c, linear_read():
53                         xtemp = samp->x; ytemp = samp->y;
54                         samp->x =       ( lin->a[2] +
55                                         lin->a[0]*xtemp +
56                                         lin->a[1]*ytemp ) / lin->a[6];
57                         samp->y =       ( lin->a[5] +
58                                         lin->a[3]*xtemp +
59                                         lin->a[4]*ytemp ) / lin->a[6];

Credits go there:
http://automon.donaloconnor.net/installing-tslib-and-calibrating-it/83/

khorben: hackable:1 welcomes a new developer: Trim

khorben@defora.org (khorben) — Sat, 02 Apr 2011 14:26:00 +0000

I am glad to announce the arrival of a new developer within the hackable:1 project: Adrien Dorsaz, aka Trim. He has already contributed improvements to the wireless configuration interface (wicd) and calendar application (dates), besides many helpful bug reports!

Welcome Trim, with you the imminent dse2 release has gotten only better. Cheers!

khorben: hackable:1 builds and provides a package repository for Maemo

khorben@defora.org (khorben) — Sun, 20 Mar 2011 21:18:47 +0000

I had been thinking about testing the DeforaOS graphical applications [1] on my N900 [2] for a while, but remained concentrated on the Openmoko Freerunner [3] and hackable:1 [4] until it was satisfying enough. With the upcoming dse2 [5] release being in a good shape [6], I decided to have a short look anyway.

My first reaction was very much like when I checked Maemo [7] back in 2008:

you need me to install scratchbox, which only supports i386? [8]
the documentation links to external sites (Debian packaging) but doesn't explain how to actually build a package? [9]
you prevent me from navigating the repositories freely? [10]

But this time, with the lessons learned while re-implementing strap:1 and cross-compiling Debian packages, I figured I could do it another way: with hackable:1 itself. Here is how.

First, I determined how to populate the cross-compilation environment with the proper binaries. I added trunk/build/strap1/hostname/n900.nokia.maemo, containing:

ENVIRONMENT=GNOME #it's empty at the moment
VERBOSE=1
DEBIAN_MIRROR=repository.maemo.org
DEBIAN_REPOSITORIES=sdk/free
DEBIAN_VERSION=maemo5.0
DEBIAN_SOURCES="deb http://$DEBIAN_MIRROR/ $DEBIAN_VERSION $DEBIAN_REPOSITORIES"
VENDOR=Nokia
MODEL=N900
PURPOSE=phone

This also required handling Nokia-N900-phone as a valid profile, in trunk/build/strap1/profile/Nokia-N900-phone:

ARCH="armel"
STRIP="arm-linux-gnueabi-strip"
#this device is a phone
. "strap1/profiles/include/phone.include"
#add bluetooth support
. "strap1/profiles/include/bluetooth.include"
[...]

(and so on for the rest of the hardware capabilities)

Once this added, this simple command was enough to populate the environment:

# ./strap1.sh DESTDIR=/usr/arm-linux-gnueabi HOSTNAME=n900.nokia.maemo install

There I was. It was even faster than with a regular Debian target, since there are way less packages available to parse. But did I miss installing the development packages? Totally. Yet it doesn't matter:

# ./strap1.sh DESTDIR=/usr/arm-linux-gnueabi HOSTNAME=n900.nokia.maemo \
  PACKAGES="libssl-dev libgtk2.0-dev" install

And seconds later, I had these two installed as necessary, along with their dependencies of course. Sweet, but we're not done yet. Let's build actual packages:

$ cd trunk/packages
$ ./packages.sh DEBIAN_ARCH=armel DEBIAN_VERSION=maemo libsystem
$ ./packages.sh DEBIAN_ARCH=armel DEBIAN_VERSION=maemo libdesktop
$ ./packages.sh DEBIAN_ARCH=armel DEBIAN_VERSION=maemo editor

Unfortunately, even with the correct binaries and packages definitions installed in the cross-compilation environment, dh_shlibdeps failed to grab the right dependencies. Disabling it during cross-compilation was enough to do the trick (commenting it out in debian/rules from the diff file).

Time to add this new repository into the N900 [11], through "Application manager"->"Catalogs"->"New" [12]:

Catalog name: hackable:1
Web address: http://build.hackable1.org/debian
Distribution: wip-maemo
Components: main

Open a terminal, gain root privileges:

# apt-get update
# apt-get install libsystem0 libdesktop0 editor
[...]
$ editor

And it works. I repeat: sweet.

Update:

you can install the following package to fix the missing icons: http://repository.maemo.org/extras-devel/pool/fremantle-1.3/free/f/fixpr12icons/fixpr12icons_1.0+maemo-0_all.deb
this page is more exhaustive about the packaging process in Maemo: http://wiki.maemo.org/Packaging

[1] http://www.defora.org/os/wiki/3426/Graphical-environment
[2] http://maemo.nokia.com/n900/
[3] http://wiki.openmoko.org/wiki/Neo_FreeRunner
[4] http://trac.hackable1.org/
[5] http://trac.hackable1.org/trac/wiki/AvailableVersions/dse2
[6] http://www.defora.org/os/download/download/3512/dse2-Screenshot-2.png
[7] http://www.maemo.org/
[8] http://scratchbox.org/documentation/user/scratchbox-1.0/html/installdoc.html#AEN47
[9] http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing
[10] http://repository.maemo.org/dists/maemo5.0/
[11] http://people.defora.org/~khorben/share/n900/Screenshot-20110321-000354.png
[12] http://people.defora.org/~khorben/share/n900/Screenshot-20110321-000410.png

khorben: New unofficial beta release of hackable:1

khorben@defora.org (khorben) — Sun, 13 Mar 2011 20:27:55 +0000

I just announced the availability of the first beta version for dse2, the DeforaOS Smartphone Environment [1] as found in hackable:1 [2]:
http://lists.hackable1.org/pipermail/hackable1-dev/2011-March/001686.html

I don't think I have much to add to this; except on a personal level maybe, which would be appropriate here I guess.

When I was first offered an Openmoko Neo1973 in summer of 2007 [3], I think I was both excited and disappointed about the device. It was a very promising opportunity for Open Source and telephony, at a time where only few devices were known to be usable with alternate and free environments. But I really did not like the look & feel of the device, or the state of the software running on it. Little did I suspect that I would spend so much time and energy with its successor, the Freerunner [4].

This happened first while I was working with Bearstech [5] on the promotion of hackable devices [6]. There, we focused on supporting what seemed to be the most viable solution at the time: the Om2007.2 stack. This part was a very frustrating experience, which I have mentioned already [7].

And now, I begin to feel much better about the whole thing. First, the Openmoko platform is still alive: thanks to Nikolaus Schaller of Golden Delicious [8], and of course thanks to the openness of the platform, a third-party hardware upgrade is available. Then, well, Google happened, Android is everywhere, and many more devices are usable with Open Source software.

But what's more, I am beginning to feel better and better about the DeforaOS project as a whole. This was a painful yet fantastic motivation to bring it where it is today. I had even decided to mostly give it up about a month ago, at least for a while. But the deadline [9] I set for the project on improving the user environment is almost matched now [10]. Better, I have great plans for the following one [11]. I may even go to University again [12]! This is not without reminding me about my own description of myself :) [13]

So yeah, four years later and much to my own surprise, I am getting increasingly comfortable and curious about using the dse2 release as a daily phone. It can only inspire me to push it to the next level :) [14]

To conclude:

special thanks to the Neo1973-gift-maker!
all of this is completely futile, and most of my thoughts are going to people of Japan, Ivory Coast, France and Libya right now.

[1] http://www.defora.org/os/wiki/3438/DeforaOS-Smartphone
[2] http://trac.hackable1.org/
[3] http://events.ccc.de/camp/2007/Intro/
[4] http://wiki.openmoko.org/wiki/Neo_FreeRunner
[5] http://www.bearstech.com/
[6] http://hackable-devices.org/
[7] http://people.defora.org/~khorben/place/blog/88/The-DeforaOS-smartphone-environment
[8] http://www.goldelico.com/
[9] http://www.defora.org/os/wiki/display/3324/Roadmap
[10] http://www.defora.org/os/wiki/3426/Graphical-environment
[11] http://www.defora.org/os/wiki/3427/Distributed-environment
[12] http://www.net.t-labs.tu-berlin.de/teaching/thesis/#network_virtu
[13] http://people.defora.org/~khorben/place/wiki/12/About
[14] http://www.defora.org/os/wiki/display/3323/Planned-developments

khorben: Over 10 thousand commits

khorben@defora.org (khorben) — Sun, 13 Mar 2011 12:02:26 +0000

According to Ohloh [1], I just went over 10,000 commits [2]:

DeforaOS 8173
hackable:1 1350
RunningBear 483
Whitix 13

for a total of 10,019.

Now let's see if it was worth the effort...

[1] http://www.ohloh.net/
[2] http://www.ohloh.net/accounts/khorben/widgets

khorben: Resurrecting RunningBear

khorben@defora.org (khorben) — Sun, 27 Feb 2011 01:27:48 +0000

Today (or tonight) I have finally managed to import most of the fixes pushed into DeforaOS since the last meaningful commits to the RunningBear project (around December 2008 I guess). This was motivated by a few reasons:

a bug report on memchr() in the DeforaOS libc [1]
NetBSD booting on N900 [2]
good progress on DeforaOS [3] [4]
same on hackable:1 [5]

Unfortunately, it still isn't good enough to support Xynth's user interface on the system [6]. But it's getting close enough, and I think the missing parts are:

support for setjmp() and longjmp() in the libc;
same for signal(), checking alarm() too;
for NetBSD, importing and adapting Linux' <sys/kd.h> to match the wscons API.

These are three hairy issues to tackle, but nothing's too hairy for a RunningBear (hey it's 3 am I'm allowed).

With luck RunningBear could actually begin its career running on both the Openmoko Freerunner and Neo1973, HTC TouchPro and Nokia N900 smartphones, based on either Linux or NetBSD kernels. I'll try to do it with hackable:1 first though :)

Last but not least: RunningBear is on Ohloh now! [7]

The links:
[1] http://www.defora.org/os/project/bug_display/3474?bug_id=40
[2] http://www.netbsdfr.org/?p=1993
[3] http://www.defora.org/os/news/3478/Summary-of-latest-releases
[4] http://www.defora.org/os/news/3484/Release-party-for-RunningBear
[5] http://www.hackable1.org/
[6] http://xynth.sf.net/
[7] http://www.ohloh.net/p/RunningBear

khorben: Compiling Android applications on NetBSD

khorben@defora.org (khorben) — Thu, 24 Feb 2011 15:48:27 +0000

As mentioned previously, I gave a try to the Android SDK recently, and was even able to package a few applications on my NetBSD-based development workstation (amd64 architecture). I am listing the most important steps here; for the actual instructions, please refer to http://developer.android.com/sdk/installing.html

Sun Java SE 6

First of all, you need Sun's Java development environment installed and running. It is readily packaged in pkgsrc (as Linux i386 binaries), in lang/sun-jdk6:

# cd /usr/pkgsrc/lang/sun-jdk6
[...]

First, you'll have to accept both licenses of the JRE (runtime) and JDK (development) packages; to do so, add the following lines to /etc/mk.conf:

ACCEPTABLE_LICENSES+= sun-jre6-license
ACCEPTABLE_LICENSES+= sun-jdk6-license

Then, you'll have to download the generic Linux i386 packages yourself:

jre-6u22-linux-i586.bin
jdk-6u22-linux-i586.bin

They are both found at http://www.oracle.com/technetwork/java/archive-139210.html . When done, move them to where pkgsrc stores downloaded content, typically /usr/pkgsrc/distfiles.

Back to /usr/pkgsrc/lang/sun-jdk6, install it as usual:

# make install
[...]

This will install a complete Linux i386 binary emulation environment, if you didn't already have it installed (like for Adobe's Flash player). At this point, if the checksum of any file is wrong, then make sure to delete it and download it again: they are correctly referenced in pkgsrc, no need to insist.

Eclipse IDE

The next important thing is to obtain the Eclipse IDE (version 3.5 or earlier). An old version is already packaged in devel/eclipse (3.0.1), but it will certainly not be enough to get the SDK to work. The 3.6 Linux build of Eclipse ran perfectly though, as downloaded here: http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/helios/SR1/eclipse-java-helios-SR1-linux-gtk.tar.gz

It is then enough to extract and run the environment directly:

$ tar xzf eclipse-java-helios-SR1-linux-gtk.tar.gz
$ cd eclipse
$ ./eclipse

Create and choose a workspace directory as proposed, and you should then be greeted with the Eclipse welcome screen.

Android ADT plug-in for Eclipse

Before installing the actual SDK for Android, it will greatly help if you get the "Android Development Tools" integrated into Eclipse. Select the Help menu, then "Install new software...". Click "Add..." to add the "ADT Plugin" repository at "https://dl-ssl.google.com/android/eclipse/" and "OK". "Select all" and hit "Next".

It's fine (so to speak) if it takes time at this stage: it just took ten minutes for me right now as I am testing this. So even if Eclipse seems to have hung, it seems that the first time you're doing this, it needs to (slowly) download, parse and refresh a whole lot of internal repository data before it even gets to the one you just added.

Anyway, just accept the license if you agree, go through the unsigned content, and restart Eclipse as proposed. If you're lucky (and patient) enough it will work eventually.

Android SDK

Yes, we're getting there. It is now time to download and extract the Android SDK as well:

$ ftp http://dl.google.com/android/android-sdk_r10-linux_x86.tgz
$ tar xzf android-sdk_r10-linux_x86.tgz

With this done, you still have to let Eclipse know where you have extracted the tools: "Window" menu, "Preferences", in the "Android" tab simply browse to the SDK location, "Apply", "Apply" again (important) and "OK".

Do not hesitate to repeat this last step a few times, possibly restarting Eclipse right after doing it, as in my case it didn't seem to get it right the first or second time around.

Android SDK platforms

There is one last step and you'll be free to compile your first Android applications. In the "Window" menu, "Android SDK and AVD Manager": check and install the SDK platforms as needed. You'll then be ready to create and compile your first package, as documented there: http://developer.android.com/guide/tutorials/hello-world.html

Remaining challenges

There is still one thing that doesn't work on NetBSD with this setup: the emulator. It legitimately complains with this message:

/lib/libc.so.6: version `GLIBC_2.7' not found (required by
.../android/android-sdk-linux_x86//tools/emulator)

This is because the Linux emulation environment packaged is too old to support programs linked with newer versions of the glibc. As annoying as this is, there is good news: as far as I know, it is already supported in the -current branch of NetBSD's development, and will definitely be available in the 6.0 release.

Conclusion

I have to say, in spite of the weight and very specific requirements of the SDK, it seems to be clearly documented and integrated. It's a good lesson for the more open development environments which I'm used to work with so far (like hackable:1, http://trac.hackable1.org/).

But unfortunately, again, if anything breaks, I did not find anything easier than to erase the whole "eclipse" folder and start over. It seems that programming complete IDE and SDK environments is too complex for developers to implement error checking: this has bitten me heavily when installing the SDK on Linux Debian 6.0 amd64:

install the SDK without the i386 binary compatibility packages installed;
everything seems to work, no errors, but it keeps forgetting where the SDK tools are, and then fails to create virtual devices;
install the lib32ncurses5 i386 package (and dependencies)
re-declare where the SDK tools are, it won't warn you again that they're missing but still won't work;
start over from scratch, it will.

*sigh*

Yet:

$ file workspace/HelloWorld/bin/HelloWorld.apk
workspace/HelloWorld/bin/HelloWorld.apk: Zip archive data, at least v2.0 to extract

Update: I just packaged eclipse 3.6.1 in wip/eclipse. HTH :)

khorben: Installing the Meego SDK on Debian Squeeze

khorben@defora.org (khorben) — Sun, 20 Feb 2011 22:44:52 +0000

I recently had to install the Android SDK on a couple of my machines, and will share my experience doing that after this post. I am currently trying to compare it with Meego, and I think these few notes can be useful.

I encountered a couple issues:

the "meego-sdk" package was uninstallable because of a dependency issue;
the SDK installs into /opt and the recommended partitioning has / too small (about 200MB are required)

The first issue was solved by forward-porting libmpfr1ldbl from Debian Lenny; if you adapt for your setup and actual versions:

# echo deb-src http://ftp2.de.debian.org/debian/ lenny main >> /etc/apt/sources.list
# apt-get update
[...]
# apt-get source -b libmpfr1ldbl
[...]
# dpkg -i libmpfr1ldbl_2.3.1.dfsg.1-2_amd64.deb
[...]
# apt-get install meego-sdk
[...]

I'll see if I can easily package it within hackable:1, it could be interesting to help install the SDK thanks to this repository; it's usually the other way around...

The second issue was easily solved with a bind mount:

# echo /usr/opt /opt bind defaults,bind 0 0 >> /etc/fstab
# mkdir -p /opt /usr/opt
# mount /opt

This has to be done before the previous step if you needed it. Do not forget to move the contents of /opt to /usr/opt if necessary.

I have also posted this information on http://wiki.meego.com/Talk:Image_Creation_For_Beginners .

Interestingly enough it supports OpenID. It was trivial enough to login using my existing ID on http://openid.bearstech.com/ . Neat :)

khorben: First (unofficial) release of the DeforaOS smartphone environment

khorben@defora.org (khorben) — Mon, 20 Sep 2010 14:51:02 +0000

I finally have the pleasure to deliver the first version of the DeforaOS Smartphone environment, as featured in the hackable:1 distribution.
First, the direct links:

If you like the artwork better than I do myself, you can also find a splash screen for u-boot there:

http://www.defora.org/download/snapshots/hackable1/Hackable1-Openmoko-Freerunner-user-2010.07a-splash.gz

I have gathered some release notes and documentation within hackable:1's wiki, which you will find there:

Of course, I gathered some screenshots as well. They can be seen here:

http://www.defora.org/os/project/download/3343/Phone

Before I conclude, I am the first one to know that this release is far from perfect. If you feel like you have anything to say about it, you will be more than welcome to let it be known. There are a number of ways to do that:

contacting me personally as described on http://people.defora.org/~khorben/place/wiki/13/Contact
using DeforaOS' development mailing-list, as on http://lists.defora.org/
filing a bug in DeforaOS: http://www.defora.org/os/project/bug_new (create your account first at https://www.defora.org/os/user/register)

Now for the final words of this post, I have no reason to hide the fact that hackable:1 itself is probably a dead project already. I seem to be the last developer interested, which I find quite sad since I know no other project providing ready-to-flash Debian images for embedded platforms.
If you also have a need and desire for such a framework, I encourage you to let it be known. As for myself, I have in mind to improve and maintain such a way to generate ready-to-use images, probably as part of the DeforaOS project as well, unless somebody beats me to it.

Anyway, for more literature on this work, feel free to check earlier blog posts and news announcements on this blog or at http://www.defora.org/ .

Happy testing!

khorben: Releasing a new snapshot of the DeforaOS smartphone environment on hackable:1

khorben@defora.org (khorben) — Mon, 30 Aug 2010 12:57:56 +0000

I have managed yesterday to release a new snapshot of the DeforaOS smartphone environment, as found packaged on top of the hackable:1 distribution. Unfortunately, there is still one obvious blocker bug before it can be easily tested as a real phone at the moment: as it seems, the modem "forgets" the PIN code a few seconds after accepting it, and is then unable to register correctly.
Of course, my current plan is to investigate and fix this as soon as possible (with a new snapshot). Yet, among the changes since the last release of the environment, you will already find:

a new finger keyboard, with popup keys (and using Gtk+' theme)
the addition of a phone log;
preferences windows for the phone application;
the return of the background picture, and a preferences window to easily change it;
last but not least, the final version of my initial attempt at SMS encryption.

With this, I will continue my work on the user experience:

fix and update the web browser (broken since the switch to Debian testing);
continue improvements to the finger keyboard (bigger keys, multiple layouts)
nicer Gtk+ theme and artwork if I manage (screenshots!)
more actual tests and usability improvements to the phone application;
power management;
GPRS support.

I have also begun to implement an application to configure access to wireless networks, with wpa_supplicant's help. It will take another while though.

For more information, as always, check either http://www.defora.org/, the IRC channel of hackable:1 (#hackable1 on Freenode), the respective mailing-lists (devel@lists.defora.org, hackable1-dev@lists.hackable1.org...) or even, feel free to contact me directly of course: http://people.defora.org/~khorben/place/wiki/13/Contact

And before I forget, the snapshot itself is announced and available there: http://www.defora.org/os/news/3394/New-snapshot-of-the-DeforaOS-smartphone

khorben: Improvizing a talk at Debienna

khorben@defora.org (khorben) — Thu, 26 Aug 2010 16:54:19 +0000

I have been staying a few days in Vienna a couple weeks ago, where I happened to join a Debienna [1] meeting. As things went it felt appropriate to introduce hackable:1 [2] (and my current work on it) to this fine crowd. I have therefore quickly prepared a presentation, of which slides can be found there [3].

It was called "hackable:1 (and then more)", and I really appreciated this opportunity. See you guys!

[1] http://www.debienna.at/
[2] http://trac.hackable1.org/
[3] http://people.defora.org/~khorben/papers/h1more/h1.html

khorben: News from the hackable:1 front

khorben@defora.org (khorben) — Fri, 30 Jul 2010 14:00:45 +0000

About the DeforaOS smartphone environment, I have just uploaded a first image for tests, as presented here:
https://www.defora.org/os/news/3380/Snapshot-of-the-DeforaOS-smartphone-available-for-tests

It directly benefits from the recent switch to Debian Squeeze/testing, as the default version of Debian on which hackable:1's development is now based. Like before, images are generated daily and found here:
http://build.hackable1.org/

Last but not least, you may have heard of OsmocomBB, a Free Software GSM Baseband software implementation:
http://www.osmocom.org/
Good news is, I have started to package it for use within hackable:1. A few things are left to be fixed before they can be pushed automatically online, but I have been able to cross-compile libosmocore and the layer23 set of tools already.

khorben: The DeforaOS smartphone environment

khorben@defora.org (khorben) — Sat, 12 Jun 2010 19:46:31 +0000

I'll change my habits a bit here, and write a personal note about what I've been working on recently. Some of you may know about it already, since I have begun to announce it, but probably to a smaller audience this far [1].

It's probably relevant to begin with some background information about all this, although even then it's difficult to know where to start.

Reinventing the wheel

For some reason I found the urge to start an Operating System project of my own, which began with a modified version of Debian GNU/Linux [2]. This goes as far back as 2001, which may seem like yesterday to many experienced UNIX users, but was just a year after my first installation of a distribution on my own computer. This turned into a LFS-based project [3], before becoming the DeforaOS project as it is today [4], with more or less the goal to re-implement a complete kernel and user environment.

That is to say, you may see a pattern here, and remind me that such time may be better spent improving the existing projects. While I would definitely agree that many Open Source projects need help (quite logically, otherwise I wouldn't have started my own), I will briefly summarize the reasons behind my choices:

I am having fun, and learning in the process;
back then, I did not have the technical means (eg cheap Internet access), let alone political power to influence much of the things I really wanted;
with my projects evolving, I stuck with this work and choices rather than give it all up;
frankly I still do not see myself having any political power now in the community, to do what I really want anyway;
last but not least, I am essentially trying to implement a different design, which I believe is worth a try.

Of course this doesn't mean that I always make the same choices as a professional [5]. This experience has always been useful, even though a compromise in design I made to implement a working solution unfortunately hasn't succeeded to date [6]. But I have then been focusing a full year on the hackable:1 project instead [7], with a few releases along the way.

The Openmoko Freerunner

This is clearly another illustration of the "reinventing the wheel" approach. Why go all the way and create an Open Source smartphone from scratch [8]? It sure must be tedious, and from my experience and the information I have obtained in the process, I can say it sure was. And I can't say it was a clear, undisputed success either.

I'll be honest: I never liked the device itself. I found it ugly and bulky at best. I encountered the most annoying hardware bugs and subsequent frustration rushes. No need to mention the community fragmentation, which didn't help either. But today still, it sure has its uses, and is actually useful in plenty of ways.

Coding again

Burning out, having new opportunities, I parted ways and resumed work as a security consultant instead [9]. I could afford to take a first break in far-away land (thanks a.) and have fun creating software again, rather than feel like a packaging robot for what seemed to me as being broken code anyway.

I could manage to get a few bugs fixed in my current Operating System of choice (NetBSD [10]), and then turn a few more sub-projects of DeforaOS to be good enough that I began to (finally) use many of them on a daily basis.

The motive(s)

Owning a Sharp Zaurus [11] for a few years, I had already been thinking about an embedded version of the desktop environment while writing it. But I could do better; I could take my revenge on the Openmoko Freerunner instead. Still bitter from the outcome of my efforts while working with the device, I was convinced that I could do better. Be it true or not, as always there is only one way to know: trying it hard, whatever the reason.

After a quick glance at the Openmoko community, to no surprise I found its activity to be declining. Maybe this is not true and I was simply expecting it, but I think it's fair to say that the hardware is aging. Nonetheless, combined with hackable:1 it has the advantage to easily letting me run my own native environment. This is certainly not true of the more popular mobile platforms.

Trying a different way

As mentioned, I thought I could turn this phone into something more useful than it already was. This was based on the following assumptions, based on my personal appreciation:

the existing projects are over-engineered;
they have no global coherence concerning usability;
they are often developed as regular applications, regardless of the hardware constraints.

Better then, some interesting and unusual features of the hardware are available and documented [12], some of which could turn into interesting security developments. I cannot pretend to have actually been able to do better, or implement all these fancy features, especially within this other month break; but here is where I am now.

The DeforaOS embedded desktop environment

First, I have spent some time improving and adapting my existing desktop applications to fit the Freerunner. I won't copy and paste what I have already written about it [13]. Instead, here is a summary of its current status:

neither hardware buttons are required (nor currently used) for regular operation, as everything can be done on-screen;
both panels are fully functional, with an integrated application launcher, and displaying the clock, hardware status (including registration, signal level and operator) and of course an application switcher;
the on-screen keyboard is fast, although definitely not finger-friendly at the moment (xkbd embedded in the panel), and will be re-implemented from scratch;
the contextual menus (as offered through a Gtk+ extension) could be more intuitively found;
the file manager is functional, but could be better integrated with the freedesktop.org standards;
the clipboard and drag&drop features from the same project could be improved as well;
the homescreen functionality cannot be enabled at the moment due to how matchbox-window-manager handles it;
DeforaOS' own window manager is not mature enough to be used instead at this point;
the latest versions of the web browser cannot be packaged on hackable:1 at the moment, as it depends on a more recent version of WebKit.

I think this reflects quite well what is to be expected there.

The DeforaOS smartphone environment

Meanwhile, I have implemented a complete telephony application from scratch [14]. The design goals were:

use Gtk+ and the glib libraries in C, and only relying on them and DeforaOS' libDesktop;
embed the GSM daemon directly inside it;
implement the core application with all the required functionality built-in (eg contacts, messages, phone calls, preferences...)
let this application be as reactive as possible (eg single process)
extend it through optional plug-ins;
support hardware modems as broken as on the Openmoko Freerunner.

It's still far from being eligible as a regular mobile phone sold with a contract, but as of today this first set of goals was mostly met. Some essential features are still missing:

adding, editing and deleting contacts;
maintaining a phone log;
sending DTMF codes during calls;
storing the messages sent;
support for delivery reports;
preferences dialogs;
entering the PUK/PIN2/PUK2 codes;
switching to data mode;
call forwarding...

Most of them are not challenging anymore, and are just a matter of taking a few hours this and there to get them done.

Where is gets interesting

One of the first parts I believe I should emphasize in this post is the plug-in support. First, it allows full integration with the actual, underlying hardware platform with all the code clearly separated. This is the case on the Openmoko, where:

a first plug-in takes care of supporting profiles, by requesting a ring tone, triggering the vibrator and so on;
the hardware plug-in catches these events and turns the relevant components on and off.

Secondly, it allows extending the functionality in lots of different ways, from PulseAudio support to DBUS and potentially FSO integration [15], without mentioning webcams, GPS positioning [16] and then more.

And there's more.

SMS encryption

One of the first additional security features I have been thinking about is SMS encryption [17]. While not being specific to the Freerunner, it is certainly an interesting platform for such a feature. My current implementation, while not being cryptographically strong at the moment, can already be demonstrated as a working Proof-of-Concept [18].

More than that, it is maybe time to think about a common, interoperable way to implement this feature. It looks like things could be moving towards this direction, with new projects emerging like TextSecure [19].

Cell tracking and geotagging

Not unlike some other phones, but probably in a more accessible way, the Freerunner supports an "engineering mode". It is basically a monitoring mode [20][21], much like the one on your regular 802.11abgn wireless card (except you can't sniff traffic, yet [22][23][24]).

While not being as featureful and polished as kismet [25], my current implementation (couple of days old) can already illustrate this concept.

The future

With a project as promising as Osmocombb [26] able to run on the Freerunner, I can only let you guess where all of this can be going. There are still many things to be done with this hardware, and of course I am also hoping to run my software on other devices as well, like the ones from ROAD [27], GizmoForYou [28], Nokia [29], Glofiish [30], HTC [31] and Palm [32] among others.

If you would feel interested in any of this, do not hesitate to let me know [33]. Better, you can use the development infrastructure directly [34]. I will welcome your feedback and ideas, free patches and hardware, consider contracted projects.

Thank yous

To conclude, I have omitted one of the reasons behind all of this in this post. I had the pleasure to be invited to the Nokia Hackfest in Berlin mid-March this year [35], and then be honoured with a free N97 and N900 device. They have both proven very helpful while developing this software already.

Of course there's a number of people and projects who are also a great help to me every day. I can only hope to be helpful to you, too. Cheers!

[1] http://www.defora.org/os/news/3363/Introducing-the-DeforaOS-smartphone
[2] http://www.debian.org/
[3] http://www.linuxfromscratch.org/
[4] http://www.defora.org/
[5] http://people.defora.org/~khorben/cv.en.html
[6] http://runningbear.org/
[7] http://trac.hackable1.org/
[8] http://www.openmoko.org/
[9] http://www.duekin.com/
[10] http://www.netbsd.org/
[11] http://www.trisoft.de/slc3200.htm
[12] http://wiki.openmoko.org/wiki/Neo_1973_and_Neo_FreeRunner_gsm_modem
[13] http://www.defora.org/os/news/3362/DeforaOS-as-an-embedded-desktop-environment
[14] http://www.defora.org/os/project/3343/Phone
[15] http://www.freesmartphone.org/
[16] http://realtimeblog.free.fr/
[17] http://www.cryptosms.org/
[18] http://www.passageenseine.org/hackevents/confidences-par-sms
[19] http://www.whispersys.com/
[20] http://nobbi.com/monitor/index.html
[21] http://www.gnokii.org/screenshots.shtml
[22] http://www.gnuradio.org/
[23] http://cryptome.org/jya/crack-a5.htm
[24] http://reflextor.com/trac/a51
[25] http://www.kismetwireless.net/
[26] http://bb.osmocom.org/
[27] http://www.road.de/
[28] http://www.gizmoforyou.net/
[29] http://www.nokia.com/
[30] http://www.glofiish.com/
[31] http://www.htc.com/
[32] http://www.palm.com/
[33] http://people.defora.org/~khorben/place/wiki/13/Contact
[34] http://www.defora.org/os/project/bug_list/3343/Phone
[35] http://www.youtube.com/watch?v=5jW3VDqvzLs

hackable:1 official blog: Openmoko devroom at the fosdem

Mon, 15 Feb 2010 18:08:52 +0000

Hello hackable:1 users !

Serdar Dere, from #openmoko-cdevel managed to get a devroom at this year's fosdem for the openmoko community !
First things first, huge thanks to him.

Second, we get the room on Sunday morning and the schedule is here. As you can see, it is full of talks and hackable:1 has a slot.

Meet you there ! Who's coming ?

EDIT: The slides

hackable:1 official blog: New feature for rev5: h1settings

Tue, 22 Dec 2009 14:30:21 +0000

In this article I'm going to describe a new feature which will be available in rev5: h1settings.

h1settings is a library which handles the global settings of the phone. It is a basic wrapper upon some gconf keys and has functions to :

read and update key values
listen to gconf key changes

Currently, only a few keys are available :

Device states :

gprs on/off : /desktop/h1/phone/enable_gprs
gsm on/off : /desktop/h1/phone/enable_gsm
gps on/off : /desktop/h1/gps/enable_gps
wifi on/off : /desktop/h1/phone/enable_wifi
bluetooth on/off : /desktop/h1/phone/enable_bluetooth

Power management :

power management enabled / disabled

The idea behind this library is to add loose coupling between components. For example the power management key is used by the gsm applet when a call is in progress (to fix this silly bug: http://trac.hackable1.org/trac/ticket/42 ) in order to disable power management (i.e. suspend). The gsm applet does not know how to disable PM but neod knows.

Currently, all the actions related to key states except gsm are handled by neod, the central daemon. It registers itself for these keys changes and sets the state of the devices. For the gsm part, it is handled by the gsm applet because it has already everything needed to switch on/off the antenna.

Another advantage is that an independant settings app can be built very easily without any dependencies with the underlying system, and this app already exists : h1settings.
See some screenshots below :

hackable:1 official blog: Running hackable:1 on the ROAD Officer S101

Tue, 22 Dec 2009 14:29:59 +0000

Within my position for the promotion of free, open-source hardware solutions in general (and currently, telephony in particular), I am of course trying to keep in touch with the latest developments in this field. Eventually, I have met the fine people at ROAD, a small company in Berlin developing a phone: the Officer S101.

If you don't know about it already, its form-factor will remind you of the Nokia Communicator: from the outside, it looks like a regular candy-bar phone, but it also reveals a full keyboard and wide-screen display when opened. What interests us here is that its inside is open, too :)

The device is not in production yet, but they have been so kind as to let me borrow a sample for a while, which I demonstrated during my hackable:Device workshops at HAR2009 by the way. This is where I managed to install hackable:1 on the phone.

On the hardware side, it was difficult to let it be easier to test. Let me stress first that this was a pre-production device, and all of this may be subject to changes! So here we are:

the phone has an internal flash memory but can also boot on an SD card, which is conveniently replaceable without opening the phone or even removing the battery,
the first partition of the SD card must be formatted as a FAT filesystem,
I was provided with two second-stage bootloaders: one that boots the phone from flash, and the other which updates it.

Therefore, it was just a matter of copying the correct bootloader on the SD card, along with the root filesystem to flash if desired.

About the software now, this device happens to use the same architecture as the Openmoko Freerunner within Debian, "armel". One only has then to choose the right packages, configure them accordingly and generate a filesystem archive.

First, I have added a generic device definition file in trunk/build/profiles/ROAD-Officer.include:

DEBIAN_ARCH="armel"
STRIP="arm-linux-gnueabi-strip"

The "STRIP" line is necessary because of the way we are currently cross-compiling Debian packages: the native tools are unable to strip the binaries cross-compiled. Therefore, strap:1 is currently doing it instead, while generating the images.

#this device is a phone
. "profiles/generic-phone.include"
#add bluetooth support
. "profiles/generic-bluetooth.include"
#add GPS support
. "profiles/generic-gps.include"
#add touchscreen support
. "profiles/generic-touchscreen.include"
#add wifi support
. "profiles/generic-wifi.include"

This should be self-explanatory :)

#packages
#Debian
PACKAGES="$PACKAGES
[...]
xserver-xorg-core
xserver-xorg-input-kbd
xserver-xorg-input-tslib
xserver-xorg-video-fbdev
zlib1g"

Unlike the Openmoko Freerunner, which has its own dedicated X server, we are using the generic framebuffer-based X server. It just works :)

#specific kernel
#FIXME still needs to be packaged
PACKAGES_BLACKLIST="xserver-xorg-video-all"

In order to gain space, we are blacklisting this meta-package: xserver-xorg-core dependencies are actually satisfied with at least one video driver installed, which is the case here.

Next comes the actual profile definition, in trunk/build/profiles/ROAD-Officer-user.profile:

. "profiles/ROAD-Officer.include"
#blacklist packages to gain space
PACKAGES_BLACKLIST="bash
debconf-i18n"
#additional dependencies adjustments
PACKAGES="$PACKAGES
debconf-english"
CLEAN_DOC=yes
CLEAN_LOCALES=yes

This was directly taken from the Openmoko Neo1973 profile, which has tough space constraints on the flash. Here we do not have such limitations, however it made the testing process slightly faster.

Anyway, after some more tuning in trunk/build/packages, it was time to generate the filesystem archive:

$ ./build.sh VENDOR=ROAD MODEL=Officer PURPOSE=user archive

At this stage, the only missing bit was the kernel. I simply used the one already flashed onto the device, but I still needed some modules. They were of course provided to me in source and binary forms, but I don't think this kernel tree is available publicly at the moment. I am sure it will be as soon as the ROAD developers can manage.

Unfortunately, I could only get this far yet. It boots all the way to the graphical user interface, where the Om2007.2 design does not really fit the rather wide screen. We are currently working hard on the next release, rev5, and focusing on the Openmoko Freerunner first, but I will be resuming this work soon enough!

hackable:1 official blog: Temporary issues with emdebian's toolchain solved

Tue, 22 Dec 2009 14:29:24 +0000

When cross-compiling hackable:1 packages, we are relying on the stable emdebian toolchain to compile our programs. Apparently, there has been a problem last week, where the toolchain was erroneously recompiled and from then on depending on packages not available on Debian Lenny.

We have coordinated this issue with emdebian's team, and are glad to announce that everything seems to be back in order.

If you have been upgrading your hackable:1 cross-compilation environment during this window, there is a simple way to get it to work again:

# apt-get remove --purge libgcc1-armel-cross
# apt-get install gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

Then you should be able to cross-compile again!

hackable:1 official blog: Study boot process to improve boot time

Tue, 22 Dec 2009 14:29:05 +0000

One thing I'll certainly work on in the upcoming weeks is boot time improvement.
So far, booting takes quite a long time. But instead of looking at my clock when powering up my FreeRunner, I installed a tool to go deeper in the boot process and analyse its (non-)performance.

This tool is called Bootchart-lite, a clone of the well known Bootchart on desktop systems.
That's a basic rewrite from embedded systems that create similar logs as its big brother bootchart, meaning bootchart can compute them.

If you are interested in working on boot time improvement, you should install it !

Uboot configuration

The bootloader must be configured to add a kernel parameter. Here is the way for Uboot. Adapt it for Qi if you use it.

    # apt-get install fso-utils # from FSO
    # mkdir /tmp/uboot && cd /tmp/uboot
    # dfu-util -a u-boot_env -U env.u-boot
    # uboot-envedit -i env.u-boot -p > env_modified.u-boot.tx

Edit env_modified.u-boot.txt to tell the kernel to use bootchart-lite instead of init as first process.

    boot_menu_timeout=300
    bootargs_base=rootfstype=jffs2 root=/dev/mtdblock6 quiet bootlevel=8 init=/usr/bin/bootchart-lite console=ttySAC2,115200 console=tty0 loglevel=8 regular_boot
    ...

    # uboot-envedit -i env.u-boot -f env_modified.u-boot.txt -o env_modified.u-boot
    # dfu-util -a u-boot_env -D env_modified.u-boot

* Install the packages *

On your FreeRunner running Hackable:1, install bootchart-lite: (As of september, 18, it is packaged for daily builds, and will be packaged for rev5)

    hackable1# apt-get install bootchart-lite
    hackable1# reboot

Get data and render the image

On your computer, install bootchart-view (from the big brother bootchart project), and get the logs.
Then, render the PNG (or SVG) image.

    # apt-get install bootchart-view 
    $ scp -r root@hackable1:/etc/bootchart-lite .
    $ cd bootchart-lite
    $ tar czf bootchart.tgz *.log
    $ bootchart -f png bootchart.tgz

Analysis

That's the most difficult step :) !

I'll have a look on that later, I'm focusing on rev5 for now.

Eh ! There are "beta2" images available on http://build.hackable1.org. Would you give it a try ?

Please let us know how you like it and if bugs remain !

hackable:1 official blog: Hackable:1 rev5 is out !

Tue, 22 Dec 2009 13:27:04 +0000

Dear Hackable:1 users,

After rev5rc1, we spent hours and hours debugging this or improving that to finally get the rev5 out today. Yep, that's right: hackable:1 rev5 (Codename: Chuck) is there!

First of all, you can grab the different flavours (user for the flash and developer for the SD) here: http://download.hackable1.org/rev5

Changelog
Here are the changes since rev4:

+ End users matters

Most of the software stack now runs under the 'hackable1' user, for security purposes.
SMS proper implementation
The contact list bug has been found and fixed!
Power management improvements, suspend works, bluetooth and wifi are no longer turned on by default.
An application called 'h1settings' can be used to configure phone features, (enable / disable GSM / Wireless / GPS, power management, ...) as well as time and date.
We created a new theme to celebrate this new release!
We got a splashscreen! It features a Chuck figure to reflects the rev5 codename: Chuck
For those who used to love the games on OM2007.2, we put them back !
Boot time seems to have been improved a bit

+ Power users / developers matters

This rev5 release has entirely been built from the automatic build system.
A Linux kernel is now packaged in hackable:1, in order not to rely on fso-pkg anymore.

Debugging has been disabled (boot time improvement)
Easier kernel upgrade when using an ext2 partition to store the kernel on µSD cards
Separation of kernel modules in three sets: essential (comes with the kernel), common modules and "more modules"
You can read a bit on http://zecrazytux.net/Embedded/Hackable1/Custom_Kernel.html

CDBS is now used for some packages.

the package h1packtools contains a CDBS rule that may suffice for simple programs with the autotools
this rule also enables cross-compilation ; it is based on previous works on this subject

Git repositories can now be used as sources for remote projects.

Where can I find it? Where can I get it? I didn't understand last time, so I ask again : what is the answer to the ultimate question about life, the universe, and everything?

As ever, you can download hackable:1 on http://download.hackable1.org/rev5.

All the necessary information can be found on http://trac.hackable1.org as ever, that is documentation, installation instructions as well as known issues.

It's obvious that the answer to the aforementioned question is "Chuck".

Who should I thank for all that stuff?

Among the people who worked on this release, the most notorious are (alphabetically):

Marcus Bauer (mbauer)
Jérome Blondon (jbl2024)
Sébastien Bocahu (zecrazytux)
Pierre Pronchery (khorben)
David Wagner (Deubeuliou)

We'd also like to thank all the testers, among them most notably Bearstech employees, and regular contributors/users of hackable:1, who kept us going forward.

What should I expect next?
Due to a very good number of good reasons, which could all of them be summed up by a minute of one of khorben's rants against libgsmd, we'll switch to Freesmartphone.Org for rev6.
We will also switch from xserver-xglamo to xserver-xorg for the sake of more responsive graphics.
On the developer side, we will of course continue to improve the packaging system and lower the entry barrier.

All in all, more reliable GSM & suspend, and almost all the features one may need. Stay tuned!

The hackable:1 team

hackable:1 official blog: Hackable:1, rev5rc1, at last!

Thu, 15 Oct 2009 15:58:10 +0000

Dear Hackable:1 users,

We are glad to announce that, after long & thorough efforts from the development team, after a bunch of testing hours, after a long time spent on arguing whether we should include this or that feature, we made it: hackable:1 rev5rc1 (Codename: Chuck) is there!

Here is a changelog of corrected bugs and added features from rev4.

Changelog

+ End users matters

Most of the software stack now runs under the 'hackable1' user, for security purposes.
SMS proper implementation
The contact list bug has been found and fixed!
Power management improvements, suspend works (well almost each & every time, sadly we're still hunting GSM issues for that matter)!
An application called 'h1settings' can be used to configure phone features, (enable / disable GSM / Wireless / GPS, power management, ...)
We created a new theme to celebrate this new release!
We got a splashscreen! It features a Chuck figure to reflects the rev5 codename: Chuck
Boot time seems to have been improved a bit

+ Power users / developers matters

This RC1 and the upcoming final rev5 release are now built from the automatic build system.
A Linux kernel is now packaged in hackable:1, in order not to rely on fso-pkg anymore.

Debugging has been disabled (boot time improvement)
Easier kernel upgrade when using an ext2 partition to store the kernel on µSD cards
Separation of kernel modules in three sets: essential (comes with the kernel), common modules and "more modules"
You can read a bit on http://zecrazytux.net/Embedded/Hackable1/Custom_Kernel.html

Where can I find it? Where can I get it? What is the answer to the ultimate question about life, the universe, and everything?

As ever, you can download hackable:1 on http://download.hackable1.org/rev5rc1.
All the necessary information can be found on http://trac.hackable1.org as ever, that is documentation, installation instructions as well as known issues.
It's obvious that the answer to the aforementioned question is "Chuck".

Who should I thank for all that stuff?

Among the people who worked on this release, the most notorious are (alphabetically):

Marcus Bauer (mbauer)
Jérome Blondon (jbl2024)
Sébastien Bocahu (zecrazytux)
Pierre Pronchery (khorben)
David Wagner (Deubeuliou)

khorben: Working on gsmd

khorben@defora.org (khorben) — Wed, 16 Sep 2009 13:51:22 +0000

Last week, I have spent some time figuring out how to improve the status of the phone stack for the hopefully-soon-to-be-released development version of hackable:1 [1]. There are unfortunately a few major problems:

asking the PIN code multiple times [2]
network registration rarely effective
SIM contacts and messages not always fetched [3]
sending messages not always working
no GPRS support at all (from a GUI like [4])

It sounds like a lot, but I'm pretty sure the cause is the same for all: interaction with the gsmd. It's somewhat strange, since the development sources were synchronized with rev4...

Therefore, I've been using libgsmd-tool extensively for a while. First, I realized that the code for its "shell" mode (-m shell) is somewhat fragile. Unfortunately, the design of this part doesn't make it trivial to fix.

Anyway, then, I've been using the "atcmd" mode as well (-m atcmd), while working on the GPRS interaction in particular. Here comes the funny part: since this command then basically works like a serial console, why not tell pppd to use it instead of the actual serial device?

gsm-tool - (C) 2006-2007 by Harald Welte and OpenMoko, Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

ATZ
STR=`ATZ'
RSTR=`OK'

It makes even more sense in this context, since the phone stack no longer runs as root, and therefore shouldn't be allowed to tinker with the gsmd daemon at all anymore (eg "/etc/init.d/gsmd start/stop").

The first part was easy; patching libgsmd-tool to:

output errors to stderr,
remove the local echo (eg "STR=...")
write the response without escaping (eg "RSTR=...")

The second part took me a bit more time, but is actually trivial when you know it: using the "pty" directive of pppd instead of "/dev/ttySAC0". The change goes in /etc/ppp/peers/gprs:

##
## pppd options
##
#/dev/ttySAC0
pty "/usr/bin/libgsmd-tool -m atcmd"

It actually works up to a certain point:

I doubt that connectivity reports still work while the connection is up (eg signal quality, etc)
gsmd probably currently doesn't expect this to happen,
there should be some kind of pass-through mode, where libgsmd-tool would pipe the data in and out of stdin to and from the gsm daemon.

With this solved, this could be a rather elegant solution to be able to use GPRS without interrupting gsmd. I guess it would also allow the other applications sharing access to the daemon to keep the communication socket open during that time.

For the record:

Sep 16 15:47:34 syn pppd[321]: pppd 2.4.4 started by khorben, uid 1000
Sep 16 15:47:34 syn chat[518]: send (ATZ^M)
Sep 16 15:47:34 syn chat[518]: expect (OK)
Sep 16 15:47:34 syn chat[518]: OK
Sep 16 15:47:34 syn chat[518]:  -- got it
Sep 16 15:47:34 syn chat[518]: send (AT+CGDCONT=1,"IP","internet.eplus.de"^M)
Sep 16 15:47:35 syn chat[518]: expect (OK)
Sep 16 15:47:35 syn chat[518]:
Sep 16 15:47:35 syn chat[518]: OK
Sep 16 15:47:35 syn chat[518]:  -- got it
Sep 16 15:47:35 syn chat[518]: send (ATD*99***1#^M)
Sep 16 15:47:35 syn chat[518]: expect (CONNECT)

[1] http://www.hackable1.org/
[2] http://trac.hackable1.org/trac/ticket/254
[3] http://trac.hackable1.org/trac/ticket/264
[4] http://people.defora.org/~khorben/place/blog/60/New-project--gprs-for-hackable-1-on-the-Openmoko-Freerunner

zecrazytux: Custom Linux kernel for the Openmoko Freerunner on Hackable:1 This is an ugly script to get the correct path of modules to add in the .modlist

Sat, 12 Sep 2009 22:00:00 +0000

Custom Linux kernel for the Openmoko Freerunner on Hackable:1

We've been using FSO/debian’s kernel package in Hackable:1 till now (mid-september).

I decided to package a custom one for Hackable:1. Why ?

to disable debugging that I suspect being a cause of a slow boot (debug + screen output, wich is slow on the Freerunner)
we may need it for other projects in anear future
for hackability: easy to patch, modify the configuration… while still being integrated in hackable:1 thanks to its packaging
because I can :)

developper information

You should already know our build system, if not, take a look at :) – http://trac.hackable1.org/

As of september, 13, 09:

Kernel sources come from git://git.openmoko.org/git/kernel.git

although GTA02 is now supported in the mainstream kernel 2.6.31, the support of gta02 hardware is uncomplete.
The kernel config can be found in the debian/ directory after patching with packages/linux-image-gta02/linux-image-gta02.diff.
It was copied from pkg-fso and modified a bit, mostly in order to disable debugging features.
As it uses git, you cane asily build your patched kernel, using another git repository and another commit tag. (you only have to modify debian/changelog a bit, or use bump.sh)

general informations

Three packages are created:

linux-image-gta02: Linux kernel plus the basic kernel modules that are necessary for the Openmoko Freerunner to run correctly
linux-modules-gta02: common kernel modules you may need, when pluging a peripheral for example
linux-moremodules-gta02: other modules, that are built for a few people who may need them (not for everybody end-user)

[temporary] call for module sorting

Please let me know in which package should modules go… :)

All modules that are compiled go to linux-moremodules-gta02 first, then, some are moved to linux-image-gta02 and linux-modules-gta02 according to the module lists : debian/linux-(image|modules).modlist

This is an ugly script to get the correct path of modules to add in the .modlist files

hackable:1 official blog: Run Ogsmd on Hackable:1

Wed, 19 Aug 2009 21:31:46 +0000

As you may know, we are willing to migrate to FSO. As part of it, we made ogsmd running on H:1 and we will rewrite phone-kit to use libfso-glib instead of libgsmd.

Until we get all the stuff packaged, here are the step to make ogsmd running on a Hackable:1 rev4 installation.

Install the framework

We will use a git version that I know working. On your computer:

git clone git://git.freesmartphone.org/framework.git
cd framework
git checkout 17898fc0f73453c11d1b1e8db57f8e8a0cfbc943 .
cd ..
scp -r framework root@192.168.0.202: # I assume that it is you FR's IP

SSH into your freerunner and:

cd framework
python setup.py install
cd ..

Install the muxer

We will use SHR packages which a copy of them is on our trac.

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/fso-abyss_0.3.5+gitr67+ff68be1581069ca494a559e85f6299246888d3b5-r0_armv4t.ipk"
ar -x fso-abyss_0.3.5+gitr67+ff68be1581069ca494a559e85f6299246888d3b5-r0_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libgsm0710mux0_0.3.5+gitr35+8e3e7533b286d8086bce8fa09bce23bb9f18bb98-r1_armv4t.ipk"
ar -x libgsm0710mux0_0.3.5+gitr35+8e3e7533b286d8086bce8fa09bce23bb9f18bb98-r1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libgsm0710-0_1.1.1+gitr15+3bb80ba6cc9f86ed3996f88bfa2986cc572489d6-r1_armv4t.ipk"
ar -x libgsm0710-0_1.1.1+gitr15+3bb80ba6cc9f86ed3996f88bfa2986cc572489d6-r1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libfsotransport0_0.9.3+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk"
ar -x libfsotransport0_0.9.3+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk
tar -xvzf data.tar.gz -C /

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/ogsmd/libfsobasics0_0.8.1.0+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk"
ar -x libfsobasics0_0.8.1.0+gitr367+3c3e1b862cdde806cef8f502dfe79f1d48f1c5d7-r6.1_armv4t.ipk
tar -xvzf data.tar.gz -C /

We will use SHR frameworkd.conf:

wget "http://git.shr-project.org/git/?p=shr-themes.git;a=blob_plain;f=frameworkd/frameworkd-config-shr/om-gta02/frameworkd.conf;hb=HEAD" -O /etc/frameworkd.conf

If the following file doesn't exists, libgsm0710mux segfaults (see http://trac.freesmartphone.org/ticket/467)

cat << __EOF > /etc/abyss.conf
[omuxerd]
autoopen = 1
autoclose = 1
autoexit = 1
[session]
mode = 1
framesize = 98
port = /dev/ttySAC0
speed = 115200

[device]
wakeup_threshold = 6
wakeup_waitms = 200

__EOF

And if this one doesn't exists, fso-abyss claims it doesn't provide any channel

touch /etc/cornucopia.conf

A file may have permissions problem, first check it:

ls -l /usr/lib/dbus-1.0/dbus-daemon-launch-helper

If the group isn't messagebus:

chgrp messagebus /usr/lib/dbus-1.0/dbus-daemon-launch-helper
chmod u+s /usr/lib/dbus-1.0/dbus-daemon-launch-helper # because chgrp removes the SUID

Launch Ogsmd

Let's kill the old stuff...

killall -9 ogsmd

...and launch te framework:

frameworkd -s ogsmd

If no error (Python Traceback) occurs, we can move on:

libfso-glib sample
Install libfso-glib

wget "http://trac.hackable1.org/trac/raw-attachment/wiki/libfso-glib/libfso-glib0_0.2.0-gitrx44+9d292508739452b55b80ec40ec57405a5de2159f-r0_armv4t.ipk"
ar -x libfso-glib0_0.2.0-gitrx44+9d292508739452b55b80ec40ec57405a5de2159f-r0_armv4t.ipk
tar -xvzf data.tar.gz -C /

Install the sample (See the sources)

wget http://trac.hackable1.org/trac/raw-attachment/wiki/libfso-glib/sample-libfso-glib_0.1-1_armel.deb
dpkg -i sample-libfso-glib_0.1-1_armel.deb
sample-w

You will be asked for your PIN (unless you are already authentified) and you will be registered.

Then, it will catch several signals. after that, you can call yourself and see the signals "CallStatus" be matched. These signals are sent whenever the status of a call (which ID is specified, i.e. "1") change. (ie "incoming" or "release"). See FSO doc for further information.

And now what ? You can already, by reading freesmartphone.h, find any interesting function you need and write nice applications.

Any question ?
If you have any question about this manipulation or about Hackable:1, feel free to ask in the comments.

You can fin updates of this tutorial on our trac

khorben: Cross-compiling Debian packages for hackable:1, part 2

khorben@defora.org (khorben) — Tue, 18 Aug 2009 10:09:23 +0000

I wrote a while ago about how to cross-compile Debian packages, and within the
hackable:1 Linux distribution in particular. I'm glad to say that I managed to
find a decent work-around for a problem I mentioned last time: dh_shlibdeps
couldn't work.

dh_shlibdeps is in fact a wrapper around the dpkg-shlibdeps command. This
command analyzes every binary and library shipped in a package being generated,
in order to automatically list their dependencies. This can be problematic when
cross-compiling, since the binaries don't match the current architecture, and
may not even match the database of installed packages.

The trick here is to force dh_shlibdeps to:

look into the cross-compilation root folder,
read the dependency tracking information specially written for the occasion.

This is now done using this syntax in hackable:1:

$ dh_shlibdeps -l/usr/$(DEB_HOST_GNU_TYPE)/lib:/usr/$(DEB_HOST_GNU_TYPE)/usr/lib \
-- -Ldebian/shlibs.cross

where:

-l does the former directly,
and -L does the latter through dpkg-shlibdeps (escaped with --).

With this fix, the packages cross-compiled are almost as good as native ones,
stripping being the last culprit (only eating space). This will require a
modification to all the packages, but it will then help a lot with automated
images generation.

hackable:1 official blog: hackable:1 makes your device happy

Mon, 17 Aug 2009 14:11:00 +0000

As a lot of you know, at Bearstech, we're very serious with hackable:1 and what we intend to do with it.

If you were to ask to a typical hackable:1 developer, he'd probably say he crafts his code as he would paint an art piece or carve a nice wooden table. All the development is done for your GTA02 pleasure.

As can prove the following pictures, left alone, our GTA02s are not that happy. See how they seem to whine or just how they seem alone, oblivious to the fact that they're with their peers:

But then, a little bit of H:1 magic, and look at how they seem to shine in happiness, all directed towards the same common objective, united to fight for their common goal:

There is no ~~spoon~~ more proof needed to say that hackable:1 will make your device happy. Up to you guys !

iscape: Behind the scenes of Bearstech

noreply@blogger.com (marcus) — Fri, 14 Aug 2009 06:53:46 +0000

As part of our research & development on mobile devices we are currently participating on a project from ANR, the Agence Nationale de la Recherche - the french national agency for research. This project is about mobility and multihoming and we do the Linux terminal part.

Currently we are investigating the transport layer and here specifically SCTP. SCTP is on the same layer as TCP or UDP but combines advantages of both protocols and adds multihoming capability.

SCTP opens independent so called streams on one connection. In order to distinguish it from TCP a connection is therefore called an association.

Another difference with TCP is that SCTP is a message oriented protocol and not a stream oriented protocol. This is very handy for the application developer as one does not have to collect and reassemble the data packagewise but gets it delivered in a whole.

Other nifty features include automatic network interface detection together with a heartbeat and automatic failover to any other known working network interface.

Last not least the streams are indepent. This can be used for reliable delivery on networks with package loss by sending a message over every stream. If one sends a message with TCP ten times and one gets lost then the subsequent messages get stuck until the lost package has arrived. This is known as head-of-line problem. With SCTP streams are independent and thus delivery on other streams continues even when a package on one stream was lost and therefore is blocked for retransmission.

That's it for today for the Bearstech Labs, stay tuned!

hackable:1 official blog: Welcome on our new hackable:blog !

Thu, 13 Aug 2009 17:35:21 +0000

Hey everyone,

Long time no see. At last, we decided to setup a blog in order to keep you all in touch with what you need to know about hackable:1, and about the new things we do.

Stay tuned, as we're bounded to put a lot of things here sooner than later!

khorben: New project: gprs for hackable:1 on the Openmoko Freerunner

khorben@defora.org (khorben) — Thu, 06 Aug 2009 11:10:10 +0000

I have just released the first version of gprs, a tool to ease connections to the GPRS network on hackable:1, for the Openmoko Freerunner in particular. The project's homepage is here:
http://people.defora.org/~khorben/projects/gprs/

It's still alpha quality but already works in some conditions. I have uploaded a couple screenshots as well. I hope to package it soon, it will then be instantly available via the daily builds.

zecrazytux: mkdebpackaging.sh: a minimalistic, crosscompilation-aware replacement for dh_make

Thu, 11 Jun 2009 22:00:00 +0000

mkdebpackaging.sh: a minimalistic, crosscompilation-aware replacement for dh_make

the first step to create a debian package is usually using `dh_make', that creates a few important files that are used to describe the package(s):

debian/control: which packages are generated, what is necessary to build, install…
debian/changelog: gives the version number of the package and keeps traces of everything that happened to that package.
debian/rules: a Makefile describinghow the software should be built

why did I wrote a replacement for dh_make ?

dh_make does not support take care of crosscompilation-only CFLAGS or LDFLAGS so that we had to tweak every debian/rules templates each time. Copy & paste is boring and time-ineficient.
dh_make creates a somewhat “too big” Makefile for our needs.

How to use it

cd into a software source directory (remember that directories should be named something like softname-X.x (X.x being the version)).
execute the script:
$ /path/to/mkdebpackaging.sh -m “Sebastien BOCAHU” -e “sbocahu-AT-bearstech.com”
edit debian packaging templates (files into debian/)
build the package:
$ dpkg-buildpackage -us -uc # for native compilation
$ dpkg-buildpackage -us -uc -aarmel # for ARM crosscompilation

Review it and give your point of view !

I wrote it quite quickly and many things can certainly be improved, so please tell me :)
Patching ltmain.sh (libtool) can fail, so that you have to dig into it by your own.

jbl2024: embedded webapp on the freerunner

Sun, 07 Jun 2009 16:08:00 +0000

This weekend, i played with nitrogen on my freerunner :

The funny thing is that it is a full web app with the webserver running on the freerunner. Thanks to the nitrogen framework, the code is not bloated as usual and is quite simple.

Example : the clock is refreshed by the server every minutes with these simple statements:

body() -> 
	Body = [	
    	#panel { class="h1-logo", body = [#image { image="/images/hackable1.gif"} ] },
	    #label { id=clock, text="10:14"},
    	#label { id=mylabel, text="" }
    ],
	wf:comet(fun() -> clock_update(clock) end),
	wf:render(Body).

clock_update(Clock)->
    {_Date, {Hour, Min, _Sec}} = erlang:localtime(),
    Value = io_lib:format("~2.10.0B:~2.10.0B", [Hour, Min]),
    wf:update(Clock, lists:flatten(Value)),
	wf:comet_flush(),
	timer:sleep(1000*60),
    clock_update(Clock).

Last but not least, the client runs well on my laptop too :

So we have the best of the both worlds (web & desktop) :

access to native resources thanks to erlang
event driven code with nitrogen (push with comet)
customized ui (jQuery)
distributed client (example : accessing the contact list without installing crappy software)

The main drawback is performance (for the ui part) and memory consumption (i need to make some tests to figure out exactly).

The source code for the nitrogen/erlang part is available here : http://blondon.fr/blog/public/web_s... I'll post the whole app (html, media and css) asap.

khorben: How to flash Openmoko flash images very fast

khorben@defora.org (khorben) — Thu, 28 May 2009 23:31:39 +0000

There is a very nice and fast alternative to using dfu-util to flash images on the Openmoko Freerunner phone:

boot the developer version of hackable:1 on an SD card
use dd like this:

# cat Hackable1-Openmoko-Freerunner-user-daily-rootfs.jffs2 /dev/zero | \
     		| dd of=/dev/mtdblock6

for the root filesystem, and:

# cat uImage.bin /dev/zero | dd of=/dev/mtdblock3

for the kernel.

Even better, if you don't want to create a temporary copy of the image to flash, transfer it on the fly via SSH:

# cat Hackable1-Openmoko-Freerunner-user-daily-rootfs.jffs2 /dev/zero | \
     		progress ssh root@192.168.0.202 dd of=/dev/mtdblock6
     [...]
139853824 bytes (140 MB) copied, 278.255 s, 503 kB/s

Just omit progress if you don't run NetBSD, or use either this port or this version.

jbl2024: hackable:1 rev4 and the gprs

Thu, 21 May 2009 05:47:00 +0000

I'm using the gprs almost every days during my train trips. It works like a charm although it does not use the muxer. Here are the detailed instructions to use the muxer :

change MUX=no to MUX=yes in /usr/bin/p and /usr/bin/x
change delay from 5 to 10 in /usr/bin/x (lines 65 & 69)
in /etc/ppp/peers/gprs :
- line 36 : comment the /dev/ttySAC0 option
- line 42 : uncomment the updetach option
- line 43 : comment the nodetach option

reload the gui stack (/etc/init.d/xserver-hackable1/restart), wait for registration and launch the p script.

Now you can use the gprs and use the phone as the same time (but the gprs connection will hang when calling)

By the way, in order to improve the phone experience, the latest svn version of the openmoko-gsm-applet now handle the gprs automatically :

start when the registration is done
stop when starting a call
stop when receiving a call
restart when call is finished

TODO :

use some gconf keys to check if gprs is allowed to start (see http://trac.hackable1.org/trac/wiki/settings#Settingsspecificationpage )

zecrazytux: Wifig available – documentation about packaging and crosscompilation for Hackable:1 libcommongui0 wifig

Mon, 20 Apr 2009 22:00:00 +0000

Wifig available – documentation about packaging and crosscompilation for Hackable:1

Wifig

I've packaged jbl2024’s wifig, an application for easily configuring wireless access.

For now, packages aren’t available on the hackable:1 repository. You can find them on my website:

Wifig requires (missing in the stock hackable:1 rev3 release):

libcurl
udhcpc
wmiconfig

Please review it !
It needs to be polyshed (be added on the menu, for example)

Documentation about packaging and crosscompilation for Hackable:1

I've wrote a bit of documentation about packaging, crosscompilation and possible problems with the crosscompilation envrironnement:

I hope this kind of documentation would help people to contribute :) !

khorben: Cross-compiling Debian packages for hackable:1

khorben@defora.org (khorben) — Fri, 17 Apr 2009 00:00:36 +0000

I was finally able to create my first cross-compiled Debian package this evening. This wasn't without a lot of pain, and some issues remain. Still, it's worth mentioning how to reproduce it, along with the problems that I have more or less solved along the way.

Requirements

It's somewhat easier to start from hackable:1's cross-compiling environment. In fact there are still a few glitches to get it truly working, as always just create tickets if you get stuck (or solve something yourself).

pkg-config 0.23

In contrast with the current autoconf/automake/libtool's nightmare, pkg-config has managed to make life easier. This is particularly true since its 0.23 release and fix for the PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_LIBDIR environment variables. In our case, they are set as follows:

export PKG_CONFIG_LIBDIR="/usr/arm-linux-gnueabi/usr/lib/pkgconfig:/usr/arm-linux-gnueabi/usr/share/pkgconfig"
export PKG_CONFIG_SYSROOT_DIR="/usr/arm-linux-gnueabi"

This does two important things:

prefix the relevant CFLAGS and LDFLAGS flags with the path to the cross-compiled include and library files;
forces pkg-config to only look at the definition files for packages installed in the cross-compilation environment.

Unfortunately, Debian does not include pkg-config 0.23 yet. I have explained how to install it from source, but even better I have packaged the patched 0.23 release in hackable:1. It will appear from the upcoming build bot soon.

libmokoui2

Unlike jbl2024 with neod, I have settled on libmokoui2. Here's a summary of the issues I ran into.

$ dpkg-buildpackage -rfakeroot -us -uc -aarmel
[...]
checking for C compiler default output file name... 
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [config.status] Error 77
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

Here's what said in config.log:

configure:2950: arm-linux-gnueabi-gcc -g -O2  -Wl,-z,defs -lX11 conftest.c  >&5
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/arm-linux-gnueabi/bin/../../lib/libX11.so when searching for -lX11
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: skipping incompatible /usr/arm-linux-gnueabi/bin/../../lib/libX11.a when searching for -lX11
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: cannot find -lX11
collect2: ld returned 1 exit status

The solution here is to force the LDFLAGS, as follows:

ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
CROSS= --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
LDFLAGS=-L/usr/$(DEB_HOST_GNU_TYPE)/lib -L/usr/$(DEB_HOST_GNU_TYPE)/usr/lib
else
[...]
./configure $(CROSS) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs $(LDFLAGS)"

This works much better. We even got rid of -lX11, which should not be necessary: it is already required by the other libraries which will be used.

libtool nightmare

This is what drove me nuts again. I am not the only one:

« You might play with compiler and linker flags, try to hack and understand the libtool shell script (best of luck if you can decipher it), and end up cursing the ancestors of those who ever came up with such a dumb system. »

...and so I read it, and cursed endlessly. Thousands of lines of shell stress-testing code. To put it shortly, libtool is re-generated everytime you run ./configure, which appends ltmain.sh to some configuration variables.

At this point, depending on which LDFLAGS you're using, libtool will have a life of its own, sometimes replacing -lname by /usr/lib/libname.so, sometimes not (and ignoring most other flags). This got wrong in our case; in fact, libtool was correct in picking up *.la files (libtool's own library description format) in /usr/arm-linux-gnueabi/usr/lib, but it was blindly trusting them as they mention the libraries are stored in /usr/lib instead.

The solution should have been as "simple" as using -inst-prefix-dir (which I did not know about, and found by reading the code). Unfortunately it wasn't and I had to patch ltmain.sh to obtain what I feel is the correct fix:

test -f "$inst_prefix_dir$add" && add="$inst_prefix_dir$add"

This checks if the library is in the staging directory, which takes then precedence over the normal path.

dh_strip and dh_shlibdeps

I was totally expecting them to break: dh_strip hardcodes strip as the executable to run (instead of $(DEB_HOST_GNU_TYPE)-strip). Likewise, dh_shlibdeps will have to be modified to support cross-compilation. So I temporarily disabled them both.

And the winner is...

It feels good when it works:

dpkg-deb: building package `libmokoui2-dev' in `../libmokoui2-dev_0.3+svn4878-1_armel.deb'.
dpkg-deb: building package `libmokoui2' in `../libmokoui2_0.3+svn4878-1_armel.deb'.
dpkg-genchanges  >../libmokoui2_0.3+svn4878-1_armel.changes
dpkg-genchanges: including full source code in upload
dpkg-buildpackage: full upload (original source is included)

It's not so bad, I learned some :)

iscape: hello planet hackable:1

noreply@blogger.com (marcus) — Thu, 09 Apr 2009 02:13:27 +0000

Hello Planet,

am just testing my blogging set up here, more posts with real content to follow soon.

khorben: hackable:1 as a Xen guest

khorben@defora.org (khorben) — Thu, 02 Apr 2009 23:16:42 +0000

As probably already pretty obvious here, my main Operating System is NetBSD. Over the past few weeks, I've been trying virtualization, using Xen with NetBSD as the native host. This excellent howto describes the whole procedure better than I could do it.

This wasn't without a few issues though. Here's what was important in my case:

Xen device files

Don't forget to create the device files:

# cd /dev && MAKEDEV xen

The bootloader

For 64-bit hosts, or simply if your / partition is "big" (somewhere between 512MB and 4096MB in my experience), then you must use NetBSD's native bootloader. It requires NetBSD 5.0 (or -current, and you can also get it to work on 4.0 and below).

First, don't forget to copy /usr/mdec/boot to /boot when updating the bootloader (symptom is "unknown command"). Then, copy and modify /boot.cfg from /usr/src/etc/etc.amd64/boot.cfg:

menu=Boot normally:boot /netbsd.gz
menu=Boot Xen:modules enabled;load /netbsd.xen0 bootdev=wd0a ro console=pc;multiboot /xen.gz dom0_mem=1024M
menu=Boot single user:boot /netbsd.gz -s
menu=Disable ACPI:boot /netbsd.gz -2
menu=Disable ACPI and SMP:/boot /netbsd.gz -12
menu=Drop to boot prompt:prompt
default=1
timeout=10

Create the virtual machine

You can use a plain file as the guest, to be able to switch between Xen and qemu at will. I have detailed my procedure below.

Create and partition a 20GB file

I'm not sure if this blocksize is optimal. You may also feel free to set swap space at this stage, I chose to proceed without any:

# dd if=/dev/zero of=ldeb bs=1024*1024 count=20480
# vnconfig -c vnd0 ldeb
# fdisk -u vnd0
[...]
Do you want to change our idea of what BIOS thinks? [n] n

Partition table:
0: <UNUSED>
1: <UNUSED>
2: <UNUSED>
3: <UNUSED>
Bootselector disabled.
No active partition.
Which partition do you want to change?: [none] 0
The data for partition 0 is:
<UNUSED>
sysid: [0..255 default: 169] 131
start: [0..xcyl default: 63, 0cyl, 0MB] 63
size: [0..xcyl default: x, xcyl, xMB] $
bootmenu: []

Partition table:
0: Linux native (sysid 131)
   start 63, size 41942977 (20480 MB, Cyls 0-2610/212/34), Active
       PBR is not bootable: All bytes are identical (0x00)
[...]
Which partition do you want to change?: [none]

We haven't written the MBR back to disk yet.  This is your last chance.
Partition table:
[...]
Should we write new partition table? [n] y

NetBSD also needs a disklabel to identify the different partitions:

# disklabel -Ii vnd0
partition> a
Filesystem type [?] [4.2BSD]: Linux Ext2
Start offset ('x' to start after partition 'x') [0c, 0s, 0M]: 63
Partition size ('$' for all remaining) [xc, ys, zM]: $
partition> W
Label disk [n]? y
Label written
partition> Q

Format and mount the partition

I force a block size of 4KB for compatibility with NetBSD, and 128 bytes per inode for performance:

# mke2fs -b 4096 -I 128 /dev/vnd0a
# mkdir /mnt/ldeb
# mount /dev/vnd0a /mnt/ldeb

Download and extract hackable:1

# wget http://build.hackable1.org/Hackable1-Openmoko-Freerunner-cross-daily.tar.gz
# tar -xzvpf Hackable1-Openmoko-Freerunner-cross-daily.tar.gz -C /mnt/ldeb

Download and install the kernel modules

We're using Xen 3.0.4 now to make sure it is well supported as of today. The kernel itself doesn't need to be on the partition, and will be installed later:

# wget http://bits.xensource.com/oss-xen/release/3.0.4-1/bin.tgz/xen-3.0.4_1-install-x86_64.tgz
# tar xzvf xen-3.0.4_1-install-x86_64.tgz dist/install/lib/modules \

dist/install/boot

# mkdir -p /mnt/ldeb/lib/modules
# mv dist/install/lib/modules/2.6.16.33-xen /mnt/ldeb/lib/modules

Unmount the partition

And take care of the vnd pseudo-device as well:

# umount /mnt/ldeb
# vnconfig -u vnd0

Install the kernel image

Copy the kernel next to the image:

# cp dist/install/boot/vmlinuz-2.6.16.33-xen /home/xen/ldeb.xenU

Configure the virtual machine

This is my configuration file, with the comments stripped off:

# cat > /usr/pkg/etc/xen/ldeb << EOF
kernel = "/home/xen/ldeb.xenU"
memory = 768
name = "ldeb"
cpu = 1
vif = [ 'mac=aa:00:00:50:02:f0, bridge=bridge0' ]
disk = [ 'file:/home/xen/ldeb,0x300,w' ]
root = "hda1"
extra = "root=/dev/hda1 ro"
EOF

Boot the machine

Finally, if all is well:

# xm create -c /usr/pkg/etc/xen/ldeb

You should then be able to login as root. It's recommended to install libc6-xen, some other tweaks may be useful too. I'll be all ears :)

Update:

the disklabel is better now:
using "Linux Ext2" instead of "4.2BSD"
starting at offset 63
the flag to mke2fs was wrong (it's -I to specify the bytes per inode)
it's probably vnd0a instead of vnd0e

zecrazytux: Barcamp à SUPINFO Marseille le 17 avril

Sat, 07 Mar 2009 23:00:00 +0000

Barcamp à SUPINFO Marseille le 17 avril

Un barcamp aura lieu le vendredi 17 avril à SUPNFO Marseille.

J'y présenterais l'OpenMoko, Hackable:1, et plus généralement le projet de Hackable Devices de Bearstech qui m'intéresse beaucoup.

N'hésitez pas à venir nous rejoindre, que vous ayez un OpenMoko où non !

Différents thêmes seront abordés, et je présenterais également NetBSD, pkgsrc et Xen sur NetBSD lors de ce Barcamp.

Plus d'informations ici :)

Venez nombreux !

jbl2024: Finger scrolling and the freerunner

Sat, 21 Feb 2009 07:09:00 +0000

The openmoko-today app actually implements a kind of finger scrolling, but i find it very weird. I launch applications instead of scrolling every time i try to scroll.
In order to achieve finger scrolling, i have created a scrolled window with an event box above. The scrollbars are hidden and i'm listening to the button-press, button-release and motion-event signals to handle everything.

How to scroll the window

The initial Y position is saved in the button-press callback.
In the motion-event callback, we have the current Y position. A delta is calculated between theses 2 values
This delta is applied to scroll the window (by changing the GtkAdjustment value).

How to detect a mouse click instead of a scrolling action

In order to detect mouse click instead of scrolling :

i launch a short timer when the user click on a button.
When the timer expires, the button is saved in a variable and is activated.
The timer is canceled whenever the motion-event is fired (and the button variable is cleared).
When the user raises his finger (button-release signal of the eventbox), if the button is still here, the clicked signal is fired.

Implementation

The source code for the finger scrolling system can be found in libcommongui .

For an example of usage, see wifig

jbl2024: erlang on hackable:1

Sat, 14 Feb 2009 09:23:00 +0000

Erlang works out of the box on hackable:1

Here are the steps to make a little gtk app :

install erlang :

apt-get install erlang

Download gtknode at http://code.google.com/p/gtknode/ Then :

./configure --prefix=/usr
make
make install

test and enjoy :

%%%-------------------------------------------------------------------
-module(testerl).

-export([start/0]).

-record(widget, {id, name}).

-define(G(C,A),gtknode:cmd(hello,C,A)).

create_button(Winstruct, Label)->
    Id = ?G('Gtk_button_new_with_label',[Label]),
    ?G('Gtk_box_pack_start', [get_vbox(Winstruct), Id, false, false, 5]),
    ?G('Gtk_widget_show',[Id]),
    Widget = #widget{name = "Name", id=Id},
    add_widget_to_struct(Widget, Winstruct).


get_vbox(Winstruct)->
    [Vbox] = dict:fetch(vbox, Winstruct),
    Vbox.
    
    
add_widget_to_struct(Widget, Winstruct) when is_record(Widget, widget)->
    Widgets = dict:fetch(widgets, Winstruct),
    dict:store(widgets, [Widget|Widgets], Winstruct). 

add_to_struct([], Dict)->
    Dict;
add_to_struct([{Key, Value}|Tail], Dict)->
    DictBis = dict:append(Key, Value, Dict),
    add_to_struct(Tail, DictBis).

start() ->
    gtknode:start(hello),
    Win = ?G('Gtk_window_new',['GTK_WINDOW_TOPLEVEL']),
    ScrolledWindow = ?G('Gtk_scrolled_window_new', [ 'NULL', 'NULL']),
    ?G('Gtk_container_add',[Win,ScrolledWindow]),
    ?G('Gtk_scrolled_window_set_policy', [ScrolledWindow, 'GTK_POLICY_NEVER', 'GTK_POLICY_ALWAYS']),

    Viewport = ?G('Gtk_viewport_new', ['NULL', 'NULL']),
    ?G('Gtk_container_add',[ScrolledWindow, Viewport]),
 
    Vbox = ?G('Gtk_vbox_new', [false, 0]),
    io:fwrite("Vbox = ~p~n", [Vbox]),
    ?G('Gtk_container_add',[Viewport,Vbox]),
 
    But = ?G('Gtk_button_new_with_label',["butté"]),
    
    ?G('Gtk_widget_set_name', [But, "button"]),
    ?G('Gtk_box_pack_start', [Vbox, But, false, false, 5]),
    
    ?G('Gtk_widget_show',[Win]),
    ?G('Gtk_widget_show',[ScrolledWindow]),    
    ?G('Gtk_widget_show',[Viewport]),
    ?G('Gtk_widget_show',[Vbox]),
    ?G('Gtk_widget_show',[But]),
    ?G('GN_signal_connect',[But,clicked]),
    ?G('GN_signal_connect',[Win,destroy]),
   
    Winstruct = add_to_struct([{window, Win}, {vbox, Vbox}, {widgets, []}], dict:new()),
    loop(Winstruct, But).


loop(Winstruct, But) ->
    receive
        {hello,{signal,{But,clicked}}} ->
            io:fwrite("widget : ~p  ~p~n",[But, clicked]),
            io:fwrite("winstruct = ~p~n", [Winstruct]),
            WinstructB = create_button(Winstruct, "toto va a la plage"),
            loop(WinstructB, But);
        {hello,{signal,{_,destroy}}}  ->
            gtknode:stop(hello)
    end.

erl -sname anode@localhost
(anode@localhost)1> c(testerl).
(anode@localhost)2> testerl:start().

iscape: apple, ipods and navigation systems

noreply@blogger.com (marcus) — Wed, 23 May 2007 23:44:52 +0000

I just had the other day the opportunity to see my parents using a navigation system for their first time. Actually it was a "PNA", a PDA form factor system specifically designed for the task of navigation. I have to add that my Father is engineer and that my parents have a computer since 10 years. Nevertheless the user interface was all but intuitve to them. Without my help they would have never succeded to get the thing running.

Apples iPod was not the first mp3 player, yet its success is based on its superior usability.

To quote Antoine de Saint-Exupery:
"It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away."

My point is that lots of software is way to overengineered for the non-geek user. Too many features, too much technical stuff under the hood, while forgetting about the main purpose, whether this is playing mp3's or bringing you from A to B.

Apart from watching people using software I have learned a lot from Kathy Sierra's blog "Creating Passionate Users".

Actually I wonder if part of google's success is simply based on the fact that the front page www.google.com has never gotten cluttered with other stuff like yahoo or msn.

And a last note: I can't use my car radio without the manual - I'm not joking. In fact I simply refuse to read the manual for a radio. Long ago the days when there were just two turning knobs: on/off-volume and search a station.