-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| Andy, there exists an _open_ ticket with detailed description. It | doesn't seem that anybody did any additional real-life testing or | verification as there is nothing except original report. I know | mwester did huge amount of testing especially with GTA01 where this | behaviour can be easily triggered and observed. | | Please, don't dismiss it that easily. | | URL (to bug tracker that is not used to track bugs properly) for your | reference: | | http://docs.openmoko.org/trac/ticket/1376 Well first thanks for not keeping the trac a big secret. The Trac talks about a behaviour seen by binding s3c2410 UART behaviour with flow control to the GSM chip. Due to differences in the CPU UART behaviour, it's a leap in the dark to claim the GTA02 problem is due to "multi character" granularity in GSM device. s3c2442 has 64-deep FIFO, not 16, the thresholds are different and this was not reported for GTA02 until post 2.6.24 kernels. '' In AFC, nRTS depends on the condition of the receiver and nCTS signals control the operation of the transmitter. The UART's transmitter transfers the data in FIFO only when nCTS signals are activated (in AFC, nCTS means that other UART's FIFO is ready to receive data). Before the UART receives data, nRTS has to be activated when its receive FIFO has a spare more than 32-byte and has to be inactivated when its receive FIFO has a spare under 32-byte (in AFC, nRTS means that its own receive FIFO is ready to receive data).'' (p11-4 on s3c2442 datasheet about UART). The GTA02 behaviour seems to revolve around an inserted \00 byte as far as I can make out, that doesn't seem to be the same behaviour as this GTA01 issue. ''...it does not appear that the overrun is by some small, constant number of characters (which might indicate a timing issue in the GSM or perhaps the hardware between it and the host UART). Instead all remaining characters in the message being transmitted are lost, regardless of the length of the message.'' That's not what is being seen with this current issue on GTA02. Werner says he's eyeballed the code and doesn't see a problem. Therefore I don't see that there is a "multi character" handshake granularity in the GSM device from all this. Do you see how to work that out from this? - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmQg0YACgkQOjLpvpq7dMqKCwCeMqbGjlTA+2hpbnxwF7v/676p 7bsAn29dUdV/086ZyOUKJ4CCWnFDbaOI =oqT6 -----END PGP SIGNATURE-----
