Re: Some experiments with the SIMCOM SIM5216E modem on a ARM926 board

[Jean-Christian de Rivaz <jc@eclis.ch>]

[-- Attachment #1: Type: text/plain, Size: 6355 bytes --]

Hi Marcel,

>> It's a mystery for me if Simcom do there own software or only use the
>> Qualcamm one. The chipset of this modem is the QSC6270 and I expected
>> that ofono already have something appropriate. I suspect the "g1" driver
>> to be a close match and if fact it work already quite well. Are you
>> willing to accept a new modem plugin that is basically a copy of the "g1" ?
>
> I expect a new modem plugin for the sim900. So that approach is fine.
>
> However using the g1 driver as a base is a bad example. That driver is
> bit-rotting a lot.

Ok, I didn't known that. Maybe the SIMCOM5216 need the same 
"bit-rotting" as the g1. We will see.

> Let me ask this differently. What are the GSM/UMTS features that you
> actually need for your product?

Power control, SIM pin code, manual or automatic operator selection, 
signal strength indication, Voice call dial/receive/hangup, SMS 
send/receive, and GPRS TCP/IP link.

>>> With USB as transport you really wanna do modem detection via udev. So
>>> you might wanna get this solved with uclibc.
>>
>> After some additional work I was getting udev working on the target. But
>> understanding how the udev ofono rules should be written for a composite
>> device is really hard. I did not found an example on how this should be
>> done to set both OFONO_DRIVER _and_ OFONO_LABEL. I was also confused by
>> the fact that there is two plugins that handles the udev events: udev
>> and udevng.
>
> Send the section for your device from /sys/kernel/debug/usb/devices. I
> can have a look then.

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  3 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=05c6 ProdID=9000 Rev= 0.00
S:  Manufacturer=SimTech, Incorporated
S:  Product=SimTech SIM5216
C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
E:  Ad=85(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=5ms
E:  Ad=87(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

The SIMCOM documentation say:

USB interface is mapped to five virtual ports: “SIMTECH USB Modem”, 
“SIMTECH NMEA Device”, “SIMTECH ATCOM Device”, “SIMTECH Diagnostics 
interface” and “SIMTECH Wireless Ethernet Adapter”. UART, “SIMTECH USB 
Modem” and “SIMTECH ATCOM Device” could respond to AT command, and URC 
report to these three ports at the same time, but user could set 
dedicated port to receive URC (Unsolicited Result Code).

But experiment show that only the If#=2 and If#=3 are able to handle the 
AT commands, so I suspect that the doc don't list them in the good 
order. I was unable to see anything on the other interfaces. The If#=1 
even hang microcom if I try to send any char on it. The If#=3 was the 
only one that the Linux USB cdc_acm driver was ok to recognize as a 
serial port:

usb 1-1: new full speed USB device number 5 using ohci
ohci ohci.0: GetPortStatus(1)
usb 1-1: skipped 5 descriptors after interface
usb 1-1: skipped 5 descriptors after interface
usb 1-1: skipped 5 descriptors after interface
usb 1-1: skipped 6 descriptors after interface
usb 1-1: default language 0x0409
usb 1-1: udev 5, busnum 1, minor = 4
usb 1-1: New USB device found, idVendor=05c6, idProduct=9000
usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=0
usb 1-1: Product: SimTech SIM5216
usb 1-1: Manufacturer: SimTech, Incorporated
usb 1-1: usb_probe_device
usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: adding 1-1:1.0 (config #1, interface 0)
cdc_acm 1-1:1.0: usb_probe_interface
cdc_acm 1-1:1.0: usb_probe_interface - got id
cdc_acm 1-1:1.0: Control and data interfaces are not separated!
cdc_acm 1-1:1.0: This needs exactly 3 endpoints
cdc_acm: probe of 1-1:1.0 failed with error -22
usb 1-1: adding 1-1:1.1 (config #1, interface 1)
cdc_acm 1-1:1.1: usb_probe_interface
cdc_acm 1-1:1.1: usb_probe_interface - got id
cdc_acm 1-1:1.1: Control and data interfaces are not separated!
cdc_acm 1-1:1.1: This needs exactly 3 endpoints
cdc_acm: probe of 1-1:1.1 failed with error -22
usb 1-1: adding 1-1:1.2 (config #1, interface 2)
cdc_acm 1-1:1.2: usb_probe_interface
cdc_acm 1-1:1.2: usb_probe_interface - got id
cdc_acm 1-1:1.2: Control and data interfaces are not separated!
cdc_acm 1-1:1.2: This needs exactly 3 endpoints
cdc_acm: probe of 1-1:1.2 failed with error -22
usb 1-1: adding 1-1:1.3 (config #1, interface 3)
cdc_acm 1-1:1.3: usb_probe_interface
cdc_acm 1-1:1.3: usb_probe_interface - got id
cdc_acm 1-1:1.3: Control and data interfaces are not separated!
cdc_acm 1-1:1.3: ttyACM0: USB ACM device
usb 1-1: adding 1-1:1.4 (config #1, interface 4)
cdc_acm 1-1:1.4: usb_probe_interface
cdc_acm 1-1:1.4: usb_probe_interface - got id
cdc_acm 1-1:1.4: Zero length descriptor references
cdc_acm: probe of 1-1:1.4 failed with error -22
hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
ohci ohci.0: GetPortStatus(1)

I disabled the cdc_acm driver because I finally found that this commit 
add the device from the Linux USB option driver:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=ec0cd94d881ca89cc9fb61d00d0f4b2b52e605b3;hp=46b1848360c8e634e0b063932a1261062fa0f7d6

It simply provides 5 serial ports 'ttyUSB#'. I was using the ttyUSB3 for 
my experiments.

>> I discovered that the last version of uClibc have now the libubactrace.
>> So I updated to it. I can propose this really simple patch to assert the
>> presence of the backtrace call:
>>

> Looks fine to me actually. Send a patch for it.

Done.

Jean-Christian