Uwe Hermann - A slightly paranoid Debian developer

libsigrokdecode 0.1.1 released, more protocol decoders supported

Uwe Hermann — Wed, 30 Jan 2013 02:18:00 +0100

Just a quick announce: We released libsigrokdecode 0.1.1 today, a new version of one of the shared libraries part of the open-source sigrok project (for signal acquisition/analysis of various test&measurement gear, like logic analyzers, scopes, multimeters, etc). I will update the Debian package soonish.

As you probably know, in addition to the infrastructure for protocol decoding, this library also ships with a bunch of protocol decoders written in Python. Currently we support 29 different ones (in various states of "completeness", improvements are ongoing).

This release adds support for the following new protocol decoders:

avr_isp: AVR In-System Programming
can: Controller Area Network
jtag: Joint Test Action Group (IEEE 1149.1)
jtag_stm32: Joint Test Action Group / ST STM32
lm75: National LM75
lpc: Low-Pin-Count
maxim_ds28ea00: Maxim DS28EA00 1-Wire digital thermometer
onewire_link: 1-Wire serial communication bus (link layer)
onewire_network: 1-Wire serial communication bus (network layer)
sdcard_spi: Secure Digital card (SPI mode)
tlc5620: Texas Instruments TLC5620 DAC
uart_dump: UART dump

Please check the announce on the sigrok blog and/or the NEWS file for the full list of changes and improvements.

Happy hacking and decoding!

sigrok at the 29th Chaos Communication Congress (29c3)

Uwe Hermann — Tue, 25 Dec 2012 23:27:59 +0100

Yup, it's been a while since my last blog post, but I'm not dead yet. Most of my spare time goes into sigrok development these days (open-source signal analysis suite for logic analyzers, oscilloscopes, multimeters, and lots more), but I'll try to revive my blog too. I have various microcontroller/embedded topics and devices I want to talk about in a small blog post series in the nearer future. But more on that later.

Feel free to subscribe to the sigrok-devel mailing list, join us on IRC in #sigrok (Freenode) where most of the discussions take place, or follow our new sigrok blog (RSS) if you're interested in the ongoing sigrok developments. Anyway, for now just a quick announce:

Same as last year, we will be at the Chaos Communication Congress (29c3), this time in Hamburg, Germany. The conference takes place from December 27th to 30th, 2012.

We'll have a sigrok "assembly", likely in area 3b of the conference building, where we'll be hanging around, working on new sigrok features, new hardware drivers, new protocol decoders and various other things. We'll have lots of gear with us for demo and development purposes, including logic analyzers, oscilloscopes, MSOs, multimeters, and lots more.

Bring your own device if you own models we don't yet support or know about. We'll be happy to have a look!

Chat with us, give us your suggestions which features you'd like to see, which devices you want to be supported, which protocol decoders you'd like to have, or even help us write some drivers/decoders!

Hope to see you there!

sigrok - cross-platform, open-source logic analyzer software with protocol decoder support

Uwe Hermann — Wed, 02 May 2012 16:05:19 +0200

I'm happy to finally announce an open-source (GNU GPL), cross-platform (Linux, Mac OS X, FreeBSD, Windows, ...) logic analyzer software package myself and Bert Vermeulen have been working on for quite a long time now: sigrok (it groks your signals).

History

I originally started working on an open-source logic analyzer software named "flosslogic" in 2010, because I grew tired of almost all devices having a proprietary and Windows-only software, often with limited features, limited input/output file formats, limited usability, limited protocol decoder support, and so on. Thus, the goal was to write a portable, GPL'd, software that can talk to many different logic analyzers via modules/plugins, supports many input/output formats, and many different protocol decoders.

The advantage being, that every time we add a new driver for another logic analyzer it automatically supports all the input/output formats we already have, you can use all the protocol decoders we already wrote, etc. It also works the other way around: If someone writes a new protocol decoder or file format driver, it can automatically be used with any of the supported logic analyzers out of the box.

Turns out Bert Vermeulen had been working on a similar software for a while too (due to exactly the same reasons, crappy Windows software, etc.) so it was only logical that we joined forces and worked on this together. We kept Bert's name for the software package ("sigrok"), set up a SourceForge project, mailing lists, IRC channel, wiki, etc. and started working.

Overview, Features

You can get the lastest sigrok source code from our main git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok

Here's a short overview of sigrok and its features as of today. The software consists of the following components:

libsigrok, a shared library written in C, which contains the general infrastructure for handling logic analyzer data in a streaming fashion.

It also contains the individual hardware drivers which add support for various logic analyzers. Currently supported hardware includes: Saleae Logic, CWAV USBee SX, Openbench Logic Sniffer (OLS), ZEROPLUS Logic Cube LAP-C, ASIX Sigma/Sigma2, ChronoVu LA8, and others. Many more devices are on our TODO list (and we already own them), it's just a matter of time to reverse engineer the USB protocols and implement a driver for them.

Thanks ASIX for being open and helping with the ASIX Sigma driver, and many thanks to ChronoVu for being open as well and providing information about the ChronoVu LA8 protocol! Thanks to Håvard Espeland, Martin Stensgård, and Carl Henrik Lunde (who contributed the ASIX Sigma driver), Sven Peter and "Haxx Enterprises"/bushing (for contributing the ZEROPLUS Logic Cube LAP-C driver, ported from their zerominus tool). Also, thanks to Daniel Ribeiro and Renato Caldas who worked on the Link Instruments MSO-19 driver (still work in progress).

Finally, libsigrok also contains the individual input/output file format drivers. Currently supported are: sigrok session (the default format, which contains all metadata), bits, hex, ASCII, binary, gnuplot, the OpenBench Logic Sniffer format, the ChronoVu LA8 format, Value Change Dump (VCD) viewable in gtkwave, and Comma-separated values (CSV).

libsigrokdecode, a shared library written in C, which contains the protocol decoder infrastructure and the protocol decoders themselves, which are written in Python (>= 3.0).

The list of currently supported protocol decoders includes:

  dcf77                DCF77 time protocol
  lpc                  Low-Pin-Count
  mx25lxx05d           Macronix MX25Lxx05D
  jtag_stm32           Joint Test Action Group / ST STM32
  i2s                  Integrated Interchip Sound
  spi                  Serial Peripheral Interface
  edid                 Extended display identification data
  pan1321              Panasonic PAN1321
  mlx90614             Melexis MLX90614
  jtag                 Joint Test Action Group
  rtc8564              Epson RTC-8564 JE/NB
  transitioncounter    Pin transition counter
  usb                  Universal Serial Bus
  i2cdemux             I2C demultiplexer
  i2c                  Inter-Integrated Circuit
  i2cfilter            I2C filter
  mxc6225xu            MEMSIC MXC6225XU
  uart                 Universal Asynchronous Receiver/Transmitter

Many more decoders are on our TODO list, and we especially welcome contributed protocol decoders, of course! We intentionally chose Python as implementation language for the decoders, to make them as easy to write (and understand) as possible, even if that means that performance suffers a bit. Have a look at the SPI decoder for example, to get a feeling for the implementation.

Protocol decoders can be stacked on top of each other, e.g. you can run the i2c decoder and pipe its output into the rtc8564 (Epson RTC-8564 JE/NB) decoder for further processing of the RTC-specific, higher-level protocol. We also plan to support more complex stacking and combining of decoders in various ways in the nearer future.

sigrok-cli, is a command-line frontend, which uses both libsigrok and libsigrokdecode. It can acquire samples from logic analyzers and output them in various formats into files or to stdout, and/or run protocol decoders on the aquired data.

Example: Data acquisition with 1MHz samplerate into a file.
```
 $ sigrok-cli -d chronovu-la8:samplerate=1mhz --time 1ms -o test.sr
```
Example: Protocol decoding (JTAG).
```
 $ sigrok-cli -i test.sr -a jtag:tdi=5:tms=2:tck=3:tdo=7
 [...]
 jtag: "New state: EXIT1-IR"
 jtag: "IR TDI: 11111110, 8 bits"
 jtag: "IR TDO: 11110001, 8 bits"
 jtag: "New state: UPDATE-IR"
 jtag: "New state: RUN-TEST/IDLE"
 [...]
```
sigrok-qt, a Qt-based GUI for sigrok, using both libsigrok and libsigrokdecode.

This is intended to be a cross-platform GUI (runs fine and looks "native" on Linux, Windows, Mac OS X) supporting data acquisition and protocol decoding.

NOTE: The Qt GUI is not yet usable! We're working on getting it out of alpha-stage for the next release.
sigrok-gtk, a GTK+-based GUI for sigrok, using both libsigrok and libsigrokdecode (soon).

This is a cross-platform GUI contributed by Gareth McMullin (thanks!), supporting data aqcuisition (and soon protocol decoding).

