gsm-utils
Package: gsmlib_1.10.orig.tar.gz
This project is quite old and unmaintained. If you compile it with a recent gcc (I was using 4.3.x), you’ll need to apply this patch provided by Debian. The building procedure is straight-forward, but the results, at least for me, were quite disapointing because the SMS daemon crashed very often.

gammu
Package: gammu-1.31.0.tar.bz2
Gammu is a fork of gnokii (the third option), it’s well documented, it’s robust and more complex, and it has a lot of features making it a bit heavier than gnokii. If your hardware is a PC or a high-end ARM processor I would recommend gammu. It also depends on libdbi that implements a database-independent abstraction layer in C, similar to the DBI/DBD layer in Perl.
Since I can only use SQLite3, I don’t need the portability to other databases making the use of libdbi redundant.

gnokii
Package: gnokii-0.6.31.tar.bz2
Gnokii is a set of tools, similar to gammu that allows to send/receive SMS, read/write to a phonebook and other services. I was only interested in the SMS functionality that seemed to cover quite well.
gnokii’s SMS daemon, smsd, is quite light, making it suitable for small ARM processors like the one I have.
Latest versions support SQLite3 so I could even put the two tables that smsd uses for sending and receiving SMS inside my database.

The documentation is not great, but good enough to get started. The code is quite clear and easy to understand. In fact, I found a memory leak in smsd that I fixed and sent to the mailing list. The patch was applied quite fast showing the active development around this project.

I decided to use gnokii and document its building procedure since the cross-compilation is not straight forward.

This is the procedure I followed:

Set the following environment variables that will make our life easier:

$ export BUILD=i386-linux
$ export HOST=arm-linux
$ export PROJECT_PATH=/home/projects/rootfs

Configure:

GLIB_CFLAGS="-I$PROJECT_PATH/usr/include/glib-2.0 -I$PROJECT_PATH/usr/lib/glib-2.0/include" \
GLIB_LIBS="-L$PROJECT_PATH/usr/lib" \
SQLITE3_CFLAGS="-I$PROJECT_PATH/usr/include" \
SQLITE3_LIBS="-L$PROJECT_PATH/usr/lib" \
./configure \
--build=$BUILD \
--host=$HOST \
--without-x \
--without-bluetooth \
--without-libical \
--disable-libusb \
--disable-phonet \
--enable-sqlite \
--disable-xdebug

Before building, edit the following Makefiles:

1. common/phones/Makefile
2. common/links/Makefile
3. common/devices/Makefile
4. common/data/Makefile
5. gnokii/Makefile
6. common/Makefile
7. utils/Makefile
8. gnokiid/Makefile

Unset the variable LIBS:

LIBS =

Edit the file gnokii/Makefile:
Set the variable LIBS to the following value:

LIBS =   -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0

Edit the file smsd/Makefile:
Set the variable GLIB_LIBS to the following value:

GLIB_LIBS = -L/home/projects/rootfs/usr/lib -lsqlite3

Now you can build and install in /home/projects/rootfs/usr/local:

make
make DESTDIR=$PROJECT_PATH/usr/local install

Gnokii still has some rough edges that can be fixed/improved, but after a couple of months of intensive use its behaviour has been quite stable.

I’ve improved it a little bit and released it in GitHub. You can check it out here.

This program is in its first stages and currently it only converts the most widely used C-structs constructs to XML. However, it could potentially serialize other C constructs and almost any C code since it uses an almost full-compatible C grammar.

The version I released in GitHub adds the support for structs/unions defined inside a macro.

I’ll try to explain how this feature works:
Suppose you have a file, test3.h, with a macro that defines the following struct:

#define def_struct_data(prefix,number,code_number)\
struct prefix##driver_data\
{\
    task_status_t tsk_sts;\
\
    struct buttons_platform_data pdata[number];\
    struct prefix##an_event event;\
\
    struct prefix##buttons_settings\
    {\
        uint8_t thresholds[3];\
        uint8_t pressed_threshold;\
        struct prefix##buttons_mask hash_table[code_number];\
    }__attribute__((packed)) settings;\
\
    uint8_t raw[((number) / 8) + 1];\
    uint8_t raw_mem[((number) / 8) + 1];\
\
}__attribute__((packed));

As you probably know, the syntax of a C macro is not valid for a C compiler, that’s one of the reasons for using the C pre-compiler: it converts the macro to something that the compiler understands.
In the SC2XML case, applies the same condition. Therefore, you have to create a very simple C file that includes the file that you want to serialize, in this case test3.h, along with the use of the macro and execute sc2xml with that file:

Assume that the name of your simple C file is test3.stub.h. It should looks like this:

#include "test3.h"
def_struct_data(prefix,number,code_number)

def_struct_data is the name of your macro.

Execute sc2xml:

