In the Debian example, the wiki introduced NetInstall. Later I find out the mk_mmc.sh script shown there to be useful for (1) duplicating and (2) restoring working Linux backup to new or corrupted MMC/SD card. I break down that Robert C. Nelson’s mk_mmc.sh script at GitHub to small routines for setting up the card.

Typical boot-rootfs partitions of SD card to boot ARM-Linux boards

It’s an elegant script automating the process of preparing SD card for embedded Linux, but requires large downloading on the run (mostly root file system and then U-Boot binaries and loader config). Duplicating/restoring means we already have those and probably only need to do elementary process rather than full card preparation. Below are some processes that can be repeatedly used.

Checking Tool Versions

The tools to work with are common in Linux distribution (I used Ubuntu) and require root privilege. The script checked for fdisk and parted installed. My versions are

$ fdisk -v
fdisk (util-linux-ng 2.17.2)
$ parted -v
parted (GNU parted) 2.2

Originally mk_mmc.sh will exit If “GNU Fdisk” found instead. Also for the above parted version, “--align cylinder” argument will be used.

Creating Two Partitions

Setting up two partitions which are the boot image (FAT 16) and root file system (ext4). The SD card plugged in through USB card reader found as /dev/sdb in this example (we’re formatting be sure of this!). If you plug MMC card to laptop slot, it may be found as /dev/mmcblk0.

1. Format card into a single disk

$ parted --script /dev/sdb mklabel msdos
$ fdisk -l /dev/sdb

2. Create the boot partition (allocating 64MB)

$ fdisk /dev/sdb << END
n
p
1
1
+64M
t
e
p
w
END

then make sure it’s done.

$ sync

3. Flag it as boot

$ parted --script /dev/sdb set 1 boot on

4. Create the root file system by first determining space left after the first partition

$ END_BOOT=$(LC_ALL=C parted -s /dev/sdb unit mb print free | grep primary | awk '{print $3}' | cut -d "M" -f1)
$ echo $END_BOOT 
69.7
$ END_DEVICE=$(LC_ALL=C parted -s /dev/sdb unit mb print free | grep Free | tail -n 1 | awk '{print $2}' | cut -d "M" -f1)
$ echo $END_DEVICE 
3951

In this case 4GB SD card is used and the above calculation will stretch space left from 69.7 to 3951 of as rootfs partition.

$ parted --script --align cylinder /dev/sdb mkpart primary ext4 $END_BOOT $END_DEVICE

5. Format boot and rootfs according to each file system type with those naming also. They’re already accessible as /dev/sdb1 and /dev/sdb2 (previously didn’t exist) or relevant /dev/mmcblk0p(some index).

$ mkfs.vfat -F 16 /dev/sdb1 -n boot
$ mkfs.ext4 /dev/sdb2 -L rootfs

6. Finally we have something like the output of parted below

$ LC_ALL=C parted -s /dev/sdb unit mb print free 
Model: HUAWEI MMC Storage (scsi)
Disk /dev/sdb: 4023MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
 
Number  Start   End     Size    Type     File system  Flags
 1      0.03MB  70.9MB  70.8MB  primary  fat16        boot, lba
        70.9MB  4023MB  3953MB           Free Space

(yes I used Huawei modem as the microSD card reader)

Restoring Linux

For the boot partition content we can simply copy-paste the backup files, while for rootfs normally compressed file (preserving path information) is used for backup. Restore this by mounting rootfs and then unpacking the file (again /dev/sdb2 in this case).

[root@host]$ mkdir /media/rootfs
[root@host]$ mount -t ext4 /dev/sdb2 /media/rootfs
[root@host]$ pv armel-rootfs-201110131018.tar | sudo tar --numeric-owner --preserve-permissions -xf - -C /media/rootfs

Below is an example of how to backup rootfs from the mounted SD card (/media/rootfs).

[root@host]$ cd /media/rootfs
[root@host]$ /media/rootfs# tar --numeric-owner --preserve-permissions -cvf /home/arif/Documents/arm-linux/ubuntu/rootstock-rootfs/armel-rootfs-201202141421.tar ./*

(Check my other post related to creating rootfs)

Creating Swap

mk_mmc.sh also offers optional swap creation. It is a “file” inside rootfs partition created by