NOTE: The GTK+ GUI is not yet fully usable (but it's more usable than sigrok-qt)! Consider it alpha-stage software for now.

We're happy to hear about other (maybe special-purpose) frontends you may want to write using libsigrok/libsigrokdecode as helper libs!

Firmware

Some logic analyzer devices require firmware to be uploaded before they can be used. As always, firmware is a bit of a pain, but here's what we currently do: For non-free firmware we provide instructions how to extract it from the vendor software or from USB dumps, if possible. For distributable firmware we have a git repo where you can get it (thanks ASIX for allowing us to distribute the ASIX Sigma/Sigma2 firmware files!).

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok-firmwares

Finally, for all Cypress FX2 based logic analyzers we have an open-source (GNU GPL) firmware named fx2lafw, started by myself, but most work (and finishing the firmware) was then done by Joel Holdsworth, thanks! The support list includes Saleae Logic, CWAV USBee SX, CWAV USBee AX, Robomotic Minilogic/BugLogic3, Braintechnology USB-LPS, and many others. Get the code from the fw2lafw git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/fx2lafw

Example dumps

We collect various captured logic analyzer signals / protocol dumps in the sigrok-dumps git repository:

  $ git clone git://sigrok.git.sourceforge.net/gitroot/sigrok/sigrok-dumps

They can be useful for testing the sigrok command-line application, the sigrok GUIs, or the protocol decoders.

We're happy to include further contributed example data in our repository, please send us .sr files of any interesting data/protocol you may come across (even if sigrok doesn't yet have a protocol decoder for that protocol). See the Example dumps wiki page for details.

Packages, distros, installers

I'm currently working on updated Debian packages for sigrok (will be apt-get install sigrok to get everything), and we're happy about further packaging efforts for other distros. We have preliminary Windows installer files (using NSIS), but the Windows code needs some more fixes and portability improvements before it's really usable. On Mac OS X you can use fink/Macports to install as usual, fancier .app installer files are being worked on.

Future

Apart from support for more logic analyzers, input/output formats, and protocol decoders, we have a number of other plans for the next few releases. This includes support for analog data, i.e. support for (USB) oscilloscopes, multimeters, spectrum analyzers, and such stuff. This will also require additional GUI support (which could take a while). Also, we want to improve/fix the Windows support, and test/port sigrok to other architectures we come across. Performance improvements for the protocol decoding as well as more features there are also planned.

Contact

Feel free to contact us on the sigrok-devel mailing list, or in the IRC channel #sigrok on Freenode. There's also an identi.ca group for sigrok. We're always happy about feedback, bug reports, suggestions for improving sigrok, and patches of course!

HOWTO: Using OpenVPN on Debian GNU/Linux

Uwe Hermann — Sat, 24 Dec 2011 01:02:25 +0100

Here's a quick HOWTO for setting up an OpenVPN server and client on any (Debian, in this case) Linux machine of your choice. I'm running an OpenVPN server on a box at home, and a client on my laptop, so I can securely route all my laptop traffic through my OpenVPN server, no matter where I am.

I highly recommend reading the official OpenVPN HOWTO from top to bottom, at least once. But here's a short, condensed HOWTO (specifically geared towards my needs, yours might be different):

On the server:

Install OpenVPN (apt-get install openvpn), then copy the "easy-rsa" files to /etc/openvpn/easy-rsa from where we'll use them to create our keys and certificates:

  $ cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa
  $ cd /etc/openvpn/easy-rsa

In the vars file change the KEY_SIZE variable from 1024 to 4096 for good measure:

  export KEY_SIZE=4096

Then, read in the vars file, clean old keys and certificates (if any) and create new ones:

  $ . ./vars
  $ ./clean-all
  $ ./build-ca

You'll now have the chance to enter some data such as country code (e.g. "DE"), state/province, locality, organization name, organizational unit name, common name, name, and email address. The values you choose don't really matter much (except for commonName, maybe, which could be your hostname or domain or such). Finally, the ca.key (root CA key) and ca.crt (root CA certificate) files will be created.

Next, we'll create the server key:

  $ ./build-key-server server

You'll have to enter lots of info again (see above), commonName could be "server" or such this time. Upon "Sign the certificate? [y/n]" say y, as well as upon "1 out of 1 certificate requests certified, commit? [y/n]". Finally, the server.key and server.crt files will be created.

Same procedure for creating a client key (I used "client1" as filename and commonName here):

  $ ./build-key client1

Next up we'll generate Diffie Hellman parameters (this will take a shitload of time due to keysize=4096, go drink some coffee):

  $ ./build-dh

When this step is done, you'll have a dh4096.pem file.

As we want to use OpenVPN's "tls-auth" feature for perfect forward secrecy (it "adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification"), we'll have to generate a shared secret:

  $ openvpn --genkey --secret ta.key
  $ mv ta.key keys

So much for creating keys. Now, we'll have to configure OpenVPN. Copy the default server config file and edit it:

  $ cd /etc/openvpn
  $ cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz .
  $ gunzip server.conf.gz

The most important change in my setup is that I use port 443/TCP instead of the usual OpenVPN default of 1194/UDP. This increases the chances that you'll be able to use OpenVPN in almost all places, even in environments which firewall/block lots of stuff. Port 443/TCP (for https) will almost always be usable. I also uncommented the following line, which tells the client to use the VPN interface (usually tun0) per default, so that all the client's traffic (web browsing, DNS, and so on) goes over the VPN:

  push "redirect-gateway def1 bypass-dhcp"

Here's my server config file (comments and commented out lines stripped):

  port 443
  proto tcp
  dev tun
  ca /etc/openvpn/easy-rsa/keys/ca.crt
  cert /etc/openvpn/easy-rsa/keys/server.crt
  key /etc/openvpn/easy-rsa/keys/server.key  # This file should be kept secret
  dh /etc/openvpn/easy-rsa/keys/dh4096.pem
  server 10.8.0.0 255.255.255.0
  ifconfig-pool-persist ipp.txt
  push "redirect-gateway def1 bypass-dhcp"
  keepalive 10 120
  tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 # This file is secret
  comp-lzo
  user nobody
  group nogroup
  persist-key
  persist-tun
  status openvpn-status.log
  log-append openvpn.log
  verb 3

You can now start the OpenVPN server, e.g. via

  $ /etc/init.d/openvpn restart

Server firewall setup/changes:

I'm running a custom iptables script on pretty much all of my boxes. Here's the relevant changes needed to allow the OpenVPN server to work properly. Basically, you need to enable IP forwarding, accept/forward tun0 traffic and setup masquerading (change "eth0" below, if needed):

  echo 1 > /proc/sys/net/ipv4/ip_forward
  iptables -A INPUT -i tun+ -j ACCEPT
  iptables -A FORWARD -i tun+ -j ACCEPT
  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
  iptables -t nat -F POSTROUTING
  iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

My firewall script gets run upon every reboot. If you don't use such a script, you could add the above stuff to your /etc/rc.local file.

On the client:

Install OpenVPN (apt-get install openvpn), then copy the default client config file and edit it:

  $ cd /etc/openvpn
  $ cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf .

Change the parameters to match the server config (port 443/TCP, and so on) and use "tls-auth /etc/openvpn/ta.key 1" (note the "1" on the client, and the "0" on the server!). Replace xxx.xxx.xxx.xxx with the public IP address of your OpenVPN server. If it doesn't have a public, static IP address already, you can use services such as DynDNS, or (my preferred method), my ssh-based DIY poor man's dynamic DNS setup.

Here's my full client config:

  client
  dev tun
  proto tcp
  remote xxx.xxx.xxx.xxx 443
  resolv-retry infinite
  nobind
  user nobody
  group nogroup
  persist-key
  ca /etc/openvpn/ca.crt
  cert /etc/openvpn/client1.crt
  key /etc/openvpn/client1.key
  ns-cert-type server
  tls-auth /etc/openvpn/ta.key 1
  comp-lzo
  verb 3

Now you only need to copy the required certificates and keys to the client (into /etc/openvpn): client1.crt, client1.key, ca.crt, and ta.key. Do not copy the other, server-specific private keys and such to the client(s)! Also, the root CA key (ca.key) should not even be left on the server, but rather moved to some offline storage/box, so that it cannot fall into the wrong hands, e.g. in the case of a server compromise.

I prefer to manually start the client on my laptop when needed, so I use AUTOSTART="none" in /etc/default/openvpn and then start the client via:

  $ openvpn /etc/openvpn/client.conf

That's it. Comments and suggestions for improving the setup and/or the security aspects of it are highly welcome!

Downloading non-DRM Amazon MP3s on Linux using clamz

Uwe Hermann — Sun, 06 Nov 2011 01:16:05 +0100

I recently wanted to buy some MP3 files from Amazon (a whole album in my case, but you can also just buy single MP3 files if you want). Digital music downloads from Amazon are often much cheaper than buying the physical CD (from Amazon), and you can also instantly get the stuff within seconds, without having to wait for the physical CD to be shipped to your place.

The good thing about Amazon's MP3 downloads is that the files are not infested with any DRM-crap (if that were the case I wouldn't spend a single penny on such useless junk, of course). This allows you to burn the MP3 files on CDs and/or play them on any device you like (MP3 player of choice, laptop, hifi-system, car, e-book reader with MP3 playback support, etc. etc).

Granted, you can not re-sell the digital files on eBay later, this is the one little drawback you have when compared to physical CDs, but I guess most people can usually live with that. Also, it would be great if Amazon would provide Ogg Vorbis files instead (or in addition to) MP3 files, of course.

Anyway, in order to download the MP3 files you buy from Amazon, they suggest to install the Amazon MP3 Downloader, which (surprisingly) is even available in a Mac and Linux version (only 32-bit though), but is (unsurprisingly) closed-source. This is no-go, of course, but luckily there is an alternative.