$ sc2xml test3.stub.h
 
sc2xml 0.0.2
 
INFO: *** Parsing file data/test3.gen.h ***

The final generated XML file, test3.h.xml, will look like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<sc2xml>
    <struct>
        <struct_name>prefixdriver_data</struct_name>
        <field type="task_status_t">
            <name>tsk_sts</name>
        </field>
        <field type="struct buttons_platform_data" size="number">
            <name>pdata</name>
        </field>
        <field type="struct prefixan_event">
            <name>event</name>
        </field>
        <struct>
            <struct_name>prefixbuttons_settings</struct_name>
            <field type="uint8_t" size="3">
                <name>thresholds</name>
            </field>
            <field type="uint8_t">
                <name>pressed_threshold</name>
            </field>
            <field type="struct prefixbuttons_mask" size="code_number">
                <name>hash_table</name>
            </field>
            <struct_attributes>__attribute__ ( ( packed ) ) </struct_attributes>
            <struct_nested_name>settings </struct_nested_name>
        </struct>
        <field type="uint8_t" size="( ( number ) / 8 ) + 1">
            <name>raw</name>
        </field>
        <field type="uint8_t" size="( ( number ) / 8 ) + 1">
            <name>raw_mem</name>
        </field>
        <struct_attributes>__attribute__ ( ( packed ) )</struct_attributes>
    </struct>
</sc2xml>

Now you can see that the XML file shows exactly the struct defined in the macro def_struct_data but with nice XML tags!

I hope this project could be useful, specially if you want a non-trivial example that defines a parser and grammar with lex and yacc.

In this post I try to explain how to do this when your host/PC is a Linux machine.
The procedure described here is partially based in the quite uselful Easy guide to update to Galaxo or GAOSP! written by DaSchmarotzer that explains how to update this phone but using a Windows based machine.

Download

Get all the needed files:

• Android SDK for Linux
• Fastboot for manipulating the flash
• Custom recovery
• ROM: Choose one option. I chose Galaxo.
  • GAOSP-2-PUBLIC-BETA-3
  • Galaxo_V1.6.3.4
• Gapps for restoring Google Applications. Choose one option. I chose Galaxo.
  • gapps-gaosp-light-10312010-signed.zip
  • gapps-galaxo-signed.zip

Put everything in place

First of all, create a backup of your data. The SD card (pictures, music, etc) won’t be touched, but other important info like your contacts will be erased. If you have a Gmail account you just can synchronize your contacts for uploading them to your account and once you finish the update you can synchronize it again for downloading them to the phone.

Unpack the android SDK wherever you want. I put all the downloaded files in /home/android/.

Decompress the android SDK. The directory /home/android/android-sdk-linux_x86 will be created.

Change to the directory /home/android/android-sdk-linux_x86/tools

Move the file fastboot.zip inside the /home/android/android-sdk-linux_x86/tools directory and decompress it. A new file called fastboot will be created.
Give it execution permissions:

chmod +x fastboot

Connect your phone via USB and mount its SD card.
Copy the chosen ROM and Gapps files to the phone’s SD card.
Umount the SD card.
Turn off the phone, but leave it connected to the PC using the USB cable.

Now we have all the downloaded files in the required locations.

Manipulate the i7500 flash with fastboot

We have to tell the phone’s bootloader how to load our files. fastboot can write a new bootloader image (recovery-6.5.1.img) that allow us to do exactly that plus several other operations.

Before executing fastboot, we need to tell udev through its rules that we’re the owner of the usb device with vendors ID 18d1 (Google Inc.) and 04e8 (Samsung Electronics Co., Ltd).
You have to do these steps as root.
Change username to the username you use for logging in your system.

Create the file /etc/udev/rules.d/50.android.rules with the following content

SUBSYSTEM=="usb", SYSFS{idVendor}=="18d1", MODE="0666", OWNER="username"

Create the file /etc/udev/rules.d/90.android.rules with the following content

SUBSYSTEM=="usb", SYSFS{idVendor}=="04e8", MODE="0666", OWNER="username"

Reload udev’s rules

$ reload udev

As a normal user, add the /tools directory where fastboot is located to your PATH environment variable.

$ export PATH=$PATH:/home/android/android-sdk-linux_x86/tools

Change to the /home/android/android-sdk-linux_x86/tools directory and write the following command without pressing enter.

$ fastboot flash recovery recovery-6.5.1.img

You’ll press it after booting the phone in fastboot mode. Do so by pressing and holding both the Call button (bottom left) and the Power button (bottom right) at the same time until you see on the phone that you are in fastboot mode. You’ll have about 15 seconds to press enter on the shell. If it works, you’ll see in the shell this output:

sending 'recovery' (3080 KB)... OKAY
writing 'recovery'... OKAY

