Re: SAGEM HiloNC v2 Driver

Re: SAGEM HiloNC v2 Driver

[Freedreamer]

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

 Hi Denis,
 first of all thanks 4 your reply.

>
> 2013/3/26 Denis Kenzior <denkenz@gmail.com>
>
>> Hi Marco,
>>
>>
>> On 03/26/2013 04:07 AM, Freedreamer wrote:
>>
>>> Hi Everybody,
>>>
>>> I'm developing a driver for an embedded system which uses a sagem HiloNC
>>> v2 and I really should need your help. It's my will to commit everything
>>> when shall be ready and working.
>>> First of all I will tell you what i did..I created a plugin sagem.c
>>> ,added a new Vendor ,  modified makefile & other stuff and seems to work
>>> properly. I started from calypso driver 'cause the modem is based on a
>>> Uart and I needed the MUX over that.
>>> With a very raw/dirty code I was able to use PPP/SMS/net service over
>>> virtual com.. Very good work dude! :)
>>>
>>> Now I would like to clean up my code and get a better understanding of
>>> the stack. Unfortunately I saw that functions/modules are not always
>>> commented so I have to ask u a lot of questions (maybe also trivial):
>>>
>>> 1) AT cmds sent with "g_at_chat_send" are always async , is that right ?
>>> Is there any chance to get them sync ?
>>>
>>
>> There is not, we do not want to encourage any sort of blocking behavior
>> in the daemon.  Remember there are potentially multiple modems being
>> operated on and we do not use threads.
>>
>
Ok get it, i thought there were pthreads somewhere.


>> 2) in enable fnc the modem is powered but The sim is not ready so
>>> sometimes It hangs up...Do I have to to poll the sim status until is
>>> ready  , or the driver will do  that by itself ?
>>>
>>
>> oFono never polls for anything.  It is the driver's responsibility to do
>> that in the best possible way for the hardware.  Also, powering on the
>> modem is separate from the sim being ready.  The general flow is this:
>>
>> -Enable modem
>> -Wait for the modem to power on and use ofono_modem_set_powered when that
>> happens successfully / fails.
>> - Figure out if the SIM is inserted and signal using
>> ofono_sim_inserted_notify.  Do this step only once the SIM is ready to be
>> queried for its PIN status and perform any I/O on SIM files that are always
>> accessible (e.g. ICCID)
>>
>
 Ok. If Sim not "ready" , sending a signal prematurely could stuck anyhow
the stack ? 'cause it should explain a lot of thing..


>
>>
>> 3) could u explain me what should I really do in virtual fnc  set_online
>>> / post_online ? i tried to stub them but they have not never been
>>> called...
>>>
>>
>> oFono has 3 basic states:
>> - Off
>> - Radio Off, Sim On
>> - Radio On, Sim On
>>
>> set_online turns radio on / off
>> post_online populates the atoms that are available in radio 'On' state.
>>
>>
>>
 This is what i thought but I do not understand why I don't see the trace
log I put inside them...usually are called before pre_sim fn? are related
to any signal i have to manage/post ?


>
>> 4) unfortunately this modem has a SIM detection URC but it reset itself
>>> every time the status changes... so i should call the disable function
>>> and the enable again in order to have the MUX working... how can i do
>>> that?
>>>
>>
>> I'm not following.  Care to elaborate?
>>
>>
>>
I've managing vendor URC for sim detection right now but i have
problems.For instance if I remove it when ofonod is ready the Hilonc sends
an URC to notify sim status changed but after that it reboots itself(2 sec
later)... what i did is to notify the stack that the SIM has been removed
and modem is powered off . I thought that after calling set_powered fnc the
stack should have called my driver virtual disable function in order to
properly close the MUX .. but it's not..


>
>
>> 5) I created and started the MUX as the first thing in enable fnc but is
>>> that right ? sometimes seems that the modem hangs up if just powered up.
>>> Put a delay but don't like it very much as a solution...moreover when I
>>> power up the modem all the URC have been lost 'cause the MUX has not
>>> been created yet..
>>>
>>
>> That is what we do for most devices with a MUX, put it into MUX state
>> right away after basic initialization.  The devices we have can be queried
>> for their state in addition to URCs, so it works out very well.
>>
>>
right now i've been using custom URC in the first power up phase to
understand modem status. I manually set them but theoretically I should
check the values saved on the modem every power cycle. What I was thinking
was to test every time the values saved and enabling them if they were not
.After that I should call an AT+cfun=1,1 in order to reset the modem and
force it to send me again the needed URCs . What do u think ?

Thanks again
Marco

Regards,
>> -Denis
>
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 10123 bytes --]

Re: SAGEM HiloNC v2 Driver

[Denis Kenzior]

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

Hi Marco,

<snip>