The clamz tool (GPL, version 3 or later) allows you to easily download single Amazon MP3 files, or whole albums. First, you need to login to your Amazon account and then visit a certain Amazon page (which sets a special "congratulations, the Amazon MP3 Downloader has been successfully installed" cookie in your browser). See the clamz website for the respective URL for your country. For Germany, use this URL.

The clamz installation is easy enough on Debian:

  $ apt-get install clamz

IMPORTANT: It seems you need at least version 0.5 for recent Amazon files as they apparently changed something, see #647043. Current Debian unstable as of today already has 0.5, though.

After that is done, the rest is easy: In Amazon, click on "Buy MP3" or "Buy MP3 album", which will download a special AmazonMP3-1234567890.amz file. You can then let clamz download all the MP3s by typing:

  $ clamz AmazonMP3-1234567890.amz

Wait a few minutes, and you'll have a bunch of non-DRM MP3 files in your current directory. Easy.

See the manpage for a bunch of options which let you configure clamz to your preferences.

The TrekStor eBook Reader 3.0 (EBR30-a), review and dissection

Uwe Hermann — Sun, 23 Oct 2011 18:59:36 +0200

There a many, many, e-book reader devices available these days, and they're quickly becoming pretty affordable. The currently cheapest device in Germany (that I know of) is the TrekStor eBook Reader 3.0, model number EBR30-a, at 59.- Euros via Weltbild or Hugendubel.

The device has an 800x480 7" TFT (yep, no e-ink), 2100mAh battery, it can display PDFs, EPUB, and TXT files (and Adobe DRM crap, which I don't really care about), it has an accelerometer which allows for landscape/portrait switching, it can play MP3, OGG, WAV, and WMA audio files (headphone jack), it can display pictures (BMP, GIF, JPG, even PNG, though that's not mentioned in the vendor's specs), and it has 2GB internal storage for books/music/pictures. Uploading of (non-DRM) content is done by a simple file copy, it enumerates as a standard USB mass storage device with FAT filesystem. It's a relatively nice reader for the price, I've read a few PDFs (datasheets, presentations) on it in the subway/train while listening to music from the device and it's quite OK for my purposes. So much for the review part.

However, I didn't really buy it for reading books on it, I was more interested in taking it apart, of course ;-) My hope was that it would turn out to be a really cheap device running Linux/U-Boot which would be perfect for playing around with embedded Linux stuff. Unfortunately, I wasn't so lucky (it seems).

I've posted a few photos of the device and its hardware components on my flickr account and over at randomprojects.org, together with all the information I was able to find out so far. Here's a quick summary:

Main CPU/SoC: FI E200 B6077BA 26P1
RAM: MIRA P3S12D40ETP (512MBit / 64MByte DDR SDRAM, max. 200MHz)
NAND flash: Samsung K9GAG08U0E (16GBit / 2GByte, x8, 3.3V)
Battery management: KrossPower AXP199 A5004AB 36G
RTC/clock/calender chip (I2C): H8563S
Some accelerometer (to switch between landscape/portait mode), model unclear so far, maybe the chip labeled 605 132?

There are public datasheets for most of the hardware components (see randomprojects.org for links), but unfortunately the most important one (for the CPU) is not yet found/identified. I was told that the CPU/SoC is probably based on an ARM9 (ARM926EJ-S) core and the firmware running on it seems to be some uCos-based RTOS (not Linux, unfortunately).

So far I was not able to find out the vendor name or website of the "FI E200" CPU/SoC (let alone any datasheets), any hints would be highly appreciated. I checked arm.com: Processor Licensees, but the only two companies whose name starts with "F" having licensed an ARM9 core are Fujitsu and Freescale, which doesn't fit, I think?

I could (and probably will) check the PCB for RX/TX lines on an UART and/or JTAG pads (none are obviously labelled), and given that it's and ARM9 core there is a good chance that OpenOCD can be used and that a standard cross-gcc toolchain for ARM will work. However, that is all pretty pointless until it's clear which SoC exactly is used, and thus whether there is already Linux and/or U-Boot support for it and/or whether datasheets are available so that the respective code could be written. Without datasheets, this is going to be a pretty painful experience, not really worth investing much time, IMHO.

If anyone knows more about the vendor/device and respective datasheets, please let me know. Thanks!

Update 2012-04-19: I found the UART TX pin a while ago, a bootlog is available. The CPU and all other chips are also known now: The SoC is an Allwinner Technology F1 E200, the orientation sensor is a MEMSIC MXC6225XU.

Flashrom 0.9.4 released - Flashing BIOS/ROM chips from the Unix/Linux command line using various programmers

Uwe Hermann — Mon, 29 Aug 2011 18:25:20 +0200

Forgot to mention this here: We released flashrom 0.9.4 a few days ago, the latest release of the open-source, GPL'd ROM chip flashing software for Linux, *BSD, DOS, and partially also Windows (work in progress, though).

Here's a quick summary of the release announcement. Some of the noteworthy news items include:

Support for new programmers: OpenMoko Neo1973/Neo FreeRunner debug board version 2 or 3, Olimex ARM-USB-TINY, ARM-USB-TINY-H, ARM-USB-OCD, and ARM-USB-OCD-H, Open Graphics Project development card (OGD1), Angelbird Wings PCIe SSD/88SX7042, ITE IT85xx embedded controllers, Intel NICs with parallel flash.
Dozens of added flash chips, chipsets, mainboards.
Improved Dediprog SF100 support.
Add support for more than one Super I/O or EC per machine.
Always read the flash chip before writing, for improved error checking and faster programming.
Enable write support on NVIDIA MCP6x/MCP7x.
Lots of bugfixes, documentation fixes, internal improvements, etc.

Get the latest release tarball, or download and build the most recent version via Subversion:

  $ svn co svn://flashrom.org/flashrom/trunk flashrom
  $ cd flashrom
  $ make

I already updated the Debian package to 0.9.4 (it has also already migrated to Debian testing and Ubuntu), other people have updated Fedora, Gentoo, NetBSD etc. etc.

There's already a huge amount of patches queued for the next release, including support for even more programmers, PowerPC support (tested on Mac Mini and others), and of course the usual "more boards, more chips" items...

The FONIC Surf-Stick, Huawei E1750 HSPA USB modem, on Debian GNU/Linux via usb_modeswitch and wvdial

Uwe Hermann — Mon, 01 Aug 2011 01:30:13 +0200