In the phone’s display you’ll see something like this:

Android fastboot

At this point we have a new bootloader image in the phone’s flash that allow us to do custom operations.

Turn off your phone. I had problems for turning it off, so I removed the battery and put it again.

Updating to the new firmware

Boot the phone, but this time in recovery mode. Do so by holding the Lower volume button, the Call button and the Power button. If it works, you’ll see a green menu with lots of choices:

Android recovery mode

Select the Nandroid backup option and press the Home button to confirm. Then just follow the instructions on-screen. I chose slot 1 when asked which slot to use.

Select Wipe data/Factory reset. It’s going to erase all your applications and settings, but it shouldn’t touch anything saved on your SD card. It’s important to do so, else the phone will not work properly.

Select Apply any zip. Select either the GAOSP or the Galaxo zip files, depending on your choice. This will take a bit since it was to copy 60 or 49MB, respectively.

Select Fix package permissions.

Select Apply any zip again but this time pick the Gapps, which will restore the Google Applications on your phone.

Now you can reboot by selecting the first option Reboot system.

Notice: It could happen that the phone freezes during the booting procedure in the android or gaosp boot screen. Wait for ~10 minutes, and then if it’s still stuck, pull out the battery and boot again.
If it still doesn’t work, repeat the procedure described in this section Updating to the new firmware.

Btw, sorry for the images quality. I’ll change them with better ones.

That’s it!

References

• Drakaz
• Tutorials for the Samsung Galaxy i7500
• Easy guide to update to Galaxo or GAOSP!
• Fastboot info
  • elinux
  • android-dls
• Fastboot usage

I decided to write a program, called SC2XML: Simple C to XML serializer, flexible enough for adding later new C constructs like enums and typedefs.

In order to serialize any valid C struct/union I needed a C grammar and something that could scan and parse the file following that grammar. The best tools for doing this are lex and yacc. In Linux, Flex and Bison are the Open Source implementations of these old but quite useful Unix tools.
I strongly recommend these tools if you need to create a compiler, an interpreter or even a shell (you can have a look at a project called tarasca that I wrote some years ago as a proof of concept of a Cisco-like shell).

Since writing an ANSI C grammar is not a easy task, I downloaded the lex and yacc implementations of the ANSI C grammar written by Jutta Degener and modified it because it misses a few things like user-defined data types.

The first version of this program could potentially serialize other C constructs and almost any C code since it uses an almost full-compatible C grammar (see the header comment of scanner.l and parser.y for details).

The sc2xml package needs, as requirements, the following two standard libraries:

• glib-2
• libxml2

The package already provides the files generated by Flex and Bison called lex.yy.c, parser.c and parser.tab.h. These files are created from scanner.l and parser.y. Thus, if you modified the last two files, you will also need Flex and Bison.

You can configure, compile and install sc2xml using the traditional way:

./configure
make
sudo make install

This version, as it is normal with a first alpha release, has some limitations and bugs. At them moment, it doesn’t support some constructs like

• Anonymous structs/unions
• Multi-line pre-processor directives and macros

You can have a look at the README for more details about the current limitations and bugs.

If I have the time or there is the interest for expanding this program, I would post it in sourceforge or gitorious. Meanwhile, you can download the source code from here: sc2xml-0.0.1.tar.gz

The communication with these devices can take place thanks to the libimobiledevice library with the help of fuse (filesystem in userspace) and several other libraries and applications. For a clearer picture of the involved libraries you can have a look at this software stack diagram.

Unfortunately, having the same functionality in a Linux embedded device such as a Set-Top-Box or a Digital Receiver is not easy because all the applications are part or depend strongly on GNOME or KDE that normally are not available in these systems.
However, all the libraries can be cross-compiled allowing to mount an iPod/iPhone/iPad as a storage device.
Of course, if you want to synchronize your data such as music or videos, you’ll have to develop your own application or port an existing one.

In this post I focus only on how to compile all the required libraries for mounting an iPod/iPhone/iPad as a storage device.
If the Set-Top-Box have a media player with the required codecs, they will be able, at least, to play the content.

Requirements

Fuse needs a kernel driver that is already included in the mainline kernel. In the kernel configuration you find this option under the Filesystem menu. You can compile it as a module or in-kernel. If you choose the former, the module will be called fuse.ko.

Environment configuration

Suppose that we want to install all the libraries in /mnt/target/usr/local.
/mnt/target is the top directory of the target’s filesystem that could be mounted via NFS.
Assume that the cross-toolchain (compiler, linker…) is already in your path.

Set the following environment variables:

$ export PREFIX=/mnt/target/usr/local
$ export HOST=sh4-linux
$ export BUILD=i386-linux
$ export LD_LIBRARY_PATH=$PREFIX/lib
$ export PKG_CONFIG_PATH=$LD_LIBRARY_PATH/pkgconfig

