Some experiments with the SIMCOM SIM5216E modem on a ARM926 board

Some experiments with the SIMCOM SIM5216E modem on a ARM926 board

[Jean-Christian de Rivaz]

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

Hello,

I have got a custom board with a SIMCOM INCORPORATED SIM5216E modem, a 
device not so common. I was able to successfully use it with Ofono, but 
I want to get some advise to polish the work, as I have observed a 
couple of strange things.

The modem is connected by the USB and report: vendor=0x05c6 
product=0x9000. This seem to indicate that it use a Qualcomm chip. It 
expose 5 serial interfaces, where the 2 and 3 (starting from 0) are for 
the AT commands. Since the "atgen" driver is no more, I tested it with 
the "g1" driver. It was only a guess and I would like to know if an 
other driver is a better choice.

The first problem I faced is that I use Buildroot and the uClibc without 
udev (only devtmpfs) on the target system. Dependencies problemes into 
Buildroot make it hard to provides the libudev at the needed version 
form Ofono 1.2. So I passed --disable-udev to the configure the get ride 
of it. While compiling for a uClibc system I have to remove the 
backtrace code from src/log.c since it is not available on the uClibc. 
As others might like to use Ofono on the uClibc, I suggest to test the 
presence of <execinfo.h>, but this is only a small glitch. Now the 
difficult part is to find a way to call ofono_modem_register() without 
the udev plugin, since the modem.conf support have been removed. I did 
not find an other solution than writing a very small plugin that just do 
this in his init function:
         modem = ofono_modem_create("simcom", "g1");
         ofono_modem_set_string(modem, "Device", "/dev/ttyUSB3");
         ofono_modem_register(modem);
It work perfectly well, but look a bit overkill to force to write a 
plugin for a such simple action. I have the feeling to have missed 
something but I can't figure how I should have done this in a proper 
way. At one point I hesitate to add a AddModem method into the 
org.ofono.Manager interface, but the plugin solution was a quicker hack.

The resulting executable work on the target. I can power up, power down 
the modem, enter the SIM pin code, dial and receive call, as well as 
sending a SMS. But the operations are not reliable. This is where I 
needs some hint if this is the normal consequence of the modification I 
have made, or if I need to go into a deep debug session.

While getting a call indication, sometimes I got this:
ofonod[1346]: < \r\n+CDIP: "",128\r\n
ofonod[1346]: < \r\n+CLIP: "0786577442",129,,,,0\r\n
ofonod[1346]: CDIP for unknown call
ofonod[1346]: CLIP for unknown call
ofonod[1346]: < \r\n+CRING: VOICE\r\n
ofonod[1346]: < \r\n+CLIP: "0786577442",129,,,,0\r\n\r\n+CDIP: "",128\r\n
ofonod[1346]: drivers/atmodem/voicecall.c:cring_notify()
ofonod[1346]: drivers/atmodem/voicecall.c:clip_notify() 0786577442 129 0
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall 
event, status: 4, id: 1, number: 0786577442 called_number: , called_name
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Did not find a 
call with id: 1
ofonod[1346]: drivers/atmodem/voicecall.c:cdip_notify()  128
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall 
event, status: 4, id: 1, number: 0786577442 called_number: , called_name
ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Found call with id: 1
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[1346]: > AT+CLCC\r
ofonod[1346]: < \r\n+CME ERROR: unknown\r\n
ofonod[1346]: We are polling CLCC and received an error
ofonod[1346]: All bets are off for call management
ofonod[1346]: < \r\nMISSED_CALL: 09:34AM 0786577442\r\n
After that Ofono seem to be lost and only able to be terminated.