>             2) in enable fnc the modem is powered but The sim is not
>             ready so
>             sometimes It hangs up...Do I have to to poll the sim status
>             until is
>             ready  , or the driver will do  that by itself ?
>
>
>         oFono never polls for anything.  It is the driver's
>         responsibility to do that in the best possible way for the
>         hardware.  Also, powering on the modem is separate from the sim
>         being ready.  The general flow is this:
>
>         -Enable modem
>         -Wait for the modem to power on and use ofono_modem_set_powered
>         when that happens successfully / fails.
>         - Figure out if the SIM is inserted and signal using
>         ofono_sim_inserted_notify.  Do this step only once the SIM is
>         ready to be queried for its PIN status and perform any I/O on
>         SIM files that are always accessible (e.g. ICCID)
>
>
> Ok. If Sim not "ready" , sending a signal prematurely could stuck anyhow
> the stack ? 'cause it should explain a lot of thing..
>

If you tell oFono core that the sim is inserted, the first thing it does 
is read some sim files that are always available.  e.g. ICCID, etc. 
Then it proceeds to check the PIN.  If the PIN query fails due to a sim 
busy condition, then yes the init process will stall.  This is 
considered a bug in the driver.

>
>
>             3) could u explain me what should I really do in virtual fnc
>               set_online
>             / post_online ? i tried to stub them but they have not never
>             been called...
>
>
>         oFono has 3 basic states:
>         - Off
>         - Radio Off, Sim On
>         - Radio On, Sim On
>
>         set_online turns radio on / off
>         post_online populates the atoms that are available in radio 'On'
>         state.
>
>
> This is what i thought but I do not understand why I don't see the trace
> log I put inside them...usually are called before pre_sim fn? are
> related to any signal i have to manage/post ?

enable -> pre_sim, sim_inserted -> post_sim, set_online -> post_online. 
  Generally you do not call set_online before hitting the post_sim state.

<snip>

>
> I've managing vendor URC for sim detection right now but i have
> problems.For instance if I remove it when ofonod is ready the Hilonc
> sends an URC to notify sim status changed but after that it reboots
> itself(2 sec later)... what i did is to notify the stack that the SIM
> has been removed and modem is powered off . I thought that after calling
> set_powered fnc the stack should have called my driver virtual disable
> function in order to properly close the MUX .. but it's not..

No, if you call ofono_modem_set_powered(modem, FALSE) it assumes that 
the modem powered off due to an internally generated event (e.g. not 
oFono's doing).  The driver has to clean up properly in this case.  The 
driver disable() method is only called on oFono initiated power down 
requests.

>
>
>             5) I created and started the MUX as the first thing in
>             enable fnc but is
>             that right ? sometimes seems that the modem hangs up if just
>             powered up.
>             Put a delay but don't like it very much as a
>             solution...moreover when I
>             power up the modem all the URC have been lost 'cause the MUX
>             has not
>             been created yet..
>
>
>         That is what we do for most devices with a MUX, put it into MUX
>         state right away after basic initialization.  The devices we
>         have can be queried for their state in addition to URCs, so it
>         works out very well.
>
> right now i've been using custom URC in the first power up phase to
> understand modem status. I manually set them but theoretically I should
> check the values saved on the modem every power cycle. What I was
> thinking was to test every time the values saved and enabling them if
> they were not .After that I should call an AT+cfun=1,1 in order to reset
> the modem and force it to send me again the needed URCs . What do u think ?

I do not see anything wrong with that strategy.  Just keep in mind that 
querying things you will be resetting (potentially) anyway is likely a 
waste of time.  Only query things that are required for the 
initialization procedure.  For the rest, simply set the setting you want.

Regards,
-Denis

Re: SAGEM HiloNC v2 Driver

[Freedreamer]

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

Tnx again 4 your patience Denis,


2013/3/27 Denis Kenzior <denkenz@gmail.com>

> Hi Marco,
>
> <snip>
>
>
>              2) in enable fnc the modem is powered but The sim is not
>>             ready so
>>             sometimes It hangs up...Do I have to to poll the sim status
>>             until is
>>             ready  , or the driver will do  that by itself ?
>>
>>
>>         oFono never polls for anything.  It is the driver's
>>         responsibility to do that in the best possible way for the
>>         hardware.  Also, powering on the modem is separate from the sim
>>         being ready.  The general flow is this:
>>
>>         -Enable modem
>>         -Wait for the modem to power on and use ofono_modem_set_powered
>>         when that happens successfully / fails.
>>         - Figure out if the SIM is inserted and signal using
>>         ofono_sim_inserted_notify.  Do this step only once the SIM is
>>         ready to be queried for its PIN status and perform any I/O on
>>         SIM files that are always accessible (e.g. ICCID)
>>
>>
>> Ok. If Sim not "ready" , sending a signal prematurely could stuck anyhow
>> the stack ? 'cause it should explain a lot of thing..
>>
>>
> If you tell oFono core that the sim is inserted, the first thing it does
> is read some sim files that are always available.  e.g. ICCID, etc. Then it
> proceeds to check the PIN.  If the PIN query fails due to a sim busy
> condition, then yes the init process will stall.  This is considered a bug
> in the driver.
>
> got it.

