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
The part that call device_properties_cb is commented to permit this patch
compile.
device_properties_cb() will be changed, so it will have separated patch.
The bluetooth plugin has bluetooth_resgister_uuid() and
bluetooth_unresgister_uuid() where bluetooth profiles plugins such as HFP
and DUN can register themselves to get know about BlueZ stuff ( new
devices, bluetoothd shutdown, etc..)
The AT+CRSM=192 commands are failing on HSO devices and thus it might
be needed to return its details from a predefined database. Start with
testing this for reading the network code length.
If a Novatel device allows to enable a secondary AT command based
channel, then use that for device information, SIM handling, network
registration etc. and only leave the GPRS context setup to the first
command port.
The important part here is that the SMS atom needs to be on the second
AT command port since the main port doesn't handle sending correctly. It
never returns any success or error after the submission of the PDU.
Instead of using ofono_modem_set_powered(), use ofono_sim_inserted_notify()
which is the proper way to notify about sim state changes.
Now the problem is that voicecall commands fail with my Huawei E1552:
ofonod[12395]: > AT+CRC=1\r
ofonod[12395]: src/sim.c:ofono_sim_add_state_watch() 0x1bf8e50
ofonod[12395]: src/sim.c:ofono_sim_add_state_watch() 0x1bf8e50
ofonod[12395]: < \r\n+CME ERROR: SIM busy\r\n
ofonod[12395]: > AT+CLIP=1\r
ofonod[12395]: < \r\n+CME ERROR: SIM busy\r\n
ofonod[12395]: > AT+COLP=1\r
ofonod[12395]: < \r\n+CME ERROR: SIM busy\r\n
ofonod[12395]: > AT+CCWA=1\r
ofonod[12395]: < \r\n+CME ERROR: SIM busy\r\n
ofonod[12395]: drivers/atmodem/voicecall.c:at_voicecall_initialized()
voicecall_init: registering to notifications
ofonod[12395]: src/sim.c:ofono_sim_add_state_watch() 0x1bf8e50
ofonod[12395]: > AT^SYSINFO\r
ofonod[12395]: < \r\n^SYSINFO:0,0,0,0,255,,0\r\n\r\nOK\r\n
ofonod[12395]: > AT+CGMI\r
ofonod[12395]: < \r\nhuawei\r\n\r\nOK\r\n
ofonod[12395]: EventChannel: < \r\n^STIN:0,0,0\r\n
ofonod[12395]: > AT+CLCC\r
ofonod[12395]: < \r\n+CME ERROR: SIM busy\r\n
But as I can't make voice calls with this modem anyway, I don't worry
about them right now.
With Huawei E1552 I got sim busy errors when I plugged in the modem
and ofono was already running:
May 24 17:02:04 tukki ofonod[7619]: > AT+CRC=1\r
May 24 17:02:04 tukki ofonod[7619]: < \r\n+CME ERROR: SIM busy\r\n
May 24 17:02:04 tukki ofonod[7619]: > AT+CLIP=1\r
May 24 17:02:04 tukki ofonod[7619]: < \r\n+CME ERROR: SIM busy\r\n
Fix this by following sim state changes with ^SIMST notification and
only enable modem after SIM is ready. In case SIM is already ready
and we miss the notification for some reason, also use AT^SYSINFO
to check the state during enable phase.
Also change huawei_enable() to return -EINPROGRESS to make sure that
ofono modem is not powered too early. I believe this was a bug.
Adding a new notify function in the netreg atom for notifying a
received Network Identification and Timezone (NITZ) indication. This
data is consumed via a nettime plugin, of which there is also an
example.
Sometimes, Udev device 'remove' event could not report correct parent
node of current udev_device. Current code replies on the devpath
attached on the parent node to find modem and then remove it.
This fix is to change the way to store the devpath info into a
hashtable. So that we search hashtable to get devpath and remove the
modem.
The Wavecom WMP100 is a serial based modem, however it assumes CPIN to
be the final response. This requires some quirking in the sim driver.
Refer to commit 6d28f82dc1 for details.
Add ofono_sim_inserted_notify function to notify the core of SIM
insertion / removal.
Make every plugin generate a sim inserted event on start. For devices
with removable card, the event should be emitted after the
plugin detects such event. For devices that need to wait for SIM card
initialization, they can emit this event later.
What we really want to do here is set a flag that the agent has not been
released yet. If this is the case we should send the Disconnect call on
disable.