While receiving a SMS I sometimes got this:
ofonod[7191]: > AT+CIND?\r
ofonod[7191]: < \r\n+CIND: 4,3,1,0,0,0,1,0\r\n\r\nOK\r\n
ofonod[7191]: > AT+COPS=3,0\r
ofonod[7191]: < \r\nOK\r\n
ofonod[7191]: > AT+COPS?\r
ofonod[7191]: < \r\n+COPS: 0,0,"orange CH",0\r\n\r\nOK\r\n
ofonod[7191]: drivers/atmodem/network-registration.c:cops_cb() cops_cb: 
orange CH, 228 03 0
ofonod[7191]: src/network.c:current_operator_callback() 0xf4eb8, 0xf69d8
solution ofonod[7191]: < \r\n+CMT: 
,24\r\n07911487777770F0040B911487567744F200002110013094744
ofonod[7191]: < 005C3F79B1D02\r\n
ofonod[7191]: drivers/atmodem/sms.c:at_cmt_notify() Got new SMS Deliver 
PDU via CMT: 
07911487777770F0040B911487567744F200002110013094744005C3F79B1D02, 24
ofonod[7191]: src/sms.c:ofono_sms_deliver_notify() len 32 tpdu len 24
ofonod[7191]: src/sms.c:handle_deliver()
ofonod[7191]: src/sms.c:sms_dispatch()
ofonod[7191]: src/sms.c:sms_dispatch() dst -1 src -1
ofonod[7191]: drivers/atmodem/sms.c:at_ack_delivery()
ofonod[7191]: > AT+CNMA=1,2\r
ofonod[7191]: < \r\n>
ofonod[7191]: > 0000<CtrlZ>
ofonod[7191]: < \r\n\r\n+CMS ERROR: Invalid PDU mode parameter\r\n
ofonod[7191]: CNMA acknowledgement failed: Further SMS reception is not 
guaranteed

And finally, when I send a SMS it could end badly this way:
ofonod[6085]: > AT+CSCA?\r
ofonod[6085]: < \r\n+CSCA: "+41787777070",145\r\n\r\nOK\r\n
ofonod[6085]: drivers/atmodem/sms.c:at_csca_query_cb() csca_query_cb: 
41787777070, 145
ofonod[6085]: src/sms.c:tx_queue_entry_new() pdu_len: 26, tpdu_len: 25
ofonod[6085]: src/sms.c:tx_next() tx_next: 0xf57c8
ofonod[6085]: > AT+CMGS=25\r
ofonod[6085]: < \r\n>
ofonod[6085]: > 0011000B911487567744F20000A70CC8329BFD063DCD6FF73B04<CtrlZ>
ofonod[6085]: < \r\n
ofonod[6085]: < \r\n+CREG: 1, 1778, 4333\r\n\r\n+CMGS: 23\r\n\r\nOK\r\n
ofonod[6085]: drivers/atmodem/sms.c:at_cmgs_cb() Got MR: 23
ofonod[6085]: src/sms.c:tx_finished() tx_finished 0xf57c8
ofonod[6085]: src/sms.c:sms_tx_queue_remove_entry() 0xf57c8
ofonod[6085]: > AT+COPS=3,2\r
ofonod[6085]: < \r\nOK\r\n
ofonod[6085]: Aborting (signal 11) [ofonod]
Since uClibc did not have the backtrace call, I have no more information.

For the 3 issues, the problem is not systematic. It could work perfectly 
well, or it could bug. Maybe a timing related problem, as I run Ofono on 
a slow ARM926 device.

As I am a newbie about Ofono, I like to get some critics on what I can 
do to quickly get a reliable operation.

Jean-Christian de Rivaz

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

[Marcel Holtmann]

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

Hi Jean-Christian,

> I have got a custom board with a SIMCOM INCORPORATED SIM5216E modem, a 
> device not so common. I was able to successfully use it with Ofono, but 
> I want to get some advise to polish the work, as I have observed a 
> couple of strange things.
> 
> The modem is connected by the USB and report: vendor=0x05c6 
> product=0x9000. This seem to indicate that it use a Qualcomm chip. It 
> expose 5 serial interfaces, where the 2 and 3 (starting from 0) are for 
> the AT commands. Since the "atgen" driver is no more, I tested it with 
> the "g1" driver. It was only a guess and I would like to know if an 
> other driver is a better choice.

you really want to have a custom modem plugin for this chip. It is
pretty easy to develop this. Modem plugins are dirt simple to write and
that is intentional of course :)

I think there was some kind of SIMCOM patch (or similar enough) posted
on the mailing list some weeks ago.