libusb

Package: libusb-1.0.8.tar.bz2

This package is required by libimobiledevice.

$ ./configure --build=$BUILD --host=$HOST --prefix=$PREFIX --disable-static --disable-log
$ make
$ make install

libplist

Package: libplist-1.3.tar.bz2

This package is required by libimobiledevice.

The compilation of libplist is different because it uses cmake.
Create a file toolchain.cmake with the following contents. Modify the cross-compiler variables according to your path:

# this one is important
SET(CMAKE_SYSTEM_NAME Linux)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)
 
# specify the cross compiler
SET(CMAKE_C_COMPILER   /opt/STM/STLinux-2.3/devkit/sh4/bin/sh4-linux-gcc)
SET(CMAKE_CXX_COMPILER /opt/STM/STLinux-2.3/devkit/sh4/bin/sh4-linux-g++)
 
# where is the target environment 
SET(CMAKE_FIND_ROOT_PATH  /mnt/target/usr/local)
 
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Then create the build directory, compile and install:

$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ..
$ make DESTDIR=$PREFIX install

usbmuxd

Package: usbmuxd-1.0.4.tar.bz2

This package is needed by libimobiledevice.

usbmux uses cmake too. Therefore, the procedure is the same as liplist:

Create the file toolchain.cmake with the same contents as with libplist-1.3 or just copy it to the current directory usbmuxd-1.0.4.

$ cd usbmuxd-1.0.4
$ cp ../libplist-1.3/toolchain.cmake .

Then create the build directory, compile and install:

$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ..
$ make DESTDIR=$PREFIX install

libgpg-error

Package: libgpg-error-1.7.tar.gz

This package is needed by libgcrypt.

$ ./configure --build=$BUILD --host=$HOST --prefix=$PREFIX
$ make
$ make install

libgcrypt

Package: libgcrypt-1.4.6.tar.gz

This package is needed by gnutls

$ ./configure --build=$BUILD --host=$HOST --prefix=$PREFIX --with-gpg-error-prefix=$PREFIX

Note: I didn’t need to modify these Makefiles when using an updated STLinux2.3. But if you haven’t done an ‘stmyum update’ lately, maybe you’ll need to modify them.
Edit the Makefile:
Remove from the variables DIST_SUBDIRS and SUBDIRS the directory ‘tests’

Edit the src/Makefile:
Set the following variables to the given values:

GPG_ERROR_CFLAGS = /mnt/target/usr/local/include
GPG_ERROR_CONFIG =
GPG_ERROR_LIBS = /mnt/target/usr/local/lib/libgpg-error.so.0.7.0
libgcrypt_la_LIBADD = \
	../cipher/libcipher.la \
	../random/librandom.la \
	../mpi/libmpi.la \
	/mnt/target/usr/local/lib/libgpg-error.so.0.7.0

Compile and install:

$ make
$ make install

libtans1

Package: libtasn1-2.7.tar.gz

This package is needed by libimobiledevice.

$ ./configure --build=$BUILD --host=$HOST --prefix=$PREFIX
$ make
$ make install

gnutls

Package: gnutls-2.8.6.tar.bz2

This package is needed by libimobiledevice.

$ ./configure --build=$BUILD --host=$HOST --prefix=$PREFIX \
--with-libgcrypt-prefix=$PREFIX --enable-large_files --disable-gtk-doc-html

Edit the files src/Makefile, doc/Makefile and doc/examples/Makefile:
Set LDFLAGS to this value:

LDFLAGS = /mnt/target/usr/local/lib/libgcrypt.so /mnt/target/usr/local/lib/libgpg-error.so

$ make
$ make install

libimobiledevice

Package: libimobiledevice-1.0.2.tar.bz2

$ ./configure --build=$BUILD --host=$HOST --prefix=$PREFIX \
libusbmuxd_CFLAGS="-I$PREFIX/include" libusbmuxd_LIBS="-L$PREFIX/lib" \
libgnutls_CFLAGS="-I$PREFIX/include" libgnutls_LIBS="-L$PREFIX/lib" \
libtasn1_CFLAGS="-I$PREFIX/include" libtasn1_LIBS="-L$PREFIX/lib" \
libplist_CFLAGS="-I$PREFIX/include" libplist_LIBS="-L$PREFIX/lib" \
libglib2_CFLAGS="-I$PREFIX/include -I$PREFIX/lib/glib-2.0/include" libglib2_LIBS="-L$PREFIX/lib" \
--without-swig

Edit the file tools/Makefile:
Set LDFLAGS to this value:

LDFLAGS = /mnt/target/usr/local/lib/libgcrypt.so /mnt/target/usr/local/lib/libgpg-error.so /mnt/target/usr/local/lib/libplist.so /mnt/target/usr/local/lib/libtasn1.so /mnt/target/usr/local/lib/libusbmuxd.so /mnt/target/usr/local/lib/libgnutls.so

