When driving the Infineon modem with the builtin multiplexer there is
a small race condition with setting up the channels and sending the
first AT commands. The window here is pretty small, but it seems to be
a modem firmware issue. In case the AT command is send right away it can
happen that the modem does not process any further AT commands. In that
case the setup is stuck and enabling the modem fails.
Just adding a 10 milliseconds delay after DLC creation and before
sending the first AT commands is enough to make this work smoothly.
It is important that the copyright headers are consistent throughout
the source code. While the copyright might be owned by different
people of companies, the header itself with its license information
should be identical.
The XGENDATA result contains various strings that also contain the modem
model. Make this command mandatory for the modem bringup and after it
succeeded, check for the XMM6260 string to setup specific audio settings.
This makes using ENV{OFONO_IFX_MODEL}="XMM6260" obsolete, but for now it
is still left as a possible option. It might be removed later.
This patch adds a modem driver plugin for the Nokia N900 internal
modem. It controls the modem using the appropriate GPIO lines and thus
works without the Maemo userspace.
This plugin can run natively on the N900 with either Maemo or Meego
kernels. However, it conflicts with the Maemo userspace, for which
isigen should be used instead.
The new isigen modem driver plugin replaces the generic parts in the
isimodem modem driver. This plugin works with recent Nokia modems in
PC suite mode over USB, as well as with the N900 modem using Maemo5
userspace.
The firmware details can be requested via AT+XGENDATA. So do this at
modem init to have these in the logs. Currently nothing is done with
this data, but eventually it can be used for modem specific settings
like the audio configuration.
For the XMM6260 Infineon modem it is possible to use different audio
configuration depending on your platform. Currently the setup of
FULL_DUPLEX, BURSTMODE_48KHZ and BURSTMODE_96KHZ are supported. If
appropiate values for OFONO_IFX_MODEL and OFONO_IFX_AUDIO are set
in the udev rules file, then the audio configuration will be changed
when bringing up the modem.
This adds three more extra configuration options for IFX specific
hardware setups. They are OFONO_IFX_MODEL, OFONO_IFX_AUDIO and also
OFONO_IFX_LOOPBACK.
An example usage would be like this:
ENV{OFONO_IFX_MODEL}="XMM6260", ENV{OFONO_IFX_AUDIO}="FULL_DUPLEX"
The actual supported values are not defined by the IFX modem
detection code. This is up to the modem plugin to change behavior
if needed.
When not using none_prefix for matching the responses of AT+XSIMSTATE
call, it will consume all notifications. And this includes the initial
SIM state that the modem sends at that point. Without this notification
the SIM will never be marked as inserted.
Since the udev support allows to specify a line discipline number as
part of the modem configuration, use that one and report and error if
it has not been set.
The IFX modem plugin uses a kernel based multiplexer. And to support
different line discipline numbers on different target platforms, allow
them to be specified as option:
KERNEL=="ttyIFX[0-9]*", ENV{OFONO_DRIVER}="ifx", ENV{OFONO_IFX_LDISC}="23"
The extra OFONO_IFX_LDISC option specifies to use line discipline 23
for the multiplexer setup. The number is just an example here and the
correct one will be different.
The +XSIM notifies us about missing or removed SIM. Use that for telling
the core if a SIM card is present or not. Besides that all other states
are treated as when a SIM card got inserted.
This supports a simple static multiplexer that is activated with setting
the line discipline 23 on the TTY. It is static, because the DLC numbers
are hardcoded.
This is a first attempt at the Infineon modem support. The support
is limited since it doesn't handle the setup of the multiplexer or
the different SIM states yet.
The recently introduced online support to huawei didn't work with my
Huawei E1552. The problem was that with command AT+CFUN=1;+CFUN=5
the modem didn't initialise the sim state properly.
To fix this I changed the logic so that CFUN=5 is called only after the sim
state has switched to a valid state. Now my Huawei E1552 works with connman
again.
PIN locked SIMs still won't work. The problem is that it takes some time for
the sim state to go to a valid state:
Sep 20 15:01:57 dell-m520 ofonod[12451]: Pcui:< \r\n+CPIN: READY\r\n\r\nOK\r\n
[...]
Sep 20 15:02:00 dell-m520 ofonod[12451]: huawei: invalid sim state in post online (0)
[...]
Sep 20 15:02:01 dell-m520 ofonod[12451]: Pcui:< \r\n^SIMST:1\r\n
I don't know why it takes so long to get a valid state.
There is also another issue, in "cold start" case the phonebook
initialisation fails:
Sep 20 14:34:24 dell-m520 ofonod[11939]: Pcui:> AT+CPBS=?\r
Sep 20 14:34:24 dell-m520 ofonod[11939]: Pcui:< \r\n+CME ERROR: SIM busy\r\n
But in "warm start" it seems to work:
Sep 20 14:38:59 dell-m520 ofonod[12091]: Pcui:> AT+CPBS=?\r
Sep 20 14:38:59 dell-m520 ofonod[12091]: Pcui:< \r\n+CPBS: ("SM","EN","ON")\r\n\r\nOK\r\n
I consider this as a minor issue and didn't investigate it at all.
On my Huawei E1552 when I plug in the modem (ie. cold start) with PIN locked
SIM, the sim state is 255 (HUAWEI_SIM_STATE_NOT_EXISTENT). As the modem
doesn't send ^SIMST notifications, poll the sim state until it's ready.
In theory it might be possible to do this better, for example follow
^BOOT notifications or something, but it's unknown what parameter we
should check for.
The IFX device detection is pretty static, but instead of using
a static configuration file it is important to know when the device
node is actually present. For this udev is perfect. Adding a simple
udev rule is all that it takes:
KERNEL=="ttyIFX[0-9]*", ENV{OFONO_DRIVER}="ifx"
With this rule for every TTY with the kernel name like ttyIFX0, a new
modem will be added and the IFX modem plugin driver requested for it.
Dell D5530 is an OEM version of F3507g. It has an annoying habit of
announcing itself to world with its own name. Another problem is some weird
+CGAP messages at the same time. It also crashes upon processing received
CBS messages.
Some newer Huawei modems have support for ^USSDMODE command which seems
to be default to 1. In that mode the text USSD is not working. Switching
it to 0 and text USSD works just fine. Assumption is that with this command
the modem switches between text and PDU mode for USSD. Currently it is
unclear on how the PDU mode is suppose to work all. So default to text mode
if this command is supported.
These notifications should be emitted on SIM removal and insertion.
These notifications don't work very well though, on the hardware this
has been tested on, the modem never issued %SIMINS, and %SIMREM was
emitted only in some specific circumenstances.
Like in case of MBM modem, the SIM slot is not easily accessible
while the device is running so we assume there's no need to check
for SIM presence after startup.
Huawei EM770W is a 3G WCDMA modem that supports HSPA/UMTS/EDGE/GPRS/GSM
data service and WCDMA/GSM short message services. It also has voice
call capability that supports both 2G and 3G network.
Huawei always closes the tty port after PPP disconnect. Handle this in
huawei plugin, similarly as done with novatel. Now there's no need
to unplug the modem after disconnection.
Tested with Huawei E1552.
Based on a patch by Marcel Holtmann:
commit 0329a6ceaf
Author: Marcel Holtmann <marcel@holtmann.org>
Date: Mon Jun 7 02:36:12 2010 -0700
Reopen the GPRS context channel when the modem closes it after PPP