> The first problem I faced is that I use Buildroot and the uClibc without 
> udev (only devtmpfs) on the target system. Dependencies problemes into 
> Buildroot make it hard to provides the libudev at the needed version 
> form Ofono 1.2. So I passed --disable-udev to the configure the get ride 
> of it. While compiling for a uClibc system I have to remove the 
> backtrace code from src/log.c since it is not available on the uClibc. 
> As others might like to use Ofono on the uClibc, I suggest to test the 
> presence of <execinfo.h>, but this is only a small glitch. Now the 
> difficult part is to find a way to call ofono_modem_register() without 
> the udev plugin, since the modem.conf support have been removed. I did 
> not find an other solution than writing a very small plugin that just do 
> this in his init function:
>          modem = ofono_modem_create("simcom", "g1");
>          ofono_modem_set_string(modem, "Device", "/dev/ttyUSB3");
>          ofono_modem_register(modem);
> It work perfectly well, but look a bit overkill to force to write a 
> plugin for a such simple action. I have the feeling to have missed 
> something but I can't figure how I should have done this in a proper 
> way. At one point I hesitate to add a AddModem method into the 
> org.ofono.Manager interface, but the plugin solution was a quicker hack.

Actually the udev solution is a lot simpler. We even use that for
supporting Infineon/IMC modems and Calypso/Openmoko modems that are
hardwired to SPI or UART interfaces.

With USB as transport you really wanna do modem detection via udev. So
you might wanna get this solved with uclibc.

For the backtrace() support, I am pretty disappointed that uclibc does
not support this. It is a fundamental piece that you especially want in
embedded system. So this is strange to me.

Instead of us working around it, it might be better to get uclibc fixed
to support this. On the other hand I am open to look at patches to make
this optional.

> The resulting executable work on the target. I can power up, power down 
> the modem, enter the SIM pin code, dial and receive call, as well as 
> sending a SMS. But the operations are not reliable. This is where I 
> needs some hint if this is the normal consequence of the modification I 
> have made, or if I need to go into a deep debug session.
> 
> While getting a call indication, sometimes I got this:
> ofonod[1346]: < \r\n+CDIP: "",128\r\n
> ofonod[1346]: < \r\n+CLIP: "0786577442",129,,,,0\r\n
> ofonod[1346]: CDIP for unknown call
> ofonod[1346]: CLIP for unknown call
> ofonod[1346]: < \r\n+CRING: VOICE\r\n
> ofonod[1346]: < \r\n+CLIP: "0786577442",129,,,,0\r\n\r\n+CDIP: "",128\r\n
> ofonod[1346]: drivers/atmodem/voicecall.c:cring_notify()
> ofonod[1346]: drivers/atmodem/voicecall.c:clip_notify() 0786577442 129 0
> ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall 
> event, status: 4, id: 1, number: 0786577442 called_number: , called_name
> ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Did not find a 
> call with id: 1
> ofonod[1346]: drivers/atmodem/voicecall.c:cdip_notify()  128
> ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Got a voicecall 
> event, status: 4, id: 1, number: 0786577442 called_number: , called_name
> ofonod[1346]: src/voicecall.c:ofono_voicecall_notify() Found call with id: 1
> ofonod[1346]: > AT+CLCC\r
> ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
> ofonod[1346]: > AT+CLCC\r
> ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
> ofonod[1346]: > AT+CLCC\r
> ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
> ofonod[1346]: > AT+CLCC\r
> ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
> ofonod[1346]: > AT+CLCC\r
> ofonod[1346]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
> ofonod[1346]: > AT+CLCC\r
> ofonod[1346]: < \r\n+CME ERROR: unknown\r\n
> ofonod[1346]: We are polling CLCC and received an error
> ofonod[1346]: All bets are off for call management
> ofonod[1346]: < \r\nMISSED_CALL: 09:34AM 0786577442\r\n
> After that Ofono seem to be lost and only able to be terminated.

This looks like the voice call handling via AT+CLCC is really broken on
this modem. So you have a real problem here.

Do have the AT command specification for this modem? Maybe Simcom has a
vendor specific command for voice call state handling. And you are
suppose to use that instead.

