Elastic Sheep

Because elasticdog was already taken

Elastic Sheep header image 1

Serial Port Bluetooth module

April 16th, 2011 · Uncategorized

I recently ordered a couple of serial Bluetooth module on Ebay.

You can find the same board with different names and different flash memories on the net but they all are based on the same design. The main chip is a CSR BC417143 a.k.a. BlueCore4-External connected to a 8Mbit parallel Flash memory containing the firmware.

Here is the system architecture of the chip from the CSR datasheet:

The BlueCore4-Ext is a generic Bluetooth 2.0 EDR chip with a bunch of interfaces. The USB interface allows to use it in a USB BT dongle design. When integrating it in a microcontroller-based design, you could use the serial interface instead. The SPI interface allows the programming and configuration of the chip using CSR tools.
The provided firmware implements a Serial Port Profile based on a RFCOMM stack. But in theory this hardware could run other firmwares from CSR, for example a HCI stack to connect the chip as a generic BT USB dongle.

The module hardware is very small. The footprint is made to be soldered on another PCB. A serial breakout board is available with RX/TX connections and a 5V to 3.3V regulator. As I would like to tinker with the module to investigate its capabilities, I instead designed a breakout board allowing access to all the pins on a standard header.

I just ordered a batch of breakout boards from Olimex. I should receive them in a few weeks. If anyone is interested to get one, leave me a message. [Update 2011-05-06] Ordering informations are on the Shop page.

Update 2011-05-02

Here is the module datasheet provided by hongkong_electronics
BC4_Bluetooth Module Datasheet.zip

→ 8 CommentsTags:·

My blog mentioned in Open Silicium magazine

January 29th, 2011 · Uncategorized

Open Silicium is a new french magazine about open source and embedded system/hardware. It is published by the editor of Linux Magazine France. It is an interesting reading with eclectic articles that does not hesitate to dig into the hardware side.

But I think some of the articles may be difficult to grasp without a background in computer/electrical engineering. It reminds me of the magazines I was reading 15 years ago trying and often failing to make sense of articles about Turbo Pascal programming, entering program from paper to the computer. When the program worked you didn’t know why, and when it didn’t work you didn’t know why either!

What I was missing was good fundamentals on software and computer engineering. But at that time, the magazines where the only source of information I had, with local libraries very poorly filled with computer programming resources.

Now that the training knowledge is widespread and easily accessible through Internet, this kind of magazine is still useful to provide insight about different environment/tools/techniques. But if you are a beginner, you need to expect digging about the subjects you are interested in on your own.

Anyway thanks to the buzz around the Teensy2 and the PSGroove projet, I got a mention in this first issue. So thanks Open Silicium and keep up the good work!

→ No CommentsTags:

Adding alsa audio support to a Buildroot-based system

January 28th, 2011 · Uncategorized

I have tested the building of a basic Linux system with Buildroot. I would like now to add audio support to this system with mp3 decoding capabilities.

The mp3 decoding will be handled by the mpg123 application. The decoded audio playback will go through the alsa-lib userland interface that communicates with the alsa kernel subsystem.

The target hardware is the Versatile/PB platform emulated in QEMU.

System base configuration

The Builroot base configuration is the same as in my previous post:

  • Target Architecture: arm
  • Target Architecture Variant: arm926t
  • Target ABI: EABI
  • Toolchain/Kernel Headers: 2.6.36.x (I could specify a path to my kernel sources)
  • Package Selection for the Target/Busybox 1.17.x
  • Target Fileystem Options/cpio the root filesystem and Compression method: gzip

I select those options in the Buildroot configuration menu and then save the resulting config file in the configs directory.

$> cd buildroot-2010.11
$> make menuconfig
$> cp .config configs/versatilepb926_defconfig

The saved configuration can be directly applied from make if you want to return to a known state:

$> make versatilepb926_defconfig
#
# configuration written to [...]/buildroot-2010.11/.config
#

Adding the alsa and mpg123 support

To enable the alsa and mpg123 support:

  • Toolchain/Enable large file (file > 2GB) support
  • Package Selection for the target/Audio and Video libraries
    • alsa-lib
    • alsa-utils / aplay
    • mpg123

aplay is useful to check if simple WAV files can be played by the system. The Large File support is a dependency requirement from the alsa-utils package.