[root@host]$ dd if=/dev/zero of=/media/rootfs/SWAP.swap bs=1M count=250
[root@host]$ mkswap /media/rootfs/SWAP.swap

(the above will create 262MB swap inside rootfs SD card currently mounted to /media/rootfs of the laptop)

It will be mounted as swap by the ARM-Linux board via fstab setting configured below.

[root@host]$ echo "/SWAP.swap  none  swap  sw  0 0" >> /media/rootfs/etc/fstab

Synchronize and safely remove the card

[root@host]$ sync
[root@host]$ umount /media/rootfs

Y-cable for USB modem stick & various current rating-AC power adapters for smartphone/tablet to go with Raspberry Pi

eLinux Wiki lists market available USB-hubs reported to work. A decent brand (that will cost you) qualifies:

• Doesn’t leak power back to RPi via USB port (check this by unplugging the main power, then check the red LED indicator) as this will interfere with the reboot command (physical state vs software).
• Provides charging from one of its port for RPi, meaning no separate source for the exclusive 700 mA requirement. A single AC power adapter with high current rating will fit all (check single power connectivity sketch in this blog post)

An ugly situation when I plugged in WiFi stick and modem looks like:

kernel: [ 1836.871640] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
...
kernel: [ 1803.780601] phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x101c with error -110.

tail of the above syslog is saying error with the (1) ethernet (this is actually also a USB 2.0 but not appearing in lsusb command) and (2) the WiFi stick used (in this case with RT5370 chipset). Then, of course (3) doing things with the just plugged modem you’ll expect more instability.

I mentioned BeagleBoard-xM which also came with similar USB ethernet on-board. Unfortunately, Beagle was more stable when my case was to have it stream a zoom-camera input to internet (check my YouTube demo). The camera decoder and modem were both USB plugged without Y-cable or additional power supply. As a standalone system, part of the design was to reboot under trouble detected by the software. Again, OS command reboot is not achievable consistently with the RPi when power backfeeds through USB port.

(PS: Note that previous comparison solely points out what to expect when dealing with USB among other considerations e.g. price, different ARM, etc. which are entirely different.)

As an absolute requirement for me, I found a powered USB-hub available in Indonesian market as 7 ports XTec Go. Yes, it leaks power back as confirmed by the vendor-product ID 05e3:0608 of the chipset listed in eLinux Wiki lists with a bunch of different names (judging the picture, Hama is closest).

$ lsusb
...
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
...

Three Musketeers: powered USB-hub (Genesys chipset), Huawei E220 HSDPA modem, and TL-WN727N WiFi stick

My el cheapo USB-hub, HDSPA modem, and WiFi stick are the matchmaking of brands shown in the above image. It achieves long uptime like 6 hours serving internet when RPi used as router. I still use separate AC power adapter on the go with me: regular 700 mA that comes with smartphone will do for the RPi, while for the USB-hub, I have 2A rating from tablet charger. However, I’ve also plugged separate 500 mA charger for the hub without problem and/or excessive heat (you need to touch the supply sometime to feel any nasty heat as some of them might have been low quality build that could blow up. Yes it did). My plan with mobility is to have power bank with dual USB charging output (this Hame has 1A and 2.1A) when no AC source nears.

Have I tested other USB modem stick? Check my other post related to usb_modeswitch.

1. download source file (that is ffmpeg in this example)
2. retrieve development library/build dependecies
3. place header files and dependency libraries into toolchain path
4. configure with toolchain
5. make and create .deb installer package with checkinstall

cross-compile: Illustration of what's done on ARM-board and what's done on desktop

Prior to anything, install Linaro toolchain by adding their repo first:

$ sudo add-apt-repository ppa:linaro-maintainers/toolchain
$ sudo apt-get install gcc-arm-linux-gnueabi

A complete guide on how to compile ffmpeg can be found in their wiki. It applies generally. So, I’ll just skip to following configure:

[ubuntu-desktop]$ ./configure --cross-prefix=arm-linux-gnueabi- --enable-cross-compile --target-os=linux --arch=arm  --cpu=cortex-a8 --extra-cflags='-march=armv7-a -mfpu=neon -mfloat-abi=softfp' --enable-libtheora

As an example, the above configure requires Theora libraries. libtheora-dev itself requires libogg-dev. Use apt-get on the board to get them from Ubuntu ARM repository. Get the .deb files from /var/cache/apt/archives/ of the ARM-board to your desktop and extract them as root:

[root@ubuntu-desktop]$ dpkg -x libogg-dev_1.2.2~dfsg-1ubuntu1_armel.deb /usr/local/cross-compile
[root@ubuntu-desktop]$ dpkg -x libtheora-dev_1.1.1+dfsg.1-3_armel.deb /usr/local/cross-compile

The above /usr/local/cross-compile is just a temporary directory. The toolchain needs header files and dependency libraries to be placed inside /usr/arm-linux-gnueabi/include/ and /usr/arm-linux-gnueabi/lib/ consecutively. In my case I created the following link for header’s include:

[root@ubuntu-desktop]$ cd /usr/arm-linux-gnueabi/include
[root@ubuntu-desktop]$ ln -s /usr/local/cross-compile/usr/include/theora
[root@ubuntu-desktop]$ ln -s /usr/local/cross-compile/usr/include/ogg

and copied these from /usr/local/cross-compile/usr/lib:

libogg.a
libogg.so
libtheora.a
libtheoradec.a
libtheoradec.la
libtheoradec.so
libtheoraenc.a
libtheoraenc.la
libtheoraenc.so
libtheora.la
libtheora.so

After successful configure, run make (this will take some time), and then pack the whole working directory to the ARM-board. Instead of doing make install in the ARM-board, use checkinstall to install and create the .deb package. This way we can make use of dpkg to uninstall or re-install in the manner of package manager.

[root@beagleboard]$ sudo checkinstall --pkgname=ffmpeg --pkgversion="5:$(./version.sh)" \
     --backup=no --deldoc=yes --default

Please mind that even if we put “--install=no“, the above checkinstall will overwrite all ffmpeg binaries in /usr/local/bin/. This is the reason why I move the process to the ARM-board: to keep other running version on my desktop stays as it is.

Check the test of streaming from our cross-compiled ffmpeg in previous post.

A Little History

When first attempt to configure exited with ERROR: libtheora not found, I found the following test failed in the output log:

$ arm-linux-gnueabi-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -march=armv7-a -mfpu=neon -mfloat-abi=softfp -mcpu=cortex-a8 -std=c99 -fomit-frame-pointer -marm -pthread -E -o /tmp/ffconf.UdYctJgq.o /tmp/ffconf.mwXpf9Tl.c
...
/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../../arm-linux-gnueabi/bin/ld: cannot find -ltheoraenc
/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../../arm-linux-gnueabi/bin/ld: cannot find -ltheoradec
/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../../arm-linux-gnueabi/bin/ld: cannot find -logg

What was inside the above temporary file (/tmp/ffconf.mwXpf9Tl.c):

1
2

#include <theora/theoraenc.h>
int x;

You can run that test to check whether all dependencies are met.

$ ffmpeg -i UNIQLO_MIXPLAY.flv -v 0 -vcodec mpeg4 -f mpegts udp:192.168.1.19:1234

ffmpeg streaming from BeagleBoard played by VLC on the desktop

Although it’s a break-dance video, it plays uninterrupted, without any break.

Here is how my desktop see the stream with VLC player:

VLC setup (on the desktop) to play the UDP stream

With less documentation, a more complex setup with integration to Wowza Media Server is available on my github.

1. independent SNMP data polling by individual NMS proxy (embedded system)
2. intermittent connection between main/master NMS server with its proxy

Of course we’ll do them in implementation context of Zabbix Server as main/master NMS server and our BeagleBoard xM as its proxy.

Zabbix Proxy - distributed NMS over embedded Linux

In the technical details, I already followed pretty much the same steps showed in installation wiki (with the exception that I didn’t put the process into startup init.d script as I would start it manually as needed).

The first test is to make our Ubuntu ARM board accepts configuration done in Zabbix Server web-GUI, retrieves SNMP data to it, and sends collected data to server. Mode passive is chosen so that the server will be the one initiating contact with the board. After enabling a certain SNMP host, i.e. host-aaa, as monitored-by-proxy, the Zabbix Server log will show:

15677:20120601:022022.960 Sending configuration data to proxy 'beaglexm1'. Datalen 9205

Our board, ‘beaglexm1‘, will start to poll SNMP data from host-xxx to then store it in designated sqlite database.