>
>
>>
>>             3) could u explain me what should I really do in virtual fnc
>>               set_online
>>             / post_online ? i tried to stub them but they have not never
>>             been called...
>>
>>
>>         oFono has 3 basic states:
>>         - Off
>>         - Radio Off, Sim On
>>         - Radio On, Sim On
>>
>>         set_online turns radio on / off
>>         post_online populates the atoms that are available in radio 'On'
>>         state.
>>
>>
>> This is what i thought but I do not understand why I don't see the trace
>> log I put inside them...usually are called before pre_sim fn? are
>> related to any signal i have to manage/post ?
>>
>
> enable -> pre_sim, sim_inserted -> post_sim, set_online -> post_online.
>  Generally you do not call set_online before hitting the post_sim state.
>
>
could I don't  implement set_online if I don't need it?



> <snip>
>
>
>
>> I've managing vendor URC for sim detection right now but i have
>> problems.For instance if I remove it when ofonod is ready the Hilonc
>> sends an URC to notify sim status changed but after that it reboots
>> itself(2 sec later)... what i did is to notify the stack that the SIM
>> has been removed and modem is powered off . I thought that after calling
>> set_powered fnc the stack should have called my driver virtual disable
>> function in order to properly close the MUX .. but it's not..
>>
>
> No, if you call ofono_modem_set_powered(modem, FALSE) it assumes that the
> modem powered off due to an internally generated event (e.g. not oFono's
> doing).  The driver has to clean up properly in this case.  The driver
> disable() method is only called on oFono initiated power down requests.
>
>
> mmh ok..so If the modem restarts it's my business to disable and enable
again all the driver' stuff , right?



>
>>
>>             5) I created and started the MUX as the first thing in
>>             enable fnc but is
>>             that right ? sometimes seems that the modem hangs up if just
>>             powered up.
>>             Put a delay but don't like it very much as a
>>             solution...moreover when I
>>             power up the modem all the URC have been lost 'cause the MUX
>>             has not
>>             been created yet..
>>
>>
>>         That is what we do for most devices with a MUX, put it into MUX
>>         state right away after basic initialization.  The devices we
>>         have can be queried for their state in addition to URCs, so it
>>         works out very well.
>>
>> right now i've been using custom URC in the first power up phase to
>> understand modem status. I manually set them but theoretically I should
>> check the values saved on the modem every power cycle. What I was
>> thinking was to test every time the values saved and enabling them if
>> they were not .After that I should call an AT+cfun=1,1 in order to reset
>> the modem and force it to send me again the needed URCs . What do u think
>> ?
>>
>
> I do not see anything wrong with that strategy.  Just keep in mind that
> querying things you will be resetting (potentially) anyway is likely a
> waste of time.  Only query things that are required for the initialization
> procedure.  For the rest, simply set the setting you want.
>
>
done today and it works.


> Regards,
> -Denis
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 6493 bytes --]

Re: SAGEM HiloNC v2 Driver

[Denis Kenzior]

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

Hi Marco,

>
>     enable -> pre_sim, sim_inserted -> post_sim, set_online ->
>     post_online.  Generally you do not call set_online before hitting
>     the post_sim state.
>
>
> could I don't  implement set_online if I don't need it?

That would work, if the modem driver does not implement set_online, 
oFono core automatically transitions to Online after CPIN returns 'READY'.

>
>     <snip>
>
>
>
>         I've managing vendor URC for sim detection right now but i have
>         problems.For instance if I remove it when ofonod is ready the Hilonc
>         sends an URC to notify sim status changed but after that it reboots
>         itself(2 sec later)... what i did is to notify the stack that
>         the SIM
>         has been removed and modem is powered off . I thought that after
>         calling
>         set_powered fnc the stack should have called my driver virtual
>         disable
>         function in order to properly close the MUX .. but it's not..
>
>
>     No, if you call ofono_modem_set_powered(modem, FALSE) it assumes
>     that the modem powered off due to an internally generated event
>     (e.g. not oFono's doing).  The driver has to clean up properly in
>     this case.  The driver disable() method is only called on oFono
>     initiated power down requests.
>
>
> mmh ok..so If the modem restarts it's my business to disable and enable
> again all the driver' stuff , right?
>

If the modem resets, then yes you need to call ofono_modem_set_powered 
to FALSE.  Booting it back up should not be done in the driver, unless 
your modem supports so called silent resets.  This is where the modem 
stack crashes but silently resets itself back to the previous state. 
(e.g. no PIN entry is required, initialization is very fast). In that 
case use ofono_modem_reset.

<snip>

Glad I could help ;)

