Planet Linux-to-go

Richard 'RP' Purdie: The spirit of Linux lives on (literally)

Mon, 14 May 2012 21:03:40 +0000

One memory that springs to mind this evening is something tglx said at a plumbers conference about modern Linux hackers of the modern generation not being able to hold to traditional values, like properly enjoying beer!

I think this evening we proved that wrong. If the team here in Romania was trying to get me drunk, they’re going to have to try harder but it was an enjoyable evening and I think there are people who appreciate those traditional values, long may it continue!

Paul 'pfalcon' Sokolovsky: Solar cell types and their looks

noreply@blogger.com (pfalcon) — Thu, 10 May 2012 14:28:37 +0000

Following cool solar experiments at jeelabs.org, I also got idea to attach something to a solar cell. But first, figure out what types of them exists and available. Regarding the first, you can read in Wikipedia. But that's example of dried-out wikipedia article, giving a lot of formal facts, but little practical knowledge. What I'd like to know is what types are typically available in small consumer products.

Here's what I researched. First type is brownish, with regular vertical or horizontal lines. It's the type of solar cell which have been see for at least 20 years in calculators. So, that's amorphous silicon solar cell, less expensive (explains why we had it for 20 years around) and less efficient, they say. But they also say that there're special subtypes, designed to work in low-light conditions (specifically, provide enough voltage, even though current may be miniscule). Here's how it typically looks:

Last years, another type became widely available in cheap stuff - crystalline silicon solar cells. In cheap stuff, they look like black (or dark) colored plate, covered with few millimeter of something like epoxy, in which you can clearly see metal wires - oftentimes in irregularly spaced groups. Looking closely, it can be seen that epoxy actually holds individual bars of crystalline silicon, and irregular spacing of builtin wires are in particular due to irregular cuts of these bars in the original wafer.

Here's close up:

They say that crystalline is more efficient than amorphous, but more expensive. Explains why we started to see it around much later than amorphous. There's also mono-crystalline and poly-crystalline varieties, the first being more expensive, so my guess is that in cheap stuff we have poly-crystalline. It appears that small-size crystalline are rated for smaller voltage (2v) than an amorphous, which you can find for ~5V.
They also say that under dimmer lighting, crystalline cells provides reduced voltage.

Paul 'pfalcon' Sokolovsky: "Arduino Hosted" Python Module

noreply@blogger.com (pfalcon) — Thu, 10 May 2012 14:03:44 +0000

Here's what I've been hacking for some time now - a Python module which allows to run Arduino, etc. code on a host computer, while still allowing to access Arudino (etc.) hardware. Of course, this is very obvious idea, so announcement of such project should proceed with explaining why yet another one? Two requirements I had was: using human readable/writable underlying protocol for communication with the board and being as much as possible compatible with original Arduino API/syntax. Regarding the latter, Arduino wiki's Interfacing/Python lists few modules which allow to control Arduino from Python, but you may find it amusing how they go out of their way to deviate from standard Arduino API (I saw as funky stuff as "board.digital[13].write(1)", but even the humblest has digital_write() instead of digitalWrite()). On the contrary, with Arduino Hosted, standard Blink example looks like:

#!/usr/bin/env python
import arduino

arduino.init(debug=True)
from arduino import *

def setup():
    pinMode(LED, OUTPUT)

def loop():
    digitalWrite(LED, HIGH)
    delay(1000)
    digitalWrite(LED, LOW)
    delay(1000)

arduino.run(globals())

That's pretty direct translation of C code (plus few idioms), and directly translatable back to C. And that's idea - you prototype and debug code in hosted environment, and then can easily translate it to native code (to keep debugging on, because latency of of hosted and native execution is quite different which hides/adds lots of timing issues).

Regarding the board communication protocol, I knew about BusPirate before that, and was really happy to find Joby Taffey's BusNinja implementation for Arduino. Even more, I found the implementation for TI Launchpad from the same author (Launchpad's version somehow named "SPI Explorer"). So, BusPirate's protocol with extensions is what I based on. Of course that doesn't too well, especially with TI Launchpad, which has particularly crippled UART support. Other issue is that BusPirate (even binary protocol version) supports working with only one bus at time. That's fine for BusPirate's original purpose, but limiting for a project like this (well, so far I didn't have to use I2C and SPI at the same time).

What about Firmata? First of all, it doesn't support SPI, and working with SPI devices was the immediate need behind implementing this module. Secondly... Well, there's a saying "If the only thing you know is a hammer, then any thing around looks like a nail." That's must have been the idea behind designing a MCU control protocol basing on MIDI protocol. NO WAI.

Marcin 'Hrw' Juszkiewicz: Tizen: first impressions

Thu, 10 May 2012 01:17:29 +0000

During my stay in Oakland, CA (due to Ubuntu Developer Summit) I decided to attend also Tizen Developers Conference. Not that I have any relations with this platform — just wanted to meet some friends from Maemo times. And I did not had plans for Tuesday evening while Tizen visitors had social event planned in The California Academy of Sciences.

For those which do not know what Tizen is a bit of history. Years ago Nokia made few internet tablet devices (770, n800, n810) and phone (n900) which were running Linux distribution named Maemo. It was loosely based on Debian. In meantime Intel created Moblin which was their distribution for mobile devices. Few years passed and they joined forces and MeeGo was born. Nokia released N9 phone with it, ASUS had netbook running MeeGo and maybe few other devices appeared on market. Then history repeated: MeeGo merged with LiMo and they created Tizen project.

It is hard to tell was conference success or not because I did not attended any sessions there — just opening keynote by Jim Zemlin. On first day I also came for technical showcase and partner demos. But they were squeezed in very small room so it was hard to discuss with people showing their work. Maybe next time organizers will give at least 4m² per demo — this should be a minimum.

But today I got Tizen Developer Platform device and thumbdrive with SDK on it. So decided to play a bit with it. It was not enjoyable experience.

First ugly part was Tizen SDK “so-called” installer. 823MB shell script… I thought that those times passed long time ago. Anyway tried to run it. All I got was message that 64bits systems are not supported. Good to know that, but my x86-64 systems are able to run x86 binaries without problems. Ok, I made workaround and then got message about missing qemu, rpm, libsdl packages. No, I will not install rpm on my Ubuntu systems.

So I decided to cut that crappy shell script and take a look at tarball. Fast “tail -n+122 tizen-sdk-0423.bin >tizen-sdk.tar.gz” and I was able to extract SDK. Got 26 zip archives.

One of them contains rootfs created from packages based on Debian/Ubuntu packages. Some are from times when dinosaurs ruled the Earth (debianutils 2.17 was released in 2006), some are more fresh (like gcc-4.5 based on version from May 2011). In other words tradition started by Maemo is continued in Tizen and developers are given mix of fresh tools with long time forgotten ones. And Scratchbox 2.

To connect with device there is “sdb” tool. It introduces itself as “Smart Development Bridge” but in past it was named “Samsung Development Bridge” (run ‘strings’ on binary). And it’s father has a name “Android Development Bridge” and has some more options.

Anyway if you want to connect to device then few steps are required:

On device go to settings and set USB to ‘USB debugging’ mode. This will switch it into cdc_ether gadget.
On host do “sudo ifconfig usb0 192.168.129.1″ to configure networking.
Connect to device: “ssh root@192.168.129.3″

And then you can enjoy system which is a mixture of few Debian/Ubuntu versions. And forget about updates — unless you know how to get to 165.213.180.233 and know password of “kb0929.kim” user there (taken from /etc/apt/sources.list file).

Device uses Linux 2.6.36 kernel with unknown patches on top including CMA and Android ones. Quite old one but works. Hope to get newer one from someone.

What I do not like is availability of sources. There is review.tizen.org website with git repositories but I want to vomit when I see commits like “let’s add 2.6.36 kernel in one commit”. Lovely lack of ideas how to help developers.

What I will do with device? Not decided yet. Waiting for instructions how to get into bootloader to boot own kernels. Then who knows… replacing Tizen with Android or Ubuntu?

Related content:

Koen Kooi: Beaglebone software docs

Wed, 09 May 2012 14:40:05 +0000

Tutorials

Have a look at these websites to get an idea of what people have been working on.

The Ångström website has links to various tutorials and projects, you can find it at http://www.angstrom-distribution.org/

Limor Fried of adafruit.com fame has started a colletion of beaglebone related tutorials of one which deals with wifi: http://ladyada.net/products/beaglebone/index.html

Dan Watts has a number of tutorial on how to use the GPIOs and PWM pins: http://www.gigamegablog.com/tag/beaglebone/

Graeme Gregory has published an example kernel development workflow: http://www.slimlogic.co.uk/2011/05/openembeddedangstrom-kernel-workflow/

Reinstalling

To reinstall the SD card image you can completely reimage the SD card:

Visit http://downloads.angstrom-distribution.org/demo/beaglebone/ and get the img.xz you want. Then find out which drive corresponds with your SD card reader:

$ dmesg | grep sd

The output should look something like this:

sd 8:0:0:0: Attached scsi generic sg4 type 0
sd 8:0:0:0: [sde] 7626752 512-byte logical blocks: (3.90 GB/3.63 GiB)
sd 8:0:0:0: [sde] Write Protect is off
sd 8:0:0:0: [sde] Mode Sense: 03 00 00 00
sd 8:0:0:0: [sde] No Caching mode page present
sd 8:0:0:0: [sde] Assuming drive cache: write through
sd 8:0:0:0: [sde] No Caching mode page present
sd 8:0:0:0: [sde] Assuming drive cache: write through
 sde: sde1 sde2

This shows that it detected a 4GB card and assigned it to /dev/sde. In the next steps replace /dev/sdX with the name from the previous step. Be very careful with this using the wrong name can result in an erased hard drive.

To reimage the SD card do the following:

$ sudo -s

(type in your password)

# xz -dkc imagename.img.xz > /dev/sdX

# exit

This will take more than 20 minutes, usually 45-60 minutes, depending on the speed of your card reader and SD card.

Rebuilding

The SD card image in the box is based on the Ångström distribution. All Ångström binaries are built using OpenEmbedded. This document describes the steps necessary to setup an environment where you can rebuild the images and packages yourself.

The build is managed by scripts to make things easier, so get the setup scripts:

$ git clone git://github.com/Angstrom-distribution/setup-scripts.git

If you are behind a firewalling proxy, have a look at the oebb.sh file, it has built-in proxy handling.

Configure the setup scripts for the beaglebone:

$ MACHINE=beaglebone ./oebb.sh config beaglebone

Start with a kernel build:

$ MACHINE=beaglebone ./oebb.sh bitbake virtual/kernel

Or a small command line image:

$ MACHINE=beaglebone./oebb.sh bitbake systemd-image

Or rebuild the SD card image:

$ MACHINE=beaglebone ./oebb.sh bitbake cloud9-gnome-image

Marcin 'Hrw' Juszkiewicz: UDS-Q

Tue, 08 May 2012 13:14:38 +0000

Another May, another Ubuntu Developers Summit. This time I am in Oakland, California, USA (even if my tweets shows Dallas, Texas as geolocation).

As usual with US trips this one took insane amount of time. But I was 3cm from not going here… Why? Because I got stuck in toilet at home. Hopefully with help from neighbour I was able to bash door out and get to the bus stop on time.

Then standard set of bus, plane, plane, train and finally arrived in hotel. As my room was not yet ready I got 30$ coupon to bar to not waste time on waiting. Free meal/beer ;)

My room is at 17th floor (which means 15th) and has a nice view in the evening:

On Sunday I went to see San Francisco centre (I saw Golden Gate on earlier visit). Chinatown was interesting experience. Lot of people speaking language which I do not understand, shops full of food which I do not recognize.

Some random photos:

After getting some souvenirs and refilling of my US T-Mobile sim card I decided to go to the cinema for ‘The Avengers’ movie. It was nice experience. Touchscreen operated ticket machines which allow to buy ticket in one minute (but people were standing in long queue to buy tickets in ‘normal way’) made it even better. As in Poland there was big amount of commercials before movie (including some in style “our Army/Navy is great, why not join us”) but what I liked was just-before-movie animation reminding about not talking/texting/tweeting during movie (made with characters from “Madagaskar” series). Have to admit that RealD 3D glasses were more comfortable than Dolby 3D ones used by Polish cinemas. Movie itself was great but I think that will have to see it in Poland due to my English ;D

During evening there was usual Canonical internal plenary and then dinner. I even managed to sleep 6 hours despite jet lag ;D

Monday started with interesting keynote and presentation of Calxeda ARM server using technology they were talking about at previous UDS. Photos:

It is 2U case with 24 Serial-ATA discs and 12 nodes with 4 quad-core EnergyCore processors per node. The only cables inside are power ones as rest of connections is on pcb. Connection with world by four Ethernet connectors.

