Page 1 of 1

problem E170 on an embedded system

Posted: 13 May 2008, 14:38
by SR_FHTW
Hello,

I'm writing my diploma thesis and I need help to switch the Huawei E170 (T-Mobile wnw Stick III) to the modem mode. The Problem is that USB_ModeSwitch can't find the usb-storage device. Does the E170 need to be switched?
The emulated CD-ROM is recognized as /dev/sr0. On WinXP vendor-id=0x12d1 product-id=1003 for that storage device. These are the same properties as for the E220, so I configured them as defaults. At the moment the target is unknown for me.

Host-System:
- ARM9-based eval.-board
- linux 2.6.15 Kernel
- 8 MiB usable Flash-Memory, 240 KiB free
- 32 MiB RAM
- USB 1.1
- NFS-Shares mounted
- Kernel-Modules: usbcore, usb-storage, sr_mod, ppp_generic, ppp_async,...
- /proc/bus/usb is always empty

Devel-System:
- openSUSE 10.3 vmware server Image, VNC-Server
- GNU cross-compiling tool-chain
- uClibc C standard library
- stdc++ library
- cross-compiled libusb
- NFS-, Samba-Server
----------------------------------------
- WinXP-System with VNC-Client
- Putty, Cygwin, etc.

Posted: 14 May 2008, 20:49
by SR_FHTW
O.K. I've found the first solution. I forgot to mount the usbfs.
Now, the mode changing message can be sent to the Huawei E170 but still no response from the device recognizable.

Has anyone an idea to help me?

Posted: 15 May 2008, 10:45
by joke_dst
Yes, it needs to be switched, although it keeps the same codes after switching.

My scripts start by having no usb-storage or usbserial modules loaded, then run

usb_modeswitch -v 0x12d1 -p 0x1003 -H 1

Then wait 2 seconds, then load the usbserial module

insmod lib/modules/2.4.25-386/usbserial.o

Note that you might have to specify the codes for this card, which means you either must have a version of usbserial that can take numbers as parameters, like this:

insmod lib/modules/2.4.25-386/usbserial.o vendor=0x12d1 product=0x1003

Or you recompile the usbserial module with the codes in it already, which I did. Modifying the kernel perhaps isn't an option for you though, so try the parameters instead.

Then I sleep another 2 seconds and the interface /dev/ttyUSB0 is up and ready to be used. This can most easily be tested by running


cat /dev/ttyUSB0 &
echo AT > /dev/ttyUSB0
sleep 1
killall cat

You should se something like

AT
OK

on the screen. After that start dialing (using pppd or whatever). Good luck! :)

Posted: 19 May 2008, 09:29
by SR_FHTW
Thanks, you helped me.

Now I can load usbserial.ko and the E170 is switched every time I connect it (udev rule + script), but the next Problem occurs. ttyUSB* does not exist. General usb serial support is not enough. The USB devices 00 and 01 have vendor specific classes (ff), so I need a special usb serial kernel module.

Which module are you using and wich kernel version? I can't even find wich chipset is used on Huawei E170.

Posted: 19 May 2008, 13:05
by joke_dst
I'm using both kernel 2.4.25 and 2.6.14, with just about the same modifications to the modules (in 2.4 it's <kernel>/drivers/usb/serial/usbserial.c, and in 2.6 I'm using <kernel>/drivers/usb/serial/airprime.c)

I just add the card id's to the usb_device_id lists (generic_device_ids in usbserial.c or id_table in airprime.c). Example:

Code: Select all

static struct usb_device_id generic_device_ids[] = {
	{ USB_DEVICE(0x05f9, 0xffff) },  //? Default values, no clue what it is
	{ USB_DEVICE(0x12d1, 0x1001) },  //Huawei E169G & Co
	{ USB_DEVICE(0x12d1, 0x1003) },  //Huawei E220 & Co
	{ } /* Terminating entry */
};
Hope it helps

Posted: 21 May 2008, 11:33
by SR_FHTW
Thank you very much! It runs.
Now I can communicate with the ttyUSB0 via picocom and write my ppp/chat scripts.

I modified the airprime.c driver, in <kernel-src>/drivers/usb/serial/ and made my own huawei.c driver. I also made the registration in Makefile, Kconfig and the kernel config.
I created my own installer/patcher for the linux distribution for the evaluation- and development-board (Mobilygen Comet-MG1264).

I wait for the new Mobilygen Chamelion-MG3500 Board. It will have the 2.6.18 Kernel so I have to port my solution.
In kernel >= 2.6.20 the driver option.c is more comfortable because it already switches the mode and has more features such like speed reducing.