Regards,
-Denis

Re: SAGEM HiloNC v2 Driver

[Freedreamer]

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

Hi again Denis..
so , I have now something  that seems to work properly also when SIM is
removed/ inserted.

here a the code I've been using;

http://pastebin.com/8VgKrYur

Got as always some question :)

1) The "set_online" function I copied from other drivers but is not never
called anyway...i'll tell more..if I enable it the ofono core stucks
somewhere..:|
2) seems that if  I set the same virtual com for the service "dev_info"  &
"sim"  I got a  crash of the stack...so i put them in 2 different channel
of the Mux.
3) ppp works only if when I got DNS & ip
     ifconfig ppp0  <ip>  up
     route add -net 0.0.0.0 ppp0



2013/3/27 Denis Kenzior <denkenz@gmail.com>

> Hi Marco,
>
>
>
>>     enable -> pre_sim, sim_inserted -> post_sim, set_online ->
>>     post_online.  Generally you do not call set_online before hitting
>>     the post_sim state.
>>
>>
>> could I don't  implement set_online if I don't need it?
>>
>
> That would work, if the modem driver does not implement set_online, oFono
> core automatically transitions to Online after CPIN returns 'READY'.
>
>
>
>>     <snip>
>>
>>
>>
>>         I've managing vendor URC for sim detection right now but i have
>>         problems.For instance if I remove it when ofonod is ready the
>> Hilonc
>>         sends an URC to notify sim status changed but after that it
>> reboots
>>         itself(2 sec later)... what i did is to notify the stack that
>>         the SIM
>>         has been removed and modem is powered off . I thought that after
>>         calling
>>         set_powered fnc the stack should have called my driver virtual
>>         disable
>>         function in order to properly close the MUX .. but it's not..
>>
>>
>>     No, if you call ofono_modem_set_powered(modem, FALSE) it assumes
>>     that the modem powered off due to an internally generated event
>>     (e.g. not oFono's doing).  The driver has to clean up properly in
>>     this case.  The driver disable() method is only called on oFono
>>     initiated power down requests.
>>
>>
>> mmh ok..so If the modem restarts it's my business to disable and enable
>> again all the driver' stuff , right?
>>
>>
> If the modem resets, then yes you need to call ofono_modem_set_powered to
> FALSE.  Booting it back up should not be done in the driver, unless your
> modem supports so called silent resets.  This is where the modem stack
> crashes but silently resets itself back to the previous state. (e.g. no PIN
> entry is required, initialization is very fast). In that case use
> ofono_modem_reset.
>
> <snip>
>
> Glad I could help ;)
>
> Regards,
> -Denis
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3384 bytes --]

Re: SAGEM HiloNC v2 Driver

[Freedreamer]

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

sorry did not over the mail....

about ppp , Is that normal that I have to config these parameters?

4) SMS seems to work properly.

Thanks again for you precious help.



2013/3/28 Freedreamer <freedreamer@email.it>

> Hi again Denis..
> so , I have now something  that seems to work properly also when SIM is
> removed/ inserted.
>
> here a the code I've been using;
>
> http://pastebin.com/8VgKrYur
>
> Got as always some question :)
>
> 1) The "set_online" function I copied from other drivers but is not never
> called anyway...i'll tell more..if I enable it the ofono core stucks
> somewhere..:|
> 2) seems that if  I set the same virtual com for the service "dev_info"  &
> "sim"  I got a  crash of the stack...so i put them in 2 different channel
> of the Mux.
> 3) ppp works only if when I got DNS & ip
>      ifconfig ppp0  <ip>  up
>      route add -net 0.0.0.0 ppp0
>
>
>
>
> 2013/3/27 Denis Kenzior <denkenz@gmail.com>
>
>> Hi Marco,
>>
>>
>>
>>>     enable -> pre_sim, sim_inserted -> post_sim, set_online ->
>>>     post_online.  Generally you do not call set_online before hitting
>>>     the post_sim state.
>>>
>>>
>>> could I don't  implement set_online if I don't need it?
>>>
>>
>> That would work, if the modem driver does not implement set_online, oFono
>> core automatically transitions to Online after CPIN returns 'READY'.
>>
>>
>>
>>>     <snip>
>>>
>>>
>>>
>>>         I've managing vendor URC for sim detection right now but i have
>>>         problems.For instance if I remove it when ofonod is ready the
>>> Hilonc
>>>         sends an URC to notify sim status changed but after that it
>>> reboots
>>>         itself(2 sec later)... what i did is to notify the stack that
>>>         the SIM
>>>         has been removed and modem is powered off . I thought that after
>>>         calling
>>>         set_powered fnc the stack should have called my driver virtual
>>>         disable
>>>         function in order to properly close the MUX .. but it's not..
>>>
>>>
>>>     No, if you call ofono_modem_set_powered(modem, FALSE) it assumes
>>>     that the modem powered off due to an internally generated event
>>>     (e.g. not oFono's doing).  The driver has to clean up properly in
>>>     this case.  The driver disable() method is only called on oFono
>>>     initiated power down requests.
>>>
>>>
>>> mmh ok..so If the modem restarts it's my business to disable and enable
>>> again all the driver' stuff , right?
>>>
>>>
>> If the modem resets, then yes you need to call ofono_modem_set_powered to
>> FALSE.  Booting it back up should not be done in the driver, unless your
>> modem supports so called silent resets.  This is where the modem stack
>> crashes but silently resets itself back to the previous state. (e.g. no PIN
>> entry is required, initialization is very fast). In that case use
>> ofono_modem_reset.
>>
>> <snip>
>>
>> Glad I could help ;)
>>
>> Regards,
>> -Denis
>>
>
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3920 bytes --]

