Content tagged hackable1

News from the hackable:1 front

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

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.

The DeforaOS smartphone environment

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

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

Working on gsmd

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

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

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

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

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.

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

khorben@defora.org (khorben) — Thu, 6 Aug 2009 13:10:10 +0200

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.

How to flash Openmoko flash images very fast

khorben@defora.org (khorben) — Fri, 29 May 2009 01:31:39 +0200

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.

Cross-compiling Debian packages for hackable:1

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

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

hackable:1 as a Xen guest

khorben@defora.org (khorben) — Fri, 3 Apr 2009 01:16:42 +0200

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: 
1: 
2: 
3: 
Bootselector disabled.
No active partition.
Which partition do you want to change?: [none] 0
The data for partition 0 is:

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

Surfing and cross-compiling glib for RunningBear

khorben@defora.org (khorben) — Sun, 29 Mar 2009 05:24:06 +0200

Yeah, it's late, we lose an hour, I was tired already, and with a broken back on top of that. I got an external patch for my back (greets to Thom), and of course when coming back home I felt like coding again.

First, I continued to work on the Gtk+ WebKit version of DeforaOS Web Surfer, which is now almost as good as it used to be. By the way, there is even a reference manual using gtk-doc.

Then, thanks to the valuable experience acquired below, I managed to fix the compilation of Xynth in RunningBear, and then I learned to cross-compile glib correctly. I was in a relatively bad mood, anticipating being homesick again in the next couple of weeks, but it turned into a quite productive evening at home :)

While I'm at it, here are a couple of (outdated) screenshots of the Web Surfer, running on hackable:1.

With the GtkHtml2 engine:
http://people.defora.org/~khorben/share/DeforaOS/surfer/surfer-hackable1-daily-gtkhtml.png

The same, fullscreen:
http://people.defora.org/~khorben/share/DeforaOS/surfer/surfer-hackable1-daily-gtkhtml-fullscreen.png

Working on hackable:1's daily build

khorben@defora.org (khorben) — Fri, 20 Mar 2009 03:19:30 +0100

Yeah, it's late again, but I'm addicted to the stuff. Today was frustrating again for a number of reasons:

grub doesn't load 64-bit NetBSD kernels
worse, it doesn't load the Xen hypervisor kernel correctly on « big » FFSv1 partitions (mine is 4GB)
all NetBSD/i386 kernels suddenly panic on my T60's PCMCIA controller (I found an INSTALL-FLOPPY kernel without the issue when breaking my bootloader though)
you're gonna say NetBSD sucks, but booting my freshly updated Debian Lenny backup USB drive, it refused to recognize my Ethernet card *and* my Wireless card refused to associate anywhere
as if this wasn't enough, my Intel gigabit card forgot its own MAC address for a while (and then it fixed itself...)
RunningBear is giving me a hard time with crashes that I cannot explain so far
gdm (or Xorg) lost my keyboard during three subsequent reboots (it fixed itself again)
wpi(4) panic'd when it couldn't read its firmware
and again, there are so many things to do and fix only for work that I hate losing time on meaningless problems like these ones :(

Therefore, I needed to get something to work right. After re-writing half of hackable:1's image generation script (the dependency resolving process), I knew I must have broken the daily builds. I figured a couple days ago that I was sadly right, and I still haven't fixed the key generation with dropbear :(

Anyway, I think I managed to fix crashes with phone-kit and neod in the daily build (permissions to the audio subsystem). I restored the installation of tangogps on the system, and added -n to gpsd's options, which should help with the first fix without exhausting the battery much (tests required). Finally, I got GPS to work on my laptop, using the Openmoko Freerunner over USB. Now I can sleep...

Update: regarding the keyboard problem, I think it's a bug in the modular-xorg-server port for NetBSD, which was starting on top of an existing text console.