Hello FC community, While we wait for our FCDEV3B baby (should be no more than two weeks of waiting left according to what the assembly shop people told me), I have done some work on the software side of FreeCalypso. Here are the new developments so far:
* The deblobbing of the full TCS211 L1 (as opposed to the subset of L1 used in Citrine) is now complete except for the L1_GPRS-specific modules - all other L1 modules including l1audio and l1tm are now recompiled from C source. This deblobbed L1 can be found in the tcs211-l1-reconst and fc-magnetite Hg repositories. * All FC Magnetite build configurations that include FreeCalypso L1 have been updated to rebuild everything except L1_GPRS modules from the reconstructed source. * I've been doing a lot of work on the development host tools in the freecalypso-tools repository. Our Test Mode Shell fc-tmsh now supports almost all of the Test Mode commands (both TM3 and ETM) provided by TCS211 fw, using the same command names and syntax as TI's own TMSH (of which I don't have a copy!) when sensible, and we now have fc-cal2text and tiaud-decomp utilities for "in vitro" decoding of the firmware's RF calibration and audio mode config files, respectively. The one area which is currently lacking is documentation: all of these mighty tools need to be documented, and this documentation is currently lacking. Writing at least some documentation is on my TODO list. But if you don't mind reading the source to figure things out, there is a treasure trove of development and investigation capabilities waiting for you to tap into it. Once we get the FCDEV3B built and working, here are the things I would like to do, in no particular order: * Using the convenient access to both UARTs on the FCDEV3B, properly exercise the CSD and GPRS capabilities of our reference TCS211 fw, get a feel for them, and establish our baseline in this area. * Using the same convenient access to both UARTs, develop a mechanism for dynamically switching the main MODEM UART between its regular AT command operation and RVTMUX. The motivation is as follows: while serious development and debugging will always require both UARTs and all FC hardware should be designed to allow access to the second UART at least for developers, on many platforms it may be reasonable to have only one UART accessible in ordinary usage, with access to the second UART requiring a special cable or adapter. Ordinary users aren't expected to do a whole lot with RVTMUX, but there are a few tasks (FFS edits like changing your IMEISV or fixing a misprogrammed rfcap file) which ordinary users should be able to do and which are best done through RVTMUX, hence my idea of allowing a dynamic switch to bring RVTMUX to the MODEM UART on a non-persistent basis. * Put out a moko13 firmware release, based on Magnetite. Relative to the current state of FC Magnetite, I would like to make just two changes prior to releasing moko13: add the RVTMUX dynamic switch described above, and implement a firmware version ID scheme. * Once we have a platform (FCDEV3B) that both runs TCS211/Magnetite and has MCSI brought out (the pre-existing hw options satisfy one or the other, but not both), try out the "Bluetooth headset" voice path configuration (GSM voice routing to MCSI) and see if and how it works. Turning this mode on should now be as simple as sending an auw 0 2 command through fc-tmsh; I tried it on the GTA02 and the command executes without crashing the fw, but further testing requires the FCDEV3B and an oscilloscope probe on the MCSI pins. * The firmware we've got from TI includes a rich repertoire of L1/DSP-based audio services: supposedly it can play polyphonic melodies through the DSP, record and play back voice memos in both 06.10 and AMR formats, and even do speech recognition against pre-recorded samples in the user's own voice. I say supposedly because these functions have never been tested: we know the code is there because I just went through the trouble of deblobbing it, but whether it works or not is another question. I don't know what is more peculiar: the fact that this code is included in the sans-UI modem builds (like all of mokoN, for example) despite there being no way to invoke it, or the fact that none of the historical commercial Calypso-based dumbphones I've seen seem to make use of any of these features. In any case, I would like to exercise these functions by adding some debug AT commands that invoke them, but I want to do it on a platform where I don't have to hold the device up to my ear with cables connected from both sides, like one has to do when using a FreeRunner as a poor man's substitute for a proper GSM development board. * We are still using the all-blobs TCS211 version of the G23M protocol stack; in order to progress toward our desired blob-free state, we need to switch to the TCS2/TCS3 hybrid configuration (the one with G23M taken from LoCosto source) at some point. Once we have the FCDEV3B and have done all or most of the above, it will be a good time to tackle the hybrid modem firmware config. * Deblobbing L1_GPRS is the lowest priority: we need to switch to blob-free G23M (which includes GPRS) by polishing the TCS2/TCS3 hybrid config before it will make any sense to tackle L1_GPRS. This is all from me for now; back to waiting for the FCDEV3B assembly. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community