Re: SAGEM HiloNC v2 Driver

[Denis Kenzior]

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

Hi,

Please do not top-post on this mailing list.

On 03/28/2013 08:43 AM, Freedreamer wrote:
> sorry did not over the mail....
>
> about ppp , Is that normal that I have to config these parameters?
>

Yes, this is normal.  oFono expects another daemon (e.g. ConnMan, 
NetworkManager) to configure the network interfaces.

Regards,
-Denis

Re: SAGEM HiloNC v2 Driver

[Freedreamer]

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

2013/3/28 Denis Kenzior <denkenz@gmail.com>

> Hi,
>
> Please do not top-post on this mailing list.
>
>
> On 03/28/2013 08:43 AM, Freedreamer wrote:
>
>> sorry did not over the mail....
>>
>> about ppp , Is that normal that I have to config these parameters?
>>
>>
> Yes, this is normal.  oFono expects another daemon (e.g. ConnMan,
> NetworkManager) to configure the network interfaces.
>
> Regards,
> -Denis
>
>
Hi guys,

Sorry again! I'm a newbie in mailing list.
Thanks for ppp issue I understand. I tried my code (that worked on x86) on
the embedded ARM  board but we have problem , here the logs:
ofonod[16939]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90,
00, 15
ofonod[16939]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0,
tocopy: 15
ofonod[16939]: MUX: waking up writer
ofonod[16939]: MUX: creating source: 0x14a0390, channel: 0x148a6a0, writer:
4, reader: 0
ofonod[16939]: MUX: can write data
ofonod[16939]: MUX: checking channel for write: 0x148ac50
ofonod[16939]: MUX: checking channel for write: 0x148a6a0
ofonod[16939]: MUX: dispatching write sources: 0x148a6a0
ofonod[16939]: MUX: checking source: 0x14a0390
ofonod[16939]: MUX: dispatching source: 0x14a0390
ofonod[16939]: Chat2: > AT+CRSM=192,28474\r
ofonod[16939]: MUX: removing source: 0x14a0390
ofonod[16939]: MUX: checking source: 0x149eb80
ofonod[16939]: MUX: checking channel for write: 0x1488ec0
ofonod[16939]: MUX: dispatching write sources: 0x1488ec0
ofonod[16939]: MUX: checking source: 0x148aaf0
ofonod[16939]: MUX: checking channel for write: 0x1490430
ofonod[16939]: MUX: dispatching write sources: 0x1490430
ofonod[16939]: MUX: checking source: 0x148ad60
ofonod[16939]: Chat1: Wakeup got no response
ofonod[16939]: Aborting (signal 11) [ofonod]
ofonod[16939]: ++++++++ backtrace ++++++++

I suspect that should be a syncronization issue between the virtual
channel. Any idea?

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 2403 bytes --]

Re: SAGEM HiloNC v2 Driver

[Denis Kenzior]

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

Hi,

> Thanks for ppp issue I understand. I tried my code (that worked on x86)
> on the embedded ARM  board but we have problem , here the logs:
> ofonod[16939]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90,
> 00, 15
> ofonod[16939]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff:
> 0, tocopy: 15
> ofonod[16939]: MUX: waking up writer
> ofonod[16939]: MUX: creating source: 0x14a0390, channel: 0x148a6a0,
> writer: 4, reader: 0
> ofonod[16939]: MUX: can write data
> ofonod[16939]: MUX: checking channel for write: 0x148ac50
> ofonod[16939]: MUX: checking channel for write: 0x148a6a0
> ofonod[16939]: MUX: dispatching write sources: 0x148a6a0
> ofonod[16939]: MUX: checking source: 0x14a0390
> ofonod[16939]: MUX: dispatching source: 0x14a0390
> ofonod[16939]: Chat2: > AT+CRSM=192,28474\r
> ofonod[16939]: MUX: removing source: 0x14a0390
> ofonod[16939]: MUX: checking source: 0x149eb80
> ofonod[16939]: MUX: checking channel for write: 0x1488ec0
> ofonod[16939]: MUX: dispatching write sources: 0x1488ec0
> ofonod[16939]: MUX: checking source: 0x148aaf0
> ofonod[16939]: MUX: checking channel for write: 0x1490430
> ofonod[16939]: MUX: dispatching write sources: 0x1490430
> ofonod[16939]: MUX: checking source: 0x148ad60
> ofonod[16939]: Chat1: Wakeup got no response
> ofonod[16939]: Aborting (signal 11) [ofonod]
> ofonod[16939]: ++++++++ backtrace ++++++++
>
> I suspect that should be a syncronization issue between the virtual
> channel. Any idea?
>

