Hello FreeCalypso community, I need to revisit Openmoko's bug #666, the beastly bug involving SIM cards. For those who don't remember, early Moko GSM firmware versions had trouble accepting some newer SIM cards, those made at the time when 3G was just coming out. The issue got assigned bug #666, and because OM's people weren't willing to delve into the fw and debug the issue themselves even though they had enough source to do so, they bounced the issue to their TI support contact point. TI's support responded by giving OM a firmware patch, OM applied that patch, the problematic SIM cards started working, and the users were happy.
Our FC firmwares are based on moko11 for the chipsetsw division of the fw, and thus the version of the sim.c low-level driver we've been using so far is the one with OM's #666 "fix" included. SIM handling is one area of our firmware which I've been leaving untouched until recently, but in the past few days I had to dig pretty deeply into it while debugging a different SIM issue, and now I finally understand exactly what OM's "fix" for bug #666 has done - and I don't like it at all. OM's "fix" for bug #666 disables SIM speed enhancement. The electrical interface between SIM cards and phones (ISO/IEC 7816-3) is a kind of cross-breed between SPI and a UART: there is a dedicated clock line like in SPI, but instead of transmitting one bit of data on every clock, the transmission of bytes back and forth between the phone and the SIM is more UART-like, with each bit (called etu) taking many cycles of the underlying clock, and with the receiver needing to catch unpredictable asynchronous start times of characters just like a UART. Plus other quirks like having only one data line for both directions, requiring strictly half-duplex communication. The clock fed to the SIM by our dear Calypso is 3.25 MHz (13 MHz divided by 4), but the duration of each etu (one bit time for bytes going back and forth) depends on parameters called F and D - one etu is equal to F/D cycles of the underlying 3.25 MHz clock. When the SIM first comes out of its reset (upon RST line going high) and sends its Answer To Reset bytes to the host, F=372 and D=1 as mandated by the specs, meaning that each bit takes 372 cycles of the underlying clock. It is pretty slow. SIM interface specs going back decades (all the way back to original GSM 11.11) also specify an enhanced speed mode where F=512 and D=8, translating to just 64 cycles of the clock per bit instead of 372, or even faster modes depending on SIM support. The SIM interface hw block in our dear Calypso supports just two modes: one mode with F=372, D=1 (standard slow mode) and just one fixed speed enhancement mode with F=512, D=8. Most SIM cards today support even faster speed with F=512 and D=32, but Calypso SIM i/f doesn't go that fast. Calypso SIM i/f block has one bit in one hw register selecting between F=372, D=1 and F=512, D=8 modes. TI's original TCS211 fw prior to OM's #666 "fix" worked exactly as the specs prescribe: it would look at the TA1 byte in the SIM card's ATR in order to determine if the card supports speed enhancement and if it should be turned on. If TA1 is not present at all or if TA1 equals 0x11 or 0x01 (meaning that the card does not support anything other than default F=372 D=1 speed), the PTS procedure is skipped altogether, otherwise a PTS command gets sent to the SIM. In the original code, if TA1 indicates that F=512 D=8 or higher speed enhancement is supported, the code would ask the SIM for F=512 D=8 via PTS, otherwise PTS would be sent requesting default parameters of F=372 D=1. Error handling was exactly as prescribed in various specs: it would try the speed-enhanced PTS twice, resetting the card in between, then on the 3rd attempt (with resets in between) it would do PTS with default parameters (F=372 D=1), and on the 4th attempt it would skip PTS altogether. I don't see how this process can result in total card rejection no matter how badly the card behaves. But what OM's #666 "fix" does is that it disables SIM speed enhancement altogether: the code will send a PTS command to the card, but it will request the slow F=372 D=1 parameters from the start, no matter what speed capabilities the SIM declares in its ATR TA1 byte. But why??? And how in the world did this "fix" cause some SIM cards to start working when they didn't work before? The only rational explanation I can think of is that there was (and possibly still is) some other bug somewhere else (possibly even in hw, although unlikely IMO) that was triggered only when speed enhancement is used and only with certain SIMs having some particular unknown properties, but that other bug is masked when speed enhancement is disabled. I have build a test fw version with SIM speed enhancement restored, and I tested it with the SIMs I have. The result is that it works like a charm with "old" (but still 3G-enabled) T-Mobile SIMs (the latest T-Mobile SIMs don't work at all, with or without speed enhancement, because the bastards have disabled the classic GSM SIM application, leaving only USIM/ISIM crap) and with SysmoUSIM-SJS1, which has both SIM and USIM applications enabled. Because I don't like the idea of SIM speed enhancement being needlessly disabled for everyone (SIM operations became noticeably faster when I re-enabled it), I am thinking about reverting OM's #666 "fix" and restoring SIM speed enhancement when the card says in its TA1 byte that it is supported. Of course making this one change alone and nothing else will very likely cause those mystery SIMs (whichever ones caused that bug #666 complaint in the first place) to stop working once again - but what I don't know is whether or not anyone in our community still has one of those mysterious #666-impacted SIMs. The old OM community mailing list appears to be totally dead, thus I will NOT attempt to post there any more - instead *this* mailing list is the new GSM User Community, covering all end users of all GSM/2G devices whether they were made by Openmoko or by some other equally defunct vendor. Therefore, announcing and asking here is all I can do, and I shall proceed as follows: 1) I am making a formal solicitation right now: if anyone here has a long history of OM community involvement, remembers the days when bug #666 first hit, and has one of the affected SIMs, meaning a SIM that only started working when speed enhancement was disabled and didn't work before, I ask that you please consider sending it to me (I'll give you my mailing address, and I will wait however long it takes) so I can debug it and see what is really happening. Alternatively, if you have the necessary skills and tools, you can debug it yourself and post your findings here. 2) If no one responds to the above solicitation, I am going to assume that no one has one of those affected SIMs or more depressingly, no one cares at all. In that case I will go ahead and re-enable SIM speed enhancement in our Magnetite, Selenite and Tourmaline firmwares, and just leave it enabled until and unless someone reports a SIM problem once again. If someone does encounter a SIM problem, you will need to send the problematic SIM to me so I can debug it, figure out what the actual problem is, and find a solution that does not involve blanket-disabling SIM speed enhancement for everyone - or alternatively, you can debug it yourself and post your findings here, if you have the necessary skills and tools. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community