Compile and install:

$ make
$ make install

fuse

Package: fuse-2.8.4

$ ./configure --build=$BUILD --host=$HOST --prefix=$PREFIX
$ make
$ make DESTDIR=$PREFIX install

ifuse

Package: ifuse-1.0.0.tar.bz2

$ ./configure --build=$BUILD --host=$HOST --prefix=$PREFIX \
CFLAGS=-D_FILE_OFFSET_BITS=64 \
libimobiledevice_CFLAGS="-I$PREFIX/include" libimobiledevice_LIBS="-L$PREFIX/lib" \
libglib2_CFLAGS="-I$PREFIX/include/glib-2.0 -I$PREFIX/lib/glib-2.0/include" libglib2_LIBS="-L$PREFIX/lib" \
libgthread2_CFLAGS="-I$PREFIX/include" libgthread2_LIBS="-L$PREFIX/lib" \
libfuse_CFLAGS="-I$PREFIX/include" libfuse_LIBS="-L$PREFIX/lib"

Edit the file src/Makefile:
Set libfuse_LIBS to this value:

libfuse_LIBS = -L/mnt/target/usr/local/lib -lfuse -limobiledevice -lgnutls -lplist -lusbmuxd

Compile and install:

$ make
$ make install

Mounting the device

At this point you should be able to mount your iPod/iPhone as a storage device. Some iPods can have a partition, like /dev/sda1, formatted as VFAT of HFS+, depending on where you use it. Some others, like the iPod shuffle, doesn’t have a partition, so you’ll see them as /dev/sda.

Assuming that you want to mount it in /media/ipod, that it has partition /dev/sdb1, and it’s formatted in VFAT, you can mount it as a normal storage device:

$ mount -t vfat -o usefree /dev/sdb1 /media/ipod

For HFS+ is the same. Notice that your kernel must be compiled for supporting this filesystem:

$ mount -t hfsplus -o ro /dev/sdb1 /media/ipod

Now you can browse in /media/ipod and you’ll see the contents of your iPod’s filesystem!

References

• libimobiledevice
• fuse
• Cross-compiling using cmake

If you have an embedded Linux project or know someone who has, you can contact me at pedro (’dot’) aguilar (’dot’) iniestra (’at’) gmail (’dot’) com

svn co https://qboxhd.svn.sourceforge.net/svnroot/qboxhd/trunk  qboxhd

Some of the most important components were already OSS such as the kernel and the application software Enigma2, so they had to be released anyway. As a matter of fact, they were released several months ago, but they were never updated, although they were in an SVN repository. This was due to the team that worked in a private repository and never sync’ed to the public one.

Although Duolabs is doing a great effort for opening their development process (you can see that the SourceForge’s SVN repository is actively used), not all the software is being released. Some critical parts such as everything related to the FPGA remains proprietary.

However, most of the sources that before were proprietary, now are OSS released under the GPLv2. And this, along with a simple mechanism for compiling these sources, are the relevant part that could mean an advantage for these decoders.

Let’s start with the development environment.
It is a simple, yet useful system targeted for compiling the kernel, drivers and the middleware and application software. This environment is just a set of scripts that only allows to:

• Compile the boot loader
• Compile the kernel
• Compile the drivers (only the OSS)
• Compile enigma2 (middleware and application software)
• Work with an NFS filesystem and an TFTP server
• Create releases using the official procedure

These tools consist of a Makefile, a configuration file config.in and some other Shell and Perl scripts inside the /sdk directory. If you want to check the details you can have a look at the project’s wiki that is far from being complete, but at least it describes the basic procedure for compiling the mentioned sources.

It’s a quite simple set of tools. Thus, do not expect any development environment such as the ones used in projects like MeeGo or Android. Properly speaking, this is not an SDK, only a set of scripts that allows to build the sources and create a release almost identical to the official one.

These QboxHD tools were developed one bit at a time as requirements were added to the system and to fit the needs of a small team, taking into account that the development was done in a closed fashion, different from an open development that everybody can follow. I think that’s the reason why, in one hand, they have a specific and practical purpose, and in the other hand, are quite limited if compared to full-blown development environments.

It would be quite nice if this system was migrated to a real full-platform build tool such as Poky. Unfortunately, the SH4-based processors don’t have any support of this kind.

Now let’s move to the source code that was released.
Besides the already known OSS (U-Boot, Linux kernel and Enigma2), the relevant part is in the /src/drivers directory in which some of the drivers that previously were proprietary were now released under the GPLv2.
Inside this directory we get the following drivers:

• avs
• e2_proc
• fpanel
• frontends
• includes
• lcd
• lpc
• multicom
• player2
• qboxhd_generic
• scart
• stmfb

