copyleft hardware planet

Videos from the Embedded Linux Conference in San Francisco, April 12-14, 2010.

The 2010 edition of the Embedded Linux Conference was once again a very interesting event. For embedded Linux developers, the Embedded Linux Conference is a perfect place to learn about new technologies, profit from the experience of other developers, and to meet key software developers.

For people who couldn’t attend this conference, and for single core people who didn’t manage to attend two or three talks at the same time, here are the videos that we managed to shoot. As usual, the videos are released with a Creative Commons Attribution – ShareAlike 3.0 license.

• Welcome speech, by Tim Bird (CE Linux Forum)
  HD video (12 minutes, 128M)
• Real-Time Linux Failure, by Frank Rowand (Sony Corporation)
  slides, HD video (53 minutes, 488M)
• Using Interrupt Threads to Prioritize Interrupts, by Mike Anderson (The PTR Group)
  slides, HD video (61 minutes, 574M)
• Android: A Case Study of an Embedded Linux Project, by Greg Kroah-Hartman (Novell)
  slides, HD video (52 minutes, 893M)
• Experiences in Android Porting, Lessons Learned,Tips and Tricks, by Marc Gross (Intel)
  slides, HD video (56 minutes, 398M)
• Measuring Responsiveness of Linux Kernel on Embedded System, by YungJoon Jung and DongHyouk Lim (ETRI)
  HD video (41 minutes, 220M)
• GPIO: Talking to the Outside World, by Gene Sally (Touchtown)
  slides, HD video (0 minutes, 596M)
• Announcements, by Tim Bird (Sony)
  HD video (6 minutes, 144M)
• Embedded in 2010: An End to the Entropy?, by Matt Asay (Canonical)
  slides, HD video (41 minutes, 881M)
• Runtime Power Management: Overview and Platform Implementation, by Kevin Hilman (Deep Root Systems)
  slides, HD video (55 minutes, 1.3G)
• Embedded Multi-core with Adeos, by Dan Malek (Mentor Graphics)
  HD video (55 minutes, 367M)
• Ftrace – Embedded Edition, by Steven Rostedt (Red Hat)
  slides, HD video (55 minutes, 346M)
• Linux Toolchain Overview with Advanced Debugging and Tracing Features, by Dominique Toupin (Ericsson)
  slides, HD video (58 minutes, 251M)
• Case Study – Embedded linux in a Digital Television STB, by Melanie Rhianna Lewis (Red Embedded Consulting)
  slides, HD video (36 minutes, 358M)
• Link Time Dead Code and Data Elimination Using GNU Toolchain, by Denys Vlasenko (Red Hat)
  slides, HD video (53 minutes, 628M)
• Custom Hardware Modeling for FPGAs and Embedded Linux Platforms with QEMU, by John Williams and Edgar Iglesias (Axis Communications – PetaLogix)
  slides, HD video (53 minutes, 544M)
• Semantic Data Storage for Mobile Devices, by Rob Taylor (CodeThink)
  slides, HD video (58 minutes, 258M)
• Flattened Device Tree ARM Support Update, by Grant Likely (Secret Lab Technologies)
  slides, HD video (56 minutes, 399M)
• Supporting SoC video subsystems in video4linux, by Hans Verkuil (Tandberg Telecom)
  slides, HD video (51 minutes, 678M)
• An Introduction to the Qt Development Framework, by Jeremy Katz (Nokia)
  slides, HD video (33 minutes, 631M)
• Porting the Linux Kernel to x86 MID Platforms, by Jacob Pan (Intel)
  slides, HD video (49 minutes, 512M)
• Recent Developments in Open Video Technology, by David Schleef (Entroypy Wave)
  slides, HD video (54 minutes, 446M)
• Strategies for Migrating Uniprocessor Code to Multi-Core SMP, by Mike Anderson (The PTR Group)
  slides, HD video (45 minutes, 445M)
• Understanding Threat Models for Embedded Devices, by Jake Edge (LWN.net)
  slides, HD video (33 minutes, 188M)
• Wake-ups Effect on Idle Power for Intel’s Moorestown MID and Smartphone Platform, by German Monroy (Intel)
  slides, HD video (54 minutes, 346M)
• State of Embedded Linux, by Tim Bird (Sony)
  slides, HD video (48 minutes, 297M)
• Using the LTTng Tracer for System-wide Performance Analysis and Debugging, by Mathieu Desnoyers (EfficiOS)
  slides, HD video (52 minutes, 385M)
• Demo session, by GeeXbox (GeeXbox.org)
  HD video (5 minutes, 172M)
• Creating a Secure Router Using SELinux, by Mike Anderson (The PTR Group)
  slides, HD video (59 minutes, 436M)
• Using a JTAG to Debug Linux Device Drivers (Part 1), by Mike Anderson (The PTR Group)
  slides, HD video (55 minutes, 314M)
• Using a JTAG to Debug Linux Device Drivers (Part 2), by Mike Anderson (The PTR Group)
  slides, HD video (63 minutes, 376M)
• Developing for Non-x86 Targets Using QEMU, by Rob Landley (Impact Linux)
  slides, HD video (57 minutes, 602M)
• Effective Use of Scripting in Embedded Devices, by Steve Bennett (WorkWare Systems)
  slides, video (46 minutes, 187M)
• GeeXboX Enna: embedded Media Center, by Benjamin Zores (GeeXboX)
  slides, video (54 minutes, 244M)
• Kexec – Ready for Embedded Linux?, by Magnus Damm (Renesas)
  slides, video (31 minutes, 142M)
• No Crash Dump? No Problem!, by David VomLehn (Cisco)
  slides, video (53 minutes, 306M)
• Implementing Asynchronous Zero-Copy API for Embedded IVR Application, by Alexey Volkov (Iskratel)
  slides, video (47 minutes, 124M)
• Workload-based Aggressive Power Management on the Intel Moorestown MID and Future Intel MID/Smartphone Platforms, by Sujith Thomas (Intel)
  slides, video (49 minutes, 146M)
• Polishing Dirt: Porting RTOS Code to Linux Userspace Driver Framework, by Vitaly Wool (Ericsson)
  slides, video (51 minutes, 291M)
• Linux Without a Boot Loader?, by Greg Ungerer (SnapGear)
  slides, video (46 minutes, 403M)
• Effective Use of Scripting in Embedded Devices, by Steve Bennett (WorkWare Systems)
  slides, video (46 minutes, 187M)
• Engaging Developer Communities: Lessons and Opportunity from webOS, by Matthew Tippett (Palm)
  slides, video (45 minutes, 281M)
• Lock-free Algorithm for Multi-Core Architecture, by Hiromasa Kanda (SDY Corporation)
  slides, video (47 minutes, 242M)
• A Consideration of Memory Saving by Efficient Mapping of Shared Libraries, by Masahiko Takahashi (NEC Corporation)
  slides, video (22 minutes, 192M)
• Effectively Managing Documentation for Embedded Linux Projects, by Jeff Osier-Mixon (MontaVista)
  slides, video (49 minutes, 162M)
• Multi-core Scheduling Optimizations for Soft Real-time Multi-threaded Applications — A Cooperation Aware Approach, by Lucas Martins De Marchi (STMicroeletronics and ProFUSION)
  slides, video (45 minutes, 140M)
• DVFS for Embedded Linux, by Yong Bon Koo and Youngbin Seo (ETRI)
  slides, video (36 minutes, 150M)
• Understanding and Developing Applications for Maemo Platform, by Leandro Melo de Sales (Federal University of Alagoas, Brazil)
  slides, video (54 minutes, 271M)

We hope it makes you feel like joining the next edition of the conference. If you can’t wait, what about going to ELC Europe in Cambridge (UK) in late October? It has a very interesting program too. Of course, the sessions will also be recorded. I hope to see you there!

For those who don't know: The Motorola Ming was the A1200, a commercially very successful Linux-based phone in China and other parts of Asia, using the EZX software platform, i.e. the kind of hardware that we once built the OpenEZX software.

Motorola has recently announced that they will follow-up with some android based ming phones. It is my suspicion that apart from some mechanical design aspects, those phones will not resemble the ming in any way, neither on the baseband hardware side, nor on the application processor side, and particularly not on the software side.

So it's probably nothing than a marketing coup, trying to connect to successes of the past. Not interesting from the OpenEZX point of view, I guess.

On the last day of August, just in time, the 2010.08 version of Buildroot has been released. For the record, Buildroot is an easy-to-use embedded Linux build system: it can build your toolchain, your root filesystem with all its components (Busybox, libraries, applications, etc.), your kernel and your bootloaders, or any combination of these components.

Amongst the interesting changes in this version :

• Complete rewrite of the bootloader build code. It contained a lot of legacy, unused and unclear stuff, it is now much easier to use and extend. We’ve removed support for Yaboot and added support for the new Barebox bootloader, and all the code to support AT91Bootstrap, AT91DataFlashBoot, U-Boot, Grub and Grub 2 has been rewritten.
• Complete rewrite of the Linux kernel build code. It was also complicated to use, with an horribly complicated kernel version selection mechanism, the new code is much easier to configure and use.
• The configuration file .config is now located in the out-of-tree directory when the O= option is used. So typically, for an out-of-tree build (which are very convenient when using the same Buildroot source tree for different projects/tests), you could do : mkdir ~/myoutput ; make O=~/myoutput menuconfig ; make O=~/myoutput
• Support for building NPTL toolchains with uClibc, using the latest uClibc snapshots.
• Support for the gconfig Gtk-based configurator, in addition to the already available menuconfig and xconfig
• A particular effort has been put on fixing many of the bugs in our Bugzilla, improving robustness thanks to automated random builds, and converting even more packages to the generic and autotools infrastructure
• Various things have also been deprecated: support for the CRIS, IA64, Sparc64 and Alpha architectures, support for Gtk over DirectFB (which is at the moment not supported upstream), Java support (no maintainer has volunteered to maintain this in Buildroot)
• Many components have been bumped to newer versions
• The shared configuration cache, which allowed to speed up the configuration of different packages, has been disabled by default, since it was causing a lot of problems with certain package configurations

I’ve again contributed to a significant portion of this release, being the author of the bootloader build code cleanup, the Linux kernel build code rewrite, leading an effort to reduce the number of outstanding bugs in our Bugzilla and many other little things. The contributors for this release are shown below :

   175  Peter Korsgaard
   168  Thomas Petazzoni
    38  Gustavo Zacarias
    18  cmchao
     8  Luca Ceresoli
     7  Paul Jones
     6  Lionel Landwerlin
     6  Malte Starostik
     5  Yann E. MORIN
     3  Julien Boibessot
     3  Khem Raj
     2  Dmytro Milinevskyy
     2  Francois Perrad
     2  Nick Leverton
     2  Peter Huewe
     2  Stanislav Bogatyrev
     1  Baruch Siach
     1  Bjørn Forsman
     1  Daniel Hobi
     1  Darcy Watkins
     1  Darius Augulis
     1  H Hartley Sweeten
     1  Karl Krach
     1  Kelvin Cheung
     1  Ossy
     1  Sagaert Johan
     1  Simon Pasch
     1  Slava Zanko
     1  Thiago A. Correa
     1  Will Wagner
     1  Yegor Yefremov

For the next release, there are already a few things in the pipeline :

