Now it’s almost automatically attached as modem after insertion and people have been contributing to list of device-and-target device after mode-switching (find it as /usr/share/usb_modeswitch/configPack.tar.gz). At least for Raspberry Pi (RPi), I have one device list from August 2012 when playing around with XBian 0.8.3 and one from May 2012 in when using Raspbian Wheezy (2012-08-16).

Huawei E220 requires no mode-switch from vendor-product ID 12d1:1003 to function as modem

There is still wrapper for udev in /lib/udev/rules.d/40-usb_modeswitch.rule and my Huawei E153 HSDPA stick recognized and switched successfully as shown:

usb_modeswitch: switching device 12d1:1446 on 001/005
...
logger: usb_modeswitch: switched to 12d1:14ac on 001/006

But I didn’t get there in the first place. Because of USB power problem (detailed in previous post), I used to plug USB devices before powering up so that I could use Y-cable injected by separate power source without powered USB-hub. It turned out that if I had plugged the USB before powering up the RPi the mode-switching didn’t occur.

The HSDPA USB modem used is Huawei E153 appearing in lsusb with vendor-product ID 12d1:1446. Using aforementioned XBian and target device 12d1:140c (suggested in Santinoli’s post), I arbitrarily succeeded to switch to modem and dial internet with pppd.

[root]$ usb_modeswitch -v 12d1 -p 1446 -P 140c

(I placed Santinoli’s config in /etc/usb_modeswitch.conf)
This wasn’t stable however (also note that XBian consumed CPU above 50% for xbmc).

Later I find out that it will automatically switch to 12d1:14ac instead when plugged in after RPi is up. However, since it also won’t switch if plugged before power-up, I also try to mode-switch manually using config file found inside /usr/share/usb_modeswitch/configPack.tar.gz archive named 12d1:1446.

[root]$ usb_modeswitch -v 12d1 -p 1446 -c 12d1\:1446

It doesn’t seem to work. Modification to something close to my previous config also fails. Hence, consistent result only occurs if the stick is plugged in after RPi up. Then I decide to use USB-hub (also detailed in previous post) to tackle power issue (it will reboot anyway if you plug in without adequate powering). However, after successful mode-switch what’s being reported in eLinux Wiki often happens: it slows down, try lsub command for example.

Currently I give up the idea of using that modem and choose older Huawei E220:

1. No usb_modeswitch. Driver attached directly by the kernel as option.ko device (this device has been on the list for long)
2. Stable. No slowing down

The E153 modem itself has been implemented to stream video using the higher ARM type BeagleBoard-xM without significant stability issue (check my YouTube demo). It mode-switched when powering up Ubuntu on the Beagle.

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.

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