The drivers avs, e2_proc, includes, multicom, player2 and stmfb were basically taken from the sh4 duckbox project and STLinux and modified accordingly, so these are not really new.

The rest of the drivers are the ones used for controlling most of the decoder’s hardware. The hardware between both boards is quite different, so you’ll see specific drivers and/or macros that differentiate them.
Notice that all the drivers and applications regarding the FPGA inside these boxes remains strictly proprietary…

The fpanel is used for controlling the colours and behaviour of the sense-wheel and front-button of the QBoxHD and QBoxHD-mini, respectively. You can regulate the colours leds… nothing useful, but at least fun.

The lcd controls the front panel LCDs. Since they support at least 64k colours, you can display nice images although the data-transfer speed is not high.

The lpc is only present in the QBoxHD-mini and controls the Stand-By functionality.

The qboxhd_generic resets the tuners at boot time, boring…

The scart drivers controls the analog A/V outputs (SCART, components, composite and audio stereo). The digital video output (HDMI) is controlled by the stmfb driver that is part of the STLinux2.3 distribution.

The frontends directory contains the drivers for the DVB-S2/T/C tuners and pll’s. All of them are based on drivers taken from the mainline Linux kernel, except the DVB-S2 AVL2108 demod (with stv6306 pll) that was developed specifically for these decoders. I don’t know of any DVB-S2 PCI card or USB adapter that mounts this demod, because this driver could be re-used and maybe included in the mainline kernel.

Another interesting directory, specially for the people that wants to start playing around in userland, is the /src/apps directory in which several relatively simple applications such as display_image can be used as example for gaining confidence with the development for these decoders and, in general, with the embedded devices development.

In this directory you can find too the modified sources of Busybox and libdvbsi++ that are Open Source Projects.

As you can see, with all these sources licensed under the GPL, these decoders can be a good platform for people that want to start developing in user or kernel space with Embedded Linux and with a special focus in High Definition DVB devices.
Another benefit is that these boxes could become a reference point regarding openness in the High Definition DVB decoders market since these are basically the only decoders with almost all their sources available.

Openness is a factor that cannot be under estimated.

Cross-compiling and running Dropbear in an embedded system is not a difficult task, but the documentation is not very clear for everybody. You can start by reading the README and INSTALL files contained in the package and then, if you still have questions, you can keep reading this article in which I’ll try to give a short and clear explanation:

As you may expect from a package of this kind that was written with embedded systems in mind, it supports uClibc. The configuration, compilation and installation are the same as for libc, but it can have some tweaks that are described in the INSTALL file.

Download
http://matt.ucc.asn.au/dropbear/dropbear-0.52.tar.bz2

Environment configuration
As normal, set the environment variables that make our life easier. Change them according to your needs.
I normally have an SH4 based processor in my desk at home.

$ export PREFIX=/opt/STM/STLinux-2.3/devkit/sh4/target/usr/local
$ export HOST=sh4-linux
$ export BUILD=i386-linux
$ export COMPILER=sh4-linux-gcc

Configuration

Dropbear doesn’t have a configure script since it’s not based on autotools. It contains an options.h file in which you can select many parameters that vary from the keys installation paths to the supported encryption algorithms and X11 forwarding among others.
I strongly suggest you to have a look at this file. This will give you a good idea of what Dropbear is capable of.
In any case, I list here what I consider some of the most relevant options for embedded systems:

• Small footprint – A speed performance price must be paid when using some ciphers
• Six supported ciphers – 3DES, AES128, AES256, Blowfish, Twofish128 and Twofish256
• Adjustable size of receive window size and maximum size of transmission and reception packets

Some other default functionality in OpenSSH are supported in Dropbear too, but are not very relevant for embedded systems such as X11 forwarding.

Once you have decided the options that you need, the configuration is straight-forward as many other packages:

$ CC=$COMPILER ./configure --build=$BUILD --host=$HOST --prefix=$PREFIX

Compilation

The compilation is the step that allows you to choose the services that you want in Dropbear: the generated binary is a multi-purpose executable that contains the functionality that you need. Here you can select if you want an executable that works as a server (dropbear), that generates keys (dropbearkey), that allows Secure Copy (scp), Secure FTP (sftp), and keys conversion from OpenSSH to Dropbear format (dropbearconvert and dbclient).
If you want at least two of this services you need to give to make the argument PROGRAMS=”the programs that you want” and the MULTI=1 argument.

In this same step you can choose if you want a dynamically or statically – linked executable. For embedded systems is common to use a statically linked executable by adding the STATIC=1 argument to make.

A final make command that contains the Dropbear server, it’s key generation and Secure Copy, looks like follows:

$ make PROGRAMS="dropbear dropbearkey scp" STATIC=1 MULTI=1

