Reopening Openmoko's bug #666

[Mychaela Falconia]

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