Updated: for those who fail to build using deprecated WiringPi-Python, check this updated post to know which commit that build without error. There is now also a Python class for matrix keypad.

My idea of having the keypad is to make alternative input available under no keyboard presence nor shell access. List of things I can think of for instances, pressed key “0″ will make the Raspberry Pi (RPi) dial GPRS to a specific ISP and act as router to the USB WiFi stick, pressed key “7″ will convert it to a router that will bridge the ethernet to WiFi, etc. In short, those key readings will invoke subsequent scripts to run inside RPi.

The physical connection schematic drawings and code are gitified (visit v1.2 of the project on gitHub). A nice animated image on how the buttons connect pins forming a matrix can be found in hackyourmind.org.

Matrix keypad: alternative quick input for Raspberry Pi to start certain command

Some remarks over what the code does:

• It only read one pressed key at a time.
• It uses no interrupt. To read input it must wait and scan (this waiting experience is by far negligible to human sense).
• Debouncing doesn’t seem necessary as WiringPi already provided this by software (I suppose this timing method on their gitHub deals with debounce).

How it works? RPi forum thread gives a general idea that applies in my case:

1. Divide the 3×4 matrix as columns and rows. 4 GPIO pins as rows are pulled-up with 10k resistors and initialized as input.
2. Other 3 GPIO pins as columns are initialized as output low.
3. First loop will scan for one pressed key being read as one of the rows pulled-low
4. After the loop breaks, all columns are set as input, then the row pin found in the loop is set as output-high
5. Second loop will scan for column being pulled-high by that row pin. Between both loops, it is assumed that the key press is still in effect. In reality, normal human act of pressing this key elapses long enough for the software to run the scans in two loops.
6. Bingo! The code reads row-column combination of the pressed key.

Example of the code’s output by calling from shell:

$ while true; do /usr/local/bin/matrixQPi.py -i; done
3
6
9
8
#
*

(In the above example ^C will throw Python KeyboardInterrupt messages before breaking the bash loop)

GPIO pin logic state (meaning voltage) are both programmable and driven by physical-connection. I choose wiringPi for practical reasons: availability of its Python wrapper and its simple syntax (glancing it at first sight). WiringPi has an option of using its own pin numbering to address it in the code instead of the original GPIO numbering (there are board revisions to watch for in some cases of usage, not mine). Every pin can be initialized as input or output.

Updated: Wiring-Pi Python is deprecated and moving to 2.x version that supports I/O expander. However, you can still find this combination of commits that will work and build without error message:

- main module: WiringPi-Python@9c77bde
- submodule: WiringPi@89bbe97

(Check how to build on my README)

Using an analog multitester, here are behavioral findings:

• GPIO pin voltage swings to high logic after reboot (the meter’s needle is rocking for a second or so). It is in low voltage afterward until being programmed or physically pulled-up.
• Two pins, wiringPi pin 8 and 9, remain in high logic voltage after reboot. They are SDA0 and SCL0 to be used as an I²C, however they can be used to read button as well. (eLinux Wiki: “there are 1.8 k pulls up resistors on the board for these pins”)
• I did short the high logic to ground accidentally, it invoked reboot. (I don’t know how many times or how long of this will brick the Raspberry Pi)

Prior to trying the push-button switch, I didn’t have proper circuitry and working with wires as probes, prone to accident that was. I found an advice to insulate the +5V pin voltage so I could worry less.

Insulate the +5V pin of Raspberry Pi

A 10k pull-up resistor and a button are enough to test the following. Go to interactive Python shell and run line by line until the button push is read as low logic (GPIO7 in this example):

# python
Python 2.7.3rc2 (default, May  6 2012, 20:02:25) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import wiringpi
>>> import time
>>> INPUT=0
>>> OUTPUT=1
>>> HIGH=1
>>> LOW=0
>>> SETUP=wiringpi.wiringPiSetup()
>>> print SETUP
0
>>> wiringpi.pinMode(7,INPUT)
>>> RESULT=wiringpi.digitalRead(7)
>>> print RESULT
1
>>> RESULT=wiringpi.digitalRead(7)
>>> print RESULT
1
>>> RESULT=wiringpi.digitalRead(7)
>>> print RESULT
0
>>>

These basics convince me to go ahead with my goal of having a membrane (matrix) keypad as input for Raspberry Pi to run some script (see next post).

(Check also RPi common USB problems post)

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

A “Hello World” class to test the JVM will be:

class HelloWorldJamVM {
	public static void main(String[] args) {
		System.out.println("hello world");
	}
}

saved as HelloWorldJamVM.java. However, executing a “Hello World” requires longer steps than writing that class.

In order for the JamVM 1.5.4 to run on Ubuntu, we need (1) build-essential (certainly so) and (2) GCJ with dependency of (3) zlib1g-dev. It’s all available in the Karmic ARM repo. Another thing that we need is GNU Classpath 0.98.

Following the instruction, as root we can then configure, make, make install, make install-strip sources under jamvm-1.5.4 directory. Continue them with the classpath-0.98 sources by configuring as follow

./configure --disable-gtk-peer --disable-gconf-peer --disable-plugin --disable-Werror

and then make install as usual. The whole compiling will run slow for sure as QEMU emulates ARM far from nearing native processor performance in my case.

We can compile the above “Hello World” using GCJ with the command javac, which is actually linked to /usr/bin/gcj-wrapper-4.4.

javac HelloWorldJamVM.java

A HelloWorldJamVM.class bytecode file will appear and we can run this with JamVM

PATH=$PATH:/usr/local/jamvm/bin 
export PATH
jamvm HelloWorldJamVM

QEMU with Ubuntu ARM Cortex A8 running JamVM embedded JVM

Ready-to-use image for from the old Ubuntu 9.10 Karmic is avalaible as suggested in RootStock Wiki .

To run Ubuntu 10,04 Lucid you can create similar .img filled by RootStock generated root file system as described in this post generating lucid-arm.img. Boot image is obtained from Lucid port page, of which I saved with the name vmlinuz-lucid-current-ports which is actually linux kernel 2.6.32-21. Running QEMU is then:

qemu-system-arm -M versatilepb -cpu cortex-a8 \
  -kernel vmlinuz-lucid-current-ports \
  -hda lucid-arm.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"

However, adding -redir tcp:3232::22 isn’t directly working (although telnet is showing both directions are functional). This redirection is working with the Karmic image which gives instant ssh on my host laptop as in:

ssh localhost -oPort=3232 -l ubuntu

Note: successful QEMU machine image probably won’t boot successfully with the real board. I can’t use kernel 2.6.38-10 for Lucid rootfs on QEMU, but successfully boot that on DevKit8500D board.

QEMU console of Ubuntu 10.04 VM

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.