[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