• Cleanup of all the board support code in Buildroot, in order to cleanly add support for more boards like BeagleBoard, Qemu boards, Calao boards, etc. We’ll use the new minimal defconfig mechanism used by the kernel. I’ve already started working on this
• Cleanup of the package download process, to support Git and SVN download. The code has already been written by Maxime Petazzoni, reviewed on the list, so I expect it to be included fairly soon
• Rewrite of libtool handling code, to remove some of our ugly libtool hacks. The code is currently being worked on by Lionel Landwerlin
• Support for compiling toolchain using Crosstool-NG as a backend. The code is currently being finalized by Yann E. Morin, the author of Crosstool-NG
• Further work on package uninstallation, clean partial rebuild. Some work has been started by Lionel Landwerlin, but it needs some discussion
• Continue the conversion of packages to the generic and autotools infrastructures
• I have also a ton of other things on my TODO-list : rework gdb/gdbserver support with external toolchains, rework the configuration of IPv6/RPC/locale/etc. with external toolchains, set up a Wiki-based Buildroot website with tutorials and better documentation, clean up the toolchain build process, reduce the number of “enhancement” bugs waiting in our Bugzilla, etc.

As Peter Korsgaard, Buildroot maintainer, said in the 2010.08 announcement: The next release is going to be 2010.11. Expect the first release candidate in late October and the final release at the end of November..

It is worth noting that we will be having a Buildroot Developer Day, on Friday 29th October, right after Embedded Linux Conference Europe. At least Peter Korsgaard, Lionel Landwerlin, Yann E. Morin and myself should be there.

An example Python script, which can be re-used with other website engines.

The Free Electrons website is proudly powered by WordPress. It is a mix of static pages and blog posts, and we are very satisfied of the way we can manage and post content.

Being the webmaster, I had an issue though. Several of our pages share the same bits of content, in particular the descriptions of our public training sessions. To avoid discrepancies between pages, I ended up writing scripts to generate the contents of these pages from common parts. However, updating those pages on the website was done with manual copying and pasting, which was time consuming and error prone.

Fortunately, after some on-line research and practical experiments, I found a simple way of automating the process of login to our WordPress site, open a page for editing, and submitting a new version of the contents.

Since this wasn’t really straightforward, I’m happy to share the Python script I came up with, hoping that it be useful to you too:

#!/usr/bin/env python
#
# update-wordpress-page: updates a WordPress page with the contents
# of the input file
#
# Usage: update-wordpress-page url-base post-id content-file
#
# Example: update-wordpress-page myblog.com 245 page-contents
#
# For each url-base, the $HOME/.update-wordpress-page file
# should give the wordpress user and password
#
# Multiple wordpress sites are supported.
#
# Tested with Python 2.6 and WordPress 3.0
#
# Advantage: you don't have to leave a direct database connection
# to your website open, and don't have to understand
# the WordPress database.
#
# Copyright 2010, Free Electrons, michael@free-electrons.com
# License: Public domain

import urllib, urllib2, cookielib, optparse, sys, os
import ConfigParser, ClientForm

usage = 'Usage: %prog url-base postid page-contents'
description = 'Updates a WordPress page with the specified contents'
optparser = optparse.OptionParser(usage=usage, version='1.0beta1', \
 				  description=description)
(options, args) = optparser.parse_args()

if len(args) != 3:
   print 'Wrong number of arguments. Exiting.'
   sys.exit()

url_base = args[0]
post_id = args [1]
login_url = 'http://' + url_base + '/wp-login.php'
url = 'http://' + url_base + '/wp-admin/post.php?post=' \
      + post_id + '&action=edit'

page_contents = args[2]
file = open(page_contents)
new_contents= file.read()
file.close()

# Read configuration file

config = ConfigParser.RawConfigParser()
config.read(os.environ['HOME'] + '/.update-wordpress-page')
user = config.get(url_base, 'user')
password = config.get(url_base, 'password')

# Open the authentication page
cj = cookielib.CookieJar()
opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))

login_data = urllib.urlencode({'log' : user,
'pwd' : password,
})

# Log in
resp = opener.open(login_url, login_data)
resp.close()

# Access member only pages
resp = opener.open(url)

forms = ClientForm.ParseResponse(resp, backwards_compat=False)

try:
	# WordPress has multiple forms and uses forms[1] for content
	# Other versions or other CMS may use [0] or [2]...
	form = forms[1]
	form["content"] = new_contents
	content = opener.open(form.click()).read()
	check_success(content)

except urllib2.HTTPError, e:
	sys.exit("%d: %s" % (e.code, e.msg))
except IOError, e:
	print e
except:
	pass

resp.close()

This script can only be used to modify an existing page. It just changes the contents, and doesn’t touch other attributes. Of course, you could also extend it to create new pages and posts, but this would represent much more work, having lots of input fields to fill.

Another approach would have been to open a direct database connection to the server running WordPress, and then to perform your updates directly with SQL commands. However, this requires a knowledge about WordPress databases (making the script much less generic), and the open database port also makes your website less secure.

To use my script, you will first have to find the edit URL for your page, which reveals the WordPress post id.

I suggest you to create a special WordPress user with Editor privileges. The page history will then show which changes were automated, and which were manual.

The last thing you will have to do is create a $HOME/.update-wordpress-page configuration file as follows:

[free-electrons.com/fr]
user=bot
password=ERrdrsdGp8

[free-electrons.com]
user=bot
password=Hgdeedxx55

You can easily tune this script to support other web content engines. You first need to identify the login page (WordPress uses cookies to authenticate a session, instead of simple http authentication). Then, you will find the names of the input forms by reading the login page HTML code.

The second step is to open the page editing URL, and find out the name of the input form used for the page contents.

We don’t offer official support for our script, but I hope that this working code example will help you to make your own scripts, and to get you started faster. Python’s urllib2 and ClientForm really make this easy to do. What I especially like with ClientForm is its ability to modify the value of a given form, without having to read and fill any other input forms in the page, to keep their default content.

I successfully arrived in Bali yesterday in the evening. Flight was (as always) not quite enojoyable (Amsterdam -> Singapore more than 12 hours) – however it was bearable.
I was surprised actually by the service offered by KLM and Singapore Airlines in a positive way (food was surprisingly great: both offered fish – first time I got fish offered on an airplane as regular meal within economy class; Singapore Airlines additionally had real metal cutlery and a big portion of awesome ice-cream afterwards, for a flight of just two hours).

Met a German couple on the plane going to do professional diving somewhere in the south of Bali for three weeks. They offered me to visit them there and taking a deep look into the water with professional diving equipment. From what they told it has to be really incredible and if any way possible, I’m going to take that offer whenever I’ll be in this area.

On the final flight from Singapore to Bali I met an English guy, who is living on Bali with his Balinese wife and daugther for quite some time now and offered me to stay with them in their place for a couple of days which offer I thankfully took, as I had no clue anyway what to do after dropping out of the airplane (I in case of doubt I would have aimed a hostel near the airport mentioned in my guide).
These three people (actually four, there is an attendant living with them who is treated as part of the family) are really lovely, doing everything to make my stay enjoyable – well, I got in touch with the guy just two hours ago on the plane!

Their place – they call it “simple” – is wonderful; the whole kind-of 2nd floor is mine, within an own (bed)room, bathroom and an area with chairs and table which is opened to the inside of the whole area which in fact is a little garden – if I want to just “relax” they said…

Just take a look by yourself:

When writing this text it’s about 4 ‘o clock local time – bloody jetlag… _right now_ I just did see Bali at night (arrived at 9 ‘o clock); I’m really curious about how this all looks by day.

I took a walk in the area nearby at about 11PM and have to admit – I don’t really feel comfortable just walking around alone… Overall people offering you every kind of services in a very aggressive way, trying to rip off tourists.
However walking around in this area, tired and a little bit agitated because of the long flight, just wanna have everybody shut-up, might not have been the appropriate preconditions facing the situation in an open-minded way.

UPDATE: That was really just the first impression… the people are nice and kind, seriously. Yes, they want to sell their stuff quite often and quite everywhere, however you get used to it… just saying no, starting ignoring them or taking with them about all the world and his wife or whatever elese 

So much for now – as there are lot of things I’d like to see/visit very close by the place I’m currently staying, I think I’ll keep staying here for a couple of days – trying to figure out where to go and what to do next.

In recent days and weeks, I'm doing a bit more work on the gpl-violations.org project than during the last months and years. I wouldn't say that I'm happy about that, but well, somebody has to do it :/

Right now I'm facing what I'd consider the most outrageous case that I've been involved so far: A manufacturer of Linux-based embedded devices (no, I will not name the company) really has the guts to go in front of court and sue another company for modifying the firmware on those devices. More specifically, the only modifications to program code are on the GPL licensed parts of the software. None of the proprietary userspace programs are touched! None of the proprietary programs are ever distributed either.

If that manufacturer would succeed with such a lawsuit, it would create some very nasty precedent and jeopardize the freedom of users of Linux-based embedded devices. It would be a direct blow against projects that provide "homebrew" software for embedded devices, such as OpenWRT and many others.

I've seen many weird claims and legal strategies when it comes to companies trying to deprive developers of their freedom to modify and run modified versions of Free Software. But this is definitely so weird that I still feel like I'm in a bad dream. This can't be real. It feels to surreal.

It's a pity that I cannot speak up more about the specific company in question right now. I'm desperately looking forward to the point in time where I can speak up and speak out about what has been happening behind the scenes.

Today I created a tiny bit of OpenLayers code for the Eyesis display page. It is basically a demo what you can do by playing points of interest on a map. Displaying the panorama and a smaller map. Currently I did not add a panorama player yet. But since it is only a matter of changing [...]

I’ve just blogged on the latest stage of the Dili Village Telco roll out in Timor Leste. Fascinating what can be learnt from a real world deployment. I find the social and business issues just as fascinating as the technical problems us geeks usually focus on.

Links

1. More photos of the Dili Village Telco roll out.
2. The Dili Village Telco Wiki.
3. Other blog posts in the Dili Village Telco series.

Related posts:

1. Village Telco at linux.conf.au (LCA) 2010 I have just returned from LCA 2010 where I presented...
2. Factors Affecting Village Telco Performance This post discusses the factors that affect the quality of...
3. A2Billing with Village Telco We are pleased to announce the release of A2Billing 1.4.4...

Related posts brought to you by Yet Another Related Posts Plugin.

Verilog::Language 3.302 was released shortly after 3.300 to fix a few bugs, namely

• Increase define recursions before error.  [Paul Liu]
• Fix documentation on verilog_text and link, bug278. [Mike Z]
• Use Digest::SHA instead of SHA1, bug189.  [Ahmed El-Mahmoudy]
• Fix false test failure if Math::BigInt not installed.

It will soon be among your updates. Special credits go to Veripool.

With some spare bugs here and there due the first time nerves, last August 28th , we did the Arduino initiation workshop, the first of the workshop series we plant to do in the Tuxbrain's Den. There where 10 participants and due there is only place for 11 we consider it as tremendous success :)
Below are some pictures of the most fun moment of the workshop, the Arduino "Death Roulette", a simple game to demonstrate the communication between Arduino boards and also the speed reaction of the participants, we have the record in number of players in 5 gamers :)

read more

chumby is now offering a “hacker” board, which is the guts of the chumby One, but modified to be more hacker-friendly: it comes with three high speed USB host ports, uses the power connector from the Sony PSP (instead of the weird, hard to find connector on the chumby One) and incorporates a variety of headers, such as Arduino-style shield headers and a 44-pin breakout header that gives you access to a lot of digital I/O and some analog inputs. There’s even a four-directional switch on board and some LEDs so you can do quick hacks that don’t require a video display for user feedback. Speaking of the display, while this board doesn’t come standard with an LCD, it does provide composite video output via a 4-wire 1/8″ jack so you can, by using an iPod video cable, plug the chumby hacker board into any TV that supports a composite video input.

