:: Re: [maemo-leste] Grand plan to get…
Top Page
Delete this message
Reply to this message
Author: Merlijn Wajer
Date:  
To: Tony Lindgren, Pavel Machek
CC: maemo-leste, nekit1000, mpartap, sre, martin_rysavy
Subject: Re: [maemo-leste] Grand plan to get make phones... phone (for Motorola Droid 4)
Hi,

On 13/05/2020 21:16, Tony Lindgren wrote:
> * Tony Lindgren <tony@???> [200509 20:42]:
>> Below are the initial v5.7 kernel based branches at [0][1][2][3][4].
>>
>> We now use the generic serdev-ngsm driver with the standard /dev/gsmtty*
>> devices spun up by n_gsm instead of the custom /dev/motmdm* devices like
>> we did earlier. This means all the commands must prefix the Motorola
>> custom packet ID to the commands like:
>>
>> printf "U1234AT+CFUN?\r" > /dev/gsmtty1
>
> I got the minimal ofono updates done for serdev-ngsm and pushed out the
> changes into a new branc motmdm-serdev-ngsm on github at [5] below.
>
> I ended up adding few more gatchat patches. It's still unsure if we
> end up using any of those, that depends on the outcome of Pavel's work.
> Anyways, the current gatchat related commits are now:
>
> 419b63fdc93b ("gatchat: Allow configuring a custom header length")
> ba17d8002edf ("gatsyntax: Add handling for Motorola custom line header")
> 1049763ffd3e ("gatchat: Add support for optional terminator delimiter")
> 8ecd26be270e ("atutil: Handle custom suffix for OK on motorolamodem")
>
> The rest of the code is pretty much the same as in the earlier
> motmdm branch. I squashed the earlier bug fixes into the commits
> adding motmdm support though.
>
> The diff between motmdm..motmdm-serdev-ngsm branches is below for
> reference.


I had to fix this error, but otherwise it built and runs (probably a
musl vs glibc thing):

> drivers/motorolamodem/motorolamodem.c: In function ‘mot_at_chat_send’:
> drivers/motorolamodem/motorolamodem.c:44:2: error: unknown type name

‘uint16_t’; did you mean ‘u_int16_t’?
> uint16_t id;
> ^~~~~~~~
> u_int16_t


I can connect to the network, enter pin code, get sim card status, etc.
I still don't seem to get ofono notifications (like signal strength) on
time at all, though. If I wait for a few minutes, and then run the
send-sms script, I get a load of ofono signal strength updates, all at
once. Those are probably being queued up somewhere and not received
(note the timestamps):

> signal time=1589454570.078843 sender=:1.35 -> destination=(null destination) serial=169 path=/motmdm_0; interface=org.ofono.NetworkRegistration; member=PropertyChanged
>    string "Strength"
>    variant       byte 40
> signal time=1589454570.100084 sender=:1.35 -> destination=(null destination) serial=170 path=/motmdm_0; interface=org.ofono.NetworkRegistration; member=PropertyChanged
>    string "Strength"
>    variant       byte 60
> signal time=1589454570.102769 sender=:1.35 -> destination=(null destination) serial=171 path=/motmdm_0; interface=org.ofono.NetworkRegistration; member=PropertyChanged
>    string "Strength"
>    variant       byte 40
> signal time=1589454570.104143 sender=:1.35 -> destination=(null destination) serial=172 path=/motmdm_0; interface=org.ofono.NetworkRegistration; member=PropertyChanged
>    string "Strength"
>    variant       byte 60



Pavel, are you seeing this on your ofono fork/branch too?

I will add this ofono to the -devel repo today, since it's easy to build
for me. Happy to try to build Pavel's ofono too, if you think the repos
diverge significantly (it's not quite clear to me at this point).

Cheers,
Merlijn