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~ _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