I went to “Create filesystems for embedded devices” session where we discussed how to make Ubuntu Core even smaller. People mentioned OpenEmbedded, OpenWRT, buildroot as usual, we got some strange use cases too. What will come from it? Time will show.

Plenaries were interesting. First Chris Kenyon told about cooperation with OEMs and ODMs and how it relates with Ubuntu. Laptop in a pizza box picture was nice — reminded developer boards. Then Bdale Garbee from HP shown us that there is no way to go though life without being served by HP technologies or hardware. Both talks were great and I hope that rest of plenaries will be like that.

After plenaries I went to San Francisco to register at Tizen conference and to meet some friends from Maemo times. Technical showcase and partner demos were boring and it was hard to feel that it is something innovative. But who knows… maybe Tizen will be yet another phone/tablet/ivi/etc OS even when Moblin, Maemo, MeeGo did not succeed.

During evening (back at UDS) there was ‘Meet & greet” social event. Our Linaro group (Amber, Ricardo, Paul, me) was showing member boards and replying to misc questions from audience.

What next? Sessions, social events, discussions about my patches with other developers, some sight-seeing.

Related content:

Marcin 'Hrw' Juszkiewicz: Thanks to Kindle I am back to reading

Mon, 23 Apr 2012 12:19:30 +0000

I always loved to read. In 6th class in elementary school I took fourteen books from school library at once (when only 3 were allowed). In 8th class I was going there only for required readings as there were no books there which could interest me (tough timing as I read all what liked and no money for new ones).

Basically during my school life I used several libraries and at most of them has a status of ‘frequent visitor’ which meant no need to say name during books exchange. Also booking of rare books was possible.

After studies I moved to other city then to another then to another… My amount of books was slowly growing because I wanted not to have too many things. Interesting new books were also usually expensive so compared to my income was not helping. And I somehow skipped searching for new libraries — instead were checking friends’ bookshelves.

Once I settled down in Poznań and then in Szczecin my collection was slowly growing. And then, in November 2011 I bought myself Kindle Classic. Life got changed…

First I loaded it with some documents and books which I had on hard drive — technical, science fiction etc. Reading was pleasure. Then I loaded more and more…

Recently I started making use of promotions announced on “Świat Czytników” website which resulted in more and more books in queue. Then evenings, travels, waiting in queues transformed into reading spaces ;)

It is good to read a lot again.

Related content:

Reading books for children

All rights reserved © Marcin Juszkiewicz
Thanks to Kindle I am back to reading was originally posted on Marcin Juszkiewicz website

Marcin 'Hrw' Juszkiewicz: Links for 2012-04-10 [del.icio.us]

Wed, 11 Apr 2012 07:00:00 +0000

GTD For Hackers
David Allen's "Getting Things Done", or GTD for short, is a popular, powerful system for managing one's life. If you have trouble dealing with your e-mail inbox, or feel you're drowning under a flood of inputs and information, or just don't seem to have time to do everything you think you should be doing, or others want you to do, then GTD may be a good thing for you to consider. This book explains how author, a computer geek, has implemented it in my own life. It is aimed at everyone whose lives include a lot of computer use, and who know how to use their computers.
Non-DD to DD steps
If you've been collaborating to Debian as a non-DD and then you become a DD with uploading rights, you have to do some changes in all your configurations.

Holger 'zecke' Freyther: Introducing Poettering scale of software awesomeness and using

noreply@blogger.com (zecke) — Sat, 07 Apr 2012 12:54:39 +0000

I would like to quickly introduce the Poettering scale of software awesomeness. The scale appears to be number of features over time, the higher the number the better. Evidence has shown that this scale is the best to compare software and should be used whenever one needs to decide on competing projects.

Now that we learned how easily one can find the better piece of software, let's apply it. First Emacs vs. vim. Both are more or less the same age, this allows us to find out if vim or Emacs is better solely by looking at the features. As Emacs can send email, has a tons of lisp scripts it is clearly more "Poettering awesome" than vi. The second example is KDE and GNOME, again both are more or less the same age and we only need to compare the amount of features to know which one is better. We do this by looking at the configuration dialogs, KDE has clearly more options than GNOME. So KDE is clearly more "Poettering awesome" than GNOME.

Holger 'zecke' Freyther: Device profiles in Qt5

noreply@blogger.com (zecke) — Fri, 06 Apr 2012 11:43:38 +0000

OpenGL and Devices

The future of Qt's graphic stack is OpenGL (ES 2.0), but this makes things more complicated in the device space. The library names and low level initialization needed for OpenGL is not standardized. This means that for a given board one needs to link libQtGui to different libraries and one needs to patch the QPA platform plugins to add device specific bits. The GPU vendor might provide DirectFB/eGL integration but one needs to call a special function to bind eGL to DirectFB.

Historic Approach

The historic Qt approach is to keep patches out of tree, custom mkspecs files that need to be copied into Qt before building. I have had two issues with this approach:

Device support should be an essential part of Qt5.
Build testing (and later unit testing) is more complicated.

Device Profile Proposal

The approach we took is a pragmatic one, it should be easy for device manufacturers to do the right thing, it should not be a burden for the maintainability of Qt. After some iterations we ended up with device profile proposal and began to implement to it. Most of it is merged by now.

Key Features

It begins with the ./configure script that now has the -device=DEVICE and -device-option KEY=VALUE to select a device and to pass options, e.g. additional include paths, BSP package, to Qt. The second part is a device to influence the behavior of QPA platform plugins. Right now this applies to the DirectFB and EGLFS plugin. A device can install hooks that are called as part of the initialization of these plugins. The hook is the pragmatic approach to get a mix-in with the existing code base.

Supported Devices

Right now we have completed device support for the RaspberryPi,BCM97425 and AMLogic 8726-M. We do support some more devices but they might still require external patches.

Marcin 'Hrw' Juszkiewicz: Links for 2012-04-02 [del.icio.us]

Tue, 03 Apr 2012 07:00:00 +0000

Travelling North [VHS] Reviews

Paul 'pfalcon' Sokolovsky: OpenSource Sensor Node firmware for BlueCore-based Bluetooth Modules

noreply@blogger.com (pfalcon) — Mon, 02 Apr 2012 20:59:56 +0000

BlueCore4-Ext is a popular Bluetooth chip used in many Bluetooth modules, some priced below $10. The idea is to create Wireless Sensor/Control Network using this modules, as Bluetooth is really ubiquitous technology nowadays, so any smartphone can be used to provide user UI/control for such network. This is especially facilitated by the fact that BlueCore4-Ext is a SoC (system-on-chip) integrating microcontroller and peripherals in one package (small too), allowing it to be programmed with a user firmware for autonomous functioning with minimum of additional components. It even has built-in temperature sensor, so just add a battery and you have ready-made wireless temperature sensor (not too precise, granted, but you can calibrate it yourself ;-) ).

(Image by robocraft.ru)

BluTuNode is a firmware for such a Bluetooth Wireless Node, which allows to control it from a host over the air.

Source code: http://github.com/pfalcon/blutunode

Features implemented:

Full control of GPIO: input/output, configuring direction, pullups/pulldowns, etc.
Reading sampled from build ADCs.
Reading of temperature sensor.
Querying other system parameters.
Querying Bluetooth parameters.
Poll mode, when module automatically reads some sensor at specified period and sends information to host.

Features planned/ideas:

UART control (note that this is generally not a priority, because UART is mostly used to connect to host/microcontroller, and this firmware is designed for autonomous modules).
SPI/I2C/1-wire support to connect external sensors.
More Bluetooth-level information and control.
OpenSource tools to program/manage BlueCore modules.
Flash access/writing, over-the-air firmware updates.

Appendix:

Some technical characteristics of BC4-based module:

SoC: BC417 (BC417143B full model ID)
CPU: XAP2+, 16-bit RISC (no special 8-bit data support), Harward architecture, 64Kword data space, 1Mword+ code space
Flash: 1Mbyte (512Kwords, 75% typically occupied by Bluetooth stack/OS)
RAM: 24Kword
Execution environment: Virtual machine, no native hardware access (later versions of firmware OS support "native" mode, heavily bounds-checked still).

Marcin 'Hrw' Juszkiewicz: Links for 2012-04-01 [del.icio.us]

Mon, 02 Apr 2012 07:00:00 +0000

Chip Overclock: Small Town Big City
Since 2005 I have been passionately and aggressively pursing two goals. Find an economical hardware and software platform on which to teach embedded and real-time software development. It must support a gradual learning curve, accomodating beginners needing a gentle introduction, but also experienced developers who need to learn the advanced concepts used in bleeding edge commercial development environments. Demonstrate that the advanced object-oriented software techniques, idioms, patterns, and architectures that I have seen evolve for embedded software development over the past several decades can be applied to this small and inexpensive platform. This has resulted in a number of projects that long-time readers of this blog (if there should be any) will recognize.
Dmitry Grinberg
It is common to see newbies asking in microcontroller forums if they can run Linux on their puny little 8-bit micro. The results are usually laughter. It is also common to see, in Linux forums, asked what the minimum specs for Linux are. The common answer is that it requires a 32-bit architecture and an MMU and at least a megabyte of ram to fit the kernel. This project aims to (and succeeds in) shatter(ing) these notions. The board you see on the right is based on an ATmega1284p. I've made one with an ATmega644a as well, with equal success. This board features no other processor and boots Linux 2.6.34. In fact, it can even bring up a full Ubuntu stack, including (if you have the time) X and gnome.

Paul 'pfalcon' Sokolovsky: Developing for TI LaunchPad MSP430 board on Ubuntu

noreply@blogger.com (pfalcon) — Thu, 29 Mar 2012 23:38:56 +0000

If you google for it, you'll find quite a few blog posts, but most of them are from 2010. But starting with Ubuntu 11.10 (Oneiric), gcc-msp430 and friends are included in the main repositories, so you can just apt-get install them:

apt-get install binutils-msp430 gcc-msp430 \
    msp430-libc msp430mcu mspdebug

There's one annoying bug in Oneiric's version of binutils-msp430 which breaks build with -ffunction-sections -Wl,--gc-sections options (which is kinda common trick in embedded world to remove unused functions and reduce code size): mspgcc #3386145. It is fixed in Ubuntu 12.04 (Precise).

I'm however still running Maverick, so instead I downloaded following Oneiric packages:

binutils-msp430_2.21~msp20110421-2_i386.deb
gcc-msp430_4.5.3~mspgcc-4.5.2-20110612-1_i386.deb
libgmp10_5.0.1+dfsg-7ubuntu2_i386.deb
libmpc2_0.9-3_i386.deb
msp430-libc_20110612-1_i386.deb
mspdebug_0.16-1_i386.deb

Then few from Precise:

binutils-msp430_2.22~msp20110716p5-1_i386.deb
msp430mcu_20110613-3_all.deb

(If you try to install Precise versions of other packages on Maverick, they want to pull upgrades to system libs, which I wanted to avoid).

and installed them manually with dpkg.

Paul 'pfalcon' Sokolovsky: Connetcing to preprogrammed TI Launchpad demo under Linux

noreply@blogger.com (pfalcon) — Thu, 29 Mar 2012 01:38:11 +0000

TI Launchpad board comes with preprogrammed demo application for temperature sensing which is touted to output temperature values to host via USB-encapsulated UART. By connecting to it via terminal you can see that it indeed sends something, but that doesn't look anything like temperature represent in ascii digits, like someone naively could expect. It turns out that it's well kept secret on Launchpad wiki pages how to make sense out of it - at least, you get advertisements for CCS and Java-based GUIs to read out the output, but not straight docs of how to use builtin demo without all those crutches. So well, wrong approach - it's your random user-friendly arduino, approach of reading docs doesn't work here, better go straight to the source.

And, here's step by step instructions:

First thing to note is that Launchpad's UART-via-USB emulation is extremely fragile. It seems that if MCU started to produce UART output but host doesn't read it out, then buffer in USB bridge just gets overflowed and it stops responding to USB. So, if you want to get it working, follow each step below precisely and if any issue happens, restart from beginning (with unplugging LaunchPad).

If you have plugged LaunchPad into USB, unplug it now to make sure you start with properly reset device.
Plugin the board into USB, general-purpose green and red should blink interchangeably. The demo app doesn't yet sense temperature or sends it out yet in this mode.
Execute stty 2400 -F /dev/ttyACM0 . That's right - the demo app communicates at 2400 bit/s data rate and using any other rate will produce garbage input. (One reason for such low speed is that LaunchPad's MCU actually doesn't have hardware UART, it is emulated in software).
Run hexdump -v -C /dev/ttyACM0 . It shouldn't produce any output yet.
Press GPIO button. The demo app goes into measurement mode and starts to send out temperature in Fahrenheit as raw bytes over UART. Try to heat/cool air around the board to see values change.