Can you compile oFono with debug information on (export CFLAGS=-O0, 
--enable-debug) and see whether you get a better backtrace.  This is 
pretty hard to debug with the information provided.

Regards,
-Denis

Re: SAGEM HiloNC v2 Driver

[Freedreamer]

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

2013/3/28 Freedreamer <freedreamer@email.it>

>
>
> 2013/3/28 Denis Kenzior <denkenz@gmail.com>
>
>> Hi,
>>
>> Please do not top-post on this mailing list.
>>
>>
>> On 03/28/2013 08:43 AM, Freedreamer wrote:
>>
>>> sorry did not over the mail....
>>>
>>> about ppp , Is that normal that I have to config these parameters?
>>>
>>>
>> Yes, this is normal.  oFono expects another daemon (e.g. ConnMan,
>> NetworkManager) to configure the network interfaces.
>>
>> Regards,
>> -Denis
>>
>>
> Hi guys,
>
> Sorry again! I'm a newbie in mailing list.
> Thanks for ppp issue I understand. I tried my code (that worked on x86) on
> the embedded ARM  board but we have problem , here the logs:
> ofonod[16939]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90,
> 00, 15
> ofonod[16939]: src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff:
> 0, tocopy: 15
> ofonod[16939]: MUX: waking up writer
> ofonod[16939]: MUX: creating source: 0x14a0390, channel: 0x148a6a0,
> writer: 4, reader: 0
> ofonod[16939]: MUX: can write data
> ofonod[16939]: MUX: checking channel for write: 0x148ac50
> ofonod[16939]: MUX: checking channel for write: 0x148a6a0
> ofonod[16939]: MUX: dispatching write sources: 0x148a6a0
> ofonod[16939]: MUX: checking source: 0x14a0390
> ofonod[16939]: MUX: dispatching source: 0x14a0390
> ofonod[16939]: Chat2: > AT+CRSM=192,28474\r
> ofonod[16939]: MUX: removing source: 0x14a0390
> ofonod[16939]: MUX: checking source: 0x149eb80
> ofonod[16939]: MUX: checking channel for write: 0x1488ec0
> ofonod[16939]: MUX: dispatching write sources: 0x1488ec0
> ofonod[16939]: MUX: checking source: 0x148aaf0
> ofonod[16939]: MUX: checking channel for write: 0x1490430
> ofonod[16939]: MUX: dispatching write sources: 0x1490430
> ofonod[16939]: MUX: checking source: 0x148ad60
> ofonod[16939]: Chat1: Wakeup got no response
> ofonod[16939]: Aborting (signal 11) [ofonod]
> ofonod[16939]: ++++++++ backtrace ++++++++
>
> I suspect that should be a syncronization issue between the virtual
> channel. Any idea?
>
>
> Hi ,
got new information. I start gdb and backtrace and i found where is the seg
fault. The function   "decode_at_error"  doesn't check if *error or *final
are NULL... and in my case they are.
if  I put a check in the function it remains stuck waiting AT cmd reply....

any help is appreciated.

Marco

below the logs:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7dbb740 (LWP 13322)]
0x000000000045d1be in decode_at_error ()
Missing separate debuginfos, use: debuginfo-install
bluez-libs-4.101-6.fc18.x86_64 dbus-libs-1.6.8-2.fc18.x86_64
glib2-2.34.2-2.fc18.x86_64 glibc-2.16-28.fc18.x86_64
libgcc-4.7.2-8.fc18.x86_64 systemd-libs-197-1.fc18.2.x86_64
(gdb) backtrace
#0  0x000000000045d1be in decode_at_error ()
#1  0x000000000045c6b0 in attr_cb ()
#2  0x000000000043fc28 in at_chat_finish_command ()
#3  0x000000000043fcb9 in wakeup_no_response ()
#4  0x00000034e56485db in g_timeout_dispatch () from /lib64/libglib-2.0.so.0
#5  0x00000034e5647a55 in g_main_context_dispatch () from
/lib64/libglib-2.0.so.0
#6  0x00000034e5647d88 in g_main_context_iterate.isra.24 () from
/lib64/libglib-2.0.so.0
#7  0x00000034e5648182 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#8  0x000000000040f5f2 in main ()