(Photo by Adafruit)

The hacker board is currently being sold through Adafruit and also soon through Sparkfun as part of a limited-run beta program. The board is priced at around $89. The goal of the beta program is to collect feedback from users who purchase the board to fine-tune the design and to figure out what I/Os and accessories make sense to bundle with the board. Like the Arduino, we don’t integrate a lot of features onto the mainboard itself (keeps base cost low). Instead, we’d like to make sure that adequate I/O resources exist for developers to hack in the peripheral module they require to complete their project — or for more enterprising developers to build their own flavor of peripheral board and sell their own accessory.

There’s a few resources available to get people started on using the boards: a forum for general support and questions, and a wiki containing links to datasheets, schematics, and other more permanent documentation that people will find useful. Adafruit also has available a snazzy hackerboard page with tons of info, well-documented tutorials, and nice photos to boot.

One other point of note about the hacker board is that you can install a native gcc toolchain on it, so you don’t need to configure/install a cross-compiler on your host PC to develop for it. Heck, it’s got a 454 MHz CPU and plenty of disk space, so why not? Adafruit has a tutorial on how to install the compiler using a downloadable self-extracting script and a USB dongle. I’ve also heard rumors that an OpenEmbedded port is coming to the board soon, so stay tuned.

If you do end up purchasing a board and participating in the beta, please do contribute to the fora and wikis with your feedback. As always, happy hacking!

The ware for August 2010 is shown below. Click on the photo for a much larger version.

Taking this ware apart was particularly enlightening because I had thought about building one of these myself quite often, and now that I see the insides I realize I had over-complicated my schemes.

The July 2010 ware is the Silicon Cow at Asus (titled with the imaginative name of “2357″, as seen on the name plaque below). Congrats to Marc for guessing it correctly! email me to claim your prize.

I snapped these photos a couple months back when I happened to find myself at Asus HQ in Taipei. The silicon cow is across the lobby from the more famous “Mona Lisa” sculpture that was mentioned in the guesses.

Con algun bug que otro por los nervios del estreno, el pasado Sábado 28 de Agosto, se realizo el taller de iniciación de Arduino, el primero de la serie de Talleres que del Tuxbrain Den, 10 asistentes, dado que solo hay capacidad para 11 lo consideramos un llenazo absoluto :)
A continuación algunas fotos de momento estelar de la mañana, el Arduino "Death Roulette" un sencillo juego para demostrar la comunicación por puerto serie entre placas Arduino, y de paso los reflejos de los participantes, el record a batir en próximos talleres de iniciación es de 5 jugadores :)

read more

Long time no news…

some things happened which weren’t worth a particular post (or I was just too lazy), so I’ll try to summarize of a few things which happen(ed):

== tech stuff

OpenWrt is still my focus – the qt4 package now got libX11 support (besides DirectFB / linuxfb, both accessed by the QWS-part) – thanks a lot to Michael Büsch at this point!

I’m also very interested in the new features of qt4.7 – especially the declarative UI part of qt4.7 called QML – an approach of designing UIs in a declarative way, means, from the UI’s point of view (more in the mentioned links above).

I’m curious about how/whether it can/will be used/accepted by “native” designers to write fully functional GUI applications.

It’s approach is looking quite promising to me – the language style as well as the implementation – really curious about how it’ll do on embedded devices without graphics acceleration. After some talks to qt developers GL support is not required; a number of animations, effects and transitions were optimized for software processing and should be even smoother than rendered via GL.

First usecase is going to be a picture frame, which has the same SoC built in (Ingenic JZ4740) as the NanoNote and therewith is pretty well supported.

The picture-frame is an ID800WT manufactured by Sungale.

Before somebody is going to think, whether I want to promote/support/recommend this brand/product:

From the board layout’s point of view it is the worst product sold in Germany I’ve ever seen! And it’s too expensive! And the company violates the GPL!

Take a look at the board by yourself:

The USB Wifi-stick got hot-glued onto the board, it seems they even unsoldered the USB-socket manually (because it looks really charred all around) and connected it with some random wires to a SMD-chip which in fact is an USB-hub. Around there’s hot-glue all around, partially charred, partially way too much. This is really the worst in Germany sold product ever!

However it serves the purpose – has supported wifi (atheros), an 800×600-display, a touchscreen, USB-host, etc.

After my holidays I’ll try to evaluate and play around with qt4.7-features on that device on top of OpenWrt.

== trips

After almost one week spent in Croatia, Split, participating at the “nothing will happen” conference – which was really amazing and organized by very nice people – I’m going to travel to Bali for one month, leaving in two days.

Actually I wanted to go to Burma (Myanmar), however I mixed them up and booked my flight to Bali, Indonesia… anyway – more beach and sea this time…

This is going to be my third trip to Asia and I’m really looking forward to it – this time for holiday, backpacking without any fixed plans.

Actually I also didn’t want to take a computer with me – still I bought an EeePC 1015. Resolution is disappointing, however price, weight, battery life (about 8 fucking hours!) and site serve the purpose of just having a terminal perfectly.

See you there

I'm subscribed to a considerable number of RSS feeds, and so far I actually used to read them all on my Nokia N810, which is more or less permanently located at the bedside table

Now I wanted to import all the subscriptions into an Android RSS feed reader on the Galaxy S. Unfortunately the feed reader that I found most useable doesn't have OPML import. However, looking at its sqlite3 database for feed subscriptions, it was pretty easy to come up with a small perl script to generate "INSERT" statements for all the feeds from the N810 OPML file. In case anyone is interested, the script is available from here.

If you have any suggestions on a good Android RSS reader that can manage large number of subscriptions and put them into a tree/hierarchy of groups, feel free to let me know.

Michael writes:

i’m happy to announce that we are now able to program the onboard flash without the Xilinx tools (and JTAG pod). Please have a look at [1] and its README.

ATM it works with my homemade FT2232C JTAG pod but should work with every other supported JTAG cable (by UrJTAG), too. Esp. the FT2232H based one by Yanjun Luo.

The time for flashing the bitstream is around 25s (without verify).

[1] http://git.serverraum.org/?p=mw/fjmem-mm1.git;a=summary

So, this means we have to use one less proprietary and bloated program. Thanks!

According to several sources such as indianevm.com, Hari Prasad was being arrested. He is part of a team of IT security researchers that gathered evidence to demonstrate how incredibly weak the security of India's voting machines is. For more details, read the indianevm.com article linked above, and the various quotes/links in it.

This is very upsetting. They should jail those who have authorized the deployment of such an insecure system in the first place. Those are the people responsible - not some researchers who go out of their way to uncover the technical problems to warn the general public about the inherent risks of this technology.

I sincerely hope that the authorities will understand the grave mistake they're doing here. Don't shoot the messenger. It's not his fault that engineer, engineering management and/or regulatory government authorities have permitted such a system in the first place.

It’s the first time, I’m writing about a freeware. But even though it is not opensource, this freeware does have interesting features which Toped developers are working on for Toped.

Glade is capable of reading GDS2, OASIS, LEF and DEF. Some of its features are;

• Fast, hardware accelerated OpenGL graphics;
• Import/Export GDS2, OASIS, DXF, LEF, DEF and Verilog;
• Import Cadence display.drf and techfiles directly;
• Edit and display hierarchy from 0 to an unlimited number of levels;
• Create instance, label, rectangle, path, polygon, via, pin commands with interactive display during enter;
• Layer select window for setting layer visibility/selectability, current layer, choosing layer colour and transparency, fill pattern, line style/width and setting layer names;
• …and many others!

Since Glade being just a freeware and not opensource, it will not be available under the Free Electronic Lab(FEL) umbrella, the user is ought to download it from the developer’s website and execute the following commands manually.

$ export GLADE_HOME=`pwd`
$ export PATH="$PATH:$GLADE_HOME/bin"
$ export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$GLADE_HOME/lib"

Since Glade was not compiled under a FEL compatible repository, it crashes frequently. In either case, I would also recommend FEL users to use toped 

# yum install toped

or magic

# yum install magic

as they are tested and deeply rooted into FEL’s proposed design flows.

For many years I'm on a more or less consistent hunt for finding a reasonably open and free mobile phone. This started in 2004 with OpenEZX, has continued with Openmoko, project gnufiish and has resulted in a bit of peeking and poking in the Palm Pre. However, none of those projects ever had the success I was hoping for:

