Mike (mwester) wrote: > So close. So very close... > > I've been expending much effort in fixing up the many suspend/resume > issues that have been crippling the poor GTA01. At this point, the > major ones are all resolved, but I've encountered a difficult one. > > So I have questions. This email is long, so for those with shorter > attention spans I'll cut to the chase:
thanks a lot. still feeling a bit sick, so i will only answer what i know now. > a) Where is the list of known problems with the different GSM modem > firmwares, and the list of fixes in each firmware? we hace such a list at openmoko, but i dunno about the release ability, will follow that up internally and report back. > b) Is there a document that describes what we (or anyone else, for that > matter) know about the problems or unexpected behavior of our version of > the S3C2410 SoC UARTs, especially with regard to auto flow control and > overruns? > c) What are the real-world parameters for the GSM modem with regard to > flow-control: > > 1) How much data can it buffer internally? > > 2) What does it do when its internal buffers fill -- does it throw > data away? Does it transmit despite being flow-controlled? Is there an > AT command available to alter or control how it behaves? Can it report > internal buffer overflows? What could trigger it to transmit despite > being flow-controlled? dunno, but good questions. sean c. should be able to answer that. ccing him. > 3) Do different firmware versions for this modem behave differently in > regard to flow control, and if so, how so? afaik not > d) If I were to acquire a scope, are the CTS, RTS, and other signals > between the GSM and the UART accessible on the debug board? Are there > pads on the phone itself? not on the debugboard, but on the device itself. should be labeled, but in case you want to really do that, just holler. > e) Can we do anything with gsmd, and/or phonekit, to work around the > problem in the meantime? -- Joachim Steiger developer relations/support