> While receiving a SMS I sometimes got this:
> ofonod[7191]: > AT+CIND?\r
> ofonod[7191]: < \r\n+CIND: 4,3,1,0,0,0,1,0\r\n\r\nOK\r\n
> ofonod[7191]: > AT+COPS=3,0\r
> ofonod[7191]: < \r\nOK\r\n
> ofonod[7191]: > AT+COPS?\r
> ofonod[7191]: < \r\n+COPS: 0,0,"orange CH",0\r\n\r\nOK\r\n
> ofonod[7191]: drivers/atmodem/network-registration.c:cops_cb() cops_cb: 
> orange CH, 228 03 0
> ofonod[7191]: src/network.c:current_operator_callback() 0xf4eb8, 0xf69d8
> solution ofonod[7191]: < \r\n+CMT: 
> ,24\r\n07911487777770F0040B911487567744F200002110013094744
> ofonod[7191]: < 005C3F79B1D02\r\n
> ofonod[7191]: drivers/atmodem/sms.c:at_cmt_notify() Got new SMS Deliver 
> PDU via CMT: 
> 07911487777770F0040B911487567744F200002110013094744005C3F79B1D02, 24
> ofonod[7191]: src/sms.c:ofono_sms_deliver_notify() len 32 tpdu len 24
> ofonod[7191]: src/sms.c:handle_deliver()
> ofonod[7191]: src/sms.c:sms_dispatch()
> ofonod[7191]: src/sms.c:sms_dispatch() dst -1 src -1
> ofonod[7191]: drivers/atmodem/sms.c:at_ack_delivery()
> ofonod[7191]: > AT+CNMA=1,2\r
> ofonod[7191]: < \r\n>
> ofonod[7191]: > 0000<CtrlZ>
> ofonod[7191]: < \r\n\r\n+CMS ERROR: Invalid PDU mode parameter\r\n
> ofonod[7191]: CNMA acknowledgement failed: Further SMS reception is not 
> guaranteed

Meaning that acknowledgment with a PDU is not supported. This is sort of
normal.

Check for /* support for ack pdu is not working */ in
drivers/atmodem/sms.c. It does not list OFONO_VENDOR_QUALCOMM_MSM.

However your main problem is that the g1.c modem plugin is the wrong
base for your testing. You need to write your own modem plugin for this.

> And finally, when I send a SMS it could end badly this way:
> ofonod[6085]: > AT+CSCA?\r
> ofonod[6085]: < \r\n+CSCA: "+41787777070",145\r\n\r\nOK\r\n
> ofonod[6085]: drivers/atmodem/sms.c:at_csca_query_cb() csca_query_cb: 
> 41787777070, 145
> ofonod[6085]: src/sms.c:tx_queue_entry_new() pdu_len: 26, tpdu_len: 25
> ofonod[6085]: src/sms.c:tx_next() tx_next: 0xf57c8
> ofonod[6085]: > AT+CMGS=25\r
> ofonod[6085]: < \r\n>
> ofonod[6085]: > 0011000B911487567744F20000A70CC8329BFD063DCD6FF73B04<CtrlZ>
> ofonod[6085]: < \r\n
> ofonod[6085]: < \r\n+CREG: 1, 1778, 4333\r\n\r\n+CMGS: 23\r\n\r\nOK\r\n
> ofonod[6085]: drivers/atmodem/sms.c:at_cmgs_cb() Got MR: 23
> ofonod[6085]: src/sms.c:tx_finished() tx_finished 0xf57c8
> ofonod[6085]: src/sms.c:sms_tx_queue_remove_entry() 0xf57c8
> ofonod[6085]: > AT+COPS=3,2\r
> ofonod[6085]: < \r\nOK\r\n
> ofonod[6085]: Aborting (signal 11) [ofonod]
> Since uClibc did not have the backtrace call, I have no more information.
> 
> For the 3 issues, the problem is not systematic. It could work perfectly 
> well, or it could bug. Maybe a timing related problem, as I run Ofono on 
> a slow ARM926 device.

I think you caught a real bug here. I would be great to get a gdb
backtrace to figure out what caused it.

Regards

Marcel

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

[Jean-Christian de Rivaz]

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

Hi Marcel,

Thanks for your valuable response. Here is an update of the situation.

>> The modem is connected by the USB and report: vendor=0x05c6
>> product=0x9000. This seem to indicate that it use a Qualcomm chip. It
>> expose 5 serial interfaces, where the 2 and 3 (starting from 0) are for
>> the AT commands. Since the "atgen" driver is no more, I tested it with
>> the "g1" driver. It was only a guess and I would like to know if an
>> other driver is a better choice.
>
> you really want to have a custom modem plugin for this chip. It is
> pretty easy to develop this. Modem plugins are dirt simple to write and
> that is intentional of course :)
>
> I think there was some kind of SIMCOM patch (or similar enough) posted
> on the mailing list some weeks ago.

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" ?