• OpenEZX was never really finished, and only for the 1st generation phones (A780) by the time they were long end of life
• OpenMoko Neo1973 and FreeRunner were a great project, and they are still the most open+free mobile phones that ever existed. However, they're GPRS only and the hardware is even more outdated now then it was when we created it.
• gnufiish was an attempt of running software from the Openmoko days (such as freesmartphone.org) on some E-TEN glofiish phones. However, we never could make the SPI-based modem communication work from our re-engineered Linux driver :(
• Palm Pre is an interesting device, in that Palm provides easy root access, does not attempt to lock the device down with cryptographic signatures and provides full recovery flashing tools by means of WebOS Doctor. But once again, the proprietary communication protocol with the 3G Modem was the big blocker item for using real custom software and not the WebOS stuff they ship.

So I've constantly been on the watch for new devices that are coming out. Most of the phones you can buy in recent years are either running proprietary software like Windows Mobile, Symbian, Apples iPhone-OSX - or they run Android but then use some integrated Qualcomm Smartphone-on-a-chip product. The problem with the latter (from a Free Software point of view) is that Qualcomm is very secretive about their products, does not provide any kind of public documentation, and the ever-increasing integration between application processor and baseband processor makes it more difficult to run custom software on them.

The Samsung Galaxy S (GT-I9000) seemed like a good candidate to me, for several reasons:

• Samsung does not use cryptographic signature techniques and gaining root as well as flashing the AP software is relatively easy
• The phone is based on a traditional separate application processor (AP) and baseband processor (BP) design. The AP is a Samsung S5PC110, the BP is some Qualcomm MSM6xxx.
• High-end hardware, with the S5PC110 running at 1GHz and 512MB RAM
• Samsung provides excellent "GPL source code offers" containing the Linux kernel used in their firmware - including detailed instructions in how to build it. Also, many of the drivers are included under GPL, such as drivers for all the integrated peripherals of the SoC, some custom components like the USB multiplexor ASIC, etc. as well as the driver for the dual-ported RAM between the AP and BP for the 3G Modem communication
• The Android RIL shipped by Samsung contains lots of debugging/decoding/dumping code that can make reverse engineering the AP/BP protocol.

So right now I'm in the exploration phase, making myself familiar with the bootloader, the flashing process, the userspace ABI of the custom (GPL licensed) kernel drivers, etc. It's a fairly pleasant experience so far, and I now have a debootstrap'ed Debian lenny on an additional ext2 partition on the SD card. This provides me with an actually useful userland I can chroot() into, such as lsof, strace, ltrace, tcpdump, etc. to do some more exploration of the phone.

The only real ugliness on the software side so far is the use of proprietary Samsung filesystems (RFS/TFS4). The only reason those filesystems existed, as far as I can tell, was to run legacy filesystems like FAT on top of raw NAND or OneNAND flash. This is mainly necessary if you want to export e.g. a FAT partition via USB Mass Storage to a Windows PC. However, the GT-I9000 doesn't have any OneNAND, but only an internal moviNAND (basically a SD-Card in a BGA package that you can solder on the board). MMC/SD cards already include the wear leveling algorithm, so there is absolutely no point (from what I can tell) in running the RFS/TFS4 stack.

In fact, in several forums people are complaining about the slow I/O performance of the Galaxy S, and they have a much better performance when using ext2/ext3 directly on that moviNAND device.

Recently I have been working on Packedobjects which included redesigning the API and replacing a lot of C code in Scheme. I will try and formalize the whole encoding process which I have called Integer Encoding Rules. I also began work on a manual which includes some examples. My aim is to support the tool on OpenWrt which also involves maintaining the GNU Guile build.

I built and tested the software on my Ben Nanonote. The ipk is available: http://zedstar.org/ipk/packedobjects_0.4_xburst.ipk

After improving the documentation I intend to use the tool in a networking course at work. I think it is important for students to gain some experience of designing and structuring binary network protocols.  We will be getting a bunch of Nanonotes to compliment the Openmoko Freerunners we have. This will provide some nice hands on experience packing some data and communicating it across different kinds of hardware.

Long term, I am interested in designing some funky SlowFi protocols on copyleft hardware.

More or less a bit surprising to me, I got again involved in RFID research, on which I hadn't really done much ever since my involvement in the OpenPCD and OpenPICC projects some five-to-four years ago.

It's a lot of fun, and I didn't seem to forget much. What really bothers me a bit is that the OpenPCD / librfid / OpenPCD integration never really was completed, and that libnfc doesn't work with OpenPCD. Let's hope I'll somehow find some time to change this. It just feels wrong that OpenPCD was the first hardware project created to encourage (security) research into RFID, and now all the current tools only run on the Proxmark or on proprietary readers...

For the French speaking readers, we are looking for a graduate engineer to open a new office in Toulouse, France.

All the details are available on our French blog.

This job is not only open to French applicants. Everyone ready to relocate in Toulouse is welcome, but we need someone with a good command of the French language. This will be needed to serve local customers.

这篇来自美国犹他大学的助理教授Matt Might，原址在这里。汉化：阮一峰

译者注解：

美国犹他大学的助理教授Matt Might，用这组图解释，博士学位到底是什么意思。他说，每年都有新生的入学教育，但是有些观点语言说不清楚，不如画图。

我觉得，这组图真的很好懂，而且一点没错，博士就应该是图中的意思。老子说”大道至简”，可是真的要很简单地表达出来，却是非常难的一件事。

While working on voice support for OsmocomBB I had to look in detail at how the audio path in the TI Calypso chipset works. Basically it is not very complicated:

The Uplink path consists of an amplifier for the microphone and an ADC, the digital samples are transferred to the DSP which takes care about the encoding according to the selected GSM voice codec.

In the Downlink path the decoded samples from the DSP are sent to a DAC which is followed by an amplifier and the loudspeaker.

Some additional details are that you can select the analog input/output (e.g. if the headset connector is used). Parameters which can be adjusted are the gain of the amplifiers and the sidetone level (a feedback between the uplink and the downlink audio path).

The digital samples for the DSP use a sample rate of 8 kHz. A not so obvious feature is that there are two FIR (Finite Impulse Response) digital filters with 31 taps in the DSP, one for the uplink, the other for the downlink. Those filters can be used to improve the voice quality or reduce ambient noise. So far those filters are set to not modify the signal (the filter coefficient of the first tap is 1, all others are 0). The format of the filter coefficients is signed fixed-point Q2.14, so for example 0x4000 means 1.

Tonight I was thinking about what the possibilities are for the driver to actually see what he is shooting and at the same time facilitate appliances such as traveling salesman routing for the fastest shooting experience. I have some other ideas for the ‘main’ screen such as a 2D map with trails where the car [...]

Video Jam Session sur plate-forme Milkymist One!
CE QUE C’EST

• Une introduction au système de synthèse de visuels sur [http://www.milkymist.org Milkymist] (venez à l’heure pour ne pas manquer la présentation)
• L’écriture de vos propre patches
• L’occasion de jeter un oeil aux premiers prototypes…
• …et de les utiliser pour tester vos propre patches!
• L’occasion d’une soirée sympa, même si vous venez en “spectateur”

CE QUE CE N’EST PAS

• Un workshop FPGA
• Un workshop de développement de logiciel embarqué
• Un workshop nécessitant des compétences techniques avancées
• Une démonstration exhaustive de toutes les possibilités de la plate-forme, il manque encore énormément de choses qui prendront des mois à développer.
• Une représentation de la facilité d’utilisation finale de la plate-forme; l’interface graphique intégrée n’est pas encore développée.

AMENEZ

• Pour interagir avec les visuels et/ou pour l’ambiance de la salle:
  • Vos tables DMX, qui pourront servir à interagir avec votre patch
  • Vos spots (PAR à LED ou non) DMX qui pourront etre contrôlés par le patch. Plus il y en aura, plus ça mettra une ambiance psyché dans la salle, façon trip glasses sans les lunettes.
  • Un gradateur DMX si vous avez des vieux PARs à incandescence.
  • Vos claviers et contrôleurs MIDI, qui pourront servir à interagir avec votre patch
  • Câbles DMX (XLR 3 broches) et MIDI
• Vos CDs, vinyls, … ou toute autre source sonore, vous pouvez aussi venir mixer en live Ca réagit bien à la techno minimale avec des bonnes basses.

INFOS PRATIQUES
Jeudi 19 août à partir de 19:45 au /tmp/lab
Inscriptions sur la page du wiki /tmp/lab.
Comment venir: les infos sont ici.

• Support for DMX. Reflash your board now to play with RGB LED fixtures and DMX controllers DMX channels 1-4 are mapped as dmx1-4 for the output port and idmx1-4 for the input port in the patches. See the two example patches using DMX. And no, even though the FPGA core supports all the 512 DMX channels, there is no way to use other channels in the patches without modifying the software which is just “proof of concept” now.
• Support for memory card (in 4-bit SD mode, not SPI)
• Support for Synplify synthesis
• Fixed a bug that prevented access to the upper 64M of SDRAM. The whole 128M are addressable now.
• Rewritten USB PHY
• All AVR Classic instructions in Navré (ie full C toolchain support), except conditional jumps on I/O registers (won’t be needed)
• Navré bugfixes

Despite some improvements (which were enough to validate the PCB design), USB still does not work completely and the road is still long before we have full OHCI support. This will be part of the next release.

As Dieter Spaar has pointed out in a mailing list post on the OsmocomBB developer list, he has managed to get a first alpha version of TCH (Traffic Channel) code released, supporting the FR and EFR GSM codecs.

What this means in human readable language: He can actually make voice calls from a mobile phone that runs the Free Software OsmocomBB GSM stack on its baseband processor. This is a major milestone in the history of our project.

While Dieter has been working on the Layer1 TCH support and the setup of the voiceband path in the analog baseband chip (audio ADC/DAC), Andreas Eversberg has been quietly working on getting call control of Layer3 into a state where it can do all the signalling required for mobile-originated and mobile-terminated call.

Combining both of their work together, they have been able to make a 20 minute long voice call from a baseband processor running a Free Software GSM stack. For all we know, it is the first time anything remotely like this has been done using community-developed Free Software. Five years ago I would have thought it's impossible to pull this off with a small team of volunteers. I'm very happy to see that I was wrong, and we actually could do it. With less than half a dozen of developers, in less than nine months of unpaid, spare-time work.

Sure, the next weeks and months will be spent on bringing the code from alpha level to something more stable, fixing known issues and known bugs, etc. But I'm confident the biggest part of the work on the OsmocomBB stack is behind us. Big thanks to the developer team driving this project forward.

In recent months, a number of alleged GPL-violation reports regarding products (tablet computers, mini netbooks and the like) using the Wondermedia WM850x line of ARM SoCs. People have been contacting me, as I was working as VIA Open Source Liaison, and there is the general belief that VIA and Wondermedia Technology (WMT) are one company.

I had investigated this issue even before there were any reports, and I'd like to publicly state that:

• Wondermedia is a separate company from VIA, with independent management, making their own business decisions. The 850x SoC development was started inside VIA, but is no longer part of VIA for a long time.
• Any references to VIA in the source code or old data sheets date from that time before the SoC business became part of Wondermedia
• I have had assurances from Wondermedia, even before there were any allegations, that similar to VIA they explicitly notify their customers about the GPL and always provide their SDK / BSP as full corresponding source code.
• Effectively, this means that GPLv2 Section "3a" is used. WMT has provided the Linux and u-boot source code to its customers, and thus has no obligation under GPLv2 Section "3b" to provide it to anybody else (any 3rd party)
• So, if you buy a product including a WMT SoC and u-boot/Linux, like always, GPL compliance of what has been shipped to you has to be assured by the manufacturer of the product, not the semiconductor maker

Notwithstanding all of the above, Wondermedia was willing to provide the Linux kernel and u-boot source code of their SDK to me, so I can share it with the community. As indicated, they're not legally required to do this and I'm happy they do it anyway to show their good intentions.

You can download the released source code from the gpl-devices.org ftp-server, more specifically here are the latest Linux kernel (modified 2.6.29 android derivative) and u-boot source code archives.

This software is provided without any kind of support. If you see some GPL related legal problems (i.e. you believe it is incomplete), don't hesitate to contact me. To the best of my knowledge WMT (basically a small hardware start-up with small software development team) has no resources to actively push any of this mainline.

The Forth programming language has been ported to the NanoNote with the gforth package. Forth is quite unlike anything that I’ve ever seen. Apparently it was developed especially for small embedded systems. A popular introduction and tutorial on Forth is Starting Forth by Leo Brodie.

Linux 内核将在 2.6.36 版本中支持 国产君正 XBurst JZ4740 CPU。

经过一年的努力，Lars 最终将 JZ4740 的代码提交到 Linux 的主干分支，第一个被支持的 JZ4740 设备 Ben NanoNote 也一起提交到了主干分支。

国内一些用 君正 CPU 的公司也就不再需要向老的内核上打补丁来支持JZ4740，而且也能享受到更多新内核的功能。要感谢Qi Hardware 项目对同步的重视，和主干同步给代码的质量带来的好处一言难尽。被官方支持是对一个软件项目的肯定，对于投身自由软件的工程师来说是最好的奖励。一个项目的代码如果不再修改了。证明这个软件项目停止了（要消亡了。。。）。而不是证明这些软件的代码已经达到一定水平不需要修改了。国内很多自由软件贡献者都是在外企，这也证明了国内软件企业不明白和主干同步的重要性，这是一种共享，一种融合，付出就有回报，而在付出的同时我们得到的是更多的对项目意见，而且这些意见都 来自从事软件事业十几年或者几十年的工程师。

Links:

http://www.openmobilefree.net/?p=644

http://en.qi-hardware.com/w/images/2/2f/Bonding_wire10.jpg

http://en.qi-hardware.com/w/images/c/cc/Ben_on_hand.jpg

http://projects.qi-hardware.com/index.php/p/qi-kernel/source/tree/jz-2.6.35/

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e6b78c4f224925c71cce57033b1e6e30dd56add7

I’ve continued working on a simple system monitor application in Python and Pygame by rewriting the code in a more object-oriented style and adding a CPU and Memory monitor. Eventually I’d like to add disk space monitors, and to write a simple application launcher.

#!/usr/bin/python</code>

<code># A simple battery monitor application powered
# Python and Pygame.

#########################################################
# Press CONTROL-q to exit

from pygame import *
from copy import deepcopy
# initialize
init()

########################################################
# colours
white = 255,255,255
black = 0,0,0
red = 255,0,0
green = 0,255,0
yellow = 255,255,0
backcolour = black
solid = 0

########################################################
# background screen
def backgroundScreen(colour):
'''Setup background screen
In: colourTUPLE.
Return: screenOBJ'''
screen = display.set_mode((320,240))
backgrnd = colour
screen.fill(backgrnd)
display.flip()
return screen

# Warning colour
def getWarningColour(powerPercent):
'''Set a colour for the power block and percent text'''
if powerPercent &gt;= 50:
warningColour = green
elif powerPercent &gt;= 25:
warningColour = yellow
else:
warningColour = red
return warningColour

# get file
def getFile(path):
'''Returns a string'''
targetFile = open(path)
contents = targetFile.read()
targetFile.close()
return contents

# Check for keypress
# Exit on control-q
def exitKey():
for e in event.get():
if e.type == KEYDOWN \
and e.key == K_q \
and key.get_mods() &amp; KMOD_CTRL:
return True

######################################################
class Point(object):
'''Point object'''

def __init__(self, x, y=0):
'''Create a point from x,y or (x,y). '''
if type(x) is tuple and y == 0:
self.x = x[0]
self.y = x[1]
elif type(x) is int and type(y) is int:
self.x = x
self.y = y
else:
message = "Point type error: %s, %s" % (x, y)
raise RuntimeError(message)

def __str__(self):
return "(%s, %s)" % (self.x, self.y)

def __add__(self, term):
'''Term can be a Point or a tuple.
Returns a Point.'''
result = Point(0, 0)
if type(term) is tuple and len(term) == 2:
result.x = self.x + term[0]
result.y = self.y + term[1]
return result
elif isinstance(term, Point):
result.x = self.x + term.x
result.y = self.y + term.y
return result
else:
message = "Point type error: %s" % (term)
raise RuntimeError(message)
def tuple(self):
return (self.x, self.y)

######################################
class Txt(object):

def __init__(self, message,
size = 16, fontName = None):

# self.message is used by Txt.write()
self.message = message
# font object
self.fontObj = font.Font(fontName, size)

def write(self, position, forecolour = white):
'''Render font object'''
if isinstance(position, Point):
position = position.tuple()
antialias = True
self.textObj = self.fontObj.render(self.message,
antialias,
forecolour,
backcolour)
# Create a rectangle
self.textRect = self.textObj.get_rect()
self.textRect.topleft = position
draw.rect(screen, backcolour, self.textRect, solid)
# Blit the text
screen.blit(self.textObj, self.textRect)
display.update(self.textRect)

#######################################################
class Header(object):

def __init__(self, text, origin):
self.text=Txt(text, 16)
self.origin = origin

def write(self):
self.text.write(self.origin)
#######################################################
class Monitor(object):

def __init__(self, name, origin):
self.origin = origin
# header text
self.header = Header(name, (origin + (0, 5)))

def draw(self):
self.header.write()

#######################################################
class batteryMonitor(object):
'''Header text, terminal, body'''
def __init__(self, origin):
'''origin is Point object '''

self.origin = origin
# header text
self.header = Header("Battery", (origin + (0, 5)))

# percent text
self.percentOrigin = self.origin + (55, 5)

# battery: body + terminal
batteryOrigin = self.origin + (100, 0)
batteryH = 22
batteryW = 12
self.lineWidth = 1

# battery terminal
terminalOrigin = batteryOrigin + (batteryW/4, 0)
terminalW = batteryW / 2
terminalH = int(round(batteryH * .1))
self.terminal = Rect(terminalOrigin.x,
terminalOrigin.y,
terminalW,
terminalH)

# battery body
bodyOrigin = batteryOrigin + (0, terminalH)
bodyW = batteryW
bodyH = batteryH - terminalH
self.body = Rect(bodyOrigin.x, bodyOrigin.y, bodyW, bodyH)

# list of power readings to average
self.powerReadings = []

def draw(self):
'''header, terminal, body'''

self.header.write()

# terminal
draw.rect(screen,
white,
self.terminal,
solid)

# body
draw.rect(screen,
white,
self.body,
self.lineWidth)

# update screen
display.flip()

def getPower(self):
'''Check powerlevel and return average of last 5 readings
reading is a percentage'''

# Check the battery power level
path = "/sys/class/power_supply/battery/capacity"
powerPercent = int(getFile(path))
# powerPercent = 75
# add to list of past readings
self.powerReadings.append(powerPercent)
# limit the list to 3 readings by deleting first item
if len(self.powerReadings) &gt; 3:
self.powerReadings = self.powerReadings[1:]
# average the list of readings
average = float(sum(self.powerReadings)) / len(self.powerReadings)
# round the average to the nearest 5
powerPercent = int(round(average *2, -1) /2)
return powerPercent

def updateBlock(self, powerPercent):
'''Build power block and display with percentage'''

# Set a colour for the power block and percent text
warningColour = getWarningColour(powerPercent)
# Make a block to represent the power level
# Copy from body Rect
self.power = deepcopy(self.body)
# adjust the height of the power block to reflect the power level
self.power.h = int(round(self.power.h * powerPercent / 100))
# move the power block to the bottom of the battery
self.power.bottom = self.body.bottom - self.lineWidth
# blank the body outline
draw.rect(screen, backcolour, self.body, solid)
# draw solid power block
draw.rect(screen, warningColour, self.power, solid)
# redraw the body outline over the power block
draw.rect(screen, white, self.body, self.lineWidth)
display.update([self.body, self.power])

# Print the power percent
label = "%2s %%" % (powerPercent)
percent = Txt(label, 22)
percent.write(
self.percentOrigin,
forecolour = warningColour)

###############################################################
class CPUMonitor(object):
'''Header text, body rectangle'''

def __init__(self, origin):
'''origin is Point object '''
self.origin = origin

# header text
self.header = Header("CPU", (self.origin + (0, 5)))

# percent text
self.percentOrigin = self.origin + (55, 5)
self.percentBlank = Rect(self.percentOrigin.x, self.percentOrigin.y, 40, 20)

# cpu monitor body rectangle
bodyOrigin = self.origin + (100, 0)
bodyH = 20
bodyW = 12
self.body = Rect(bodyOrigin.x, bodyOrigin.y, bodyW, bodyH)
self.lineWidth = 1

def draw(self):
'''header, body rectangle'''

# header
self.header.write()

# body
draw.rect(screen,
white,
self.body,
self.lineWidth)
# update screen
display.flip()

def getLevel(self):
'''Check cpu level.
reading is a percentage'''

cpuFile = getFile("/proc/loadavg")
# extract first item and convert to percentage
listFromFile = cpuFile.split()
cpuPercent = int(float(listFromFile[0]) * 100)
return cpuPercent

def updateBlock(self, cpuPercent):
'''Build cpu block and display with percentage'''

# Set a colour for the power block and percent text
warningColour = green
# Make a block to represent the cpu level
# Copy from body Rect
self.block = deepcopy(self.body)
# adjust the height of the cpu block to reflect the cpu percent
self.block.h = int(round(self.block.h * cpuPercent / 100))
# move the cpu block to the bottom of the body
self.block.bottom = self.body.bottom - self.lineWidth
# blank the body outline
draw.rect(screen, backcolour, self.body, solid)
# draw solid cpu block
draw.rect(screen, warningColour, self.block, solid)
# redraw the body outline over the cpu block
draw.rect(screen, white, self.body, self.lineWidth)
display.update([self.body, self.block, self.percentBlank])

# Print the cpu percent
label = "%2s %%" % (cpuPercent)
percent = Txt(label, 22)
# blank out the old percent text
draw.rect(screen, backcolour, self.percentBlank, solid)
# write percentage
percent.write(
self.percentOrigin,
forecolour = warningColour)

###############################################################
class MemMonitor(object):
'''Header text, body rectangle'''

def __init__(self, origin):
'''origin is Point object '''
self.origin = origin

# header text
self.header = Header("Mem", (self.origin + (0, 5)))

# percent text
self.percentOrigin = self.origin + (55, 5)
self.percentBlank = Rect(self.percentOrigin.x, self.percentOrigin.y, 40, 20)

# total and free text
self.freeOrigin = self.origin + (100, 20)
self.freeBlank = Rect(self.freeOrigin.x, self.freeOrigin.y, 100, 20)

# monitor body rectangle
bodyOrigin = self.origin + (100, 0)
bodyH = 10
bodyW = 100
self.body = Rect(bodyOrigin.x, bodyOrigin.y, bodyW, bodyH)
self.lineWidth = 1

def draw(self):
'''header, body rectangle'''

# header
self.header.write()

# body
draw.rect(screen,
white,
self.body,
self.lineWidth)
# update screen
display.flip()

def getLevel(self):
'''Check mem level.
reading is a percentage'''

memFile = getFile("/proc/meminfo")
# Convert to list and extract total and free
listFromFile = memFile.split()
memTotal = int(listFromFile[1])
memFree = int(listFromFile[4])
memPercent = int(float(memFree) / memTotal * 100)
return memPercent

def updateBlock(self, memPercent):
'''Build mem block and display with percentage'''

# Set a colour for the power block and percent text
warningColour = getWarningColour(memPercent)
# Make a block to represent the mem level
# Copy from body Rect
self.block = deepcopy(self.body)
# adjust the length of the cpu block to reflect the mem percent
self.block.w = int(round(self.block.w * memPercent / 100))
# blank the body outline
draw.rect(screen, backcolour, self.body, solid)
# draw solid mem block
draw.rect(screen, warningColour, self.block, solid)
# redraw the body outline over the mem block
draw.rect(screen, white, self.body, self.lineWidth)
display.update([self.body, self.block])

# Print the mem percent
label = "%2s %%" % (memPercent)
percent = Txt(label, 22)
# blank out the old percent text
draw.rect(screen, backcolour, self.percentBlank, solid)
# write percentage
percent.write(
self.percentOrigin,
forecolour = warningColour)

###############################################################

# Hide the mouse pointer
mouse.set_visible(0)

# setup screen
screen = backgroundScreen(backcolour)

###############################################################
class TestMonitor(Monitor):

def __init__(self, name, position):
Monitor.__init__(self,name, position)
###############################################################

t = TestMonitor("header", Point(10,200) )
# t.draw()
###############################################################

# header, terminal, battery body
batteryMonitorOrigin = Point(10, 10)
battery = batteryMonitor( batteryMonitorOrigin )
battery.draw()

# header, cpu monitor body
cpuMonitorOrigin = Point(10, 50)
cpu = CPUMonitor( cpuMonitorOrigin )
cpu.draw()

# mem monitor
memMonitorOrigin = Point(10,100)
mem = MemMonitor( memMonitorOrigin )
mem.draw()

# The main loop
oldLevel = 100
oldPower = 0
oldMem = 0
done = False
while not done:

cpuPercent = cpu.getLevel()

if cpuPercent != oldLevel:
cpu.updateBlock(cpuPercent)
oldLevel = cpuPercent

powerPercent = battery.getPower()

if powerPercent != oldPower:
battery.updateBlock(powerPercent)
oldPower = powerPercent

memPercent = mem.getLevel()

if memPercent != oldMem:
mem.updateBlock(memPercent)
oldPower = memPercent

done = exitKey()
time.wait(250)

I bought several components of a Nokia WCDMA UltraSite BTS. However the unit is not yet complete. What is missing:

• IFU - Interface Unit
• WTR - Transmitter and Receiver
• WPA - Power Amplifier
• Rack/Cabinet for all the components

If anyone knows where to get those parts for a reasonable price, please let me know. The final goal is to have support for this unit and similar WCDMA basestations from other manufactures in OpenBSC.

I am aware that UMTS Femtocells are cheaper and they do WCDMA too. Its surely possible to support them in OpenBSC, its mainly a matter of free time and/or who will start with it. But Femtocells have a different architecture than "real" BTS/Node B units, a Femtocell usually combines the RNC (Radio Network Controller) with the basestation and uses a different protocol for controlling the unit. So it still makes sense to have a "real" WCDMA BTS/Node B for OpenBSC integration.

On the qi-hardware list a post of non electronic hack of the Ben Nanonote from Werner Almesberger has improve a lot the stability of the system , see picture and video of what we are talking about :)

read more

I've started to write upe some information on modern smartphone hardware architecture. It will be in a similar style to what I previously wrote on feature phones and gsm modem hardware, but with a specific focus on smpartphones, their multiple processors, memory sharing, AP/BP interface, audio architecture, etc.

I should have done this a long time ago. In fact, I think I should write more documents like that on various technical subjects. If you want to learn about low-level aspects of modern telephones, there is way too little published information out there.

Tomorrow early morning I'll be on my way to Tapei/Taiwan. The main reason for this trip is the invitation to speak at COSCUP 2010.

I'm really looking forward to getting back Taipei, which has become something like my second home during the years I was working on Openmoko. I've really gotten used to life in this super-urban Asian metropolis... to the extent that I'm almost a bit homesick while I'm actually at home in Berlin/Germany.

The V1.3 (production) Mesh Potatoes has an etched (PCB) antennas. This post talks about how we tested this antenna and verified the V1.3 design.

Testing at Atcom in June

In June I was visiting Atcom in Shenzhen, China. The first 1.3′s were calibrated and ready for testing so we headed out to a nearby open area with some MP01 V1.2 and V1.3 prototypes.

We taped a V1.2 and a V1.3 back to back on a length of PVC pipe to compare results at roughly the same height. Lead-acid batteries were used for portable power.

We did some A-B comparison tests, e.g. a V1.3 to V1.3 call then a V1.3 to V1.2 call and V1.2 to V1.2 call. As well as making calls we measured the rx signal strength using the node_tune.sh script. We wandered about and tested at various ranges.

Edwin and Alen seemed happy that the two antennas (V1.2 omni and V1.3 printed antenna) worked about the same. This is consistent with the tests Jeff and I performed last December.

The node_tune.sh script reports rx signal strengths to a laptop. It’s hard to be precise as the levels bounce around by several dB. Also we must remember the signal strength indicator on a AR2317 SoC is not a calibrated instrument, it’s just a rough estimate. Typical result might be -70 +/- 3 dBm over 10 signal strength samples. As near as we could tell, the results were about the same for the V1.2 and V1.3.

Given it was an inner city site there were other networks on the same channel so ping times bounced about a bit. Despite that the guys managed to make OK phone calls up to about 350m, with the V1.3 only a few metres above the ground. At that height 350m between omni antennas is actually better than I have achieved in Dili or Adelaide. Not bad considering we were in the middle of a city of 12M people.

Time to introduce some of the Atcom guys. From the left we have Nick and HeZhong. Alen (the MP01 hardware engineer) is in the blue shirt, and Edwin is on the far right holding the potato stick.

It was about 30C and 95% humidity but still nice to be outside. Everyone seemed to enjoy themselves, and it was good training for Atcom in antenna testing. For example when we walked behind a tree the phone call dropped right out, a few steps to one side and the call came back up. I have also used the “potato on a stick” training method with great success in East Timor. Quick and fun education in Wifi propagation.

Testing on the Jetty

By July I was back in Adelaide. Time for some more potato testing. Joel and I repeated the tests on the Jetty with the V1.3. The site and path (400m Line of Site) was the same as the January tests.

The call quality was fine with the MP in any orientation (I rotated it during a call), even kicking it around on the surface of the jetty with my feet. Pretty similar to January’s results with the prototype PCB antennas. The audio would drop out when Joel stepped in front of his MP but seemed to come back up after a few seconds. Perhaps the Wifi bit rate automatically dropped to account for the extra path loss of Joel!

Checking the Antenna Impedance

Next I hooked up my Standing Wave Ratio (SWR) bridge to the MP V1.3 antenna. The SWR bridge is described in this earlier post.

The SWR bridge lets me test if an antenna is resonant. If it is resonant the antenna impedance will look like a 50 ohm load at 2.4GHz. The SWR bridge can also be used to compare the V1.3 PCB antenna with other Wifi antennas. As described in the earlier post the SWR bridge produces a DC voltage that indicates the mis-match in the antenna impedance from the desired 50 ohms. A low voltage from the SWR head is a good result. Here are the results:

Load	SWR Bridge Output (VDC)
50 ohm resistive dummy load	0.24
open circuit (no antenna)	0.80
N-type antenna as used on V1.2	0.36
Off the shelf router antenna	0.35
Prototype 17mm PCB antenna	0.30
Prototype 20mm PCB antenna	0.40
MP V1.3 PCB antenna	0.22

The MP V1.3 PCB antenna is very close to the “ideal” 50 ohm resistive load. Although with this rough home-made kit a fairer conclusion is that the V1.3 antenna is in the same ball park as the others.

The SWR head & V1.3 antenna was driven from another Mesh potato sending ping floods. A 2.4GHz signal generator would make this testing easier. Using a Wifi transmitter as a signal source means bursty TX signals which makes these measurements tricky. A 2.4GHz sig-gen I could sweep (even manually) would also be great to determine exactly where the antenna is resonant.

MP01 Antenna Options

The V1.3 has a group of three 0-ohm resistors that can be used to change the antenna configuration. The resistors simply act as shorting links, they could be replaced by blobs of solder:

The normal configuration is R406 and R404 loaded. This connects the AR2317 SoC to the PCB antenna. To use an external antenna, R406 and R402 is loaded. This connects the AR2317 to J4, where a pigtail can be used to connect J4 to the external antenna.

A third possibility is R402 and R404 loaded. This removes the AR2317 from the circuit, and allows the PCB antenna to be connected to J4 for testing. This is the configuration I used for testing with the SWR bridge in the photo above.

A 2.1km Test between Jetties

On 3 August we made phone calls over a 2.1km path using two V1.3 MP01s with the built in omnidirectional PCB antenna. The phone calls were of excellent quality (no pops or clicks).

Thanks very much to my friend Angelo (a local Electronic Engineer) who helped out on the day. These tests take hours to set and perform and it’s great to have a friend to help.

Angelo is an IT Sys Admin by day and loves trouble shooting. During the Wifi test set up we (quite accidentally) stumbled across a previously unknown but serious bug in the Power over telephone Line (PoTL) part of the power supply. Just in time to prevent the bug being repeated 500 times in the first production run! Thanks Angelo for helping us track this bug down.

For the Wifi tests we used two local jetties (Grange and Henley) which extend 500m out to sea. This reduces interference from nearby Wifi networks and gives good height above ground (sea) level.

Below is Grange Jetty as viewed from Henly Jetty. Sorry about the grainy image below. Grange Jetty is so distant it is hard to image with the camera I have. Angelo is the guy with the brown eyes standing just behind the canopy at the end of the jetty.

Angelo suggested we could have gone much further. I think I agree, as doubling the distance again is a only a further 6dB power loss. But we have run out of convenient jetties for now.

These results, like the earlier results above, show that the V1.3 PCB antenna is working very well. I would like to take this opportunity to thank Jeff Wojtiuk for doing an excellent job in designing this antenna. Thanks Jeff! I would also like to thank Alen Chen from Atcom who has done a fine job on the PCB layout and hardware engineering for the MP01.

Some test data and results, gathered from the Henley end of the link:

• Height at Grange Jetty was 8m+4m mast
• Height at Henley Jetty was 8m+2m mast
• ping -s 1400 -c 100 21% loss 29/42/76 ms
• ping -c 100 7% loss 3/6/12 ms
• Batman metric 240-250
• “iwlist ath0 scan” detected 6 networks, between -81 and -95dBm

I used the node_tune.sh script to measure received signal strength while rotating the Henley end MP01. The signal strength varied between -90 and -86dBm over 360 degrees, with a peak (-86) being reached with the front of the MP01 at 90 degrees to Grange Jetty, i.e. the PCB antenna was edge on. This is an unexpected result.

We tried rotating the MP01 at the Grange end. In this case the maximum signal strength was reached with the MP01 facing Henley jetty. This is the expected result. The difference between the two sites makes me wonder of other factors were involved. For example multipath due to reflections from the sea or nearby metal objects.

Rotating could also have induced a Wifi bit rate rate shift (e.g. from 5.5 to 1 Mbit/s). The AR2317 transmit power varies betwen 15 and 20dBm between 54 and 1 Mbit/s. A rate shift over the link would cause lower lower tx and hence rx power but a higher bit rate. I performed the rotation tests during a regular phone call. Perhaps using broadcast packets would have been a better idea, IIRC they are transmitted at a fixed bit rate and hence fixed power level.

It is important to remember that the AR2317 RSSI indicator is not a calibrated measuring instrument. It is probably not very logarithmic, and no doubt drifts all over the place with temperature and varies from unit to unit. Burst Wifi and interfering signals make power measurements difficult. So we can treat the received signal levels as indicative only. For example I assume an error of +/- 3dB on any RSSI measurements in this system. A much better way to measure RX signal power is to use a spectrum analyser as the receiver.

Using a Wifi calculator I checked the free space path loss and Fresnel zone clearance. The expected power at the receiver is:

Pr = Tx power + Tx antenna gain – path loss + Rx antenna gain

Plugging in the numbers we get:

Pr = 17 + 2 – 106 + 2 = -85dBm

The driver reported the received power as -86dBm, which is a reasonable match if you trust the received power measurement (which I don’t). Still, it’s fair to say we are in the ball park, and that both the antenna and MP01 radio are performing well. Crystal clear VOIP over a 2100m Wifi link with just Omni antennas and 50-100mW is an exceptional result.

I plugged in 17dBm for the tx power above as I was unsure of the bit rate, unfortunately I don’t know how to read the current bit rate of the Wifi driver in ad-hoc mode. The actual tx power could be between 15 and 20dBm, depending on the bit rate.

The 1st Fresnel zone was 8m which we should clear OK with our masts and the jetty height above sea level. However I am not sure what effect the sea has on Wifi. Being slightly conductive it’s probably more reflective than a path over land.

These results show us how important interference and Line of sight (LOS) are to Wifi. In Dili we couldn’t set up a 300m link between MPs equipped with Omni-directional antennas due to massive interference. Even to obtain that range with directional antennas we needed huge, free standing masts (up to 25m) to clear obstacles like trees. However “on the beach” we can achieve an impressive 2.1km with omnidirectional antennas and modest power levels.

Links

Coincidentally a couple of friends sent me this link on PCB antenna design while I was writing this post.

Related posts:

1. Potato on the Jetty – Range testing PCB Antennas Today we made some phone calls over a 400m link...
2. Antenna Testing Jeff and I have just had an enjoyable day outside...
3. 800m Phone Call I just made some test phone calls between two Mesh...

Related posts brought to you by Yet Another Related Posts Plugin.

Interesting news worth to spread about the commercial LabVIEW :

In LabVIEW 2010, the DFIR offers new compiler optimizations such as algebraic reassociation, common subexpression elimination, loop unrolling, and subVI inlining. This release also includes the adoption of a Low-Level Virtual Machine (LLVM) into the LabVIEW compiler chain. LLVM is an open-source compiler infrastructure used widely in industry. With LLVM, new optimizations were added such as instruction scheduling, loop unswitching, instruction combining, conditional propagation, and a more sophisticated register allocator.

The Submersible Capable of under-Ice Navigation and Imaging (SCINI) is an underwater remotely operated vehicle (ROV) designed to facilitate oceanographic science research in extreme polar environments.  The project was part of a three year grant, starting in 2007, from the National Science Foundation aiming to develop a cost-effective research tool that can be [...]

Last year I started to occasionally play with Erlang. People who know me as die-hard C coder who tries to avoid C++, Java and Python wherever possible will probably be surprised here now.

I have no intention of changing my general position on programming languages. I don't feel comfortable using something where I don't know and/or understand the immediate impact on how this code will be executed on the actual silicon.

However, if you have a need to play with anything that uses ASN.1, but particularly the aligned/unaligned PER encoding variants, then it is pretty clear that there is nothing available as Free Software that can compare to the Erlang asn1ct/asn1rt modules.

At that time last year I was doing some rapid prototyping with the RANAP protocol, and the progress was quite quick. I never had time to return to that project, so it (and my Erlang skills) were left dormant.

In recent weeks, I have picked Erlang up again - again to work on ASN.1 encoded messages: This time TCAP and MAP. While we still need the in-progress TCAP+MAP implementation in C for OsmoSGSN, there are other tasks at hand where an Erlang-based implementation might yield a much higher productivity.

So right now I'm working on a program that parses/decodes and iterates through every MAP component in a TCAP message and replaces certain fields, re-encodes the entire message and sends it off the wire. Once that is done, I think I'll actually try to do a more complete TCAP server and implement a simplistic HLR for OsmoSGSN testing.

I've come up with GSMTAP about two years ago while working on airprobe. The goal was to have something similar to what radiotap does in the wifi world: A pseudo-header that adds additional information and context that is not present in the actual message.

Initially, GSMTAP was intended to be a separate link-layer type in the pcap file format, but this would preclude its use in real-time protocol analysis. So I modified it to be encapsulated in UDP packets, which are sent and received using normal UDP/IP sockets.

Over recent years, GSMTAP has not only been integrated into multiple programs of the airprobe project, but is also understood by wireshark. OpenBTS has also decided to adopt the format and can generate GSMTAP messages for debugging purposes.

After creating OsmocomBB, it was taught how to generate GSMTAP messages very quickly, too.

So by now, at least when it comes to Free Software, it is definitely the de-facto standard for capturing/transmitting and analyzing protocol messages from the GSM air interface.

However, until now, there has never been any official "homepage" of the GSMTAP header. This has changed now, the GSMTAP homepage is now part of the OsmocomBB wiki.

According to GSM 02.07 B.1.26, there should be a Ciphering Indicator in the ME to allow a user to detect if ciphering is not switched on. The Ciphering Indicator can be turned off by the network operator clearing the OFM (Operational Feature Monitor) bit in the "administrative data" field of the SIM (see GSM 11.11, 10.3.18)

Usually the Ciphering Indicator is turned off, at least in those SIMs I have seen so far. And you usually cannot modify the administrative data in the SIM. But would a phone actually display something if the Ciphering Indicator is enabled and ciphering is not on ?

To find this out I used a Test SIM which allows modifying all fields of the SIM. Such a Test SIM is for testing handsets, you cannot use it with your official GSM network. The OFM bit was set to one to enable the Ciphering Indicator. To simulate encrypted and unencrypted calls I used a Racal 6103E GSM Testset. I could have also used OpenBSC, however with the 6103E switching between encrypted and unencrypted calls was faster, it just required the press of a button.

Here are the results for some phones I had access to, Yes means that I noticed a difference between encrypted and unencrypted calls and what this difference was and No means that I noticed no difference:

• Nokia 3310: Yes, Open Lock Symbol during Call
• Siemens M55: Yes, *!* Symbol during Call, regardless of OFM bit
• Mitsubishi MT-040: No
• P1300: Yes, Cx Symbol during Call
• Motorola C123: No
• Motorola W156: No
• Netzing NE110: Yes, C* Symbol during Call
• BlackBerry 9000: No
• BlackBerry 9520: No
• BlackBerry 9700: No
• Sony Erisson K800i: No
• HTC Touch Pro: No
• HTC Hermes: No

This is by no means a detailed investigation however it is at least some indication that a lot of phones do not care at all about the Ciphering Indicator, probably because it is usually turned off in the SIM anyway.

A lot of things have happened in China relating to Fedora; our MIPS port gained attention from Loongson and we made Fedora 13 available on our servers. Although it has not been mirrored yet to secondary.fedoraproject.org, you can already try it out. The other thing is about what Kaio and I have been busy with for the last half year, the Chinese Fedora Community!

It seems our efforts have not been unnoticed and the Fedora Community Architecture team sent Mel Chua to China. Yesterday she arrived in Beijing and we immediately started to discuss about our community and future activities and how to gain a more widespread acceptance of Open Source in China.

One of the things we immediately agreed upon was, luckily her explanation was less morbid, to 'Raptor-proof our community'. Our community is fragile when it comes to responsibilities and the load carried upon those shoulders. For this to succeed we would like you to propose people or yourself for a role within the community.

It would be ideal if some of you would step forward and become a regional ambassador who can represent key regions in China, like Shanghai, Hong Kong, etc. The workload for this is low and when we can balance it out it would even be minimal. You would take care of distributing Fedora swag, like t-shirts in your area.

This Raptor issue also troubles our MIPS port. Currently we have three members and of this only the lead role can be performed by someone else. We have a nice group of people around us, but we are always searching for new members. If you want to help with documenting or other activities, just get in touch. No, you don't need to be Chinese :-P. If you have a Yeeloong netbook and got tired or Mandriva, help us test and build third-party packages.

We would really like to know about Open Source activities happening all over China or maybe you have suggestions. If you want to discuss this with us, join #fedora-zh and mailinglist. Mel's agenda for this week is still open, so if you want to meet her in Shanghai, this is your chance.

Thanks to all the members of the Chinese Fedora Community!

I started to implement Layer-1 support in OsmocomBB for traffic channels. Its not yet ready and in a rather crude state but I hope to clean it up in the next few days so that it can be released.

During testing I used a nice feature of my HP8922 GSM Testset: It can continuously generate Full-Rate TCH speech traffic on a timeslot without the need for any signalling. You can even connect an external audio source like a CD player and "broadcast" your own content. And while it is in this mode, the HP8922 can also receive speech traffic and you can hear it on its built-in loudspeaker.

The benefit of this for getting the Layer-1 code on the phone right is that you can concentrate on TCH receiving and transmitting without having to care about signalling. You just "tune" to the right ARFCN and timeslot (I don't use hopping during testing) and see that you get your code running.

I guess that having this special mode (setting an ARFCN and timeslot and "listen" to the TCH) in the phone can be quite useful for debugging non-hopping, non-encrypted, single ARFCN cells like OpenBSC and OpenBTS.

I wasn't aware of it, but Microsoft Research is doing SDR (Software Defined Radio): Sora.

Their approach is interesting, all the raw samples are transferred between the PC memory and the ADC/DAC of the Radio Front-end by a PCIe card and all the signal processing is done by the CPU of a PC. There is no DDC (Digital Down Converter) or DUC (Digital Up Converter) in an FPGA involved. They already implemented 802.11a/b/g and an LTE receiver this way.

The price of the hardware does not sound too expensive. The software only runs on Windows and I have not yet checked the license terms in detail.

I could imagine that combining this approach with the power of a GPU can be quite interesting.

Some news sites seem to do very limited research and present it as big news that you can now build an IMSI-Catcher for a budget of USD 1500, using OpenBTS and a URSP.

Let me bring some clarity into this situation:

• Fundamentally, an IMSI-Catcher is nothing special but a GSM base station (BTS) that is configured to the network country code (NCC) and mobile network code (MNC) of a commercial network operator.
• In GSM, the phone has no way to authenticate and thus verify the legitimacy of the mobile network. This is like a "rogue access point" in a open (unencrypted/unauthenticated) WiFi network.
• Thus, anyone who has a device that can run as a GSM base station has the ability to run an IMSI catcher.
• There are two Free Software / Open Source projects for running your own GSM network, both have first been published in 2008: OpenBTS and OpenBSC.
• None of those two projects are intended to be used as an IMSI-Catcher but for legitimate operation of GSM networks. However, if a user choses to configure the NCC and MNC of a commercial operator and allow "unknown/unregistered/unprovisioned IMSIs (SIMs) on his network, he will effectively have an IMSI catcher.
• Such operation is in violation of spectrum usage regulations, even if you have a valid test/experimental license, since that license does not permit you to use somebody else's NCC/MNC.
• Furthermore, such operation is in violation of criminal law in most jurisdictions. In Germany there is a separate offense in the criminal code, called Paragraph 317 Stoerung von Telekommunikationsanlagen, combined with Paragraph 202b Abfangen von Daten.
• Furthermore, there are certainly civil claims to be made by the affected operator (and its subscriber) against anyone who unlawfully operates such a fake base station
• OpenBTS and OpenBSC, as well as the problems resulting from this fake base station attack have been covered in a variety of conference presentations from 2008 through today.
• Thus, there is nothing new about what has been presented at Defcon 18

Also, the theoretic basics ow how to operate an IMSI catcher are nothing new either. There are even a number of patents covering IMSI catchers, the first that I know of has been patented by Rohde & Schwarz in 2003. Also, see this blog post by OpenBTS founder David Burgess on this topic.

So all that you always needed is a bit of hardware and software to send radio waves containing messages formatted in the way how they are described in the (equally public) GSM specifications as published by ETSI and 3GPP. Commercial, proprietary systems have existed for a decade. From 2008 on, there is some Free / Open Source Software to operate GSM networks. The situation remains unchanged in 2010.

So please, remember this the next time somebody is trying to tell you that this is the latest invention since sliced bread.

The Ware for July 2010 is shown below. Click on the image for a much larger version.

This ware is not a functional ware, but rather a work of art. I’m a little worried this might be too obscure for the competition, but I did a check on google, and the right keywords produced images of this artifact. If it turns out this is too hard to guess, I’ll release some more hints over time.

Thanks to everyone who played last month’s Name That Ware! I was astonished at the number of people who made a huge effort to count all the vias.

Before I announce the winners, I’ll reveal the design stats on the number of vias on the PCB:

144 9-mil vias
1062 10-mil vias
13 13-mil vias
15 162-mil vias

For a grand total of 1381 vias. This would make Alex G the winner at 1379 vias. Congrats, email me to claim your prize!

I spent some time to extend Airbrobe's gsm-receiver so that it now can be used to nearly fully decode the downlink traffic of a non-hopping, single ARFCN cell. "Nearly" means that it does not yet support Half-Rate speech TCH channels or TCH data channels (which are not widely used anyway with GPRS).

It might not be obvious, but I was also responsible for decoding/decrypting speech in gsm-receiver. In June 2009 I wrote a tool based mainly on parts of OpenBTS to solve a little "challenge" by Piotr Krysik posted on the Airprobe mailing list to get the speech out of an USRP capture. This standalone tool was later integrated into gsm-receiver by Piotr. Now at least you know who to blame why there is stuff from OpenBTS integrated into gsm-receiver ;-).

Besides being used in Karsten Nohl's A5/1 cracking attack, those features of gsm-receiver are quite handy for debugging OpenBSC or OpenBTS in the downlink direction.

A short tutorial of how to use gsm-receiver can be found here.

One of the next steps I plan to do is implementing the uplink direction. Please don't ask when this will be ready, if someone else is already working on it, please let me know so that the same thing is not done twice.

Dieter Spaar, who has been involved in various ways with both OpenBSC and OsmocomBB has just started a blog. This is good news and I hope this way he will get a bit more (much deserved) exposure on his great work.

At Blackhat US 2010, there was a Talk that (among other things) apparently included the subject of a RACH DoS on GSM base stations, implemented using my Layer1 of the OsmocomBB software.

As some news sites are covering this as "news": This vulnerability has been long known in the field and was - to the best of my knowledge - first demonstrated to a public audience by Dieter Spaar at the Deepsec 2009 conference in November 2009. You can get his slides.

The difficult part for many years has not been to know about the possibility of this weakness. Anyone who has read the GSM air interface specification will inevitably see that there is a limited number of RACH slots and a limited number of dedicated channels. Once you fill more RACH slots than the cell has dedicated channels, and you keep re-filling them at a higher rate than the cell can expire those dedicated channels, you have a DoS.

So rather, the difficult part was to implement it in practise, as traditionally all GSM baseband chipsets have been extremely closed, just like the very software (firmware) running on them. Today, starting from Q2/2010, it is very easy to do a proof-of-concept implementation, as we have created OsmocomBB: An Open Source baseband firmware.

Dieter Spaar's implementation predates OsmocomBB development by the better part of a year. At that time, he had to resort to binary-patching existing proprietary (binary-only) baseband firmware. So I think people should recognize his effort in doing the first practical implementation of that attack.

I finally decided to start writing a small blog about what things I am working on. The reason is that it seems these days without talking or writing about what you do, your work won't get noticed or others might take what you have done and claim its theirs.

At Blackhat USA 2010, Karsten Nohl has been presenting on a practical real-world A5/1 cracking attack. For recent years, Karsten, myself and others have been speaking at various opportunities, indicating that a practical attack using readily-available information and tools from the Internet is very possible, and that it is only a matter of time for somebody actually does it.

While Karsten has focused on the actual cryptographic attack, I've been putting in some time in projects like airprobe (a GSM receiver/decoder).

Now finally, a team of friends at the new Security Research Labs (founded by Karsten) in Berlin has put the pieces of the puzzle together.

Airprobe has been extended to fully support decoding of TCH/F (FACCH, SACCH and traffic), as well as SDCCH/SACCH control channels, and to specify the timeslot and physical channel configuration from the command line. Using this, you can

• decode the AGCH, wait for an IMMEDIATE ASSIGNMENT of a SDCCH
• decode that very SDCCH and wait until encryption is turned on
• dump an encrypted burst where you have sufficient known plaintext
• use a different program to actually recover the A5/1 ciphering key
• feed that key into airprobe and decrypt+decode the ASSIGNMENT COMMAND of the TCH
• use airprobe to decrypt+decode that assigned TCH/F

The external program to recover the A5/1 ciphering key is called Kraken and is also available from the SRLabs website.

So what are the limitations? Well, so far this only works on non-hopping cells with a single ARFCN. The limitations are those of the receiver hardware (and SDR software), and not really limitations of the airprobe GSM decoder or the actual software tools.

In the past I would have assumed that non-hopping and/or single-ARFCN cells are rare, but in fact we can find them even inside a big city like Berlin, from at least two of the four German GSM operators. So that's why this attack is very practical, no matter what the GSMA might say.

In case you're wondering why there is such a long period with no updates: I've been travelling over the last week and barely had sufficient time to follow my e-mail and get the most high-priority work done. Hope to update the blog soon.

read more

Installing Ubuntu 10.04 on the IGEPv2 board. Using the board as a small server.

Last year, folks at Texas Instruments told me about the IGEP v2 board. This board is similar to the Beagle board, but also features 512 MB of RAM and NAND flash (instead of 256 for the Beagle), on board Ethernet (RJ45), Wi-Fi and Bluetooth, all this for only 145 €! Its fast ARM CPU (TI OMAP 3530 running at 720 MHz) and graphical capabilities allow it to be used in for services usually performed by desktop or server CPUs.

At the Free Electrons main office, we needed a server to share files, create backups and upload these backups to our servers on the Internet. I decided to use the Ubuntu 10.04 distribution on ARM, based on Debian GNU/Linux. As I didn’t find all the details I needed on the IGEP community website, here are the steps that I took. Several details were found on the http://labs.igep.es/index.php/How_to_get_the_Ubuntu_distribution page though.

This page assumes that you are familiar with building the Linux kernel, controlling an embedded board from a serial line and booting it, and using the GNU/Linux system in general (see the training materials from our embedded Linux course). Beginners may be lost because we don’t give all the details, but more experienced developers should just find the board specific details that they need.

First, get an SD card (at least 2 GB), and prepare its partitions with the mkcard.sh utility.

To compile your kernel, get a CodeSourcery toolchain for ARM. I used the 2010q1 release. Install it in /usr/local/CodeSourcery/arm-2010q1/ (for example)

Get the kernel sources:

$ mkdir $HOME/igep
$ cd $HOME/igep
$ git clone git://git.igep.es/pub/scm/linux-omap-2.6.git
$ cd linux-omap-2.6/

Let’s switch to the latest stable version:

$ git tag
v2.6.28.10-3
v2.6.28.10-igep0020b-0
v2.6.28.10-igep0020b-1
v2.6.28.10-igep0020b-2
v2.6.33.2-0
v2.6.33.4-0
$ git checkout -b v2.6.33.4-0 v2.6.33.4-0
Checking out files: 100% (13116/13116), done.
Switched to a new branch 'v2.6.33.4-0'

Now, set the environment variables for cross-compiling the kernel sources to the arm architecture:

$ export PATH=/usr/local/CodeSourcery/arm-2010q1/bin:$PATH
$ export ARCH=arm
$ export CROSS_COMPILE=arm-none-linux-gnueabi-

Now, take the default configuration for the board and build your kernel:

$ make help | grep igep
$ make igep0020_defconfig
$ make -j 4
$ make uImage

It’s time to build your Ubuntu filesystem, using the Rootstock utility:

$ tar zxvf rootstock-0.1.99.3.tar.gz
$ cd rootstock-0.1.99.3
$ sudo ./rootstock --fqdn igepv2 --login mike --password letmein --imagesize 2G --seed build-essential,openssh-server --dist lucid

Copy the kernel to the first partition of your SD card:

cp arch/arm/boot/uImage /media/boot/
cp .config /media/boot/config-2.6.33.4

Install the root filesystem on the second partition of your SD card:

$ cd /media/rootfs/
$ sudo tar zxvf $HOME/igep/rootstock-0.1.99.3/armel-rootfs-201006102239.tgz

Configure the rootfs to let you log in on the serial console (ttyS2 with OMAP). Do this by copying etc/init/tty1 to etc/init/ttyS2 and replacing tty1 by ttyS2 in this file.

Install kernel modules manually for the first time:

$ mkdir -p /lib/modules
$ cd $HOME/igep/linux-omap-2.6/
$ make INSTALL_MOD_PATH=/media/rootfs modules_install

In the Rootstock version I tested, the specified user didn’t get created (bug report). To be able to log in, I had to disable the root password by removing the first * character in the root entry in etc/shadow:

We are now ready to boot our new system. First, unmount your SD card partitions:

$ sudo umount /media/boot
$ sudo umount /media/rootfs

Insert your SD card in the slot on your board, connect your serial cable and in the U-boot prompt on the serial line, configure the kernel boot parameters:

$ setenv bootargs mem=512M console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait
$ setenv bootcmd 'mmc init 0 ; fatload mmc 0 80000000 uImage'
$ setenv autostart yes
$ saveenv
$boot

You should see your Linux kernel boot and get to a login shell. Log in as root with no password.

It is now time for the final tweaks. First, create a non root user (remember the Rootstock bug), allow it to run the sudo command, and choose a root password too:

adduser mike
adduser mike sudo
passwd

Let’s cope with a last Rootstock bug. Add the updates and security repositories to /etc/apt/sources.list:

deb http://ports.ubuntu.com/ubuntu-ports lucid-updates main
deb http://ports.ubuntu.com/ubuntu-ports lucid-security main

Without this, you would miss package updates and security releases, and your packages would never change!

If you use the IGEP board as a server as I do, you may need your server to have a fixed MAC address. The trouble is the e2prom storing the MAC address is not populated by default, and every time you boot, the kernel gives you a random MAC address.

The easiest fix I found was to choose an arbitrary MAC address (you can take the first random one that you get), and force it in /etc/network/interfaces:

auto eth0
iface eth0 inet dhcp
hwaddress ether 00:01:04:1b:2C:1F

As the IGEPv2 board doesn’t have a battery by default, it won’t be able to keep the correct time. You can use the ntp daemon to address this:

sudo apt-get install ntp

Your configuration should now be complete. You can now use your IGEPv2 board as a tiny, ultra low power server with Ubuntu server. All the rest is ordinary Debian / Ubuntu server administration. Of course, you can also install desktop packages and use your board as a desktop replacement (you may need to add kernel command line settings for graphics). Have fun!

By the way, the IGEPv2 board is not the best solution if you all you need is a server. The amazing graphical capabilities of the OMAP chip would just be useless. For a server, better, cheaper and more powerful alternatives are the SheevaPlug and GuruPlug. Don’t miss these very nice devices!

List of sessions and speakers at ELC Europe in Cambridge, UK

Being a member of the organization committee of the Embedded Linux Conference Europe, I get access to fresh news about this yearly conference. The call for presentations is now over and we have just announced the list of sessions.

Note that this list is not the final one yet. Some speakers haven’t confirmed their participation or haven’t sent their biographies yet. There are also two or three speakers added at the last minute who are not listed yet.

The conference will happen in Cambridge, UK, on October 27-28, 2010. Keep an eye on the website (or on our blog). Registration should open in a few days from now, and all practical details will be given then.

See also the agenda of the GStreamer conference which will happen at the same location on the day before.

Changes:

• Support for video input (not used by the demo renderer)
• Support for MIDI (not used by the demo renderer)
• Support for VESA DDC (not used by the demo renderer)
• Support for RC5 infrared remote control (usable in OSD menu)
• Flash write support (contributed by Michael Walle)
• New memory map (contributed by Michael Walle)
• Experimental “softusb” USB core (no functional firmware yet)
• Increased Minimac FIFO sizes
• Improved netboot code

Follow those instructions to upgrade your board – as the memory map changed since the last release, you will need to upgrade to be able to run the latest software.

We’d like your help to test the next release of Verilog-Perl.  A beta release of the next Verilog-Perl release is available on Rawhide:

$ yum install perl-Verilog-Perl --enablerepo=rawhide

This version adds support for 99% of the SystemVerilog 2009 standard, and also fixes a number of preprocessor bugs and other issues.  These changes were massive enough that it may have broken some existing code, however the user interface is identical to the 3.200 series, so your existing scripts should work.