975:20120531:212024.098 proxy #8 started [poller #5]
984:20120531:212024.128 proxy #17 started [discoverer #1]
968:20120531:212025.423 Received configuration data from server. Datalen 9205
971:20120531:212030.388 Enabling SNMP host [host-aaa]

From time to time as configured, our board will also run housekeeping to keep our board database file in small size.

1081:20120531:224513.922 Executing housekeeper
1081:20120531:224514.505 Deleted 4885 records from history [0.453765 seconds]

Under normal connection, in main Zabbix Server we’ll start seeing the collected data from host-aaa the same way as when the SNMP data is polled by the server directly. To emulate disruption to the connectivity, I choose to use simple iptables drop packet. This time the server will no longer seeing new data.

After the drop block is released, the server we’ll start seeing new data as well as data from the period of intermittent connection. It will take some time before all of that being sent to the server.

In general that proves it. I collected 44 OID values from the host-aaa every 30 seconds and in this case BeagleBoard utilization was very low as this wasn’t a stress test to see its performance.

Zabbix Proxy Distributed NMS

An example set out for Zabbix Proxy on Debian appears to be pretty straightforward to follow. With the ARM board already installed with build-essential, snmp, and snmpd, the following needs to be added:

$ sudo apt-get install libsnmp-dev libcurl4-openssl-dev fping curl sqlite libsqlite3-dev ntpdate

then start the pre-compilation configure (in this case Zabbix 1.8.7 is used):

cd zabbix-1.8.7
./configure --enable-proxy --enable-agent --with-sqlite3 --with-net-snmp --with-libcurl

It will go smooth. However, during make there are complains about undefined references to ‘sqlite3_open‘, ‘sqlite3_close‘, etc.:

../../src/libs/zbxdb/libzbxdb.a(db.o): In function `zbx_db_connect':
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:331: undefined reference to `sqlite3_open'
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:343: undefined reference to `sqlite3_busy_timeout'
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:334: undefined reference to `sqlite3_errmsg'
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:335: undefined reference to `sqlite3_close'
../../src/libs/zbxdb/libzbxdb.a(db.o): In function `zbx_db_init':
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:385: undefined reference to `sqlite3_open'
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:387: undefined reference to `sqlite3_errmsg'
../../src/libs/zbxdb/libzbxdb.a(db.o): In function `zbx_db_close':
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:446: undefined reference to `sqlite3_close'
../../src/libs/zbxdb/libzbxdb.a(db.o): In function `zbx_db_vexecute':
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:827: undefined reference to `sqlite3_exec'
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:852: undefined reference to `sqlite3_changes'
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:833: undefined reference to `sqlite3_free'
../../src/libs/zbxdb/libzbxdb.a(db.o): In function `SQ_DBfree_result':
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:1363: undefined reference to `sqlite3_free_table'
../../src/libs/zbxdb/libzbxdb.a(db.o): In function `zbx_db_vselect':
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:1121: undefined reference to `sqlite3_get_table'
/home/zabbix/zabbix-1.8.7/src/libs/zbxdb/db.c:1127: undefined reference to `sqlite3_free'

this is obviously from the database related code compilation. I run the gcc manually for the db.c file inside its directory by adding the flag ‘-lsqlite3‘ in the tail of ‘../../src/libs/zbxdb/libzbxdb.a‘ to make it work. Afterward by going to the initial directory first, running make again will then continue successfully.

$ cd src/zabbix_proxy
$ gcc -DZABBIX_DAEMON -g -O2     -L/usr/lib/arm-linux-gnueabi    -I/usr/local/include -I/usr/lib/perl/5.12/CORE -I. -I/usr/include      -I/usr/include -lsqlite3  -L/usr/lib/arm-linux-gnueabi -lcurl  -L/usr/lib -lnetsnmp -lcrypto  -L/usr/lib -lnetsnmp -lcrypto   -rdynamic    -o zabbix_proxy zabbix_proxy-servercomms.o zabbix_proxy-events.o zabbix_proxy-zlog.o zabbix_proxy-proxy.o heart/libzbxheart.a ../../src/zabbix_server/dbsyncer/libzbxdbsyncer.a ../../src/zabbix_server/discoverer/libzbxdiscoverer.a housekeeper/libzbxhousekeeper.a ../../src/zabbix_server/httppoller/libzbxhttppoller.a proxyconfig/libzbxproxyconfig.a ../../src/zabbix_server/pinger/libzbxpinger.a ../../src/zabbix_server/poller/libzbxpoller.a ../../src/zabbix_server/trapper/libzbxtrapper.a ../../src/zabbix_server/nodewatcher/libzbxnodewatcher.a datasender/libzbxdatasender.a ../../src/zabbix_server/selfmon/libzbxselfmon.a ../../src/libs/zbxsysinfo/libzbxserversysinfo.a ../../src/libs/zbxsysinfo/linux/libspecsysinfo.a ../../src/libs/zbxsysinfo/common/libcommonsysinfo.a ../../src/libs/zbxsysinfo/simple/libsimplesysinfo.a ../../src/libs/zbxlog/libzbxlog.a ../../src/libs/zbxdbcache/libzbxdbcache.a ../../src/libs/zbxmemory/libzbxmemory.a ../../src/libs/zbxalgo/libzbxalgo.a ../../src/libs/zbxnix/libzbxnix.a ../../src/libs/zbxsys/libzbxsys.a ../../src/libs/zbxconf/libzbxconf.a ../../src/libs/zbxcommon/libzbxcommon.a ../../src/libs/zbxcrypto/libzbxcrypto.a ../../src/libs/zbxcomms/libzbxcomms.a ../../src/libs/zbxcommshigh/libzbxcommshigh.a ../../src/libs/zbxjson/libzbxjson.a ../../src/libs/zbxexec/libzbxexec.a ../../src/libs/zbxself/libzbxself.a ../../src/libs/zbxserver/libzbxserver.a ../../src/libs/zbxicmpping/libzbxicmpping.a ../../src/libs/zbxdbhigh/libzbxdbhigh.a ../../src/libs/zbxdb/libzbxdb.a -lsqlite3 -lcurl  -lnetsnmp    -lm  -lresolv
$ cd ../../
$ make

ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument

TP Link TL-WN321G USB WiFi Stick

Within minutes it will also crash the system with messages similar to:

kernel: [ 5645.279693] SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount ETM buffer dump show-blocked- tasks(W) dump-ftrace-buffer(Z)

The correct way to attach is

wpa_supplicant -B -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf

The config file content is just like what the community help suggested. The stick with vendor & product ID of 148f:2573 has been part of the nl80211 development at Linux Wireless.

wpa_supplicant version is v0.7.3. Ubuntu version is 11.10 as described further in previous post.

$ modprobe -v usbserial vendor=0x05c6 product=0x0015

or (2) usb-modeswitch, (3) Matthias Urlichs initially wrote option.c driver as a way to insert USB modem as kernel module.

This driver exists because the “normal” serial driver doesn’t work too well
with GSM modems. Issues:
- data loss — one single Receive URB is not nearly enough
- nonstandard flow (Option devices) control
- controlling the baud rate doesn’t make sense

Most modems will be successfully attached with this driver, appearing in one of the typical /dev/ttyUSB0 to /dev/ttyUSB2. The product ID 0x0015 for GSM modem compiled here is a Qualcomm (vendor ID 0x05c6) OEM modem I received from Embest DevKit8500D order. There are more than one form factor when searching for its images on Google. Closest one we have in Indonesia is ADVAN DT8-HT bundled in Telkomsel Flash.

Qualcomm 05c6:0015 from Indonesian operator

I’m compiling it for the Beagleboard xM Rev C running Ubuntu Oneiric (installed in this post). A quick look gives:

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 005: ID 05c6:0015 Qualcomm, Inc.

The above 0x0015 product ID doesn’t exist inside option.c of linux kernel 3.0.0-12 source. Adding this to series of existing Qualcomm modems gives:

635
636
637

	{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6000)}, /* ZTE AC8700 */
	{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
	{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0015)}, /* Qualcomm no brand */

The include also needs usb-wwan.h from that kernel source. Copy them both under /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/. For other include files, install:

1. linux-headers-3.0.0-12_3.0.0-12.20_all.deb
2. linux-image-3.0.0-12-omap_3.0.0-12.20_armel.deb

and create this link as root

1
2

$ cd /usr/src/linux-headers-3.0.6-x3/include/
$ ln -s /usr/src/linux-headers-3.0.0-12/arch/arm/mach-versatile/include/mach mach

After removing the old one (pointed to build -> /build/buildd/linux-3.0), create a link inside /lib/modules/3.0.6-x3 named build pointing to:

build -> /usr/src/linux-headers-3.0.6-x3

Modify the original Makefile to contain only rule for option.o

obj-m			+= option.o

and then build the driver

$ make -C /lib/modules/3.0.6-x3/build/ M=/usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/
make: Entering directory `/usr/src/linux-headers-3.0.6-x3'
  LD      /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/built-in.o
  CC [M]  /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/option.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/option.mod.o
  LD [M]  /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/option.ko
