[om2008.8] Testing packages for Qtopia

[Michael Shiloh]

Lorn Potter wrote:
> Michael Shiloh wrote:
>>
>> Holger Freyther wrote:
>>> Hey,
>>>
>>> I think that the No PIN Dialog (#1765, #1798), GSM Antenna/No Network 
>>> (#1766),  missing SMS notification (#1792) and the various duplicates 
>>> and variations (no phonebook..) are related to a funny issue in the 
>>> QAtChat and TI Calypso handling.
>>>
>>> As the planned "testing feed" might need one more day and the issue 
>>> is obviously quite big I have created a small Qtopia update.
>>>
>>> You can add: "src/gz zecke 
>>> http://people.openmoko.org/zecke/qtopia-testing/" to your feed config 
>>> and do a opkg update, opkg upgrade to get the Qtopia fixes. Feedback 
>>> is welcomed.
>>>
>>>
>>>
>>> Explanation of the issue:
>>>
>>> Players:
>>>     - QAtChat is responsible for queueing commands and forwarding 
>>> responses
>>>     - TI Calypso is the hardware/module that runs the GSM firmware.
>>>
>>> Ti Calypso:
>>>     - The module does PM on it's own. After ~5 seconds it goes to a 
>>> deep sleep/suspend. Writing anything to the serial will wake it up, 
>>> the down side is that the first command will be lost.
>>>
>>> QAtChat:
>>>     - This class can handle modems like the TI Calypso and can send a 
>>> wakeup command.
>>>
>>>
>>> So everything looks fine? Well, it depends on the wakeup command you 
>>> send. The existing code picked ATE0 which might or might not generate 
>>> a response. So the current code needs to discard everything that 
>>> comes from the modem until after a timeout (500msec) has passed. 
>>> Well, everything but notifications (first patch from me).
>>>
>>> Now timing enters the stage. Qtopia starts qdsync which on our flash 
>>> takes quite a bit to start and somehow the QAtChat queue is blocked, 
>>> sometimes we manage to send a ATE0 (wakeup before starting qdsync) 
>>> and the discard interval passed without executing any code but we 
>>> didn't process the input from the modem.... So we get an OK as ATE0 
>>> response and treat it like the response of the current command and 
>>> things start to fail. We treat the output of the previous command as 
>>> the result of the current one...
>>>
>>> Two solutions:
>>>     - Send a command that does not generate a response. Mickeyl found 
>>> one and is happily using that for the TI Calypso in ogsmd and I 
>>> copied that now.
>>>
>>>     - QAtChat::wakeupFinished might flush commands, or remove "OK" 
>>> but getting this right is really tricky. So the above solution is 
>>> preferred.
>>>
>>>
>>> feedback is welcome, I've been running with these changes since 
>>> saturday...
>>
>>
>> Holger,
>>
>> Thanks for this great explanation of what's going on at this level. 
>> This type of understanding is excellent.
>>
>> If you, or someone, had the time to wikify this information it would 
>> be wonderful.
> 
> why would you want to put this kind of bug report on a wiki? (unless you 
> mean internal)
> It will most likely get fixed/worked around at some point. The user can 
> do nothing about this anyway.
> 

Not the bug report, but the discussion of how QAtChat and Calypso talk 
to each other.

Michael