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

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!

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)

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.
All in all, more reliable GSM & suspend, and almost all the features one may need. Stay tuned!

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 !

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!

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!

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 :

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.

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:

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!