I recently got myself a FONIC account for mobile Internet. This (German) prepaid-provider offers a "daily flatrate" for 2.50€ per day. After the 10th day of usage (i.e., 25€) you don't pay any more. This means, even if you need mobile Internet access 31 days a month, you only pay for 10 days. After 500MB/day or 5GB/month you're throttled down to GPRS speed (but you can still connect, and you don't pay more).

The FONIC account comes with the "FONIC Surf-Stick", a Huawei E1750 HSPA USB modem (apparently it supports GPRS, EDGE, UMTS, HSDPA (up to 7.2Mbit/s), HSUPA (up to 5.76 Mbit/s), and a SIM card.

In order to use the device on Linux you need two packages, usb_modeswitch and wvdial:

  $ apt-get install usb-modeswitch wvdial

Recent versions of usb_modeswitch (and matching udev entries) already support the Huawei E1750 out of the box, a few seconds after attaching the device it's automatically switched into modem mode. After this has been done you should have three new serial devices, usually /dev/ttyUSB0, /dev/ttyUSB1, and /dev/ttyUSB2. You'll need /dev/ttyUSB0 for talking to the device using AT commands. The lsusb output should look like this (see here for full lsusb -vvv):

  $ lsusb
  Bus 001 Device 045: ID 12d1:1436 Huawei Technologies Co., Ltd.

(before usb_modeswitch was run, the USB IDs were 12d1:1446)

The required settings for connecting are documented at fonic.de, specifically the APN (pinternet.interkom.de). A username and/or password is not required. You need to provide your FONIC PIN though. Dialing is done using the *99# number and using the ATDT command.

I'm using the following wvdial config file:

  $ cat /etc/wvdial.conf
  [Dialer Defaults]
  Modem = /dev/ttyUSB0
  Baud = 460800
  [Dialer pin]
  Init1 = AT+CPIN=1234
  [Dialer fonic]
  Phone = *99#
  Username = foo
  Password = foo
  Stupid Mode = 1
  Dial Command = ATDT
  Init2 = ATZ
  Init3 = AT+CGDCONT=1,"IP","pinternet.interkom.de"

For mobile Internet access you would do the following:

Attach the device via USB, wait a few seconds to let usb_modeswitch do its magic.

Run wvdial pin and wait a few seconds (until the prompt returns):

  $ wvdial pin
  --> WvDial: Internet dialer version 1.61
  --> Initializing modem.
  --> Sending: AT+CPIN=1234
  AT+CPIN=1234
  OK
  --> Modem initialized.
  --> Configuration does not specify a valid phone number.
  --> Configuration does not specify a valid login name.
  --> Configuration does not specify a valid password.

Run wvdial fonic and wait until the "CONNECT" message appears and you get DNS addresses:

  $ wvdial fonic
  --> WvDial: Internet dialer version 1.61
  --> Initializing modem.
  --> Sending: ATZ
  ATZ
  OK
  --> Sending: ATZ
  ATZ
  OK
  --> Sending: AT+CGDCONT=1,"IP","pinternet.interkom.de"
  AT+CGDCONT=1,"IP","pinternet.interkom.de"
  OK
  --> Modem initialized.
  --> Sending: ATDT*99#
  --> Waiting for carrier.
  ATDT*99#
  CONNECT
  --> Carrier detected.  Starting PPP immediately.
  --> Starting pppd at Mon Aug  1 xx:xx:xx 2011
  --> Pid of pppd: 18672
  --> Using interface ppp0
  --> local  IP address xxx.xxx.xxx.xxx
  --> remote IP address yyy.yyy.yyy.yyy
  --> primary   DNS address 193.189.244.225
  --> secondary DNS address 193.189.244.206

If everything worked fine you should now have connected successfully.

There are other alternatives for achieving the same result, including umtsmon (Qt3 in the last release from 2009, looks a bit unmaintained), kppp, the GNOME NetworkManager, and others, but wvdial worked OK for me.

For more details about the Huawei E1750 device (e.g. lsusb -vvv and more photos), see my wiki page at

http://randomprojects.org/wiki/FONIC_Surf-Stick_Huawei_E1750

Update 2011-08-03: My measured download speed for a Debian ISO (over HTTP via wget, at night, roughly 22:00 o'clock) is 350-470 KB/s in case anyone is interested. During this download the blue LED on the stick was enabled, which denotes a UMTS connection (green == GPRS/EDGE, turquoise == HSDPA).

Testing stuff with QEMU - Part 4: Debian GNU/Linux on PowerPC

Uwe Hermann — Thu, 28 Jul 2011 23:39:21 +0200

It's been a while since my last blog post, and also quite a while since my last item in the "Testing stuff with QEMU" series, so here goes.

I'm using this QEMU image to do compile-tests on the PowerPC architecture for various software projects, especially flashrom (open-source flash ROM programming software).

So here's how to install Debian GNU/Linux on PowerPC (in QEMU):

Install QEMU:
$ apt-get install qemu
Create a (resizable) image which will hold the installed OS. Use the relatively new "qcow2" QEMU image format, which will only take up as much space as is really needed and has some other nice features (compression, encryption).
$ qemu-img create -f qcow2 debian_powerpc.qcow2 2G
Download a Debian installer ISO for PowerPC:
$ wget http://cdimage.debian.org/cdimage/archive/5.0.8/powerpc/iso-cd/debian-508-powerpc-netinst.iso
Note: For some reason, the current Debian stable 6.0.2.1 ISO didn't work for me (red screen with undefined error during the install; didn't look into the issue, yet). Using an older 5.0.8 image worked fine.
Install Debian in the QEMU image:
$ qemu-system-ppc -hda debian_powerpc.qcow2 -boot d -cdrom debian-508-powerpc-netinst.iso
The installation is nothing really special, you'll know almost everything from your usual x86 installation procedure. Note that you have to use "qemu-system-ppc" (not your usual "qemu"), of course.
After the install has finished, shut down QEMU; from now on you can boot it with:
$ qemu-system-ppc -hda debian_powerpc.qcow2

See the screenshots for some system info. By default an OpenBIOS firmware and the quik bootloader is used, the emulated "machine" is g3beige (Heathrow based PowerMAC). You can use QEMU's -M and -cpu options to select different machines or CPUs.

Hope this helps.

openbiosprog-spi, a DIY Open Hardware and Free Software USB-based SPI BIOS chip flasher using flashrom

Uwe Hermann — Thu, 26 Aug 2010 10:23:05 +0200

If you're following me on identi.ca you probably already know that I've been designing a small PCB for a USB-based SPI chip programmer named openbiosprog-spi.

The main use-case of the device is to help you recover easily from a failed BIOS upgrade (either due to using an incorrect BIOS image, due to power outages during the flashing progress, or whatever). The device only supports SPI chips, as used in recent mainboards (in DIP-8 form factor, or via manual wiring possibly also soldered-in SO-8 variants). It can identify, read, erase, or write the chips.

Of course the whole "toolchain" of software tools I used for creating the hardware is open-source, and the hardware itself (schematics and PCB layouts) are freely released under a Creative Commons license (i.e., it's an "Open Hardware" device). The user-space source code is part of flashrom (GPL, version 2), the schematics and PCB layouts are licensed under the CC-BY-SA 3.0 license and were created using the open-source Kicad EDA suite (GPL, version 2).

The schematics, PCB layouts, and other material is available from gitorious:

  $ git clone git://gitorious.org/openbiosprog/openbiosprog-spi.git

You can also download the final Gerber files (ZIP) for viewing them, or sending them to a PCB manufacturer.

Some more design notes:

The device uses the FTDI FT2232H chip as basis for USB as well as for handling the actual SPI protocol in hardware (MPSSE engine of the FT2232H).
Attaching the SPI chip:
- There's a DIP-8 socket on the device so you can easily insert the SPI chip you want to read/erase/program.
- Optionally, if you don't want a DIP-8 socket, you can solder in a pin-header with 8 pins, which allows you to connect the individual pins to the SPI chip via jumper wires or grippers/probes.
The PCB board dimensions are 44mm x 20mm, and it's a 2-layer board using mostly 0603 SMD components.

Basic usage example of the device on Linux (or other OSes supported by flashrom):

  $ flashrom -p ft2232_spi:type=2232H,port=A -r backup.bin (reads the current chip contents into a file)

Over at the main projects page of openbiosprog-spi at

http://randomprojects.org/wiki/Openbiosprog-spi

I have put up a lot more photos and information such as the bill of materials, the Kicad settings I used for creating the PCBs, the Gerber files and the Excellon drill files and so on.

The first few prototype boards I ordered at PCB-POOL.COM (but you can use any other PCB manufacturer of course), the bill of materials (BOM) lists the Mouser and CSD electronics part numbers and prices, but you can also buy the stuff elsewhere, of course (Digikey, Farnell, whatever).

I already hand-soldered one or two prototypes and tested the device. Both hardware and software worked fine basically, you just need a small one-liner patch to fix an issue in flashrom, but that should be merged upstream soonish.

In order to make it easy for interested users to get the PCBs I'll probably make them available in the BatchPCB Market Place soonish, so you can easily order them from there (you do still need to solder the components though). Note: I'm not making any money off of this, this is a pure hobby project.

All in all I have to say that this was a really fun little project, and a useful one too. This was my first hardware project using Kicad (I used gEDA/PCB, also an open-source EDA toolsuite, for another small project) and I must say it worked very nicely. I didn't even have to read any manual really, it was all pretty intuitive. Please consider not using Eagle (or other closed-source PCB software) for your next Open Hardware project, there are at least two viable open-source options (Kicad, gEDA/PCB) which both work just fine.

Using the HP Pavilion dv7-3127eg laptop with Debian GNU/Linux

Uwe Hermann — Thu, 15 Jul 2010 09:56:44 +0200

Yep, so I bought a new laptop recently, my IBM/Lenovo Thinkpad T40p was slowly getting really unbearably sloooow (Celeron 1.5 GHz, 2 GB RAM max). After comparing some models I set out to buy a certain laptop in a local store, which they didn't have in stock, so I spontaneously got another model, the HP Pavilion dv7-3127eg (HP product number VY554EA).

Why this one? Well, the killer feature for me was that it has two SATA disks, hence allows me to run a RAID-1 in my laptop. This allows me to sleep better at night, knowing that the next dying disk will not necessarily lead to data loss (yes, I do still perform regular backups, of course).

Other pros: Much faster than the old notebook, this one is an AMD Turion II Dual-Core Mobile M520 at 2.3 GHz per core, it has 4 GB RAM (8 GB max), and uses an AMD RS780 / SB700 chipset which is supported by the Free-Software / Open-Source BIOS / firmware project coreboot, so this might make the laptop a good coreboot-target on the long run. I'll probably start working on that when I'm willing to open / dissect it or when the warranty expires, whichever happens first.

Anyway, I set up a page at randomprojects.org which contains lots more details about using Linux on this laptop:

http://randomprojects.org/wiki/HP_Pavilion_dv7-3127eg

Most of the hardware is supported out of the box, though I haven't yet tested everything. There may be issues with suspend-to-disk / suspend-to-RAM, sometimes it seems to hang (may be just a simple config change is needed in /etc/hibernate/disk.cfg).

Cons: Pretty big and heavy (but that's OK, I use it mostly as "semi-mobile desktop replacement"), glossy screen, loud fans (probably due to the two disks).

For reference, here's an lspci of the box:

  $ lspci -tvnn
  -[0000:00]-+-00.0  Advanced Micro Devices [AMD] RS780 Host Bridge Alternate [1022:9601]
           +-02.0-[01]--+-00.0  ATI Technologies Inc M96 [Mobility Radeon HD 4650] [1002:9480]
           |            \-00.1  ATI Technologies Inc RV710/730 [1002:aa38]
           +-04.0-[02-07]--
           +-05.0-[08]----00.0  Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) [168c:002b]
           +-06.0-[09]----00.0  Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168]
           +-0a.0-[0a]--
           +-11.0  ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] [1002:4391]
           +-12.0  ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397]
           +-12.1  ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
           +-12.2  ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]
           +-13.0  ATI Technologies Inc SB700/SB800 USB OHCI0 Controller [1002:4397]
           +-13.1  ATI Technologies Inc SB700 USB OHCI1 Controller [1002:4398]
           +-13.2  ATI Technologies Inc SB700/SB800 USB EHCI Controller [1002:4396]
           +-14.0  ATI Technologies Inc SBx00 SMBus Controller [1002:4385]
           +-14.2  ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383]
           +-14.3  ATI Technologies Inc SB700/SB800 LPC host controller [1002:439d]
           +-14.4-[0b]--
           +-18.0  Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration [1022:1200]
           +-18.1  Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map [1022:1201]
           +-18.2  Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller [1022:1202]
           +-18.3  Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control [1022:1203]
           \-18.4  Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control [1022:1204]