Adding the /dev/snd/* entries

By default, Buildroot does not add create audio device files. It uses the default device table that is located in target/generic/device_table.txt.

To add the /dev/audio and /dev/snd/* device files, I create a new device table file derived from the generic one adding the entries required by Alsa: target/generic/alsa_device_table.txt.

Then I change the selected device table in the Buildroot configuration:

  • Target Filesystem options/Path to the device table
    • target/generic/alsa_device_table.txt

Here is the updated audio section of the device table:

# Audio stuff
/dev/audio	c	666	0	29	14	4	-	-	-
#/dev/audio1	c	666	0	29	14	20	-	-	-
/dev/dsp	c	666	0	29	14	3	-	-	-
#/dev/dsp1	c	666	0	29	14	19	-	-	-
#/dev/sndstat	c	666	0	29	14	6	-	-	-
/dev/mixer	c	666	0	29	14	0	-	-	-
/dev/snd	d	755	0	29	-	-	-	-	-
/dev/snd/controlC0	c	666	0	29	116	0	-	-	-
/dev/snd/pcmC0D0c	c	666	0	29	116	24	-	-	-
/dev/snd/pcmC0D0p	c	666	0	29	116	16	-	-	-
/dev/snd/seq	c	666	0	29	116	1	-	-	-
/dev/snd/timer	c	666	0	29	116	33	-	-	-

My patched file for buildroot-2010.11: alsa_device_table.txt

Sorry I don’t remember the original source from where I copied those major/minor device numbers.

Saving the updated configuration

$> cp .config configs/versatilepb926_alsa_defconfig

Copying audio files in the root filesystem

Audio files can be directly copied in the output/target/root directory of Buildroot for test purposes.

When running make again, buildroot includes those files in the CPIO archive of the rootfs.

→ 7 CommentsTags:·····

Building and emulating a basic ARM Linux system

January 17th, 2011 · Uncategorized

Here are my notes about the process I used to build a basic ARM linux system testable with QEMU. This knowledged has been gathered from the balau82.wordpress.com blog and from a Pierre Ficheux’s article introducing BuildRoot and published in Linux Magazine special issue n°47.

Here is a summary of the environment I will use:

  • Ubuntu 10.04 development host
  • ELDK 4.2 ARM cross compilation toolchain
  • Linux kernel 2.6.37
  • BuildRoot 2010.11
  • QEMU 0.13
  • Emulated hardware target: Versatile/PB development platform

Installing a cross compilation toolchain

The Embedded Linux Development Toolkit (ELDK) contains a GCC cross-compilation toolchain and a number of pre-built target tools and libraries. It is available for ARM, PPC and PPC64 targets (Documentation and ELDK 4.2 ARM ISO).

The ELDK 4.2 toolchain is EABI (the ELDK 4.1 was OABI).

A full install of the ELDK 4.2 development tools and target components for the ARM target require about 2GB of disk space. Only installing the development tools will require just 71MB. To avoid installing the target components you need to empty the etc/rpm_arm.list file provided in the ISO distribution.

# Mount the ISO and copy its content in the current directory
$> sudo mkdir /mnt/tmp
$> sudo mount –o loop –t iso9660 arm-2008-11-24.iso /mnt/eldk42
$> cp –r /mnt/eldk42 .
$> unmount /mnt/eldk42

# Patch the rpm_arm.list file
$> cd eldk42/etc
$> mv rpm_arm.list rpm_arm.list.original
$> touch rpm_arm.list
$> cd ..

# Install the toolchain
$> sudo mkdir –p /opt/ELDK42/arm
$> ./install –d /opt/ELDK42/arm arm

The toolchain is installed in /opt/ELDK42/arm.

Cross compilation environment variables

I use a shell script to set default environment variables required to cross compile the kernel.

set_env_arm.sh

#!/bin/sh
PATH=/opt/ELDK42/arm/usr/bin:$PATH
ARCH=arm
CROSS_COMPILE=arm-linux-
export PATH ARCH CROSS_COMPILE

Execute this script before any call to the kernel makefile.

Kernel configuration and build

To use the default kernel configuration for the Versatile/PB platform and then access the configuration menu:

$> curl –O http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.37.tar.bz2
$> tar xjvf linux-2.6.37.tar.bz2
$> cd linux-2.6.37
$> ../set_env_arm.sh
$> make versatile_defconfig
$> make menuconfig

In the configuration menu, I modify the following settings:

  • Disable the module support
  • Kernel Features / Use the ARM EABI

The ARM EABI option is required because of the ELDK 4.2 toolchain configuration.

Then to build the kernel:

$> make

The resulting kernel image is in the file arch/arm/boot/zImage.

Building QEMU from the sources

Compiling QEMU from source requires the following packages to be installed in Ubuntu: zliblg-dev libsdl-dev.

$> curl –O http://wiki.qemu.org/download/qemu-0.13.0.tar.gz
$> tar xzvf qemu-0.13.0.tar.gz
$> cd qemu-0.13.0
$> ./configure --target-list=arm-softmmu --enable-sdl
$> make

The generated executable is arm-softmmu/qemu-system-arm.

To get a list of the supported machines:

$> arm-softmmu/qemu-system-arm –M ?
...
realview-pb-a8 ARM RealView Platform Baseboard for Cortex-A8
realview-pbx-a9 ARM RealView Platform Baseboard Explore for Cortex-A9
versatilepb ARM Versatile/PB (ARM926EJ-S)
...

Executing the linux kernel in QEMU

The QEMU emulator is started by specifiying a machine to emulate and a Linux compressed image.

$> cd arm-softmmu
$> ./qemu-system-arm -M versatilepb –m 128M 
-kernel ../../linux-2.6.37/arch/arm/boot/zImage

The-m option specifies the RAM size available for the versatilepb machine. It defaults to 16MB if not specified.

The following capture shows the kernel boot in QEMU. The kernel boot ends with a kernel panic because we don’t have provided an init filesystem.

Building a root filesystem with BuildRoot

Buildroot is a set of makefile that helps to build complete embedded Linux system. It can compiles a GCC cross-compilation toolchain, a kernel and a root filesystem with selectable applications and packages.

I already have a compiled kernel thus I will use BuildRoot to only build a basic root filesystem containing the Busybox shell. This root filesystem will be a simple compressed CPIO archive.

$> curl –O http://buildroot.uclibc.org/downloads/buildroot-2010.11.tar.bz2
$> tar xjvf buildroot-2010.11.tar.bz2
$> cd buildroot-2010.11.tar.bz2
$> make menuconfig

I set the following options:

  • Target Architecture: arm
  • Target Architecture Variant: arm926t
  • Target ABI: EABI
  • Toolchain/Kernel Headers: 2.6.36.x (I could specify a path to my kernel sources)
  • Package Selection for the Target/Busybox 1.17.x
  • Target Fileystem Options/cpio the root filesystem and Compression method: gzip

Some dependencies you may need to install in Ubuntu: g++ flex msgfmt(gettext) patch subversion.

To start the BuildRoot execution (with optional V=1 to enable the verbose mode):

$> make V=1

BuildRoot automatically download the required source packages from their original servers, applies patches if necessary and compile them. It then builds a filesystem with the built packages installed.

Executing the kernel with the BuildRoot root filesystem

$> cd qemu-0.13.0/arm-softmmu
$> ./qemu-system-arm -M versatilepb –m 128M 
-kernel ../../linux-2.6.37/arch/arm/boot/zImage 
–initrd ../../buildroot-2010.11/output/images/rootfs.cpio.gz

The initrd option specifies a filesystem image to load as the initial ram disk. During boot the kernel will mount this ram disk as its root filesystem and look for an init executable to start. In our case the init executable is provided by Busybox.

Here a capture of the result. I am able to loginp as root and then do a ls on the root of the filesystem.

Quitting QEMU when the mouse has been grabbed

The QEMU graphical window can grab the mouse pointer to interact with the virtual machine display. Ctrl-Alt should exit the mouse grab but in my case (QEMU executed by Ubuntu emulated by OS X/VMWare Fusion) it does not work so I am unable to get back the mouse when I want to end my session.

So I use the console accessed through Ctrl-Alt-2 and the quit command.

compat_monitor0 console
QEMU 0.13.0 monitor - type 'help' for more information
(qemu) quit

→ 11 CommentsTags:···

Linux ARM emulation articles

October 4th, 2010 · Uncategorized

I have begun learning about Linux with embedded ARM targets.

Here is a good set of links to learn the basics of building a kernel and how to boot it in the QEMU virtual machine:

→ No CommentsTags:··