The "sim900" patch is still not accepted and, I as far as I understand, 
it don't handle as many feature as the "g1" in the post_sim(). I don't 
known yet if the two products are close enough to be handled by the same 
driver. I have asked Simcom about this question an I hope that there 
will give some indication.

> 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.

I finally gave up and used the patch below, without any udev rule. ( I 
use the "g1" driver for now, but I understand that I need to change that 
later. )

diff -ruN ofono/a/plugins/udevng.c ofono/b/plugins/udevng.c
--- ofono/a/plugins/udevng.c	2012-01-07 05:21:37.000000000 +0100
+++ ofono/b/plugins/udevng.c	2012-01-12 01:10:39.000000000 +0100
@@ -595,6 +595,36 @@
  	return TRUE;
  }

+static gboolean setup_g1(struct modem_info *modem)
+{
+	const char *device = NULL;
+	GSList *list;
+
+	DBG("%s", modem->syspath);
+
+	for (list = modem->devices; list; list = list->next) {
+		struct device_info *info = list->data;
+
+		DBG("%s %s %s %s", info->devnode, info->interface,
+						info->number, info->label);
+
+		if (g_strcmp0(info->interface, "255/255/255") == 0 &&
+					g_strcmp0(info->number, "03") == 0) {
+			device = info->devnode;
+			break;
+		}
+	}
+
+	if (device == NULL)
+		return FALSE;
+
+	DBG("device=%s", device);
+
+	ofono_modem_set_string(modem->modem, "Device", device);
+
+	return TRUE;
+}
+
  static struct {
  	const char *name;
  	gboolean (*setup)(struct modem_info *modem);
@@ -616,6 +646,7 @@
  	{ "telit",	setup_telit	},
  	{ "zte",	setup_zte	},
  	{ "samsung",	setup_samsung	},
+	{ "g1",		setup_g1	},
  	{ }
  };

@@ -808,6 +839,7 @@
  	{ "nokia",	"option",	"0421", "0623"	},
  	{ "samsung",	"option",	"04e8", "6889"	},
  	{ "samsung",	"kalmia"			},
+	{ "g1",		"option",	"05c6", "9000"	},
  	{ }
  };

Should I insist with the udev rules, or something like this (but the 
"g1") is ok ?

> For the backtrace() support, I am pretty disappointed that uclibc does
> not support this. It is a fundamental piece that you especially want in
> embedded system. So this is strange to me.
>
> Instead of us working around it, it might be better to get uclibc fixed
> to support this. On the other hand I am open to look at patches to make
> this optional.

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:

 From 662640e0afb2eb38d896c2673b3afe4c5a280737 Mon Sep 17 00:00:00 2001
From: Jean-Christian de Rivaz <jc@eclis.ch>
Date: Wed, 11 Jan 2012 11:39:22 +0100
Subject: [PATCH] Add autoconfigure rule to search for backtrace().

Add autoconfigure rule to search for backtrace().
On system with the uClibc, it can be into the libubacktrace.

---
  configure.ac |    4 ++++
  1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4115e34..b07544e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,6 +67,10 @@ AC_CHECK_FUNC(signalfd, dummy=yes,
  AC_CHECK_LIB(dl, dlopen, dummy=yes,
  			AC_MSG_ERROR(dynamic linking loader is required))

+AC_SEARCH_LIBS([backtrace], [execinfo ubacktrace], [], [
+			AC_MSG_ERROR(backtrace support is required)
+])
+
  PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.22, dummy=yes,
  				AC_MSG_ERROR(GLib >= 2.22 is required))
  AC_SUBST(GLIB_CFLAGS)
-- 
1.7.6.3