make: Leaving directory `/usr/src/linux-headers-3.0.6-x3`

Copy the build and deploy

$ cp /usr/src/linux-headers-3.0.6-x3/drivers/usb/serial/option.ko /lib/modules/3.0.6-x3/kernel/drivers/usb/serial/
$ depmod -a

Now syslog will show the following lines if the modem is inserted:

kernel:[ 4790.229888] usb 1-2.5: GSM modem (1-port) converter now attached to ttyUSB0
kernel:[ 4790.237121] option 1-2.5:1.0: GSM modem (1-port) converter detected
kernel:[ 4790.238250] usb 1-2.5: GSM modem (1-port) converter now attached to ttyUSB1
kernel:[ 4790.240142] option 1-2.5:1.1: GSM modem (1-port) converter detected
kernel:[ 4790.241210] usb 1-2.5: GSM modem (1-port) converter now attached to ttyUSB2
mtp-probe: checking bus 1, device 9: "/sys/devices/platform/usbhs-omap.0/ehci-omap.0/usb1/1-2/1-2.5"
mtp-probe: bus: 1, device: 9 was not an MTP device
kernel:[ 4791.227294] scsi 2:0:0:0: Direct-Access     Qualcomm MMC Storage      2.31 PQ: 0 ANSI: 2
kernel:[ 4791.232238] sd 2:0:0:0: Attached scsi generic sg0 type 0
kernel:[ 4791.246887] sd 2:0:0:0: [sda] Attached SCSI removable disk

Easycap USB Video-Audio Capture

It turned out that this custom kernel hadn’t been compiled without Easycap. We can compare that to my laptop running linux 2.6.38-10 where it was part of its kernel compilation:

[ubuntu-laptop]$ cat  /usr/src/linux-headers-2.6.38-10/.config | grep -i easy
CONFIG_EASYCAP=m

Compiling the whole thing using make menuconfig to change .config file and so on seemed too much. A more partial approach was to touch only relevant Makefile involved in building the driver. First we needed the kernel header files provided as linux-headers-3.0.6-x3_1.0oneiric_armel.deb and then source files for Easycap. As this was custom kernel, by guessing I found that it was closest to official linux 3.0.0-12.20 at launchpad, hence easycap source files were copied from it (the custom kernel might’ve been forked from this release as some random header files comparison to linux-headers-3.0.0-12-omap_3.0.0-12.20_armel returned no difference).

FYI Easycap linux driver is no longer developed separately as a SourceForge project, it has been part of drivers/staging in recent kernel releases (where you get dmesg like “module is from the staging directory, the quality is unknown, you have been warned” when inserting it). In the source we’ll find /linux-3.0/drivers/staging/easycap/ to be copied into /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/ on the board.

After removing the old one (pointed to build -> /build/buildd/linux-3.0), I created a link inside /lib/modules/3.0.6-x3 named build pointing to:

build -> /usr/src/linux-headers-3.0.6-x3

then copied the Makefile from my laptop to replace original Easycap source with this content of rules:

obj-m	+= easycap.o
 
easycap-y	:= easycap_main.o easycap_low.o easycap_sound.o
easycap-y	+= easycap_ioctl.o easycap_settings.o
easycap-y	+= easycap_testcard.o
 
ccflags-y := -Wall
# Impose all or none of the following:
ccflags-y += -DEASYCAP_IS_VIDEODEV_CLIENT
ccflags-y += -DEASYCAP_NEEDS_V4L2_DEVICE_H
ccflags-y += -DEASYCAP_NEEDS_V4L2_FOPS
ccflags-y += -DEASYCAP_NEEDS_UNLOCKED_IOCTL

Compiling should work afterward:

