Content tagged hackable1

What's going on?

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

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 :)

Calibrating the HTC TouchPro's touchscreen

khorben@defora.org (khorben) — Wed, 6 Apr 2011 15:21:48 +0200

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/

hackable:1 welcomes a new developer: Trim

khorben@defora.org (khorben) — Sat, 2 Apr 2011 16:26:00 +0200

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!

hackable:1 builds and provides a package repository for Maemo

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

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

New unofficial beta release of hackable:1

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

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

Over 10 thousand commits

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

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

Resurrecting RunningBear

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

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' 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

Compiling Android applications on NetBSD

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

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 :)

Installing the Meego SDK on Debian Squeeze

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

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 :)

First (unofficial) release of the DeforaOS smartphone environment

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

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!