>> ofonod[1346]:>  AT+CLCC\r
>> ofonod[1346]:<  \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
>> ofonod[1346]:>  AT+CLCC\r
>> ofonod[1346]:<  \r\n+CME ERROR: unknown\r\n
>> ofonod[1346]: We are polling CLCC and received an error
>> ofonod[1346]: All bets are off for call management
>> ofonod[1346]:<  \r\nMISSED_CALL: 09:34AM 0786577442\r\n
>> After that Ofono seem to be lost and only able to be terminated.
>
> This looks like the voice call handling via AT+CLCC is really broken on
> this modem. So you have a real problem here.
>
> Do have the AT command specification for this modem? Maybe Simcom has a
> vendor specific command for voice call state handling. And you are
> suppose to use that instead.

Simcom have now provided to me a complete documentation of all the AT 
commands supported by this modem. The AT+CLCC command seem to be ok:

+CLCC:<id1>,<dir>,<stat>,<mode>,<mpty>[,<number>,<type>[,<alpha>]]

I can give more details if needed. The +CME ERROR: <err> is listed as a 
possible response of the command. I noticed that the error raise when 
the a call change his state (typically a hangup) at the same time that 
the AT+CLCC is processing. The AT+CLCC command after the call state 
change returns a valid result. Here is an example:

ofonod[28737]: > AT+CLCC\r
ofonod[28737]: < \r\n+CLCC: 1,1,4,0,0,"0786577442",129\r\n\r\nOK\r\n
ofonod[28737]: > AT+CHUP\r
ofonod[28737]: < \r\nOK\r\n
ofonod[28737]: > AT+CLCC\r
ofonod[28737]: < \r\n+CME ERROR: unknown\r\n
ofonod[28737]: We are polling CLCC and received an error
ofonod[28737]: All bets are off for call management
ofonod[28737]: < \r\nMISSED_CALL: 04:11AM 0786577442\r\n
ofonod[28737]: > AT+CLCC\r
ofonod[28737]: < \r\nOK\r\n

Look like a -EINTR on UNIX that require to make a new invocation. Maybe 
we should ignore this error for this modem in this particular case. I 
have contacted the Simcom support to ask why this modem can return a 
"+CME ERROR: unknown" to the AT+CLCC and how we should handle this.

Regards,

Jean-Christian

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

[Marcel Holtmann]

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

Hi Jean-Christian,

> Thanks for your valuable response. Here is an update of the situation.
> 
> >> The modem is connected by the USB and report: vendor=0x05c6
> >> product=0x9000. This seem to indicate that it use a Qualcomm chip. It
> >> expose 5 serial interfaces, where the 2 and 3 (starting from 0) are for
> >> the AT commands. Since the "atgen" driver is no more, I tested it with
> >> the "g1" driver. It was only a guess and I would like to know if an
> >> other driver is a better choice.
> >
> > you really want to have a custom modem plugin for this chip. It is
> > pretty easy to develop this. Modem plugins are dirt simple to write and
> > that is intentional of course :)
> >
> > I think there was some kind of SIMCOM patch (or similar enough) posted
> > on the mailing list some weeks ago.
> 
> 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.

> The "sim900" patch is still not accepted and, I as far as I understand, 
> it don't handle as many feature as the "g1" in the post_sim(). I don't 
> known yet if the two products are close enough to be handled by the same 
> driver. I have asked Simcom about this question an I hope that there 
> will give some indication.

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

> > 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.

> Should I insist with the udev rules, or something like this (but the 
> "g1") is ok ?

We need something proper. I help you with that. Just need the devices
endpoint descriptors.

> > For the backtrace() support, I am pretty disappointed that uclibc does
> > not support this. It is a fundamental piece that you especially want in
> > embedded system. So this is strange to me.
> >
> > Instead of us working around it, it might be better to get uclibc fixed
> > to support this. On the other hand I am open to look at patches to make
> > this optional.
> 
> 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:
> 
>  From 662640e0afb2eb38d896c2673b3afe4c5a280737 Mon Sep 17 00:00:00 2001
> From: Jean-Christian de Rivaz <jc@eclis.ch>
> Date: Wed, 11 Jan 2012 11:39:22 +0100
> Subject: [PATCH] Add autoconfigure rule to search for backtrace().
> 
> Add autoconfigure rule to search for backtrace().
> On system with the uClibc, it can be into the libubacktrace.

This is kinda stupid, but okay.