ofonod[16255]: MUX: received data
ofonod[16255]: MUX: deliver_data: dlc: 4
ofonod[16255]: MUX: dispatching sources for channel: 0xdd98b0
ofonod[16255]: MUX: checking source: 0xdd9980
ofonod[16255]: MUX: dispatching source: 0xdd9980
ofonod[16255]: Chat4: < \r\n+CGEV: NW DETACH\r\n
ofonod[16255]: Chat1: Wakeup got no response
ofonod[16255]: drivers/atmodem/atutil.c:decode_at_error() decode_at_error
null pointer
ofonod[16255]: Chat1: Wakeup got no response
ofonod[16255]: Chat1: Wakeup got no response
ofonod[16255]: Chat1: Wakeup got no response
ofonod[16255]: Chat1: Wakeup got no response
ofonod[16255]: Chat1: Wakeup got no response

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4781 bytes --]

Re: SAGEM HiloNC v2 Driver

[Denis Kenzior]

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

Hi,

> Hi ,
> got new information. I start gdb and backtrace and i found where is the
> seg fault. The function "decode_at_error"  doesn't check if *error or
> *final are NULL... and in my case they are.
> if  I put a check in the function it remains stuck waiting AT cmd reply....
>

The wakeup logic should only be used with the Freerunner.  Please 
disable it unless you know what you're doing.  Something else is wrong.

Regards,
-Denis

Re: SAGEM HiloNC v2 Driver

[Freedreamer]

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

Hi,

2013/3/28 Denis Kenzior <denkenz@gmail.com>

> Hi,
>
>
>  Hi ,
>> got new information. I start gdb and backtrace and i found where is the
>> seg fault. The function "decode_at_error"  doesn't check if *error or
>> *final are NULL... and in my case they are.
>> if  I put a check in the function it remains stuck waiting AT cmd
>> reply....
>>
>>
> The wakeup logic should only be used with the Freerunner.  Please disable
> it unless you know what you're doing.  Something else is wrong.
>
> Regards,
> -Denis
>

Denis u were right... removing wakeup cmd it seems it works again also on
the embedded board.Now i will work on ppp and connman integration.

Thanks

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1092 bytes --]

Re: SAGEM HiloNC v2 Driver

[Freedreamer]

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

Hi,

2013/3/29 Freedreamer <freedreamer@email.it>

> Hi,
>
>
> 2013/3/28 Denis Kenzior <denkenz@gmail.com>
>
>> Hi,
>>
>>
>>  Hi ,
>>> got new information. I start gdb and backtrace and i found where is the
>>> seg fault. The function "decode_at_error"  doesn't check if *error or
>>> *final are NULL... and in my case they are.
>>> if  I put a check in the function it remains stuck waiting AT cmd
>>> reply....
>>>
>>>
>> The wakeup logic should only be used with the Freerunner.  Please disable
>> it unless you know what you're doing.  Something else is wrong.
>>
>> Regards,
>> -Denis
>>
>
> Denis u were right... removing wakeup cmd it seems it works again also on
> the embedded board.Now i will work on ppp and connman integration.
>
> Thanks
>

I almost finished the driver..seems to work properly also on the embedded
device (just for SMS & PPP ). If I would like to share the code .. how
should I procede? would u like a patch posted here or a git  pull request ?
or what else ?

another issue  : anyone could explain what module should I see to properly
set the ppp0 interface once  got a valid IP from the PPP ?

Best regards.

Marco

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1893 bytes --]

Re: SAGEM HiloNC v2 Driver

[Denis Kenzior]

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

Hi Marco,

> I almost finished the driver..seems to work properly also on the
> embedded device (just for SMS & PPP ). If I would like to share the code
> .. how should I procede? would u like a patch posted here or a git  pull
> request ? or what else ?

Use git send-email and send the patches to the mailing list.  Please see 
'Submitting Patches' section in the HACKING document.

>
> another issue  : anyone could explain what module should I see to
> properly set the ppp0 interface once  got a valid IP from the PPP ?

See test/process-context-settings

Regards,
-Denis

Re: SAGEM HiloNC v2 Driver

[Freedreamer]

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

Hi,
2013/4/4 Denis Kenzior <denkenz@gmail.com>

> Hi Marco,
>
>
>  I almost finished the driver..seems to work properly also on the
>> embedded device (just for SMS & PPP ). If I would like to share the code
>> .. how should I procede? would u like a patch posted here or a git  pull
>> request ? or what else ?
>>
>
> Use git send-email and send the patches to the mailing list.  Please see
> 'Submitting Patches' section in the HACKING document.
>
>
>
>> another issue  : anyone could explain what module should I see to
>> properly set the ppp0 interface once  got a valid IP from the PPP ?
>>
>
> See test/process-context-settings
>
> Regards,
> -Denis
>

