[om2008.8] Testing packages for Qtopia

Lorn Potter lpotter at trolltech.com
Tue Aug 12 20:02:10 CEST 2008

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.

Lorn 'ljp' Potter
Software Engineer, Systems Group, Trolltech, a Nokia company

More information about the devel mailing list