Status of TCS211 on C139

[Mychaela Falconia]

Hi DS,

> Compiling tcs211-c139 was extremely straightforward, by the way on
> Debian 8 (and 7 too) wine behaves nicely, and the nowhine wrapper is
> not needed.

Nice. :-)

> When flashing the firmware at 812500 baud I encountered three times
> in a row the "error: command echo mismatch" message. Since I can flash
> my GTA02 and C118 at this speed I don't think the cable is to blame;
> instead, I suspect this C139 is not in great shape.

One thing to keep in mind is that the way in which both CP2102 and FTDI
USB-serial adapters produce an approximation to 812500 baud is quite
poor.  Both adapters produce their baud rates from a 24 MHz clock, and
the closest approximation to 812500 baud they can produce is either
800000 baud (divide by 30) or 827586 baud (divide by 29).  If you are
using a CP2102 adapter with baud rate programming copied from the
Pirelli (which is what one gets by following OsmocomBB's programming
instructions), then it implements 812500 baud as 800000 baud in reality.

It's an error of about 1.5%, and I read somewhere that RS232-inspired
asynchronous communications can tolerate an error of up to 3% - it was
a CP2102 application note that said so, thus one would hope that the
CP2102 can tolerate such errors, but we have no real way of knowing
how much baud rate error Calypso's UARTs can tolerate.  Perhaps the
error we run with using CP2102 adapters is right on the margin of what
the Calypso can tolerate, and some individual phones get unluckier
than others.

In my own experience, I never had a problem with 812500 baud on any of
the Pirelli phones that passed through my hands (about a dozen), and
they have a CP2102 built in, producing that very same "wrong" baud
rate of 800000 bps.  As for C139, I have dumped and/or reflashed a
couple of phones since I got my current cables from UberWaves, and
812500 baud has been working reliably with the FTDI cable with my
hacky kernel patch.  (See doc/High-speed-serial write-up.)  But as I
wrote before, the UberWaves CP2102 cable I got works only at 406250
baud.  812500 baud doesn't work at all with this cable - the
communication with loadagent gets lost right on the baud switch, so I
don't get as far as trying to flash - in your case the failure must be
happening later.

> Nonetheless flashing at 406250 baud worked fine,

One good thing about 406250 baud is that 24 MHz clock-based adapters
can produce it much more accurately than 812500.  CP2102 produces
406780 baud when programmed for 406250, so it's a much smaller error.

> There are some small artifacts on the left, but
> it's barely noticeable.

Yes, I noticed them too, but I haven't done any work to investigate
them yet - we have bigger problems right now.

> One thing I did change was altering chipsetsw/
> drivers/drv_app/ffs/board/dev.c to use 5 banks at 0x370000,

Umm-hmm, I still hold my view that having Mot/Compal's fw and our own
fw use the same FFS is a totally bad idea.  Yes, you can get the rfcap
setting "for free" this way, but since you still have to set your own
IMEISV (the original fw's /pcm/IMEI file is a dud), is it really that
hard to issue an extra set-rfcap command after the required-anyway
set-imeisv?

> this way
> I can keep the current FFS and flash back the original ROM in case I'd
> have to run tests on it.

The best way to allow a given phone to be reflashed freely back and
forth between Mot/Compal's fw and ours is to give the firmwares totally
separate FFS, *not* the same FFS!  This reasoning is exactly why I put
the aftermarket FFS configuration for FreeCalypso-on-C139 where I did:
Mot/Compal's fw won't touch the 0x3C0000-0x3EFFFF region we use, while
our fw won't touch the 0x370000-0x3BFFFF region the original fw uses
for its FFS.  This way whichever fw happens to be flashed in the
0-0x36FFFF region will use its respective FFS, while the other FFS
will sit there untouched, waiting for its respective fw to come back
and visit. :)

> Anyway this recent development is very satisfying! It is really nice
> to be able to play with the GUI, which is actually not bad at all -
> we might have to spice it up with some color though!

Yes, producing a UI that makes use of colors and the full 96x64 pix
screen is definitely on the to-do list, but first we need to track
down and fix the bugs that cause the fw to crash when one tries to
bring up the LDN list or read certain saved SMS on a SIM - have you
hit any of these bugs yet in your testing?

M~