perfect! i'll keep in touch :)

tnx again!

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1295 bytes --]

SAGEM HiloNC v2 Driver

[Freedreamer]

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

Hi Everybody,

I'm developing a driver for an embedded system which uses a sagem HiloNC v2
and I really should need your help. It's my will to commit everything when
shall be ready and working.
First of all I will tell you what i did..I created a plugin sagem.c ,added
a new Vendor ,  modified makefile & other stuff and seems to work properly.
I started from calypso driver 'cause the modem is based on a Uart and I
needed the MUX over that.
With a very raw/dirty code I was able to use PPP/SMS/net service over
virtual com.. Very good work dude! :)

Now I would like to clean up my code and get a better understanding of the
stack. Unfortunately I saw that functions/modules are not always commented
so I have to ask u a lot of questions (maybe also trivial):

1) AT cmds sent with "g_at_chat_send" are always async , is that right ? Is
there any chance to get them sync ?
2) in enable fnc the modem is powered but The sim is not ready so sometimes
It hangs up...Do I have to to poll the sim status until is ready  , or the
driver will do  that by itself ?
3) could u explain me what should I really do in virtual fnc  set_online /
post_online ? i tried to stub them but they have not never been called...
4) unfortunately this modem has a SIM detection URC but it reset itself
every time the status changes... so i should call the disable function and
the enable again in order to have the MUX working... how can i do that?
5) I created and started the MUX as the first thing in enable fnc but is
that right ? sometimes seems that the modem hangs up if just powered up.
Put a delay but don't like it very much as a solution...moreover when I
power up the modem all the URC have been lost 'cause the MUX has not been
created yet..

Any help will be appreciated :)

thanks in advance

Marco

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1899 bytes --]

Re: SAGEM HiloNC v2 Driver

[Denis Kenzior]

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

Hi Marco,

On 03/26/2013 04:07 AM, Freedreamer wrote:
> Hi Everybody,
>
> I'm developing a driver for an embedded system which uses a sagem HiloNC
> v2 and I really should need your help. It's my will to commit everything
> when shall be ready and working.
> First of all I will tell you what i did..I created a plugin sagem.c
> ,added a new Vendor ,  modified makefile & other stuff and seems to work
> properly. I started from calypso driver 'cause the modem is based on a
> Uart and I needed the MUX over that.
> With a very raw/dirty code I was able to use PPP/SMS/net service over
> virtual com.. Very good work dude! :)
>
> Now I would like to clean up my code and get a better understanding of
> the stack. Unfortunately I saw that functions/modules are not always
> commented so I have to ask u a lot of questions (maybe also trivial):
>
> 1) AT cmds sent with "g_at_chat_send" are always async , is that right ?
> Is there any chance to get them sync ?

There is not, we do not want to encourage any sort of blocking behavior 
in the daemon.  Remember there are potentially multiple modems being 
operated on and we do not use threads.

> 2) in enable fnc the modem is powered but The sim is not ready so
> sometimes It hangs up...Do I have to to poll the sim status until is
> ready  , or the driver will do  that by itself ?

oFono never polls for anything.  It is the driver's responsibility to do 
that in the best possible way for the hardware.  Also, powering on the 
modem is separate from the sim being ready.  The general flow is this:

-Enable modem
-Wait for the modem to power on and use ofono_modem_set_powered when 
that happens successfully / fails.
- Figure out if the SIM is inserted and signal using 
ofono_sim_inserted_notify.  Do this step only once the SIM is ready to 
be queried for its PIN status and perform any I/O on SIM files that are 
always accessible (e.g. ICCID)


> 3) could u explain me what should I really do in virtual fnc  set_online
> / post_online ? i tried to stub them but they have not never been called...

oFono has 3 basic states:
- Off
- Radio Off, Sim On
- Radio On, Sim On

set_online turns radio on / off
post_online populates the atoms that are available in radio 'On' state.

> 4) unfortunately this modem has a SIM detection URC but it reset itself
> every time the status changes... so i should call the disable function
> and the enable again in order to have the MUX working... how can i do that?

I'm not following.  Care to elaborate?

> 5) I created and started the MUX as the first thing in enable fnc but is
> that right ? sometimes seems that the modem hangs up if just powered up.
> Put a delay but don't like it very much as a solution...moreover when I
> power up the modem all the URC have been lost 'cause the MUX has not
> been created yet..

That is what we do for most devices with a MUX, put it into MUX state 
right away after basic initialization.  The devices we have can be 
queried for their state in addition to URCs, so it works out very well.

Regards,
-Denis