$ make -C /lib/modules/3.0.6-x3/build/ M=/usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/
  LD      /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/built-in.o
  CC [M]  /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/easycap_main.o
  CC [M]  /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/easycap_low.o
  CC [M]  /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/easycap_sound.o
  CC [M]  /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/easycap_ioctl.o
  CC [M]  /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/easycap_settings.o
  CC [M]  /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/easycap_testcard.o
  LD [M]  /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/easycap.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/easycap.mod.o
  LD [M]  /usr/src/linux-headers-3.0.6-x3/drivers/staging/easycap/easycap.ko
make: Leaving directory `/usr/src/linux-headers-3.0.6-x3'

I tried to insmod the easycap.ko built, but dmesg showed some error and no /dev/video0 created. There must be some other drivers that must be loaded first which I didn’t know in what sequence (i.e. v4l2-common etc.), hence I decided to just copy that under the /lib/modules/3.0.6-x3/kernel/drivers/staging/easycap, depmod -a, and reboot.

If you plug the Easycap while inspecting the syslog tail, there won’t be similar message as found in kernel 2.6.38-10. Instead, you’ll see:

kernel: [ 1377.696838] usb 1-2.3: new high speed USB device number 6 using ehci-omap
mtp-probe: checking bus 1, device 6: "/sys/devices/platform/usbhs-omap.0/ehci-omap.0/usb1/1-2/1-2.3"
mtp-probe: bus: 1, device: 6 was not an MTP device
kernel: [ 1378.052459] Linux video capture interface: v2.00
kernel: [ 1378.169006] Easycap version: 0.9.01
kernel: [ 1378.198944] usbcore: registered new interface driver snd-usb-audio
kernel: [ 1381.043853] easycap::0adjust_standard: selected standard: PAL_BGHIN
kernel: [ 1381.151245] easycap::0adjust_format: sought:    640x480,UYVY(0x59565955),1=field,0x00=std mask
kernel: [ 1381.151306] easycap::0adjust_format: sought:    V4L2_FIELD_NONE
kernel: [ 1381.151336] easycap::0adjust_format: actioning: 640x480 PAL_BGHIN_AT_640x480_FMT_UYVY-n
kernel: [ 1381.181488] easycap::0adjust_brightness: adjusting brightness to  0x7F
kernel: [ 1381.184478] easycap::0adjust_contrast: adjusting contrast to  0x3F
kernel: [ 1381.212768] easycap::0adjust_saturation: adjusting saturation to  0x2F
kernel: [ 1381.214599] easycap::0adjust_hue: adjusting hue to  0x00
kernel: [ 1381.219207] easycap::0easycap_usb_probe: registered with videodev: 0=minor
kernel: [ 1381.219238] easycap::0easycap_usb_probe: ends successfully for interface 0
kernel: [ 1381.219543] usbcore: registered new interface driver easycap
kernel: [ 1381.314453] easycap:: easycap_open: ==========OPEN=========
kernel: [ 1384.031188] easycap::0adjust_standard: selected standard: PAL_BGHIN
kernel: [ 1384.228759] easycap::0adjust_format: sought:    640x480,UYVY(0x59565955),1=field,0x00=std mask
kernel: [ 1384.228790] easycap::0adjust_format: sought:    V4L2_FIELD_NONE
kernel: [ 1384.228851] easycap::0adjust_format: actioning: 640x480 PAL_BGHIN_AT_640x480_FMT_UYVY-n
kernel: [ 1384.233489] easycap::0adjust_brightness: adjusting brightness to  0x7F
kernel: [ 1384.235198] easycap::0adjust_contrast: adjusting contrast to  0x3F
kernel: [ 1384.237884] easycap::0adjust_saturation: adjusting saturation to  0x2F
kernel: [ 1384.239501] easycap::0adjust_hue: adjusting hue to  0x00

Later I find out that newer image is available on the Robert’s site, but not sure which linux source I should use for the Easycap if I were to to use it. Anyway, before deciding to just go with this one I’ve tried various kernels. Here are list of images and their kernel versions (I wasn’t quite sure which one was running smoothly and which wasn’t):

1. linux-2.6.35.9-l9 Ubuntu 10.04 Lucid: ubuntu-10.04.1-r4-minimal-armel.tar
2. linux-3.1.4-x6 Ubuntu 11.10 Oneiric: ubuntu-11.10-r2-minimal-armel.tar.xz
3. linux-3.1.4-x6 Ubuntu 11.04 Natty: ubuntu-11.04-r7-minimal-armel.tar.xz
4. linux-2.6.38.2-d9 Ubuntu 10.10 Maverick: ubuntu-10.10-r6-minimal-armel.tar.xz

I bricked one of these DevKit8500D by overvoltaged it to 12V DC. Yes, It has no regulator.

Various howto made net-boot or preinstalled images seem feasible, but trying them is another thing. The first attempt was to boot Ubuntu Lucid 10.04 LTS to have similar distribution as my laptop, but it would stop at boot with the message

Error: unrecognized/unsupported machine ID (r1 = 0x00000ae9).

The above ID (2793 in decimal) isn’t found in Lucid released with linux 2.6.32-21. Ubuntu Natty 11.04 boot image didn’t complain because the ID already listed in /usr/src/linux-source-2.6.38/arch/arm/tools/mach-types

...
 nemini                  MACH_NEMINI             NEMINI                  2793
...

However, ubuntu-11.04-preinstalled-headless-armel+omap.img.gz wouldn’t finish loading the linux kernel 2.6.38 somehow. Hence, I replaced the root file system using rootfs created using RootStock method. After successful boot, I installed linux-image-2.6.38-8-omap_2.6.38-8.42_armel.deb to have the rootfs kernel lib files updated (this would require wireless-crda dependency to be installed).

Creating Lucid RootStock & Replacing Natty’s

Using RootStock relies much on the host environment, in my case (version 0.1.99.3) the laptop has Lucid with 2.6.38 kernel (Natty), and it failed to create rootfs with option --dist natty by stopping at this QEMU error:

qemu: fatal: cp15 insn ee1d6f70
 
R00=4009f960 R01=420822e8 R02=0d696914 R03=000086a8
R04=00008ef0 R05=00000000 R06=000097c9 R07=42082308
R08=00020040 R09=00000000 R10=4009f000 R11=00000000
R12=00008b88 R13=4007f7f8 R14=4008f450 R15=4008aea0
PSR=20000030 --C- T usr32

DevKit8500D also freezed on boot when too many seeds used in the rootfs. A minimal seeds of Lucid rootfs used is

[ubuntu-laptop]$ sudo rootstock --fqdn omap --login ubuntu --password temppwd --imagesize 2G --seed wget,nano,linux-firmware,wireless-tools,usbutils --dist lucid --serial ttyO2 --components "main universe multiverse"

It will retrieve many packages from http://ports.ubuntu.com which takes long and produces i.e. armel-rootfs-201110261541.tgz.

A card at /dev/sdb with Natty boot images are obtained by

gunzip -c ubuntu-11.10-preinstalled-server-armel+omap.img.gz | sudo dd bs=4M of=/dev/sdb

The root file system will reside at /dev/sdb2 while boot images are in /dev/sdb1. To replace this with Lucid rootfs, run following steps

1
2
3
4
5
6

dd if=/dev/zero of=lucid-arm.img bs=1MB count=0 seek=1024
sudo mkfs.ext3 -F lucid-arm.img
sudo mount -o loop lucid-arm.img /mnt
sudo tar -C /mnt -zxf armel-rootfs-<some rootstock generated date>.tgz
sudo umount /mnt
sudo dd if=lucid-arm.img of=/dev/sdb2 bs=1MB count=0 seek=1024

There are reasons for why-not-using the included Ångström Linux (forked to linux-2.6.32-devkit8500) but this method of booting Ubuntu wasn’t straightforward after all. The on-board LAN (using Davicom DM9000AEP chip) doesn’t work and I need to use USB ethernet detected as Davicom DM9601 (a bit ridiculous?). Easycap USB video capture also works with this kernel as it has been part of 2.6.38 drivers/staging compilation.

DM9601 USB LAN

Before coming up with this combo, I’ve tried:

1. Ubuntu Lucid 10.04 CD Image: ubuntu-10.04-server-armel+omap.img
2. Ubuntu Oneiric 11.10 CD Image: ubuntu-11.10-preinstalled-server-armel+omap.img.gz
3. Robert C. Nelson’ Oneiric: ubuntu-11.10-r0-minimal-armel.tar.xz (as pointed out by the above eLinux page which has changed quite regularly since October 2011)

But nothing seemed to work.