Installation
You can use the standard method for installing Dropbear plus the same arguments used during compilation:

$ make PROGRAMS="dropbear dropbearkey scp" STATIC=1 MULTI=1 install

But this will use the default path that some times in embedded systems is not sufficient because different paths can be used. In these cases you’ll have to copy manually the executable called dropbearmulti to the desired location and create symbolic links that have the name of the program that you want to use that point to this executable. If you have used Busybox, the concept of symbolic links pointing to the same executable will be familiar:

# $PREFIX/../.. is target's root filesytem: /opt/STM/STLinux-2.3/devkit/sh4/target/
# Copy the real executable dropbearmulti to the target's root filesystem /usr/local/bin
$ cp dropbearmulti $PREFIX/bin
 
# Create the symbolic links dropbearkey and dbclient
$ ln -s dropbearmulti dropbearkey
$ ln -s dropbearmulti dbclient
 
# Create the symbolic link scp in the target's filesytem /usr/bin
$ cd $PREFIX/../bin
$ ln -s ../local/bin/dropbearmulti scp

Stripping is quite a good thing when you need to save storage:

$ cd $PREFIX/bin
$ sh4-linux-strip dropbearmulti

Dropbear 0.52 ships with an alternative standalone scp program that is taken from OpenSSH. If you want to use this instead of the default built-in, you need to compile it separately:

$ make scp

For further compilation hints you can take a look at the SMALL and MULTI files provided in the package.

Keys creation

SSH uses public-key cryptography to authenticate a remote client. Thus, once you have Dropbear properly installed, but before using it, you need to create the cryptographic keys.
You can read the following links for an in-depth explanation of how SSH and public-key cryptography work:
SSH: http://en.wikipedia.org/wiki/Secure_Shell
Public-key cryptography: http://en.wikipedia.org/wiki/Public-key_cryptography

You can create your keys using two different methods: RSA and DSS.
Both kind of keys seem to be equally secure, but RSA seems to be faster for signature verification that is the most common operation when using the keys.

Let’s create the keys using both methods.
Connect to your target via serial or telnet (at the end of this post you will, hopefully, use ssh instead of telnet):

$ mkdir -pv /etc/dropbear
$ cd /etc/dropbear
 
# Generate the RSA private and public keys.
$ dropbearkey -t rsa -f dropbear_rsa_host_key
Will output 1024 bit rsa secret key to 'dropbear_rsa_host_key'
Generating key, this may take a while...
Public key portion is: 
ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAAAgncEwjavI+PfbQ+WNDYev/g2f5PGTD7ZzAnauZP4dWOi0MTVFGOZXTf9/cWXwx12zZ2KUOS5UfWk9SdH/t67MPVDDptFaq0kJ5ReA6JzqhwaKguMIdNGTdM2HfwJabvSnDL4SZgpxXtOJYZhWaqMMO8OP560gE21h6O0mH75/IBJUak=
root@my_target
Fingerprint: md5 0a:bb:43:82:41:7b:8a:8b:4d:41:43:e7:71:54:a7:ce
 
# Generate the DSS private and public keys.
$ dropbearkey -t dss -f dropbear_dss_host_key
Will output 1024 bit dss secret key to 'dropbear_dss_host_key'
Generating key, this may take a while...
Public key portion is: 
ssh-dss
AAAAB3NzaC1kc3MAAACBALIEmhf5c65czi/2rq1Xu2I0Vv+DqeEUQDDmeFke4nyBqVOuQTq8JrHzuRz8SbeohqhXWx//546HLK/RwIG6Gkj5+RQ7uvcc9bcprwJtQVU+U1qmgepPsl6e0Cofldbz+LBLWE5R1sg1ExX/NzGNtKzIbukXUABK12/sveGODeWpAAAAFQCNmGPNFcQyso8x+Zc52FLuRrtTfQAAAIEAiN4pNvhdyNX0lg1nop0ei+qp7H8kmurXWhZMZmaKWVYOc8YqvELL/U1s9fNNPsxEBTi6ysYLM1MCHNizQ4x/npsC/1e6URaIub/Dtf55N5Bn1LaItdK2EO1wLemf1/+3yuvJvhvI2yaPEEAzIgmQatTdE38HwY3+AxXSgccqsBcAAACBAJv9gJtcu5rHGal4VCaVRcM41z+omA7agAtcpmcXOBXr719T2qSZF+GoAeLlfThndaCTchpDQXNDxwTaW6G9RxGOhrDgyKR4MgShljnBfq0wsVx06l23Ex92d8xSmXJz4E/BwtLhjUouAsrW/IJbxQlwp3stmvtik6IYP/BiM2kf
root@my_target
Fingerprint: md5 a7:ad:8e:f8:d2:78:73:ec:a7:1b:aa:ba:9b:ad:aa:2a