Full lspci -vvvxxxxnnn, lsusb -vvv, and a much more detailed list of tested hardware components is available in the wiki.

Using the Oasis UMO19 MCU003 400x USB microscope on Linux via luvcview

Uwe Hermann — Thu, 24 Jun 2010 12:31:12 +0200

I've been buying quite a lot of (usually cheapo) gadgets recently, which I'll probably introduce / review in various blog posts sooner or later. Let me start with a fun little gadget, a digital USB-based microscope. I found out about it via this thread over at lostscrews.com.

You can get this (or a very similar device) e.g. on eBay for roughly 50 Euros. Mine seems to be from a company called Oasis (though they're probably just the reseller, not sure). The device doesn't seem to have a nice name, but I can see UMO19 MCU003 on the microscope, so I guess that's the name or model number.

It can focus on magnifications of 20x or 400x. The image resolution is said to be a max. of 1600x1200, but in practice most of my images are 640x480, maybe I have to change some settings and/or the resolution depends on the magnification factor and lighting conditions.

The device acts as a simple UVC webcam when attached to USB, so you can view the images easily via any compatible webcam software, e.g. luvcview and also save screenshots of the magnified areas (see images).

First three from left to right: SMD LED (400x), clothes/jacket (400x), random PCB (20x). The other two below: A via on a PCB (400x), and the "pixels" of a TFT screen (400x).

It worked out of the box on Linux for me, the uvcvideo kernel driver was loaded automatically.

 $ lsusb
 Bus 001 Device 013: ID 0ac8:3610 Z-Star Microelectronics Corp.

I set up a wiki page for more details (including full lsusb -vvv) and sample images at:

http://randomprojects.org/wiki/Oasis_UMO19_MCU003_USB_microscope

I will also post some more images there over the next few days.

This is a really fun device for having a look at stuff you'd normally not see (or not well enough), and also useful for e.g. checking PCB solder joints, checking all kinds of electronics for errors or missing/misaligned parts, finding the chip name / model number of very tiny chips etc. etc. I can also imagine it's quite nice for biological use-cases, e.g. for studying insects, tissue, plants, and so on.

Anyway, definately a nice toy for relatively low price, I can highly recommend a device like this. Check eBay (search for e.g. "usb mikroskop 400") and various online shops for similar devices, there seem to be a large number of them with different names and from different vendors. Just make sure it has at least 400x magnification, there are also some with only 80x or 200x which is not as useful as 400x, of course.

flashrom 0.9.2 released -- Open-Source, crossplatform BIOS / EEPROM / flash chip programmer

Uwe Hermann — Tue, 08 Jun 2010 17:30:31 +0200

The long-pending 0.9.2 version of the open-source, cross-platform, commandline flashrom utility has been released.

From the announce:

New major user-visible features:
* Dozens of newly supported mainboards, chipsets and flash chips.
* Support for Dr. Kaiser PC-Waechter PCI devices (FPGA variant).
* Support for flashing SPI chips with the Bus Pirate.
* Support for the Dediprog SF100 external programmer.
* Selective blockwise erase for all flash chips.
* Automatic chip unlocking.
* Support for each programmer can be selected at compile time.
* Generic detection for unknown flash chips.
* Common mainboard features are now detected automatically.
* Mainboard matching via DMI strings.
* Laptop detection which triggers safety measures.
* Test flags for all part of flashrom operation.
* Windows support for USB-based and serial-based programmers.
* NetBSD support.
* DOS support.
* Slightly changed command line invocation. Please see the man page for details.

Experimental new features:
* Support for some NVIDIA graphics cards.
* Chip test pattern generation.
* Bit-banging SPI infrastructure.
* Nvidia MCP6*/MCP7* chipset detection.
* Support for Highpoint ATA/RAID controllers.

Infrastructural improvements and fixes:
* Lots of cleanups.
* Various bugfixes and workarounds for broken third-party software.
* Better error messages.
* Reliability fixes.
* Adjustable severity level for messages.
* Programmer-specific chip size limitation warnings.
* Multiple builtin frontends for flashrom are now possible.
* Increased strictness in board matching.
* Extensive selfchecks on startup to protect against miscompilation.
* Better timing precision for touchy flash chips.
* Do not rely on Linux kernel bugs for mapping memory.
* Improved documentation.
* Split frontend and backend functionality.
* Print runtime and build environment information.

The list of supported OSes and architectures is slowly getting longer, e.g. these have been tested: Linux, FreeBSD, NetBSD, DragonFly BSD, Nexenta, Solaris and Mac OS X. There's partial support for DOS (no USB/serial flashers) and Windows (no PCI flashers). Initial (partial) PowerPC and MIPS support has been merged, ARM support and other upcoming.

Also, the list of external (non-mainboard) programmers increases, e.g. there is support for NICs (3COM, Realtek, SMC, others upcoming), SATA/IDE cards from Silicon Image and Highpoint, some NVIDIA cards, and various USB- or parallelport- or serialport- programmers such as the Busirate, Dediprog SF100, FT2232-based SPI programmers and more.

More details at flashrom.org and in the list of supported chips, chipsets, baords, and programmers.

I uploaded an svn version slightly more recent than 0.9.2 to Debian unstable, which should reach Debian testing (and Ubuntu I guess) soonish.

coreboot / flashrom in GSOC 2010 -- student application deadline today!

Uwe Hermann — Fri, 09 Apr 2010 02:42:22 +0200

As you may know there's a Google Summer of Code program again this year.

The deadline for student applications is April 9th at 19:00 UTC, so if you're a student and you want to work on a coreboot (open-source BIOS / PC firmware) or flashrom (open-source BIOS chip flasher) project, please apply in time.

The following coreboot/flashrom GSOC project ideas have been proposed so far (but you can also suggest your own ideas, of course):

Infrastructure for automatic code checking
TianoCore on coreboot
coreboot port to Marvell ARM SOCs with PCIe
coreboot port to AMD 800 series chipsets
coreboot mass-porting to AMD 780 series mainboards
coreboot panic room
coreboot cheap testing rig
coreboot GeodeLX port from v3 to v4
Drivers for libpayload
Board config infrastructure
Refactor AMD code
Payload infrastructure
flashrom: Multiple GUIs for flashrom
flashrom: Recovery of dead boards and onboard flash updates
flashrom: SPI bitbanging hardware support
flashrom: Generic flashrom infrastructure improvements
flashrom: Laptop support

See this wiki page for why and how to apply for a coreboot/flashrom project.

Miro 3.0 released, Debian package available

Uwe Hermann — Tue, 06 Apr 2010 23:27:06 +0200

Yep, the new major release, Miro 3.0, of the cross-platform Internet RSS audio/video aggregator and player has been released.

Please check the release notes and the feature list for details. Overall more than 139 issues have been fixed since the last 2.x series release. The most notable changes are probably the dropping of xine support upstream (gstreamer is used now for all video/audio on Linux) and the introduction of subtitle support.

I have uploaded a new Miro 3.0 Debian package to unstable recently (which have been a delayed a bit due to Debian server issues), by now it should be available from most mirrors. Let me know if there are any issues...

libopenstm32 - a Free Software firmware library for STM32 ARM Cortex-M3 microcontrollers

Uwe Hermann — Thu, 04 Mar 2010 14:20:36 +0100

I guess it's time to finally announce libopenstm32, a Free Software firmware library for STM32 ARM Cortex-M3 microcontrollers me and a few other people have been working on in recent weeks. The library is licensed under the GNU GPL, version 3 or later (yes, that's an intentional decision after some discussions we had).

The code is available via git:

 $ git clone git://libopenstm32.git.sourceforge.net/gitroot/libopenstm32/libopenstm32
 $ cd libopenstm32
 $ make

Building is done using a standard ARM gcc cross-compiler (arm-elf or arm-none-eabi for instance), see the summon-arm-toolchain script for the basic idea about how to build one.

The current status of the library is listed in the wiki. In short: some parts of GPIOs, UART, I2C, SPI, RCC, Timers and some other basic stuff works and has register definitions (and some convenience functions, but not too many, yet). We're working on adding support for more subsystems, any help with this is highly welcome of course! Luckily ARM stuff (and especially the STM32) has pretty good (and freely available) datasheets.

We have a few simple example programs, e.g. for the Olimex STM32-H103 eval board (see photo). JTAG flashing can be done using OpenOCD, for example.

Feel free to join the mailing lists and/or the #libopenstm32 IRC channel on Freenode.