> ---
>   configure.ac |    4 ++++
>   1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 4115e34..b07544e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -67,6 +67,10 @@ AC_CHECK_FUNC(signalfd, dummy=yes,
>   AC_CHECK_LIB(dl, dlopen, dummy=yes,
>   			AC_MSG_ERROR(dynamic linking loader is required))
> 
> +AC_SEARCH_LIBS([backtrace], [execinfo ubacktrace], [], [
> +			AC_MSG_ERROR(backtrace support is required)
> +])
> +

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

Regards

Marcel

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

[Jean-Christian de Rivaz]

[-- 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

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

[Jean-Christian de Rivaz]

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

> 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

I didn't noticed that SIMCOM responded to my request while I edited my 
last mail. Here is the interface usage according to them:

the USB interface index is:
0-       DIAG
1-       NMEA
2-       AT
3-       MODEM
4-       Ethernet
So, the port index 2 and port index 3 exposes a working AT command 
interface.

Jean-Christian

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

[Marcel Holtmann]

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

Hi Jean-Christian,

> >> 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.

so essentially you need everything. I hope that the voice call
implementation of SIM COM modem is proper. Otherwise you end up with
higher power consumption. We can talk about that later.

> >>> 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).

So lets figure out which one is the NMEA port and which one is the
QCDM/DIAG port. Use gatchat/test-qcdm --device <tty> and see which one
responds. That one is the QCDM port and the other is the NMEA port.

I bet that interface #4 is actually some form of CDC Ethernet for
highspeed data transfers. So that you do not have to use PPP. Might
wanna ask SIM COM about it.

Once we know the interface mapping, it is pretty easy to add support for
plugins/udevng.c for this hardware.

Regards

Marcel

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

[Marcel Holtmann]

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

Hi Jean-Christian,

> > 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
> 
> I didn't noticed that SIMCOM responded to my request while I edited my 
> last mail. Here is the interface usage according to them:
> 
> the USB interface index is:
> 0-       DIAG
> 1-       NMEA
> 2-       AT
> 3-       MODEM
> 4-       Ethernet
> So, the port index 2 and port index 3 exposes a working AT command 
> interface.

okay then, run ofonod -n -d '*udev*' and see if you get proper debug
output for your modem. Just pushed a udev patch that does the detection.

Regards

Marcel

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

[Jean-Christian de Rivaz]

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

Hi Marcel,

>> the USB interface index is:
>> >  0-       DIAG
>> >  1-       NMEA
>> >  2-       AT
>> >  3-       MODEM
>> >  4-       Ethernet
>> >  So, the port index 2 and port index 3 exposes a working AT command
>> >  interface.

> okay then, run ofonod -n -d '*udev*' and see if you get proper debug
> output for your modem. Just pushed a udev patch that does the detection.

Thanks for it. Seem to be ok:

ofonod[484]: oFono version 1.2
ofonod[484]: plugins/udevng.c:udev_start()
ofonod[484]: plugins/udevng.c:enumerate_devices()
ofonod[484]: plugins/udevng.c:check_usb_device() option [05c6:9000]
ofonod[484]: plugins/udevng.c:add_device() 
/sys/devices/platform/ohci.0/usb1/1-1/1-1:1.0/ttyUSB0/tty/ttyUSB0
ofonod[484]: plugins/udevng.c:add_device() /dev/ttyUSB0 (simcom) 
255/255/255 [00] ==> (null) (null)
ofonod[484]: plugins/udevng.c:check_usb_device() option [05c6:9000]
ofonod[484]: plugins/udevng.c:add_device() 
/sys/devices/platform/ohci.0/usb1/1-1/1-1:1.1/ttyUSB1/tty/ttyUSB1
ofonod[484]: plugins/udevng.c:add_device() /dev/ttyUSB1 (simcom) 
255/255/255 [01] ==> (null) (null)
ofonod[484]: plugins/udevng.c:check_usb_device() option [05c6:9000]
ofonod[484]: plugins/udevng.c:add_device() 
/sys/devices/platform/ohci.0/usb1/1-1/1-1:1.2/ttyUSB2/tty/ttyUSB2
ofonod[484]: plugins/udevng.c:add_device() /dev/ttyUSB2 (simcom) 
255/255/255 [02] ==> (null) (null)
ofonod[484]: plugins/udevng.c:check_usb_device() option [05c6:9000]
ofonod[484]: plugins/udevng.c:add_device() 
/sys/devices/platform/ohci.0/usb1/1-1/1-1:1.3/ttyUSB3/tty/ttyUSB3
ofonod[484]: plugins/udevng.c:add_device() /dev/ttyUSB3 (simcom) 
255/255/255 [03] ==> (null) (null)
ofonod[484]: plugins/udevng.c:check_usb_device() option [05c6:9000]
ofonod[484]: plugins/udevng.c:add_device() 
/sys/devices/platform/ohci.0/usb1/1-1/1-1:1.4/ttyUSB4/tty/ttyUSB4
ofonod[484]: plugins/udevng.c:add_device() /dev/ttyUSB4 (simcom) 
255/255/255 [04] ==> (null) (null)
ofonod[484]: plugins/udevng.c:create_modem() 
/sys/devices/platform/ohci.0/usb1/1-1
ofonod[484]: plugins/udevng.c:create_modem() driver=simcom
ofonod[484]: plugins/udevng.c:setup_simcom() 
/sys/devices/platform/ohci.0/usb1/1-1
ofonod[484]: plugins/udevng.c:setup_simcom() /dev/ttyUSB0 255/255/255 00 
(null)
ofonod[484]: plugins/udevng.c:setup_simcom() /dev/ttyUSB1 255/255/255 01 
(null)
ofonod[484]: plugins/udevng.c:setup_simcom() /dev/ttyUSB2 255/255/255 02 
(null)
ofonod[484]: plugins/udevng.c:setup_simcom() /dev/ttyUSB3 255/255/255 03 
(null)
ofonod[484]: plugins/udevng.c:setup_simcom() /dev/ttyUSB4 255/255/255 04 
(null)
ofonod[484]: plugins/udevng.c:setup_simcom() modem=/dev/ttyUSB3 
aux=/dev/ttyUSB2 gps=/dev/ttyUSB1 diag=/dev/ttyUSB0

But of course, since the "simcom" driver don't exists yet, there is 
nothing after this:

ofonod[1019]: src/modem.c:set_modem_property() modem 0xfbcf8 property Modem
ofonod[1019]: src/modem.c:set_modem_property() modem 0xfbcf8 property Data
ofonod[1019]: src/modem.c:set_modem_property() modem 0xfbcf8 property GPS
ofonod[1019]: src/modem.c:ofono_modem_register() 0xfbcf8

What is the best driver to fork as a base for the simcom driver ?

Regards,

Jean-Christian

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

[Jean-Christian de Rivaz]

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

Hi Marcel,

> So lets figure out which one is the NMEA port and which one is the
> QCDM/DIAG port. Use gatchat/test-qcdm --device<tty>  and see which one
> responds. That one is the QCDM port and the other is the NMEA port.

As expected, now that we known the mapping:

$ test-qcdm --device /dev/ttyUSB0
Device: /dev/ttyUSB0
==> Version information
Compiled Date: Nov 25 2010
Compiled Time: 10:41:31
Release Date: Jun 21 2010
Release Time: 01:00:00
Model: KPUBL
MSM version: 1
==> Features response
==> Invalid command response

Others interfaces don't response, as expected.

By the way, I just discover this test-qcdm utility. SIMCOM is currently 
evaluating the possibility to provide to me some additional hardware to 
investigate the AT+CLCC issue as there can't reproduce it on there side. 
As far as understand, this would consist precisely in a software 
connected to the diagnostic port. Did you think that test-qcdm is good 
enough for the task ?

> I bet that interface #4 is actually some form of CDC Ethernet for
> highspeed data transfers. So that you do not have to use PPP. Might
> wanna ask SIM COM about it.

Yes, would be great. I will ask them on that.

Regards,

Jean-Christian

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

[Jean-Christian de Rivaz]

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

Hi Marcel,

> I bet that interface #4 is actually some form of CDC Ethernet for
> highspeed data transfers. So that you do not have to use PPP. Might
> wanna ask SIM COM about it.

I got this response from them:

The interface #4 "SimTech Wireless HS-USB Ethernet Adapter 9000" needs a 
special tool from Qualcomm for dialing, it's not open for us. We don't 
suggest you use it.

At least this confirm that the chip is from Qualcomm.

Jean-Christian