Be sure that the private keys generated in /etc/dropbear remain secret!
The generated public keys shown in this post are just an example.

Connect to the server using Dropbear

At this point you are able to connect to the target using your login/passwd. Normally in an embedded system the only user is root.

Start dropbear server in the target:

$ dropbear

Check the different execution options using the –help flag.
Optional, but recommended, is to add in /etc/hosts in the target’s filesystem the hostname of the client (host).

Finally, you can use ssh and scp:

# Connect from host (client) to target (server) using SSH.
# It will prompt for root's passwd.
$ ssh root@192.168.0.135
 
# Copy the file 'hola' from the host (client) to the directory /etc in the target (server).
# It will prompt for root's passwd.
$ scp hola root@192.168.0.135:/etc/hola

If you need to connect very often to the target, typing the passwd each time can be very annoying and could pose a security risk.
It would be better not to send the passwd at all.

For this purpose you can store the public key of your host (client) in the target (server).
Assuming that your host (client) is a Unix machine that has OpenSSH installed, you can easily create your keys:

# Key creation in the host (client) using OpenSSH:
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): y
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in y.
Your public key has been saved in y.pub.
The key fingerprint is:
74:84:22:e2:f9:6d:fc:b5:b1:72:40:58:e2:23:ff:ea user@my_client
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|         .       |
|    . . o ..     |
|   . . +o.  .    |
|    . . S..o.    |
|     . o.+..o.   |
|        . ....   |
|          o. ..  |
|         ..+B=+. |
+-----------------+

You will end-up with the private key id_rsa and public key id_rsa.pub in /home/user/.ssh/.
Copy the host’s (client) public key to ~/.ssh/authorized_keys in the target’s filesystem. Notice that ~ is normally /root, but if you’re logging in with another username, change it accordingly.
Warning: If you copy-paste the public key, check that your text editor copies-pastes it correctly, otherwise you will end-up with a broken key. You’re safe if you use vi.

Once you have your host’s (client) public key in your target’s (server) filesystem, you can login to your target without using a passwd speeding up your login procedure!

Running from inetd

If you want to use Dropbear from inetd you have to enable it in the options.h file before compiling:

#undef NON_INETD_MODE
#define INETD_MODE

In the inetd.conf configuration file you have to add the following line:

22 stream tcp nowait root /usr/local/bin/dropbear dropbear -i

Notice that if you compile with inetd support, Dropbear will refuse to start from the command line. Obviously, this applies for the other way around too.

Conclusion
Having a working Dropbear server is not a difficult task. You only have to pay attention at compilation time of the services you want from it, and when running it, of the location where you have to store the keys, specially if you want to use them for logging in without a passwd.
Reading the INSTALL, README and other instruction files is always a good idea, no matter how extensive they are.

After more than two years that this project began under the The Ducktales Team (TDT) name, it now changes its name to The OpenSource Team Ducktales Project and releases all the sources along with the necessary infrastructure for creating images.

The git repository is here http://gitorious.org/open-duckbox-project-sh4.

The main modules of the project are:

• Build environment
• Kernel sources (patches)
• Enigma2 source
• Drivers sources
• All tdt applications

The big news here are the drivers sources, specially their player2 version, that takes advantage of the STi710x hardware and at the same time exports a compatible Linux DVB API. The original player2 adds an additional Linux DVB adapter that gives compatibility issues to applications such as szap and enigma2.

It seems that this repository will be available for cloning only for a limited time, so get it asap and clone it to an open source git hosting service as they suggest.

You can clone it from here:

git clone git://gitorious.org/open-duckbox-project-sh4/tdt.git

Notice that all the source code in this repository is Open Source. It does not contain any proprietary video and audio firmwares and headers, nor the proprietary PTI driver.

I hope I can contribute to this project soon!

Thanks to the OpenSource Team Ducktales Project!!!

With this configuration, the QBoxHD gives you the freedom to change the second-stage bootloader and obviously the initramfs and kernel. In the case that you want to do any experiment with it and later come back to the original configuration you know that the first-stage bootloader is always there.
If you only want to load a different kernel and/or initramfs, you just need to change the U-Boot environment as with a vanilla U-Boot version.

Both bootloaders are based on U-Boot 1.1.2 that is somewhat old, but it gives the necessary functionality.
The modifications were done, basically, for removing unneeded functionality and reduce their footprint in NOR flash.
Of course, you are free to update it to the latest U-Boot version provided by STLinux.

You can get both versions from here:

First-stage bootloader:

$ svn checkout https://www.qboxsvn.com/genesis/trunk  genesis_trunk

Second-stage bootloader:

$ svn checkout https://www.qboxsvn.com/uboot/trunk  uboot_trunk

Have fun!