Sample output:

00000020  60 60 60 60 60 60 60 60  60 60 60 60 60 60 60 60  |````````````````|
00000030  60 60 60 60 60 60 60 60  60 60 60 60 60 60 60 60  |````````````````|
00000040  60 60 60 60 60 60 60 60  60 60 61 60 60 61 60 60  |``````````a``a``|
00000050  61 60 60 61 61 61 60 61  61 61 61 61 61 61 61 61  |a``aaa`aaaaaaaaa|
00000060  61 61 61 61 61 62 61 62  62 62 62 62 62 62 62 61  |aaaaababbbbbbbba|
00000070  62 62 62 62 62 62 62 62  62 62 62 62 62 62 62 62  |bbbbbbbbbbbbbbbb|
00000080  62 62 62 62 62 62 62 62  62 62 62 62 62 62 62 62  |bbbbbbbbbbbbbbbb|

Rodrigo 'vivijim' Vivi: git + proxy

Tue, 27 Mar 2012 20:23:48 +0000

The easiest way of using git behind a proxy is using tsocks. It is just Straightforward:

1 – Install tsocks

2 – Configure tsocks by creating a /etc/tsocks.conf like this:

local = <localnet>/255.0.0.0
server = proxy_ip
server_type = 5
server_port = proxy_port

3 – Use it:

$ tsocks git pull

Just that!

I had also tried the proxy using the GIT_PROXY_COMMAND=”/usr/bin/proxy-wrapper

where proxy-wrapper is

#!/bin/bash
nc -xproxy_addreess:proxy_port -X5 $*

But IMHO tsocks is more convenient because it is not needed to set and unset GIT_PROXY_COMMAND every time.

Marcin 'Hrw' Juszkiewicz: Ubuntu 12.04 ‘precise’ and cross compilation of ARM kernels

Mon, 26 Mar 2012 10:30:30 +0000

Over year ago I wrote How to cross compile ARM kernel under Ubuntu 10.10 and this became one of most popular posts on my website. It may work still but it is terribly outdated so I decided that it is a time for update.

Users of Ubuntu 12.04 ‘precise’ have much simpler situation when it comes to cross compilation of Linux kernels than ones who use older releases. Everything is now in distribution, we have a lot of packages converted to multiarch so instruction is much shorter.

There are few steps to cross compile Linux kernel under Ubuntu 12.04 ‘precise’ (for “armhf” which is officially supported now):

Install cross compiler:

apt-get install gcc-arm-linux-gnueabihf

Fetch kernel source:

apt-get source linux-source-3.2.0

Install packages required to build kernel:

apt-get build-dep linux-source-3.2.0

Build kernel:

cd linux-3.2.0; dpkg-buildpackage -b -aarmhf

And that’s all. Linaro kernels will be as easy to build as Ubuntu one on next days as we have to update packaging to recent Ubuntu version.

Related content:

All rights reserved © Marcin Juszkiewicz
Ubuntu 12.04 ‘precise’ and cross compilation of ARM kernels was originally posted on Marcin Juszkiewicz website

Marcin 'Hrw' Juszkiewicz: I joined MOTU team in Ubuntu

Mon, 12 Mar 2012 15:42:35 +0000

I applied for MOTU (Masters Of The Universe) membership few days ago and today during Developer Membership Board meeting my application was part of agenda.

Becoming MOTU is more complicated than gaining PPU (Per Package Upload) permissions which I got during UDS-O in Budapest. Members of board asked me many questions — it took 45 minutes to get from introduction to voting.

But this is how it should be done — MOTU is responsibility for quite big amount of packages in Ubuntu. Anyway, we got to voting:

15:57 meetingology> Voting ended on: Should Marcin Juszkiewicz become MOTU? 15:57 meetingology> Votes for:5 Votes against:0 Abstentions:0

And now I am proud member of MOTU team! Looks like next thing to apply for would be Debian Membership. I planned to do it in 2004 but OpenEmbedded took my attention ;)

All rights reserved © Marcin Juszkiewicz
I joined MOTU team in Ubuntu was originally posted on Marcin Juszkiewicz website

Rodrigo 'vivijim' Vivi: OSTS 2012

Fri, 09 Mar 2012 08:52:44 +0000

OSTS 2012 has ended and it’s time to say goodbye. Tomorrow I’m getting the flight back to Brasil with the ” Mission accomplished” feeling.

I cannot say that this was the best conference ever because it is difficult to overcome the dead Bossa Conference. However there were so many great presentations, talks and important meetings happening here. It was an amazing Conference in a Wonderful place.

And the most important part was to put faces to the irc/emails nicknames after 7 months working here.

Nice to meet you face to face guys! I hope to see you soon.

Rodrigo 'vivijim' Vivi: starting over and over again!

Fri, 09 Mar 2012 08:25:27 +0000

I was going to start this post with a yet another “back to blogging” phrase, but this is already becoming a cliche here, so I’ m starting just telling that I’m not doing any promises at this time and also telling what to not to expect here since this is the first post after I’ve joined Intel’s Linux Graphics Team .

Don’ t expect regular posts.
Don’ t expect Intel’s Linux Graphics Status and Updates. Eugeni is already doing this job very well on his blog.
Don’ t expect Intel’s news
Don’ t expect Performance Status or Benchmarks. Phoronix already does it vey well.

So, to finish this “first” post I’d like just to mention that the new front page’s picture is just a part of our new OTC-BR lab!

Marcin 'Hrw' Juszkiewicz: Updated cross toolchain for Ubuntu

Tue, 06 Mar 2012 10:28:43 +0000

During last two weeks I was working on updating PPA with cross toolchain for Ubuntu. Current development branch (12.04 ‘precise’) got gcc 4.6.2 and 4.5.3, binutils 2.22, eglibc 2.15 and linux 3.2 headers.

Then I started work on getting those updates also for previous LTS (10.04 ‘lucid’) and for previous stable release (11.10 ‘oneiric’). Versions between those two (10.10 ‘maverick’ and 11.04 ‘natty’) are not supported but binaries built for ‘lucid’ should work just fine on them.

It is time-consuming cause I had to run many builds to make sure that everything is properly patched etc. I listed all required tasks in “Toolchain update for Linaro Toolchain Backports PPA for 12.03″ blueprint on Launchpad. Most time-consuming is waiting for PPA builders but at that phase I was just checking did they finished already due to working on other projects.

So if you are stuck on one of released versions of Ubuntu and need fresh cross compiler targetting “armel” (there is no “armhf” for this PPA) consider using PPA with cross toolchain for Ubuntu.

And do not forget to report any bugs found to armel-cross-toolchain-base and gcc-4.6-armel-cross (or gcc-4.5-armel-cross if you use older one).

Related content:

All rights reserved © Marcin Juszkiewicz
Updated cross toolchain for Ubuntu was originally posted on Marcin Juszkiewicz website

Marcin 'Hrw' Juszkiewicz: I am tired of Raspberry/Pi

Mon, 05 Mar 2012 12:23:38 +0000

Please people… stop asking me about Raspberry/Pi. I do not want it, do not plan to buy one (when they will be finally available for normal people) and for sure do not plan to support it.

Raspberry/Pi may look as interesting hardware to you but it does not have to mean same to others. Want to run desktop? 256MB of memory means really crippled one (last time I saw this amount of RAM in desktop computer right before opening it to add 512MB stick). Sure, for 25-35 USD it is proper range as memory is probably the most expensive part. Device may be good for using it in more embedded environment where GPIO/I²C/I²S/SPI/UART matter — expansion connector provides those signals.

But I would rather buy BeagleBone to play with peripherials connected to such pins. Someone may ask “why? it is more expensive”. Reason is simple — it is in production, already has expansions which adds things like video output, touchscreens. And it has ARMv7 cpu which allows me to run any ARM distribution available today — so Debian ‘armel/armhf’, Ubuntu, Fedora, OpenSUSE, Ångström (which is preinstalled with great IDE to play with device already) or anything other.

I do not need small device which can run XMBC or Quake — have private PandaBoard which can do that too and has few things more than Raspberry/Pi.

And I do not think that companies which do software should start working on <100USD hardware like article at Techblaze suggests.

Marcin 'Hrw' Juszkiewicz: SD cards die

Fri, 02 Mar 2012 11:54:24 +0000

So called ‘low cost’ developer boards (like BeagleBoard xM, PandaBoard, Snowball, MX53 Quick Start) do not have NAND flash on them so people are using SD/MMC cards as boot media and storage. So we, developers, went to shops and bought SD cards. Some got class4 ones cause budget was low already, some grabbed class10 ones hoping that they will be fast, other took class6.

I got some 4GB Transcend class10 ones. They worked, gave me 15MB/s on read and were fine. Until recently they started giving strange kernel output, MMC timeouts, I/O errors which resulted in filesystem going into read only mode. As I prefer to have working board then wondering how much time it will survive I trashed both cards. Good that I had some spare unknown 8GB microSD ones. But in last ~year I had to throw away 4 SD cards…

One of solution for it is moving rootfs to some more reliable storage. I did that with MX53 Quick Start — it has 320GB Serial-ATA harddrive connected. So for PandaBoards I could use 8-16GB thumb drives or USB connected hard drives. I had this in past when there was no mx53 hardware at my desk. But this means extra costs, additional cables, probably even another set of power cables…

Will have to check market for good reliable SD cards soon. 8-16GB ones so there will be space available for doing builds. Or will switch to old school NFS root which requires only 64MB cards — just to load bootloader, kernel, initrd. Other option is a network storage like NBD, AoE or iSCSI but this requires more configuration.

Paul 'pfalcon' Sokolovsky: NSLU Optware for Android

noreply@blogger.com (pfalcon) — Mon, 20 Feb 2012 22:46:57 +0000

Yes, there was kind of attempt at that already, but:

It's no longer available at the link announced and spread over the Internet (yep, it's available at another, but why so ... complicated?)
It ships binary blobs of unknown origin. Yup, maybe one could trace their origins, but who'd bother, and telepaths are on vacation as usual. It should be described stringently where they are from, if not scripted to be collected in user's build directory from known good sources, so users can actually trust them.
It is marketed as supporting only something called "Nook Color". What's that, I thought it was Optware for Android? Could I have Optware specifically for my HP nx9420 notebook, serial number XYZZY, 3Gb of RAM? Just make sure it's different from the Optware for the same notebook, but with 4Gb of RAM, and from any other Optwares in the world!
It goes as far as patching rootfs ramdisk. That may work on Nook Color or may brick it. That may work on next firmware upgrade of Nook Color or may brick. That may work on another device or may brick. The talk is not about this, it's about the fact that it's two big differences - to be able to install and run bash and to have sshd started automatically after the boot. I definitely want first, but I will do good consideration if/when I need second. So, I don't want setup for those 2 stages to mixed and done without myself being ready for stage 2.
It still appears to rely on presence of some other 3rd party stuff (look at that #!/bin/sh line, there's no such thing on pristine Android device, only #!/system/bin/sh)

So well, I decided to take my turn on hacking up an Optware bootstrap script for pure Android (root and adb access are the only prereqs). It's hosted here: https://github.com/pfalcon/optware-android and intended to be run on a Linux hosts. It starts by downloading CodeSourcery toolchain for libc and ipkg and immediate dependencies from http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/stable to bootstrap ipkg on device. Yep, it's being tested on Nook Tablet so far, but at least it is called Optware for Android and I have that aim ;-). So, bugreports and patches are welcome. And I have few more devices to test it on, just steal me some time...

Marcin 'Hrw' Juszkiewicz: Bought Archos 80 G9 Turbo tablet

Mon, 20 Feb 2012 13:19:56 +0000

During last Linaro Connect I bought myself an Android tablet. After checking what is on market decided to buy Archos 80 G9 Turbo. According to Amazon product page it had to have 1.5GHz OMAP4460 cpu and 1GB of memory. But it did not…

Marketing droids from Archos company should be … and … then … and again … — after that … or … and finally … (put any ways of doing deadly harm into … and repeat any amount of times). Why? There is no such thing as “Archos 80 G9 Turbo” — nevermind that I have one of them on my desk. So far there are at least three models with this name:

OMAP4430 1.2GHz 512MB ram
OMAP4460 1.5GHz 512MB ram
OMAP4460 1.5GHz 1GB ram

You can easily buy first model. Best Buy has it, Adorama has it, J&R has it, Amazon sells it. Second model was expected to land on shelves in December 2011. According to XDA developers forum few of them were even sold as people have them. Last model is listed on Amazon (but first one is what you get) and according to one sources it will be released in March 2012, other says that there will not be such thing. Marketing mess is lightest description which I can write without swearing.

So I got first one. First though was “WTF?!?!!?!?!?!!!” as I got slowest option. Even started returning procedure but as all US shops had only this version I gave up and decided that even with this technical specification it is better tablet then I had before (which was Hannspad SN10T1). Fast cpu, 4:3 screen with 1024×768 resolution, quite good build quality, video output.

Tablet runs Android 3.2 ‘honeycomb’ and does it nicely. Upgrade to 4.0 ‘ice cream sandwich’ was announced to be done in this month. So from software perspective it is done properly. I had some problems with rooting procedure from XDA developers but once you do it in order (and take files from other thread to get 3.2.80 firmware) device will work just fine. Have to admit that system layout on device looks overcomplicated (175MB squashfs as / for example) but it works. Anyway I am waiting for developer firmware (I was told that they will be available ‘soon’ (for any definition of ‘soon’)).

During first days of using I noticed that some applications refuse to work properly on XGA screen, some are resized/rescaled but problems usually are with games or poorly written apps (like Facebook one). But it is visible that keeping Honeycomb under stone (aka ‘closed source’) resulted in many applications not ready to be used on tablets. Even Google+ looks like it does on a phone…

I am slowly moving to use Archos as a morning news device (Twitter, Facebook, Google+ and Google Reader) — it is perfect for it. Reading webpages in landscape or portrait modes is pleasure as device is easy to hold and screen is wide enough in any of them (which was my main complain with Hannspad).

Had to order miniHDMI -> HDMI adapter (normal size connector would even fit but it is too big for this form factor) cause they do not add it in a box. When it will arrive I will check how good movies are played after connecting to 42″ plasma capable of 1080p. OMAP4 cpu should decode any video at this resolution without problems but I wonder how device deals with 4:3 internal screen and 16:9 external one. Would be nice to watch Youtube videos fullscreen.

Playing games is fun. Fieldrunners finally does not need scrolling, Great Little War Game is also better than on my Nexus S. From “racing” games so far I tried Asphalt6 (available at XDA developers forum), Shine Runner and Reckless Getaway — all run and look cute but accelerometr based steering is not comfortable with tablet size. Also games like Mahjongg or Solitaire are possible (I consider such games unplayable on phone).

Battery life is better than on my Nexus S. Partially because lack of GSM and bigger battery, but I think that due to power management done better.

I will not tell how good it is when it comes to read e-books because I have Kindle for it already.

Back to hardware. There is USB socket for optional 3G stick. Plugged dongle from wireless keyboard/trackball combo there — not recognized due to not be USB 2.0 device. Plugged thumbdrive and got it recognized (first time I got some kernel oops and no access to storage, had to reboot tablet). Did not tried other devices.

There is just one speaker at back of device. Definitelly too small and lonely. Nokia N800 which was released 5 years ago had stereo speakers… So for gaming I strongly suggest headphones.

Ugly thing is that when you push back of case with left hand fingers screen will react to it — looks like something is pushing screen. It does not look professional…

Ending summary: so far I am satisfied. Maybe one day will try one of those crazy builds like Ubuntu ;D

Related content:

All rights reserved © Marcin Juszkiewicz
Bought Archos 80 G9 Turbo tablet was originally posted on Marcin Juszkiewicz website

Koen Kooi: Recommended kernel config options for a modern Angstrom system

Mon, 06 Feb 2012 08:17:09 +0000

Over the past year people have asked which options they need to enable when using a recent udev/systemd/udisks/powertop in angstrom so here's a list of the most important ones:

devtmpfs:

CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

This is needed for modern udev versions. The kernel will handle all the device node creation and deletion. This removes the need for udev-cache.

cgroups:

CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_BLK_CGROUP=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_FREEZER=y

Cgroups are needed for systemd.

Fuse/cuse:

CONFIG_FUSE_FS=y
CONFIG_CUSE=y

Fuse is nice to have and various libraries uses it for user-mounts (e.g. GIO).

taskstats:

CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

This makes powertop give usefull info about the processes that drain your battery.

Autofs:

CONFIG_AUTOFS4_FS=y

And this is what does the heavy lifting for the system on-demand mount feature.

Michael 'Mickey' Lauer: Coming back from FOSDEM

Sun, 05 Feb 2012 18:08:12 +0000

After having skipped FOSDEM in 2011, I wanted to go this year, especially because of the Golden Delicious stand where we had the OpenPhoenux GTA04 on show. A lot of people came around and were excited that someone picked up where Openmoko had left in 2009. The GTA04 is the true successor of the FreeRunner and I strongly invite all of you to support this movement by buying one. You will not get a more open mobile phone anywhere else.

I know that Brussels is always a bit colder than Frankfurt, so I tend to carry appropriate clothing… what I didn’t expect though was that it was frickin’ -20 on saturday. I have never been freezing more in my life. Lets cross fingers that I won’t come back home with a cold. Especially due to the crazy public transportation situation. The Deutsche Bahn managed to accumulate a one hour delay on my way to Brussels – that’s ok, however they managed to crash the engine in Aachen on my way back. So badly that we had to switch to a regional train and switch again in Cologne. Man… *sigh*

On to some good news… another thing I didn’t expect was kind of an Openmoko family reunion. It was amazing to find Jan Lübbe, Stefan Schmidt, Daniel Willmann, Harald Welte, and even Rasterman hanging around at FOSDEM. That was just great. I also happened to share my hotelroom with Boudewijn which was unexpected but again very cool.

So despite the freezing, it was a great FOSDEM for me and I’m looking forward to go again next year, perhaps bringing Sabine and Lara Marie as well.

Marcin 'Hrw' Juszkiewicz: Flashing U-Boot on Efika MX Smartbook

Wed, 01 Feb 2012 13:19:28 +0000

From time to time I read posts where people wrote that their Efika MX Smartbook does not boot any more. The only thing which it does is white power led blinking about twice per second. Standard reply in such case is “send device back to Genesi”.

Some time ago a friend of mine borrowed Efika MX Smartbook from me. During his experiments he managed to get netbook into such state. I have serial/jtag debug dongle so decided to take a look at it (and unbrick device). I managed to fix it but also somehow broke serial port so can not check why my automate way does not want to work.

What needs to be done to get Smartbook back to live? Few things:

SD card
small screwdriver
U-Boot from EfikaMX updater image
U-Boot script which will flash U-Boot into NOR
Linux account with root permissions
working SD-bootable U-Boot — this one still requires serial dongle, sorry for that. Will replace it with proper one when will get serial port working again.

Needed steps:

Repartition SD card. You can use any tool for it. All what has to be done is set up first partition at 1MB offset so we have space for U-Boot.
Format partition (if needed) as FAT.
Run “sudo dd if=u-boot.imx of=/dev/sdd bs=1k seek=1” (replace /dev/sdd with your SD card).
Put card into SD slot of Efika MX Smartbook.
Take out keyboard — you need to use small screwdriver to push holes near F1, F6, F10, End keys.
Change DIP switches – they are in a middle of motherboard. You need to reverse default setup.
Power on your Efika. There should be U-Boot output on screen. You may even get system loaded up at this step ;)
Take out SD card and copy ‘boot.scr’ to it.
Power off Efika, put SD card and boot.
Old U-Boot will be stored into NOR flash (output will be visible on screen).
Change DIP switches – they are in a middle of motherboard. You need to reverse them to default setup.
Put keyboard back.
Take out SD card.
Boot your Efika MX Smartbook — operating system should load.

Some information:

old U-Boot got flashed because new one was not tested for NOR boot
finding out information for this how to took me few hours
this procedure can be done without Efika MX Smartbook serial/jtag dongle
similar procedure can be used for Efika MX Smarttop but as I do not have such I can not offer help

Thanks goes to:

Genesi for giving me free Smartbook and serial/jtag dongle
Marek Vasut for his work on mainlining U-Boot support for Efika MX devices
Matt Sealey for some hints on IRC

Related content:

All rights reserved © Marcin Juszkiewicz
Flashing U-Boot on Efika MX Smartbook was originally posted on Marcin Juszkiewicz website

Cliff 'cbrake' Brake: A Linux Kernel Tracing Tutorial

Tue, 31 Jan 2012 13:12:46 +0000

The Linux kernel has a fairly extensive tracing infrastructure that is quite useful for debugging. There are a number of things you can do with tracing, but the focus of this article will be the traditional printk type debugging we often end up doing to trace initialization issues with a driver. The following links provide additional information on the linux kernel tracing infrastructure:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=Documentation/trace
Debugging the kernel using Ftrace – part 1: http://lwn.net/Articles/365835/
Debugging the kernel using Ftrace – part 2: http://lwn.net/Articles/366796/
Secrets of the Ftrace function tracer: http://lwn.net/Articles/370423/
http://elinux.org/Kernel_Trace_Systems

In this example, I am working on a new audio driver. The typical experience with a new driver is that you install it and nothing happens because something is not registered correctly with the Linux driver model. So, the first thing I do is start with with the platform_device_add() function in my drivers init function. To observe the kernel activity around the kernel platform code, I can do the following:

cd /sys/kernel/debug/tracing/
echo 0 > tracing_on (keep trace from filling up until we set filter)
echo function_graph > current_tracer
echo platform* > set_ftrace_filter
echo 1 > tracing_on
cat trace_pipe (leave running in a different shell)
<insmod my driver>

After executing the above, we see the following. For this example, trace_pipe is preferred because the trace is then emptied and only new information is shown.

0) + 30.518 us   |  platform_device_alloc();
0)               |  platform_device_add() {
0)   0.000 us    |    platform_uevent();
0) + 30.518 us   |  platform_uevent();
0)   0.000 us    |  platform_uevent();
0) + 30.518 us   |    platform_match();
0) + 30.518 us   |    platform_match();
0)   0.000 us    |    platform_match();
0)   0.000 us    |    platform_match();

...

0) + 30.518 us   |    platform_match();
0)   0.000 us    |    platform_match();
0)   0.000 us    |    platform_match();
0)   0.000 us    |    platform_match();
0)   0.000 us    |    platform_match();
0) ! 3936.767 us |  }
0) + 30.518 us   |  platform_uevent();
0) + 30.518 us   |  platform_device_alloc();

From the above, I can conclude that the platform_match() is not succeeding, because I would expect some more activity. At this point I chose to add a printk:

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 7a24895..f9ce0c7 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -662,6 +662,8 @@ static int platform_match(struct device *dev, struct device_driver *drv)
        struct platform_device *pdev = to_platform_device(dev);
        struct platform_driver *pdrv = to_platform_driver(drv);

+       trace_printk("pdev->name = %s, drv->name = %s", pdev->name, drv->name);
+
        /* Attempt an OF style match first */
        if (of_driver_match_device(dev, drv))
                return 1;

Now, if I re-run the trace, I see the following:

 0)               |      /* pdev->name = soc_audio, drv->name = davinci_emac */
 0)   0.000 us    |    }
 0)               |    platform_match() {
 0)               |      /* pdev->name = soc_audio, drv->name = snd-soc-dummy */
 0)   0.000 us    |    }
 0)               |    platform_match() {
 0)               |      /* pdev->name = soc_audio, drv->name = soc-audio */
 0)   0.000 us    |    }
 0)               |    platform_match() {
 0)               |      /* pdev->name = soc_audio, drv->name = omap-pcm-audio */
 0)   0.000 us    |    }
 0) ! 4241.943 us |  } /* platform_device_add */

From the above, it looks like we have a simple mismatch between “soc_audio” and “soc-audio.” Fixing this problem, and re-installing the module, we now have:

 0)               |    platform_match() {
 0)               |      /* pdev->name = soc-audio, drv->name = snd-soc-dummy */
 0)   0.000 us    |    }
 0)               |    platform_match() {
 0)               |      /* pdev->name = soc-audio, drv->name = soc-audio */
 0)   0.000 us    |    }
 0) + 91.553 us   |    platform_drv_probe();
 0) ! 4241.943 us |  } /* platform_device_add */

Now we can see that the names match, and the probe function is now being called. At this point, we may want to turn on tracing of some additional functions to try to determine what is happening next.

echo "platform* snd* mydriver*" > set_ftrace_filter

And the result:

 0)               |      /* pdev->name = soc-audio, drv->name = snd-soc-dummy */
 0)   0.000 us    |    }
 0)               |    platform_match() {
 0)               |      /* pdev->name = soc-audio, drv->name = soc-audio */
 0) + 30.517 us   |    }
 0)               |    platform_drv_probe() {
 0)               |      snd_soc_register_card() {
 0) + 30.518 us   |        snd_soc_instantiate_cards();
 0) ! 17852.78 us |      }
 0) ! 17883.30 us |    }
 0) ! 22125.24 us |  } /* platform_device_add */

With the above additional information, we can continue to learn more about the flow through the kernel.

While all of the above could have been done with printk’s, it would have been more time consuming. The kernel function tracing capabilities allow us to quickly get a high level view of the flow through the kernel without manually adding a bunch of printk statements. The kernel tracing features are completely contained in the kernel without requiring additional user space utilities which makes it very convenient to use in embedded systems. The low overhead is also important in resource constrained embedded systems.

Paul 'pfalcon' Sokolovsky: HC-04 Bluetooth module and BlueCore4 Deep Sleep

noreply@blogger.com (pfalcon) — Mon, 30 Jan 2012 00:26:21 +0000

The good news is that BlueCore indeed has Deep Sleep mode, it's not marketing hype. It can be verified by configuring PSKEY_CLOCK_REQUEST_ENABLE to drive PIO when chip uses/doesn't use external clock. The key here is not to keep PSTool run (which well, you need to tweak sleep settings).

The bad news is that an HC-04 module in Deep Sleep still consumes 2.5mA, which is far too high for anything called Deep Sleep. So, something on the module besides BlueCore still consumes too much power. However, when BlueCore is held in reset state, entire module consumes 0.

Without Deep Sleep, simple LED flash task consumes 3.5mA, so there's not that much gain from the Deep Sleep...

Paul 'pfalcon' Sokolovsky: Enabling SPI logging in BlueSuite tools CSR BlueCore chips

noreply@blogger.com (pfalcon) — Sun, 29 Jan 2012 15:25:00 +0000

BlueFlashCmd.exe and other tools, part of CSR BlueSuite toolset to program BlueCore Bluetooth chips, has support for logging SPI communication with a chip. To enable it:

BlueFlashCmd.exe -trans "SPIDEBUG_FILE=spi.log SPIDEBUG=ON" -chipver

The key parameter here is SPIDEBUG_FILE - logging is activated when it's specified, and thus logging is always done to a file. One way to have logging go to a console is to use SPIDEBUG_FILE=con: , but then it won't be possible to redirect it.

Besides SPIDEBUG=ON, there're other logging levels/features:

SPIDEBUG
SPIDEBUG_REPRODUCIBLE
SPIDEBUG_WRITES
SPIDEBUG_READS
SPIDEBUG_WIRE

The keys may be also specified in the environment instead of -trans switch arguments.

Looking at the output produced, it turns out it spends a lot in calibrating SPI speed, a way to that down is to use SPISLOW=ON setting right away.

Richard 'RP' Purdie: Tarmac takes getting used to again

Fri, 27 Jan 2012 18:03:01 +0000

Due to the various building works last year, the 675 was laid up off the road. I had planned to wait until spring to get it MOT’d (safety checked) and get it back on the road. With the mild weather there is not time like the present though.

After riding the CRM/YZ for the past months, getting back on a true road bike was very very odd. The amount the bars moved for slow speed manouvering was scary, the brakes seemed weak (but aren’t), the throttle rather responsive, the clutch immediate and the raw accelation, grin worthy.

I did manage to remember how to ride it, the battery worked, the engine management didn’t light up like a christmas tree and it gained an MOT. Triumph did a beautiful piece of engineering with that bike and I remember why I own it. We need some better weather but its ready and waiting .

Cliff 'cbrake' Brake: The easy way to get serial terminal in Linux

Thu, 26 Jan 2012 19:24:56 +0000

When doing embedded Linux development, most of us spend out time tethered to a target system with a serial cable, which is used for a serial console. Minicom is the defacto serial terminal software for Linux. However, Minicom is a little fussy in that you typically have to set it up for each port you want to use. This is no big deal, but is generally difficult for new users to understand, and yet another hurdle. And with 8-port USB->serial adapters, I have a lot of ports to set up.

Just recently, I discovered that screen can be used as a serial terminal program:

screen /dev/ttyUSB0 115200

A few notes on using:

to exit screen: Ctrl-a k
to write a hardcopy of the screen image: Ctrl-a h
to get help: Ctrl-?

All the neat features of screen are two numerous to list here, but one more that I’ll point out is the scrollback/copy feature (activated by Ctrl-a [ ). This allows you to scroll back and the navigation works much like VI — what could be nicer?

Koen Kooi: Fixing I²C timeouts during boot on the beaglebone

Wed, 25 Jan 2012 12:08:11 +0000

The beaglebone kernel was timing out on I²C bus 2 when no cape is attached. This was traced back to missing pullups on the 2 I²C lines. Looking at the source:

"uart1_ctsn.i2c2_sda",    OMAP_MUX_MODE3 | AM33XX_SLEWCTRL_SLOW \
 | AM33XX_PULL_ENBL | AM33XX_INPUT_EN

That seems to enable pullups, let's check on the device itself:

root@beaglebone:~# devmem2 0x44e10978
devmem2 0x44e10978
/dev/mem opened.
Memory mapped at address 0x40313000.
Read at address  0x44E10978 (0x40313978): 0x00000063

The magic decoder ring gives us the following:

bit	7	6	5	4	3	2	1	0
function	Reserved	Slewrate	Receiver enable	Pull up/down	Pull disable	mode
value	0	1	1	0	0	0	1	1

No pullups enabled, but pulldowns! Let's change the kernel to make it try a bit harder to enable pullups:

"uart1_ctsn.i2c2_sda",    OMAP_MUX_MODE3 | AM33XX_SLEWCTRL_SLOW \
 | AM33XX_PIN_INPUT_PULLUP},

The timeouts seem to be gone, let's double check:

root@beaglebone:~# devmem2 0x44e10978
devmem2 0x44e10978
/dev/mem opened.
Memory mapped at address 0x40313000.
Read at address  0x44E10978 (0x40313978): 0x00000073

bit	7	6	5	4	3	2	1	0
function	Reserved	Slewrate	Receiver enable	Pull up/down	Pull disable	mode
value	0	1	1	1	0	0	1	1

Success!

Paul 'pfalcon' Sokolovsky: Notes on Android EGL/native windowing system interface

noreply@blogger.com (pfalcon) — Wed, 18 Jan 2012 01:00:56 +0000

EGL is defined here and appears to be in OpenGL ES something what GLUT was (?) in OpenGL world. At least, EGL is what takes care of actually displaying on screen what was rendered by OpenGL ES.

Donut

EGLNativeWindowType is defined in opengl/include/EGL/eglplatform.h as struct egl_native_window_t* . egl_native_window_t is defined nearby in opengl/include/EGL/eglnatives.h . This is nice, clean, standalone structure (unlike horror in Eclair+). It starts with a "magic" (signature) 0x600913, followed by "version" which is sizeof of the structure (now I know why Microsoft gets a buck on each Android phone sold - they for sure patented this (stupid? lazy?) trick widely used in Win32 API). There're some function pointers (virtual method table) used by EGL to call into native windowing system (deep, close to vendor drivers) to support its workings. Out of these, there's essentially one related to rendering finalization: swapBuffers(). So yes, it seems that eglSwapBuffers() just calls out to this. The structure also directly contains "Base memory virtual address of the surface in the CPU side" and other easily graspable memory/graphics notions.

It's clear that in its young years, Android was fair and naive, not suitable at all for typical vendor OpenGL mumbo-jumbo. The "fix" came with the later versions.

Eclair and following

EGLNativeWindowType is defined (in include/EGL/eglplatform.h) to be struct ANativeWindow*. ANativeWindow was android_native_window_t in Eclair, but was renamed to ANativeWindow in Froyo (android_native_window_t is still available for compatibility). ANativeWindow is defined in platform/frameworks/base/include/ui/egl/android_natives.h:

ANativeWindow not just emulates VMT, but seems to want to do entire C++ in C-like manner in its metes and bounds. It uses subclassing from android_native_base_t, and that contains fields for magic ("_wnd" for ANativeWindow) and version-sizeof. Methods defined are also more involved. Among the most interesting are dequeueBuffer(), lockBuffer(), queueBuffer(). Essentially, it appears that EGL takes a free buffer out of native system's rotation, locks it for changing its contents, then puts back into queue for display.

Actual implementation of ANativeWindow for read device screen is in libs/ui/FramebufferNativeWindow.cpp . There's factory function to get its instance: android_createDisplaySurface().

All implementation details on buffers used are hidden in android_native_buffer_t type. It is also subclassed from android_native_base_t, its magic is "_bfr". Among simple things like width/height it contains buffer_handle_t, which leads in utero of vendor graphics driver. buffer_handle_t is native_handle*, and native_handle is a generic container for arbitrary number of fd's and pointers.

native_handle's are produced by gralloc vendor module, and that's exactly what FramebufferNativeWindow constructor does - it loads gralloc module, then uses it to open framebuffer and gralloc devices. It then allocates back and front buffers from gralloc devices with the size of the framebuffer. queueBuffer() method is implemented by calling framebuffer's post() method which well, shows the buffer on the screen.

Paul 'pfalcon' Sokolovsky: Thoughts/notes on Android version upgrades and reusing Android drivers

noreply@blogger.com (pfalcon) — Tue, 17 Jan 2012 18:40:40 +0000

So, what it takes to upgrade Android on an arbitrary Android device (from user perspective)? What takes to run Linux in full-fledged mode? This boils down to few things:

Kernel porting

Upgrade kernel. This means forward-porting hardware support modules to a new kernel version. That's, when source code for such modules is available. Sometimes, it's not violating GPL (or tainting kernel, but who wants that? ;-) ). In an ideal world, that would all that's needed, but vendors don't like GPL, and try to move stuff outside of kernel. So, the list continues.

Bitblt acceleration porting

Next step is making sure that basic hardware acceleration works - accelerated bitblt/compositing (defining compositing as bitblt with alpha). This is actually pretty important step - without accelerated bitblt, Android with more or less big screen will run pretty sluggishly. Well, X Windows won't run too zippy either. Bitblt code in Android lives in /system/lib/hw/copybit.*.so and depends on gralloc.*.so from the same dir (* there is vendor/implementation identifier - Android support multiple, pluggable implementations). Needless to say, for a random device, source for these modules are not available - vendors don't have to provide it, it's Apache2-licensed, and very few choose to uphold OpenSource spirit nonetheless. So, if new Android version have changes the ABI for those modules, then oops - upgrade is "not possible" is layman terms. Of course, real men will immediately think about writing adapters, etc...

What about other X and other "foreign" windowing systems? They would need drivers/adapters too, and base all their low-level FB access based on Android's gralloc/bitblt/etc. model.

OpenGL ES porting

Last, least, but nonetheless. Curse of the modern world - OpenGL. You didn't have it on your Apple 2 (I mean Apple 2, yes, not what you thought about!) and everything was great, wasn't it? Apart from games you don't have time to play, what it's useful for? Yes, as soon as we'll stream videosignal directly into the brain, it will be useful for augmented reality, but I mean, *useful now*. They keep talking they added some hardware acceleration using OpenGL to the normal UI, then immediately say it didn't work that great, and depends on many things, because... Because OpenGL simply doesn't work that great, yeah. For example, even "accelerated", it's pretty slow, buggy, inconsistent across devices, etc, etc.

Anyway, thanks for listening to the rant. Let's de-emphasize usefulness of OpenGL, let's just take it as a challenge - vendors hacked it, so why can't hackers hack it? The basic idea is the same as with bitblt - there's an interface between closed vendor OpenGL ES implementation and Android. If interface changed, you're hosed. I mean, you write adapters. You also write adapters to make it talk with your windowing system of choice, and not Android. The core interfacing part of OpenGL ES/Android junction is EGL. How to deal about it is worth a separate post.

Paul 'pfalcon' Sokolovsky: New Hack Toy - Zenithink ZT-180

noreply@blogger.com (pfalcon) — Tue, 17 Jan 2012 17:16:11 +0000

Recently I got new hack toy: cheap (well, depends) Chinese Zenithink ZT-180 tablet. This one seem to be (have been) pretty popular and hacker-friendly. Here's data about it:

Vendor: http://zenithink.com/
Product home page, ZT180-102 (it's the oldest in the product list, so soon will go to "Retired products" (== /dev/null))
CPU: IMAPx200 (or IMAPx210, IMAPx220), ~1GHz
GPU (SoC-builtin): GC600 (tentative)
RAM: 512MB (Android boots with mem=384M)
Bootloader: u-boot
Kernel source from the vendor (github)
Slatedroid forum announcement and discussion about the kernel release above
Vendor toolchain
Post saying that user yuray started upgrading kernel to 3.0.4. Following posts add more details, no source link provided.
yuray also appears to be the author of ZT-180-Linux-Flash-Tool.
Slatedroid ZT-180 Wiki
More detailed hacking information

It seems that I've got vendor model ZT180_G2 (maybe, ZT180_G0).

Button combinations to hold during power on:

Home+Power - Upgrade firmware from /sdcard/zt-update/
Left arrow (of swing double-button)+Power - Boot with debug kernel from /sdcard/zt-debug/ . Debug kernel is booted and continues with the normal boot process.
Right arrow (of swing double-button)+Power - Multiboot support, select one of 3 modes:

Android adb - kernel with ADB over USB support
Android mass storage - kernel with mass storage USB gadget support (tablet is presented as a mass storage when connected to host)
Other OS - WinCE

Random links:

http://www.slatedroid.com/topic/10233-zenithink-zt-180-cpu-actually-infotmic-imap210-cpu/
http://www.androidtablets.net/forum/infotmic-based/2354-infotmic-chips.html

Paul 'pfalcon' Sokolovsky: Stopping Android GUI services

noreply@blogger.com (pfalcon) — Mon, 16 Jan 2012 23:32:05 +0000

Well, this really worth a cross-post. The way to stop Android GUI services is (under root of course):

setprop ctl.stop zygote

UPDATE: Thanks to hint from StackOverflow: there're even simpler commands: "start" & "stop". Surprise.

Koen Kooi: Using 1-wire on a beaglebone

Sun, 15 Jan 2012 12:20:37 +0000

The dedicated AM335x HDQ pin(s) aren't exposed on the beaglebone header, but there are enough GPIOs available to emulate one with the w1-gpio driver in linux. I connected a DS18B20+ to the beaglebone as shown in the picture above.
After patching the kernel and booting the update uImage:

root@beagleboneA3-0457:~# dmesg | grep w1
[    0.208956] w1-gpio connected to P8_3

root@beagleboneA3-0457:~# cat /sys/bus/w1/devices/28-00000256073a/w1_slave
b8 01 4b 46 7f ff 08 10 8a : crc=8a YES
b8 01 4b 46 7f ff 08 10 8a t=27500

With a friendlier output:

root@beagleboneA3-0457:~# cat /sys/bus/w1/devices/28-00000256073a/w1_slave | tail -n1 | awk -F= '{print $2/1000 " degrees Celsius"}'
27.687 degrees Celsius

The final tweak is to use some jumper wires to prevent the beaglebone from heating up the sensor:

root@beagleboneA3-0457:~# cat /sys/bus/w1/devices/28-00000256073a/w1_slave | tail -n1 | awk -F= '{print $2/1000 " degrees Celsius"}'
19.125 degrees Celsius

w1 patch

Richard 'RP' Purdie: Ice, snow, hills, mud and new territory

Fri, 13 Jan 2012 12:38:27 +0000

Last Monday with it being a bank holiday I was invited out for a trip to the other side of Alston, starting from Allendale. I’ve wanted to ride the lanes over there for a while and this was my opportunity. I didn’t fancy setting off early in the morning in the dark and trying to find fuel in Allendale so I took the bike in the van to the starting point. On the way, I found the conditions were getting colder the further inland I went and approaching Allendale, there was one junction where it was gently snowing with snow lying on the ungritted sections of road.

I managed to get there on time and eventually everyone was ready to set off. Everyone left apart from me and one other, I was playing my tail gunner role since I had a copy of the route. It was quickly clear we wouldn’t be going anywhere whilst Stewie’s chain was lying on the ground. Stewie has a reputation for breaking chains but not getting away from the van is a new record. Eventually the others noticed we weren’t there and came back and we managed to get the chain repaired. We were off, really this time.

I have a reputation of not doing so well on ice covered tarmac so I’d decided I was going to take things very carefully. I was on the YZ which isn’t really the ideal bike for those kind of conditions having too much power and totally knackered tyres (a dead mousse distorting the front and no tread on the back comparatively speaking). Sure enough as soon as we’d done the first lane we were onto ungritted country roads covered in a thin layer of sheet (black) ice. There was one nasty off camber T junction covered in ice which I did not enjoy at all. Coming around a corner I then found a piece of road with a couple of tight turns over a bridge, all covered in ice. This would have been bad enough (but manageable) but one of the group was lying in the road, as was his bike. Thankfully I wasn’t carrying much speed but even then there wasn’t any chance of stopping on the ice, or steering around the obstacles. At this point it helps to remember the kind of vehicle and its capabilities. I quickly concluded my only chance was to ride onto the 12″ strip of verge between the road and the wall and whilst that was covered in snow and heavily banked and undulating, chances were I would have enough traction to stop. Thankfully this proved correct. Ben got himself and the bike upright and we set off again. At this point I went past a couple of the group stopped halfway up a hill. There was too much ice around for me to fancy stopping too. I spent the next couple of miles of tarmac going slowly wondering where they were but they caught me up just as we found the rest of the group.

At this point I realised we were approaching Alston and were onto some trails I know. I only ever seem to see these ones in winter when they’re covered in ice and they’re heavily rutted making riding an interesting challenge. Rather than head into Alston, we bypassed it and did an interesting piece of trail which included a steep uphill section. Unfortunately one of the group was stopped half way up which meant everyone else had to stop. That person decided not to attempt the near vertical climb at the top and let someone else take the bike back down and take it at speed. I decided to just attempt it from stationary at the half way point which proved tricky and resulted in stalling the bike multiple times. The rear tyre’s condition wasn’t helping as it was just slipping. I was wary as the exit was onto a road with a parked car in the path if you applied too much speed/power. The first attempt ended up with the front wheel up, only to have the bike slide backwards back down it with me unable to grab the back brake, only keep the front locked solid which isn’t a fun experience. I made it on the second attempt.

After the next trail, the group had disappeared. My GPS appeared to indicate the route was left so I followed it, only to realise I was heading in the wrong direction and the tracks were confused on the map. I turned around and found two group members looking for me. One U turned and headed back the way they’d come, the other continued past me. I sat in the middle and wondered what the heck I was supposed to do! We go that sorted out and found the rest of the group but I missed out on one of the trails. We then arrived in Alston and refueled. We were still on trails I’d done before but not for a long time. We wound our way up to Hartside Cafe, beyond which I’ve never ventured on green lanes. On road bikes, this marks the point the entrance to the Lake District and I’ve been there many times on tarmac though. We started down some very interesting lanes. There were a lot of muddy ruts and I was having a lot of difficulty keeping the YZ going in a straight line at any kind of speed.

We came across a group of horse riders (on tarmac) and slowly followed for a while until they pulled over onto some grass at a junction. The rest of the group went through but I was slightly behind having had trouble restarting the bike after stopping. As I approached and was about to pass, going slowly since I know how tricky these situations are, one of the horses reared up and set off down the road. I came to an instant stop despite the ice patches and waited as the rider controlled it and brought it back to the grass. At this point the horses were clearly getting nervous and it was spreading between them but I was able to carefully but quickly get off up the road past them, hopefully allowing the situation to diffuse. I can see these issues from both sides and I hope the horses/riders weren’t too upset.

Next up was a road with a sign about a ford being washed out and impassible. To us this was interesting, we’ll see. Upon arrival, it was clear there was a *lot* of fast moving water going through the core channel and it had been roped off with warning tape. We couldn’t see any indication of depth and some of the group thought it was possible but I was of the opinion it was too deep/fast and after some discussion we reached that consensus. It’d be interesting to see it in summer.

Periodically, Ben’s bike was cutting out, likely due to the cold and some form of carb icing type effect. It was frustrating as he’d have to sit for a while, then the bike would work just fine again. It was also proving a pain to kick start. I can sympathise with this after experiencing how draining kick starting the CRM was when I first started. At one point he’d dropped it in the mud and couldn’t get it started and was obviously worn out so I gave it a go whilst he recovered a bit. It started first kick, I know how annoying it is for someone to do that :/.

At the end of one lane, we had a bit of confusion over the exact route to take with it turning out to be a drop down a hill, over a tiny stream, then through a much deeper ford crossing. On the drop, I managed to get a large tree branch stuck between the mud guard and the front wheel for which I had to stop and disentanhgle it. This isn’t simple on a steep slope but I eventually managed. I only saw the last member of the group going through the ford but it was clear Ben had fallen in. I was given several pieces of conflicting advice about the best route over including mention of a large piece of old road which may or may not be in certain bits of the river but wasn’t visible from where I was on the other side. Great. I set off through and about half way, it was clear I was riding on a piece of flat slab (old roadway?). So far so good but they’d said there was a problem? Sure enough, all of a sudden it became cracked, pointing upwards and then stopped with a deep drop (1ft+) off the end. At this point I accelerated a little and attempted a small jump off the end, as best as is possible off a slime covered piece of rock in water. Thankfully the bike then landed upright in the properly deep water with both wheels and I could quickly power out the river. Apparently Ben had attempted something similar but had lost balance coming off the slab, needed to put a foot down and slipped off. Far too easily done. We emptied out the drowned bike, then towed it to get it started.

We then had to stop in a village and wait whilst once again Stewie had to repair his chain. By this point we were running well behind schedule due to the stoppages and general slow progress made. There were some lovely relatively unused lanes we passed through. One memorable moment was coming to a shear decent, probably only a couple of metres in height which took some nerve to plunge the bike over. Again I was cursing the condition of the tyres on the muddy bits and couldn’t carry any speed.

By this point time was against us as it was going to be getting dark. There certainly wasn’t time for a lunch stop and we pressed on. We winded over the A686 (heads to Alston) taking some interesting lanes although I was still fighting tyres and going slowly. We then went up a trail that leads to hardside cafe which I’ve heard of but never done. I think I made the biggest hash of it I’d made all day, being unable to get traction anywhere even vaguely muddy. I ended up stalling and having to drop the bike into ruts to find stone to get momentum up the hillside. There is a steep climb at the side of the trail here and one group member did attempt it but only got halfway. The trouble then is getting back down safely. I decided not to bother given my experiences so far that day (and experiences of steep climbs going wrong on other occasions).

We then headed over to Garrigill at which point I hit reserve fuel (eek!). I did warn the rest of the group and thought Alston for a top up might be wise but Steve thought we’d make it back ok (he and another group member hit reserve too). We took the road over the top to Nenthead. I know this road well for various reasons and know that if there will be snow/ice anywhere, its on this road (17th highest road in Great Britain). Sure enough the whole thing was sheet ice. Making it the hill was bad enough. Once at the top, you then have the problem of getting down the other side. The only way I could do it was on the verge, being very mindful of the deep holes and drop offs (up to 6ft) in the verge. I was surprised to make it down there without some kind of incident, I was going very slowly/carefully. Apparently Steve did drop his bike at one point (I didn’t for a change!).

There was one more lane and then it was tarmac back to Allendale. At this point I ran out of fuel entirely. Thankfully Paul came back to look for me when I disappeared and using a water bottle, I was able to share some of his fuel, enough to get me back to the van. Meanwhile, Stewie had also run out and was towed the last couple of miles.

Despite the issues, it was a great day out, one of the days I’ll look back on with fond memories. I really enjoyed it and look forward to exploring more trails in that area when there is a bit more daylight.

Richard 'RP' Purdie: Crazy Insurance People

Fri, 13 Jan 2012 10:54:50 +0000

“We are unable to quote for house insurance since our records show you are within 50m of water and are at risk of flooding”.

Well, yes I am within 50m of water. Its called the North Sea, its clearly visible out of all my front windows. What isn’t being accounted for are the sea defenses, a lower and upper promenade and a road between me and it, not to mention the cliffs. A hint about the height of the cliffs is the “High Point Hotel” just up the street which oddly enough is built on “High Point”.

Not quoting based on the risk of coastal erosion I could understand (although with the sea defenses here its extremely unlikely and they’d protect the road) but flooding?! I guess its possible bits of Norway might fall into the sea and cause a tsunami but thats about what it would take…

Holger 'zecke' Freyther: QtMediaHub on MIPS with Qt5 and DirectFb

noreply@blogger.com (zecke) — Tue, 10 Jan 2012 13:10:18 +0000

Ever since the start of the Qt project I am working on DirectFB in Qt5 (and Qt4) with the remote goal of getting QtMediaHub to run. It started with catching up with the rather nice refactoring of lighthouse in Qt5, fixing memory and resource leaks in Qt5, DirectFB and mostly in the DirectFB lighthouse plugin.

It moved to dealing with broken "make install", broken QML2 examples and documentation, figuring out how to get patches for QtV8/V8 into the project, adding MIPS code for the Qml mode (a new global object), global compare for MIPS and finally working on OpenGL integration for QML2.

In this specific case I had an OpenGL ES 2.0 library coming from a vendor and created the 'directfbegl' plugin to use EGL to go from IDirectFBSurface to an eglSurface. I think in this specific case there is unified 2D and 3D buffer space which should allow a lot of cool stuff.

It mostly works, QML2 has some way to go to work on battery powered devices but it is looking quite nice.

Paul 'pfalcon' Sokolovsky: Bluetooth Park Mode Exposed

noreply@blogger.com (pfalcon) — Sat, 07 Jan 2012 17:05:05 +0000

So well, as I settled on Bluetooth as a wireless sensor/automation protocol and grow my device base, I started to wonder what will happen when I'll have more than 7 slave devices. Bluetooth stack of master device (Bluez in our case) must be smart to put devices into and out of PARK mode to allow to communicate with more than 7 devices, right? Not in this world.

Not only Bluez doesn't support park management, according to Marcel Holtmann, the problem is that it's really not known if there're devices (masters) which can support more than very limited number of slaves, or even have decent park mode implementation at all:

Anyway, I started to test parking with devices I have.

HC-04 Bluetooth module with CSR BlueCore4-Ext

# hcitool cc 00:11:10:xx:xx:xx; hcitool con

Connections:
    < ACL 00:11:10:xx:xx:xx handle 12 state 8 lm MASTER

What we need here is a connection handle 12 (0x0c). hcitool doesn't have dedicated command for part mode (and for lot of other things), so we'll use raw HCI command mode using "cmd" command:

# hcitool cmd --help
Usage:
    cmd <ogf> <ocf> [parameters]
Example:
    cmd 0x03 0x0013 0x41 0x42 0x43 0x44

What's important here is that <parameters> should be byte values. If words should be given as parameters, they should be give by bytes in little-endian format.

# hcitool cc 00:11:10:xx:xx:xx; hcitool cmd 0x02 0x05 0x0c 0 0x50 0 0x40 0

Here we run HCI_Park_State(Connection_Handle=0x000c, Beacon_Max_Interval=0x0050, Beacon_Min_Interval=0x0040) command (see Bluetooth spec). And here's communication as captured by hcidump (parts irrelevant to park command omitted):

2012-01-07 15:36:46.084074 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 15:36:46.086040 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 15:36:46.271047 > HCI Event: Mode Change (0x14) plen 6
    status 0x24 handle 12 mode 0x00 interval 0
    Error: LMP PDU Not Allowed

This "LMP PDU Not Allowed" was quite confusing and took me lot of googling to figure out. Fortunately, I found insightful post from a CSR guy right on this matter: http://article.gmane.org/gmane.linux.bluez.devel/72

What we get here is that local Bluetooth master just forwards status it got from the remote device. As the message suggests, park might be disabled in remote device line policy. Let's see:

# hcitool cc 00:11:10:xx:xx:xx; hcitool lp 00:11:10:xx:xx:xx
Link policy settings: RSWITCH HOLD SNIFF PARK

Here's slight issue of what hcitool lp actually does. According to man, it "displays link policy settings for the connection to the device with Bluetooth address". There's also "hcitool lp" command which "Sets default link policy". So, reasonable assumption would be that every device may have default link policy, then during connection, they negotiate link policy which is suitable for the connection. Ok, let's set PARK policy explicitly:

# hcitool cc 00:11:10:xx:xx:xx; hcitool lp 00:11:10:xx:xx:xx PARK; hcitool lp 00:11:10:xx:xx:xx; hcitool cmd 0x02 0x05 0x0c 0 0x50 0 0x40 0
Link policy settings: PARK
< HCI Command: ogf 0x02, ocf 0x0005, plen 6
0C 00 50 00 40 00
> HCI Event: 0x0f plen 4
00 01 05 08

But hcidump shows the the same "LMP PDU Not Allowed" error. So, what we have is that HC-04 module advertizes park support, it apparently negotiates its availability for connection, but when asked to actually perform it, it rejects it. This is so much correlates with this message: http://article.gmane.org/gmane.linux.bluez.user/12710

PS3 Bluetooth remote

# hcitool info 00:06:F5:xx:xx:xx
Requesting information ...
    BD Address: 00:06:F5:xx:xx:xx
    Device Name: BD Remote Control
    LMP Version: 2.0 (0x3) LMP Subversion: 0x229
    Manufacturer: Broadcom Corporation (15)
    Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
        <encryption> <slot offset> <timing accuracy> <role switch>
        <sniff mode> <RSSI> <power control> <enhanced iscan>
        <interlaced iscan> <interlaced pscan> <AFH cap. slave>

So, this fair Broadcom device doesn't even conceal the fact that it's barely Bluetooth interoperatable - it doesn't support park state at all.

No surprises when asking it to go there nontheless:

2012-01-07 16:03:08.863586 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 13 max 80 min 64
2012-01-07 16:03:08.865636 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x1a ncmd 1
    Error: Unsupported Remote Feature / Unsupported LMP Feature

LG KS20 WindowsMobile phone

# hcitool info 00:1E:75:xx:xx:xx | grep park
        <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>

So, this one advertizes park. But:

2012-01-07 16:29:11.288514 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 16:29:11.290485 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 16:29:11.466508 > HCI Event: Mode Change (0x14) plen 6
    status 0x0c handle 12 mode 0x00 interval 0
    Error: Command Disallowed

Broadcom is such Broadcom...

Huawei U8160 aka Vodafone 858 Smart Android phone
# hcitool info 04:C0:6F:xx:xx:xx | grep park

<empty>

2012-01-07 16:19:01.322536 < HCI Command: Park State (0x02|0x0005) plen 6

handle 12 max 80 min 64

2012-01-07 16:19:01.324521 > HCI Event: Command Status (0x0f) plen 4

Park State (0x02|0x0005) status 0x1a ncmd 1

Error: Unsupported Remote Feature / Unsupported LMP Feature

Broadcom is such Broadcom...

HTC Mogul WindowsMobile phone

2012-01-07 16:11:14.184067 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 16:11:14.186430 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 16:11:14.528429 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x03 interval 80
    Mode: Park

Bwahaha! TI rules!

Samsung i740 WindowsMobile phone

Manufacturer: Cambridge Silicon Radio (10)

2012-01-07 17:54:17.141466 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 17:54:17.142911 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 17:54:17.472919 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x03 interval 80
    Mode: Park

Linux computer with Broadcom chip

Park mode work here, supervised by Bluez.

So, out of 7 devices (that's whole piconet, and I have more!) only 3 supported park mode.

More insightful posts:

Paul 'pfalcon' Sokolovsky: Linux kernel Bluetooth ACL connection auto-disconnect

noreply@blogger.com (pfalcon) — Sat, 07 Jan 2012 13:14:13 +0000

I finally found time to figure out why "hcitool cc" created connections die very soon (see previous posts). It turned out to be handled on the Linux kernel level. What's worse is that it's hardcoded at 2s - no provision for adjustment via sysfs for example. http://lxr.free-electrons.com/source/include/net/bluetooth/hci.h?v=3.0#L120 :

118 /* HCI timeouts */
119 #define HCI_CONNECT_TIMEOUT     (40000) /* 40 seconds */
120 #define HCI_DISCONN_TIMEOUT     (2000)  /* 2 seconds */
121 #define HCI_PAIRING_TIMEOUT     (60000) /* 60 seconds */
122 #define HCI_IDLE_TIMEOUT        (6000)  /* 6 seconds */
123 #define HCI_INIT_TIMEOUT        (10000) /* 10 seconds */
124 #define HCI_CMD_TIMEOUT         (1000)  /* 1 seconds */

Actual disconnection happens in hci_conn_timeout(). Other issue is that such disconnect reported as "Remote User Terminated Connection", which is, well, not true, as I don't terminate it, the system does. There's another status code, "Remote Device Terminated Connection due to Low Resources" which IMHO more suitable (if there's no "low resources", why do you disconnect so quickly, dear Linux?).

I quickly made a patch to be able to adjust disconnect timeout via sysfs, to experiment with low level connection more comfortably. Unfortunately, it turns out that I can extend delay to max 10s, even if set value much higher. So, something appears to call disconnect routine, even though I don't see any other references or timer manipulation %).

Florian Boor: Computer startup aid using a LEGO train

Fri, 06 Jan 2012 18:31:43 +0000

Some times it happens that I have to dig out some old piece of hardware and try to get it running again… I recently got a very geek present for my birthday – one that requires a working SGI Indigo next to it. Luckily nothing gets lost at kernel concepts and I was able to select from several Indigo gathering dust at the attic of our office. It looks like the machines survived quite some years not being used pretty well – including most of the harddisks. Unluckily all batteries which are supposed to supply the real-time clock chip were flat and these batteries are hard to get and soldered to the board. I did not have a replacement for the 3.6V Lithium battery but it was pretty easy to replace the battery with some cables to supply the board with 3.6V. The first thing to supply 3.6V I found was the electric LEGO locomotive the kids left lying around…

Indigo Lego Train

This one was powered by three 1.2V AA rechargeable batteries – perfect for some startup aid for this old machine. After applying power I was able to boot into IRIX 6.2 installed on this historic piece of hardware (100MHz MIPS R4000 CPU, 192MB of RAM, 2GB SCSI hard disk, ELAN graphics). I have to admit I somehow enjoyed the “time travel” experience playing around with such an old system for a while. Someone here still remembers the Netscape browser? Or Electropaint? One really scary experience was the network setup: IRIX 6.2 has the ability to configure a static IP through the GUI but obviously you have to edit the network startup script in order to set a default route on boot.

A lot more of information about these machines can be found here.

Nils Faerber: M$ to buy Nokia smartphone division? WTF!?

Fri, 06 Jan 2012 17:49:51 +0000

According to many news tickers, Slashdot amongst them:

http://mobile.slashdot.org/story/12/01/05/2325227/microsoft-in-talks-to-buy-nokias-smartphone-division

rumors spread that Microsoft is about to take over the whole smartphone business from Nokia and as nice cream tip, Elop might change back to Microsoft and lead that pack.

If I would be a Nokia share holder I would sue Elop personally for intentionally destroying Nokia's smartphone business in order to have it later on being taken over by Microsoft entirely.
Doesn't that seem like a good 'evil' plan by Microsoft?

Florian Boor: Android Lessions Part 1: Bluetooth Crash

Wed, 04 Jan 2012 23:05:45 +0000

Finally – some free days for family and friends and to write a few lines which might be useful for someone else. Since Android started to become more and more interesting for industrial and business applications I got involved in some projects porting Android to several devices. It turned out that the documentation of the lower layers (hardware and driver adaptation) is very thin in contrast to the SDK and NDK documentation. But I took some notes working on these projects… this one might be useful for other people porting Android 2.3.x and experiencing issues with Bluetooth.

I ran into the issue that activating Bluetooth in the settings application resulted in a crash of the whole GUI. It seems that only ARMv5 core based devices are affected so that only a few people ran into this so far. (Not that it would be correct on more common cores used for Android devices such as ARMv7A, but it does not seem to cause the same effect.) The solution I found in the Android 4 commit log is quite simple for a problem causing that much of hassle:

--- a/core/jni/android_server_BluetoothEventLoop.cpp +++ b/core/jni/android_server_BluetoothEventLoop.cpp @@ -311,7 +311,7 @@ static int register_agent(native_data_t *nat, { DBusMessage *msg, *reply; DBusError err; - bool oob = TRUE; + dbus_bool_t oob = TRUE;

Richard 'RP' Purdie: Banks of the tyne

Tue, 03 Jan 2012 16:43:23 +0000

Its traditional for the local trail riders to want to escape into the countryside during the Christmas holidays and this year was no exception. Last year we had snowfall which made it all the more interesting but its been relatively mild this year so far. We met at Prudhoe to realise the usual fuel stop was closed due to the bank holiday but there was another garage open nearby thankfully. We did the usual lanes around Slaley noting that the obstructed right of way which we’ve had long standing issues with and I mentioned in a previous post is finally being opened up on the correct route!

Before long I noticed the last man behind me had disappeared so I turned back to find his chain had snapped (at the split link). I was starting to assist in the repairs when it was pointed out my number plate was half hanging off. Some rearranging of some bolts had it reattached in a different way and others had the a replacement split link fitted at the expense of a pair of my pliers by that time.

We came across a shooting party who were not pleased to see us and thought we shouldn’t be there. They were shooting from a public highway (illegal) and standing around with loaded guns on a highway (illegal) but it wasn’t worth risking a discussion with them.

I seemed to be having trouble on anything muddy with the bike sliding all over. At one point I started off down a deeply rutted trail and found the bike weaving all over. It got bad enough that I ended up stopping abruptly when the wheel ran into the side of the rut, hard. Its amazing what goes through your mind and how quickly it can think through things at a time like this. Upon consideration of the situation, I quickly realised there was only air on my right hand side and that was the direction the bike was going to fall over in. Rather than try and catch the bike when my leg did find ground (and likely break something), I evidently decided that escape was the best option so I dived off the bike. I rolled in the air, hitting the ground rolling on my shoulder, and right side. Something told me I had too much momentum to try and stop. I was probably remembering the motorcycle track day rider briefings where they warn you about trying to get up too early after falling off a bike at speed (wait for 2 seconds *after* you think you’ve stopped as you likely haven’t). The consequences of not waiting are described as “breaking off your sticky out bits”. I therefore let myself make another revolution at which point my speed was sufficiently reduced and I somehow made a relatively graceful transition to a standing position at which point I was laughing. The group stopped behind me gave my gymnastics top scores. The body armour did its job and I didn’t really feel any of it. The bike was fine having really just been laid on its side.

We wound our way over trails I’m starting to know quite well heading down the south side of the Tyne and ended up at Twice Brewed for lunch. Its great to see some of the interesting places we get to on the trails although its frustrating not being able to sample the beer! We headed back along the north bank and did some trails I’ve not been on for a while, probably not since I first joined the TRF. By this time is was starting to get dark and it was time to head home. It was good to be reminded of some of those lanes and there was at least one I never remember having ridden on before so it was an interesting day out.

Paul 'pfalcon' Sokolovsky: Bluetooth link key types

noreply@blogger.com (pfalcon) — Fri, 30 Dec 2011 13:07:06 +0000

From http://lxr.linux.no/#linux+v3.1.6/include/net/bluetooth/hci.h#L254 :

/* Link Key types */
#define HCI_LK_COMBINATION        0x00
#define HCI_LK_LOCAL_UNIT        0x01
#define HCI_LK_REMOTE_UNIT        0x02
#define HCI_LK_DEBUG_COMBINATION    0x03
#define HCI_LK_UNAUTH_COMBINATION    0x04
#define HCI_LK_AUTH_COMBINATION        0x05
#define HCI_LK_CHANGED_COMBINATION    0x06

Paul 'pfalcon' Sokolovsky: Pairing Bluetooth devices from command line

noreply@blogger.com (pfalcon) — Fri, 30 Dec 2011 13:00:15 +0000

Following appear to be commands required to trigger pairing process from the command line:

hcitool cc <bdaddr>; hcitool auth <bdaddr>

Commands must be on the same line, separated by the semicolon, as described in previous post.

At this point, Bluez auth agent should kick in, asking for a code, if you have GUI one.

I found a page which suggests that only "hcitool cc" was enough for the author to trigger pairing, this could be explained by the fact that prior to 2.1, Bluetooth supported security modes which could protect either entire device access or just some of its profiles.

Paul 'pfalcon' Sokolovsky: Making hcitool commands work

noreply@blogger.com (pfalcon) — Fri, 30 Dec 2011 12:51:32 +0000

It's a shame how some now-ubiquitous technologies, like Bluetooth, are under-used and under-understood. And by usage I don't mean here occasional business card exchange, net access, being bluesnarfed and other boring consumer-level activity, but page scans, inquiries and having secure wireless communication you can trust (or not).

Anyway, if you ever tried using hcitool you may think it barely works. For example:


# hcitool cc <bdaddr>
# hcitool lq <bdaddr>
Not connected.

Ok, so here's the matter. First of all, hcitool accesses hci device directly, and that requires root access. Secondly, it works on low protocol level (ACL), so connection established by "cc" is of course not pairing or service-level connection. It's low level connection, which persist only while data is transferred and shutdown quickly to preserve the power. Yep, it shuts down while you type or even re-run next command. That's how it should be done:


# hcitool cc <bdaddr>; hcitool lq <bdaddr>
Link quality: 255

More fun:


# hcitool cc $BDADDR; hcitool auth $BDADDR; hcitool enc $BDADDR; hcitool key $BDADDR; hcitool con
Connections:
< ACL 7D:75:75:xx:xx:xx handle 12 state 1 lm MASTER AUTH ENCRYPT SECURE

Marcin 'Hrw' Juszkiewicz: Links for 2011-12-29 [del.icio.us]

Fri, 30 Dec 2011 08:00:00 +0000

Deprecated Linux networking commands and their replacements « Doug Vitale Tech Blog
Specifically, the deprecated Linux networking commands in question are: arp, ifconfig, iptunnel, iwconfig, nameif, netstat, and route. These programs (except iwconfig) are included in the net-tools package that has been unmaintained for years. The functionality provided by several of these utilities has been reproduced and improved in the new iproute2 suite, primarily by using its new ip command. The iproute2 software code and documentation are available from the Linux Foundation.

Richard 'RP' Purdie: CRM Spares Not looking so good

Tue, 20 Dec 2011 23:29:29 +0000

One of the reasons I like the CRM was the availability of spare parts. It may be an 18 year old bike but it was ahead of its time in design and you could still get most parts for it.

After the last trip out, it was suspected the oil pump throttle cable was pinched somewhere causing the sticky oil pump action, likely after having had the tank off. I finally got around to taking the tank off and it was clear this was not the cause. Even having isolated the cable from the splitter box with the main throttle cable, it was still not moving freely. Even with the cable totally removed from the bike, it wasn’t clear why it wasn’t happy although there was a nasty looking stretch in the cable outer just as it exits the oil pump. Fiddling with the cable, a strand of frayed cable appeared at which point it became clear there was hidden internal damage. I got a little more forceful in separating some of the fittings and found it really was rather worn being down to a couple of strands:

I was lucky this hadn’t snapped, cutting off the bike’s two stroke oil supply. So, no problem, I’ll just buy a new one. Upon enquiry with the usual purveyor of parts for CRMs I was told that it was not possible to order one and they had no replacement, sorry. This was a bit of a surprise and apparently likely due to the Japanese Tsunami disrupting the Honda parts supply chain. The likelihood of them ever retooling to produce these parts again was remote. I really wanted to have the bike available for use over the holidays too.

Not to be stopped by something like this I went and took a look at my brother’s box of throttle cable components and found he had the right pieces to make a new one (new end fittings, cable, inner liner and outer). The end result:

Its now on the bike and should work as required. I’ve rerouted it a bit to avoid pressure like the original had. I also had to tighten the return spring on the oil pump since the it wasn’t fully closing the oil feed at closed throttle and is evidently weakened with age and probably the previous damaged cable. Longer term, the lack of spares for the CRM might start to become an issue as there are many things that can’t be copied as easily

Koen Kooi: Using the analog pins on a beaglebone

Tue, 20 Dec 2011 17:48:13 +0000

The long term plan is to use the IIO framework, but till that happens:

root@beaglebone:~# for adc in /sys/devices/platform/tsc/ain* ; do echo "$(basename $adc): $(cat $adc)" ; done
ain1: 3967
ain2: 3762
ain3: 3930
ain4: 1993
ain5: 2096
ain6: 3748
ain7: 3814
ain8: 31

Richard 'RP' Purdie: Green lanes, mid week, two bikes

Tue, 20 Dec 2011 11:52:14 +0000

[This happened back in September but I realised I never posted it]

I’ve promised my brother a try on a trail bike somewhere and things seemed to align to make it possible. Rather than a quick try, I suggested we just go for a run out. I’ve never been trail riding mid week before and never just with two bikes. This would also be the YZ’s second real trip out. What could possibly go wrong?

We left my garage just after the rush hour traffic died down and had the horrible fight through traffic to reach the other side of Newcastle. After a few more miles we reached the first trail, a nice uphill section which is “ideal” for someone who’s never had a bike offroad before. Chris did fine though. We looped over some further trails winding our way to Slaley forest. One of the routes there has had one end blocked up and we confirmed that was still the case. The local group is working on getting it fixed.

Since Chris didn’t want to destroy his road bike boots, I was trying to be careful where I took him. I couldn’t resist demonstrating the bike was perfectly capable to going through mud over the wheels on at least one occasion though.

We exited Slaley going through some water crossings which I got the bikes through, looped around some trails. At this point Chris was riding through the water crossings with his feet up. I did point out this was fine until you hit something. This is a lesson you learn the hard way though.

We then came back to Slaley from a different direction and then up onto Emberly Fell. This trail is seasonal and closed from 30th Sept for six months of the year so it was nice to ride it before it was out of bounds for a while. I think Chris found the mud/moorland harder than the rockier pieces we’d been on so far. He did have the bike stop standing in a rut as he went for a run. At least he didn’t have to pick it up . I was also bemused at one point to be sitting waiting and rather than ride up to me, he took a detour though several bushes

From here it was up onto Blanchland moor, over the top into the next valley. I’d decided the best place to head was Hamsterly Forest, a dead end but good fun with no deep water crossings. We made it over the first part of the route, then my bike started sounding rough. Not good. At this point I realised I was out of fuel. We hadn’t made a fuel stop when getting to the other side of Newcastle like I’d planned.

So what to do? I did have “reserve” although looking into the tank, I wasn’t optimistic about how long it would last. The nearest garage was the one we were heading for in Wolsingham, quite a distance away and there was not one nearer. I’d screwed up by not stopping for fuel once through Newcastle and was still thinking in CRM tank range. All we could do was press on. I went into fuel conservation mode, stopping the bike when I could although since it had no kill switch and has to stall in gear to stop the engine, it was hard to coast down hills.

We continued to have some good fun with me riding into what looked like a little puddle that pretty much swallowed the bike. Fuel conservation was forgotten as I had to open it up to get out of that mess quickly, muddy water going everywhere. Apparently it was funny to watch.

The fuel ran out on the flat tops of the hills overlooking the valley that Wolsingham is in. I assessed how much was in the CRM and decided to steal some of its for the YZ in the hope we’d both make it to the garage. The easiest way to do this was simply to remove the CRM’s tank and drain it in which we did. I got over the flat bit, stalled the bike, then coasted down the hillside. I had enough fuel to ride the road to the garage and I don’t think I’ve ever been more relieved to reach a fuel station.

After refueling we continued on to Hamsterly with Chris getting to see
some pretty nice landscape. The water eroded path we rode along contains
pretty scary drops, bumps, rocks and other obstacles and is a lovely
illustration of what those bikes can actually cope with. We reached the
far side of Hamsterly and had lunch.

The trip back was pretty much the route out but with Slaley cut out. It was getting quite late by this point and we needed to get back. On the third last trail of the day, Chris asked me what the red light meant. It was either over temperature or low two stoke oil, we decided on over temperature and the radiator seemed low on water. It should have been fine for two stroke oil. It was also smoking quite a bit. I decided to abort the rest of the lanes and head for civilisation and a garage. It did take water but not as much as we’d expected. I decided to head home and hope we made it.

As we drew nearer my house, the smoke was getting worse and worse, it was like a smoke screen. I was dreading what state the engine was in but at this point we might as well try and make it back. We got back, washed off the bikes and put them away.

I finally got around to a quick look at the bike to see what was wrong. Surprisingly after being left for a couple of days the bike had good compression and fired up first kick. The red warning light was still on. That means its the two stoke oil as it definitely was cold (or something was broken with the temperature sensing which is unlikely). I decided to check how much two stroke oil it had and pulled off the oil pump cover to disconnect the pipe to check there was still some in there. There was oil but the oil pump looked odd somehow, cue some staring at it. There was something not right, but what? I poked the pulley and it sprang back to closed position. Opening the throttle was indeed opening the oil pump but closing the throttle was not closing the pump off, the cable was sticking. Aha!, that would explain the problems. So the working theory is that when we put the tank back on we’ve somehow trapped the oil pump cable and its not returning properly, I’ve not checked into it further yet.

Chris did extremely well for a first time out on green lanes and whilst its a shame the CRM decided to act up, I don’t think it spoilt the day too much.

Michael 'Mickey' Lauer: IT has seen a crazy year

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

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

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

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

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

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

Nils Faerber: Success - HP frees WebOS !

Sat, 10 Dec 2011 01:00:48 +0000

According to HP and their own developer blog, WebOS indeed becomes open source!

http://developer.palm.com/blog/2011/12/open-source/

This is excellent and great news. I am looking forward to seeing the actual code and project. I sincerely hope that this will not just become a code-dump onto the community.

I am very excited - let's hope for the best!

Cheers
nils

Florian Boor: WebOS goes Open Source

Fri, 09 Dec 2011 20:58:34 +0000

Amazing news! HP just announced that WebOS will become an Open Source project lead and supported by HP in future. The full annoncement can be found here.
HP has an official press release about this here. I’m really looking forward to work with it… It’s quite an interesting framework for a large number of devices. The really funny thing is that Nils asked them to do so in his blog some weeks ago :-)

Michael 'Mickey' Lauer: Towards the end of 2011

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

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

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

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

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

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

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

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

All the best to you guys!

Florian Boor: Summer Holidays

Fri, 02 Dec 2011 21:03:53 +0000

Now that its autumn in Europe it is a good time to blog about the summer vacations :) The Chaos Communication Camp was a real highlight – just a perfect environment for Hacker’s and their fork()^h^h^h offsprings summer vacations. I do not want to write too much… saving some words for more technical posts, but maybe someone likes the photos I took:

Quadcopter Nightflight

Camp at Night

Antonov AN-2

This nice machine was parked next to our caravan… it’s a little bit larger than you might guess from the photo. I have placed some more photos here.