[om2008.8] Testing packages for Qtopia
michael at openmoko.org
Tue Aug 12 21:51:51 CEST 2008
Lorn Potter wrote:
> Michael Shiloh wrote:
>> Holger Freyther wrote:
>>> 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:
>>> - QAtChat is responsible for queueing commands and forwarding
>>> - 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.
>>> - 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
>>> feedback is welcome, I've been running with these changes since
>> 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.
More information about the devel