The current list of projects where we plan to use this library is Open-BLDC (an Open Hardware / Free Software brushless motor controller project by Piotr Esden-Tempski), openmulticopter (an Open Hardware / Free Software quadrocopter/UAV project), openbiosprog (an Open Hardware / Free Software BIOS chip flash programmer I'm in the process of designing using gEDA/PCB), and probably a few more.

If you plan to work on any new (or existing) microcontroller hardware- or software-projects involving an STM32 microcontroller, please consider using libopenstm32 (it's the only Free Software library for this microcontroller family I know of) and help us make it better and more complete. Thanks!

How to setup an encrypted USB-disk software-RAID-1 on Debian GNU/Linux using mdadm and cryptsetup

Uwe Hermann — Thu, 25 Feb 2010 18:10:57 +0100

This is what I set up for backups recently using a cheap USB-enclosure which can house 2 SATA disks and shows them as 2 USB mass-storage devices to my system (using only one USB cable). Without any further introduction, here goes the HOWTO:

First, create one big partition on each of the two disks (/dev/sdc and /dev/sdd in my case) of the exact same size. The cfdisk details are omitted here.

  $ cfdisk /dev/sdc
  $ cfdisk /dev/sdd

Then, create a new RAID array using the mdadm utility:

  $ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1

The array is named md0, consists of the two devices (--raid-devices=2) /dev/sdc1 and /dev/sdd1, and it's a RAID-1 array, i.e. data is simply mirrored on both disks so if one of them fails you don't lose data (--level=1). After this has been done the array will be synchronized so that both disks contain the same data (this process will take a long time). You can watch the current status via:

  $ cat /proc/mdstat
  Personalities : [raid1]
  md0 : active raid1 sdd1[1] sdc1[0]
        1465135869 blocks super 1.1 [2/2] [UU]
        [>....................]  resync =  0.0% (70016/1465135869) finish=2440.6min speed=10002K/sec
  unused devices:

Some more info is also available from mdadm:

  $ mdadm --detail --scan
  ARRAY /dev/md0 metadata=1.01 name=foobar:0 UUID=1234578:1234578:1234578:1234578

  $ mdadm --detail /dev/md0
  /dev/md0:
          Version : 1.01
    Creation Time : Sat Feb  6 23:58:51 2010
       Raid Level : raid1
       Array Size : 1465135869 (1397.26 GiB 1500.30 GB)
    Used Dev Size : 1465135869 (1397.26 GiB 1500.30 GB)
     Raid Devices : 2
    Total Devices : 2
      Persistence : Superblock is persistent
      Update Time : Sun Feb  7 00:03:21 2010
            State : active, resyncing
   Active Devices : 2
  Working Devices : 2
   Failed Devices : 0
    Spare Devices : 0
   Rebuild Status : 0% complete
             Name : foobar:0  (local to host foobar)
             UUID : 1234578:1234578:1234578:1234578
           Events : 1
      Number   Major   Minor   RaidDevice State
         0       8       33        0      active sync   /dev/sdc1
         1       8       49        1      active sync   /dev/sdd1

Next, you'll want to create a big partition on the RAID device (cfdisk details omitted)...

  $ cfdisk /dev/md0

...and then encrypt all the (future) data on the device using dm-crypt+LUKS and cryptsetup:

  $ cryptsetup --verbose --verify-passphrase luksFormat /dev/md0p1
  Enter your desired pasphrase here (twice)
  $ cryptsetup luksOpen /dev/md0p1 myraid

After opening the encrypted container with cryptsetup luksOpen you can create a filesystem on it (ext3 in my case):

  $ mkfs.ext3 -j -m 0 /dev/mapper/myraid

That's about it. In future you can access the RAID data by using the steps below.

Starting the RAID and mouting the drive:

  $ mdadm --assemble /dev/md0 /dev/sdc1 /dev/sdd1
  $ cryptsetup luksOpen /dev/md0p1 myraid
  $ mount -t ext3 /dev/mapper/myraid /mnt

Shutting down the RAID:

  $ umount /mnt
  $ cryptsetup luksClose myraid
  $ mdadm --stop /dev/md0

That's all. Performance is shitty due to all the data being shoved out over one USB cable (and USB itself being too slow for these amounts of data), but I don't care too much about that as this setup is meant for backups, not performance-critical stuff.

Update 04/2011: Thanks to Bohdan Zograf there's a Belorussian translation of this article now!

FOSDEM 2010: coreboot and flashrom devroom and talks

Uwe Hermann — Sat, 06 Feb 2010 12:31:20 +0100

Quick public service announcement (which probably comes a bit too late, sorry):

There's a coreboot developer room at this year's FOSDEM (Free and Open-Source Software Developer's European Meeting), which starts roughly... um... today. In 20 minutes, actually. Unfortunately I cannot be there, hopefully there will be video archives of the talks. If you're at FOSDEM already, here's the list of talks:

Sat 13:00-14:00 coreboot introduction (Peter Stuge)
Sat 14:00-15:00 coreboot and PC technical details (Peter Stuge)
Sat 15:00-16:00 ACPI and Suspend/Resume under coreboot (Rudolf Marek)
Sat 16:00-17:00 coreboot board porting (Rudolf Marek)
Sat 17:00-18:00 Flashrom, the universal flash tool (Carl-Daniel Hailfinger)
Sat 18:00-19:00 Flash enable BIOS reverse engineering (Luc Verhaegen)

Highly recommended stuff if you're interested in an open-source BIOS and/or open-source, cross-platform flash EEPROM programmer software.

Roda RK886EX (Rocky III+) first laptop/notebook being supported by coreboot

Uwe Hermann — Tue, 26 Jan 2010 12:43:00 +0100

Only few days ago a long-standing bug in coreboot, the Free Software x86 BIOS/fimware project, has been fixed: Adding support for a laptop/notebook.

The code was developed by coresystems GmbH (thanks a lot!). Quoting from the announcement:

coreboot® is running on a multitude of different computers, ranging from tiny embedded systems as small as the palm of your hand over desktop and server systems to super computers with thousands of nodes. However, one might say that in the area of mobile computers coreboot has to catch up, compared to its support of other devices.

Thus, I am especially glad to announce that coresystems GmbH is releasing coreboot® for the Roda RK886EX a.k.a Rocky III+ notebook today. It's a rugged notebook, protected against shock, vibration, dust and humidity:
http://www.roda-computer.com/en/products/notebooks/rocky-iii-rk886ex.html

We have been testing various Linux distributions as well as Windows XP and Windows 7 booting on this nice notebook.

I want to sincerely thank those who made this project possible with their funding:

secunet Security Networks AG

Bundesamt für Sicherheit in der Informationstechnologie (Federal Office for Information Security, BSI)

A big thank you also goes to everyone who worked with coresystems on this project.

The committed patch series includes improved support for the Intel i945 / ICH7 chipset (which was also written by coresystems), the SMSC LPC47N227 Super I/O, the Texas Instruments Cardbus+Firewire bridge TI PCI7420, and finally the Renesas M3885x Embedded Controller (EC).

Btw, the latter, the so-called embedded controller (sometimes integrated in the Super I/O, sometimes it's an extra chip) is one of the major problems for coreboot support on laptops. They are almost always undocumented (i.e., no public datasheets are available), but they have low-level control over power/battery management, early power-up sequence, and often include keyboard controller functionality and other important stuff. Luckily, for this notebook an EC datasheet is available. Checkout the coreboot EC support code for the Renesas M3885x for an impression of what this stuff is all about.

Anyway, there is hope that this laptop will only be the first in a row of multiple supported ones in the future. Interested developers and contributors are of course always welcome on the coreboot mailing list :-)

Note to self: Missing lvm2 and cryptsetup packages lead to non-working initrd very, very soon

Uwe Hermann — Tue, 24 Nov 2009 00:00:14 +0100

I recently almost died from a heart attack because after a really horrible crash (don't ask), Debian unstable on my laptop wouldn't boot anymore. The system hung at "Waiting for root filesystem...", and I was in panic mode as I feared I lost all my data (and as usual my backups were waaay too old).

At first I was suspecting that something actually got erased or mangled due to the crash, either at the dm-crypt layer, or the LVM layer, or the ext3 filesystem on top of those. After various hours of messing with live CDs, cryptsetup, lvm commands (such as pvscan, pvs, vgchange, vgs, vgck) and finally fsck I still had not managed to successfully boot my laptop.

I finally was able to boot by changing the initrd from initrd.img-2.6.30-2-686 to initrd.img-2.6.30-2-686.bak in the GRUB2 menu (at boot-time), at which point it was clear that something was wrong with my current initrd. A bit of debugging and some initrd comparisons revealed the cause:

Both, the cryptsetup and lvm2 packages were no longer installed on my laptop, which made all update-initramfs invokations (e.g. upon kernel package updates) create initrds which did not contain the proper dm-crypt and lvm functionality support. Hence, no booting for me. I only noticed because of the crash, as I usually do not reboot the laptop very often (two or three times per year maybe).

Now, as to why those packages were removed I have absolutely no idea. I did not remove them knowingly, so I suspect some dist-upgrade did it and I didn't notice (but I do carefully check which packages dist-upgrade tries to remove, usually)...

coreboot on the cover of the Linux Journal

Uwe Hermann — Fri, 16 Oct 2009 20:29:00 +0200

Nice coreboot news — the Free Software x86 firmware ("BIOS") is featured on the cover of issue 186 of the Linux Journal.

Anton Borisov's article Coreboot at Your Service! explains the basic ideas behind coreboot, how to build an image for your board, which payloads are available and how they are used, e.g. GRUB2, SeaBIOS if you need legacy BIOS callbacks (e.g. for booting Windows), Etherboot/GPXE, or more fun stuff such as space invaders or tint (a tetris clone) in your flash ROM chip...

If you read the article and think the build process is a bit complicated and ugly, do not despair! We're currently in the process of converting the whole coreboot code base to use kconfig (the widely-known configuration tool used by the Linux kernel, busybox, and other projects), so in the very near future the whole process for building a coreboot image will work like this:

  $ make menuconfig
  $ make

Flashing the image can then be done using an EEPROM programmer and/or via the user-space utility flashrom (available for Linux, Mac OS X, FreeBSD, etc.)...

It's nice to see that coreboot is getting more and more coverage in "mainstream" media and is growing both in number of deployments and in number of supported chipsets and boards.

We are desperately in need of more developers though, there are just way too many chipsets, boards, and datasheets out there; we're happy about every patch and every new tester or developer who likes to mess with code that runs in the very first few (micro)seconds after power-on.

If you think kernel hacking and related low-level development is nice, you might also be interested in writing code where there's no RAM yet (as coreboot has to initialize it), there's no serial port for debugging (coreboot has to initialize it), no PCI devices have been set up, most of your auxiliary hardware is not yet up (ethernet NIC, parallel port, audio, IDE, SATA, USB, you name it). It's a fun environment to work in and you'll learn a lot about PC hardware, even if you (so far) thought you knew everything there is to know.

Feel free to join us on the mailing list or on IRC in #coreboot on Freenode.

Using CRM114 for spam filtering on Debian GNU/Linux

Uwe Hermann — Tue, 22 Sep 2009 15:10:04 +0200

I've been using CRM114 as spam filter for a while now, and I'm quite happy with it. Due to bug #529720 though (incompatible upstream file format changes) I decided to start my setup from scratch with a recent CRM114 version from unstable. Here's a short HOWTO, hope it's useful for others.

First you need to install crm114 and set up a few files in your $HOME directory.

  $ sudo apt-get install crm114
  $ mkdir ~/.crm114
  $ cd ~/.crm114
  $ cp /usr/share/doc/crm114/examples/mailfilter.cf.gz .
  $ gunzip mailfilter.cf.gz
  $ cp /usr/share/crm114/mailtrainer.crm .
  $ touch rewrites.mfp priolist.mfp

Edit ~/.crm114/mailfilter.cf and set the following variables (some are optional, but that's what I currently use):

  :spw: /mypassword/
  :add_verbose_stats: /no/
  :add_extra_stuff: /no/
  :rewrites_enabled: /no/
  :spam_flag_subject_string: //
  :unsure_flag_subject_string: //
  :log_to_allmail.txt: /no/

The :log_to_allmail.txt: /no/ option should probably stay at "yes" for the first few days until you have tested your setup and everything works OK. The ~/.crm114/allmail.txt file will contain all your mails, in case something goes wrong.

Now set up empty spam and nonspam files like this:

  $ cssutil -b -r spam.css
  $ cssutil -b -r nonspam.css

Test the setup by invoking mailreaver.crm as follows, typing some test text and then pressing CTRL+d:

  $ /usr/share/crm114/mailreaver.crm -u ~/.crm114
  test
  [CTRL-d]
  ** ACCEPT: CRM114 PASS osb unique microgroom Matcher **
  CLASSIFY fails; success probability: 0.5000  pR: 0.0000
  Best match to file #0 (nonspam.css) prob: 0.5000  pR: 0.0000
  Total features in input file: 8
  #0 (nonspam.css): features: 1, hits: 0, prob: 5.00e-01, pR:   0.00
  #1 (spam.css): features: 1, hits: 0, prob: 5.00e-01, pR:   0.00
  X-CRM114-Version: 200904023-BlameSteveJobs ( TRE 0.7.6 (BSD) ) MF-35EB8B9A [pR: 0.0000]
  X-CRM114-CacheID: sfid-20090920_151224_574131_D290E589
  X-CRM114-Status: UNSURE (0.0000) This message is 'unsure'; please train it!

The output should look similar to the above. If there are errors instead, you should check your settings in ~/.crm114/mailfilter.cf.

Now you have to setup a procmail rule for crm114:

  :0fw: crm114.lock
  | /usr/share/crm114/mailreaver.crm -u /home/uwe/.crm114

  :0:
  * ^X-CRM114-Status: SPAM.*
  IN.spam-crm114

In my case this rule is also followed by a spamassassin rule, so all my mail goes through two different spam filters (will look into dspam and bogofilter also I guess, the more the better).

Finally, in .muttrc I have the following configs so I can press SHIFT+x to mark a mail as spam, and SHIFT+h to mark it as non-spam (ham).

macro index X '| formail -I X-CRM114-Status -I X-CRM114-Action -I X-CRM114-Version | /usr/share/crm114/mailreaver.crm -u /home/uwe/.crm114/ --spam'
macro index H '| formail -I X-CRM114-Status -I X-CRM114-Action -I X-CRM114-Version | /usr/share/crm114/mailreaver.crm -u /home/uwe/.crm114/ --good'
macro pager X '| formail -I X-CRM114-Status -I X-CRM114-Action -I X-CRM114-Version | /usr/share/crm114/mailreaver.crm -u /home/uwe/.crm114/ --spam'
macro pager H '| formail -I X-CRM114-Status -I X-CRM114-Action -I X-CRM114-Version | /usr/share/crm114/mailreaver.crm -u /home/uwe/.crm114/ --good'

Important: crm114 is most effective if you start with empty CSS files (as shown above) and only train it by marking mails as spam/ham when it gets them wrong. The process will take a few hours or maybe a day (depending on how many mails per day you get), then the misclassification rate gets very low...

Update 2009-09-23: Changed --spam/--nonspam to the correct options for mailreaver/mailtrainer, --spam/--good.

Help add subtitle support for Miro

Uwe Hermann — Sun, 20 Sep 2009 21:55:44 +0200

If you ever wanted to support an open-source project but you are not a programmer, here's one (of many possible) ways to help:

The Miro project (Internet TV / Video and Audio Podcast application for Linux, Windows, and Mac OS X) is seeking for pledges/donations that will be used to add subtitles support in Miro.

To quote from the announcement:

We’re hoping to build real subtitle support into Miro in the next couple months, but we need your help! So we’ve started a Kickstarter project to raise $1,000 to develop this feature for Miro on all three platforms: Windows, Mac, and Linux. Can you pledge to help make it happen? One of the great things about the Kickstarter model is that unless we can reach $1,000, your pledge won’t be charged.
[...]
(if you live in the United States, donations are tax deductible — we are a 501c3 non-profit)

There are 11 days left to make a pledge.

A simple DLP-USB1232H based JTAG programmer with OpenOCD support

Uwe Hermann — Sat, 12 Sep 2009 11:00:59 +0200

Here's a quick introduction to using a cheap FTDI FT2232H based module (left-hand side on the photo) as a JTAG programmer together with the OpenOCD JTAG software for ARM and MIPS devices. The module I am using for thіs purpose is a DLP Design DLP-USB1232H, which is available from various sources (Digikey, Mouser, Saelig, and probably others) for 20-30 bucks plus shipping, depending on where you live.

By properly connecting the correct pins of the DLP-USB1232H to the target JTAG
device (I used an Olimex STM32-H103 eval board for testing) you can easily abuse the DLP-USB1232H as JTAG programmer. As I chose the proper DLP-USB1232H GPIOs for the TRST and (S)RST pins, OpenOCD even worked out of the box, without having to change a single line of code.

The only thing that's required is to provide OpenOCD with an interface config file that uses the usbjtag "layout". I have already submitted that config file upstream, I guess it should be merged soonish.

The usage is then pretty simple:

  $ openocd -f interface/dlp-usb1232h.cfg -f board/olimex_stm32_h103.cfg

And in another xterm:

  $ telnet localhost 4444
  > init
  > reset halt
  > flash write_image erase fancyblink.bin 0x08000000
  > reset

This flashes the given fancyblink.bin image onto the STM32-H103 eval board via the DLP-USB1232H JTAG programmer, where fancyblink.bin is an example program from my libopenstm32 project (that aims to create a full-blown firmware library for ST STM32 microcontrollers, similar to what avr-libc does for AVRs). Contributions for libopenstm32 (license is GPLv3 or later) are highly welcome btw., hint hint...

  $ git clone git://libopenstm32.git.sourceforge.net/gitroot/libopenstm32/libopenstm32

Full schematics, datasheets, and detailed instructions for the JTAG programmer are available from a small page I created in my Random Projects wiki, which is intended for the various smaller projects I'm working on that don't warrant getting their own domain, wiki, etc:

http://randomprojects.org/wiki/DLP-USB1232H_and_OpenOCD_based_JTAG_adapter

The Random Projects wiki is open-for-all btw, feel free to use it for any freeish, software or hardware projects of your own if you want.

Anyway, the DLP-USB1232H is a really nice device as it can also be used for many other purposes, such as USB-to-Serial or SPI BIOS chip programming, but more on that in another blog post...

identi.ca - a microblogging service based on Free Software, AGPL, and Creative Commons

Uwe Hermann — Sun, 06 Sep 2009 19:09:11 +0200

After a long time of ignoring (or at least not using) micro-blogging services such as Twitter, I recently tried the Free-Software based identi.ca service, and I'm beginning to like it.

The choice of service was pretty obvious — while Twitter uses proprietary software and has custom Terms of Service, identi.ca is based on software under the GNU Affero General Public License, and the contents are CC-BY 3.0 licensed.

The code behind identi.ca is called Laconica (recently renamed to StatusNet) and is hosted at gitorious:

 $ git clone git://gitorious.org/laconica/mainline.git

My account details are available under http://identi.ca/uwehermann, where I'm posting smaller announcements and notes about random technical stuff I'm working on (slightly more regularly than in this blog). Sometimes I use the web interface for posting, but using the Jabber integration available at identi.ca is even more convenient. You can both be notified of new posts ("dents") in real time via Jabber, as well as post your own dents from within your Jabber client, which is nice.

identi.ca seems to become more popular every day, which will hopefully make the proprietary Twitter pretty much irrelevant sooner or later.

Open-Source software for LightScribe CDs and DVDs?

Uwe Hermann — Thu, 03 Sep 2009 15:14:54 +0200

Dear Lazyweb,

is there any Free Software utility for putting those nice logos/images on LightScribe CDs or DVDs? I'm considering buying such a CD/DVD burner, but only if there's open-source software to control the device. I guess burning CDs/DVDs should be no problem using wodim/cdrecord, but adding images as labels on the CD/DVD is likely not possible without special software.

I know about the LightScribe Linux software (which is binary-only and not open-source, it seems) and LaCie LightScribe Labeler for Linux (which only creates labels but does not write them to the CD/DVD, and is not open-source either, I think).

Anyone aware of a Free Software utility for this? Or at least a public specification/datasheet which could be used for creating one? I might even be willing to join development if datasheets are available.

Qi Hardware: Freedom Redefined - New Open Hardware company to ship Ben NanoNote device in fall 2009

Uwe Hermann — Sat, 29 Aug 2009 19:47:56 +0200

I recently stumbled over a neat new Open Hardware and Free Software friendly company — Qi Hardware — founded by former OpenMoko developers.

To quote from the website:

Qi Hardware, founded on the belief in open hardware, produces mass market quality hardware applying free software principles to consumer electronics. The three fundamental elements in our development are copyleft hardware, upstream kernels and community driven software.

They have put up a timeline for upcoming products, where the 本 NanoNote™ (Ben NanoNote™) — a fully open multifunction ultra small form factor computing device — is the first entry product that is supposed to ship in fall 2009.

The Ben NanoNote is based on an Ingenic SoC (336 MHz XBurst Jz4720 MIPS-compatible CPU) with 3.0” color TFT (320x240), 2GB NAND flash, 32 MB SDRAM, SDHC microSD, micro-USB 2.0. The whole device, including the 850mAh Li-ion battery, weighs only 126g. Detailed specs are available.

Their currently planned setup includes a Linux kernel, u-boot, and OpenWRT as software basis. Personally, I'd like to see a stock Debian running on the hardware sooner or later, of course. The 2GB of flash and 32MB of RAM should be fine for a small Debian system (for instance, my NSLU2 runs off a 1GB thumb drive and has 32MB RAM, and is still very useful).

The code is all GPL'd and available from various git repos, hardware will be CC-BY-SA 3.0 licensed, and they try to use Free Software design and development tools also, including KiCAD for schematics and PCB layout, and probably HeeksCAD as CAD tool for mechanical stuff.

I'm really tired of seeing more and more self-proclaimed "Open Hardware" projects that often don't even mention any license for their schematics and PCBs, or use crappy, self-invented "open" licenses that are not even remotely open in any way. Probably even worse, many hardware related projects use closed-source, proprietary electronic design tools such as EAGLE or OrCAD, thereby ruining the whole project from the beginning by forcing everyone who likes to contribute or adapt the hardware to use non-free software. That's why I was really happy to see the Qi people thrive to use open tools from the beginning! I hope to see more hardware projects use KiCAD or gEDA/PCB for their designs in future...

Converting Mailman "Gzip'd Text" archive files to proper mbox files

Uwe Hermann — Mon, 24 Aug 2009 01:31:34 +0200

Mailman archives are often only available in the pretty useless "Gzip'd Text" format, which you cannot easily download and view locally (and threaded) in a MUA such as mutt. But that is exactly what I want to do from time to time (e.g. because I want to read the discussions of the past weeks on mailing lists where I'm newly subscribed).

After some searching I found one way to do it which I stripped down to my needs:

 $ cat mailman2mbox
 #!/usr/bin/perl
 while (<STDIN>) {
   s/^(From:? .*) (at|en) /\1\@/;
   s/^Date: ([A-Z][a-z][a-z]) +([A-Z][a-z][a-z]) +([0-9]+) +([0-9:]+) +([0-9]+)/Date: \1, \3 \2 \5 \4 +0000/; 
   print;
 }

Example run on some random mail archive:

 $ wget http://participatoryculture.org/pipermail/develop/2009-August.txt.gz
 $ gunzip 2009-August.txt.gz
 $ ./mailman2mbox < 2009-August.txt > 2009-August.mbox

You can then view the mbox as usual in mutt:

 $ mutt -f 2009-August.mbox

Suggestions for a simpler method to do this are highly welcome. Maybe some mbox related Debian package already ships with a script to do this?

AMD RS780 chipset documentation released, coreboot support upcoming

Uwe Hermann — Thu, 20 Aug 2009 17:59:08 +0200

Good news for kernel hackers, and especially coreboot developers like me: AMD has released the chipset documentation for the RS780 chipset, including the BIOS Developer's Guide. And these documents are being released freely and openly to the public, no NDAs required, which is great!

Quoting from the original announcement on the coreboot-announce mailing list:

The coreboot community, which includes government organizations, corporations, research labs and individuals from around the world, is very excited to expand on our existing and decade-long collaboration with AMD. This collaboration has, over the years, resulted in the inclusion of coreboot into everything from some of the largest AMD-based supercomputers in the world to some of the smallest embedded systems.

Together with the recent SB700/SB710/SB750 documentation release, the Developer Guide release for the RS780 family of Integrated Chipset/Graphics Processors enables the coreboot community to support any board with AMD chipsets out there, from embedded to enthusiast desktop and high-end server boards.

This new release once again demonstrates AMD's commitment to open standards and software that provides an improved user experience and Total Cost of Ownership for users in every walk of life. One cornerstone of this openness is the availability of documentation without NDA, enabling everyone to contribute.

[...]

Coreboot is open source, so every interested developer or user can modify, tweak and extend it to their heart's content.

An additional benefit of this documentation release is flashrom support for all AMD chipsets which enables users to reflash their BIOS/firmware/coreboot from within Linux and *BSD without rebooting.

Coreboot code for the SB700 and 780 chipset family is already being worked on by Zheng Bao at AMD in his spare time and the coreboot community is happy to work with him on finishing and integrating the code into the official coreboot codebase.

We'd like to thank Sharon Troia at AMD for making these documentation releases possible.

The exact download URLs are listed at http://www.coreboot.org/Datasheets.

How to run 65535 web servers on a single laptop

Uwe Hermann — Wed, 19 Aug 2009 14:36:03 +0200

OK, so here's what crazy computer geeks come up with when they're bored of just sitting in the subway and staring out of the window.

Web servers usually run on port 80. TCP/UDP ports range from 1 to 65535 (port 0 is reserved). You can run multiple web servers on different ports at the same time... Do you think what I think?

Well, first you need a web server (duh). I decided to use lighttpd, as it's said to be small and memory-efficient (which sounded pretty important given what I was trying to do). Apache would probably not be a good choice here. Mind you, I have not done any benchmarks at all, I'm just guessing...

  $ apt-get install lighttpd

Then, I wrote a little shell script containing a loop, which invoked lighttpd on port 1, 2, 3, 4, ..., 65535. That's it ;)

  #!/bin/bash
  TMPDIR=/tmp
  CONFFILE="server.document-root       = \"/var/www/\"
           index-file.names           = ( \"index.html\" )"
  for ((i = 1; i < 300; i = i + 1)) do
    echo "+++ Starting web server on port $i"
    echo $CONFFILE > $TMPDIR/lighttpd.conf
    echo "server.port = $i" >> $TMPDIR/lighttpd.conf
    /usr/sbin/lighttpd -f $TMPDIR/lighttpd.conf
    rm -f $TMPDIR/lighttpd.conf
  done

I'm sure this can be optimized a lot, but it's sufficient for now, and it works.

You can test any of the web servers by running "wget http://localhost:3556/" (for example). You can kill them all with killall lighttpd. If you already run some other daemons on some ports, you cannot start a lighttpd on the same port, so you'll end up with fewer than 65535 servers.

In case you try this on your hardware, make sure you have lots of RAM and lots of swap. Don't run this on production hardware. Feel free to post your experiences in the comments.