FreeCalypso > hg > freecalypso-citrine
view doc/Current_Status @ 35:23dbd942aa56
doc/Current_Status: update for the latest fixes
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 15 Oct 2016 05:15:23 +0000 |
parents | cb00b90edaff |
children |
line wrap: on
line source
The goal of the Citrine firmware project is to replace the Windows-built firmwares which have been produced in other subprojects under the FreeCalypso umbrella - see leo2moko and tcs211-c139. Our leo2moko project has produced a production quality modem fw image for the Openmoko GTA02, while a C139 reflashed with tcs211-c139 is the first dumbphone in history that can still function as an untethered phone after having had its fw replaced with an indie one that bears no relation to the manufacturer's original - but those TCS211-based Windows-built projects have severe limitations. Much of the firmware code base in those versions is in the form of unmodifiable binary object libraries, and the Windows-based configuration and build system is incompatible with the long-term needs of FreeCalypso development. The present fw project (FreeCalypso Citrine) seeks to rectify the situation by replacing the blob-laden, Windows-built firmware with a version that is built from full source (no binary blobs) with gcc, with an entirely different configuration mechanism that actually suits our needs. Because one of the key goals of this project is to build the firmware from *full source*, the binary object versions of L1 (GSM Layer 1) and G23M (layers 2&3 of the protocol stack) featured in our reference TCS211 fw could not be reused. Instead this project uses versions of L1 and G23M (and some other pieces) that have been lifted from the firmware for TI's other chipset (LoCosto) and backported to Calypso. The current state of the project is that we have made remarkable progress, but what we have right now is still not a satisfactory replacement for TCS211. Specifically: * Only the bare minimal modem functionality for the voice+SMS subset has been integrated so far. "Modem" means our fw can only be controlled via AT commands; no UI code (as in LCD+keypad) has been integrated at all. But it is not a true modem either as none of the data functions have been integrated yet: no CSD, no fax, no GPRS. Thus it is an AT-command-controlled voice+SMS pseudo-modem. * The firmware can be built for the following targets: Mot C11x/12x Mot C139/140 Mot C155/156 Openmoko GTA01/02 Pirelli DP-L10 All configurations are built from the same source tree. The firmware functions identically on all supported targets. Because there is no UI code integrated yet, the LCD stays dark and the buttons do nothing on those target devices that have such hardware. * Most of our supported target devices have only one practically accessible serial port (UART). Our firmware presents TI's RVTMUX interface on this UART; the operator is expected to interface to it by running our rvinterf tools on the host PC/laptop. One of the utilities in the rvinterf suite is fc-shell; this tool is used to send AT commands to the running firmware, which is the only way to control its operation. * With a valid SIM card inserted and a valid IMEISV configured, a GSM device running our firmware can successfully connect to live commercial GSM networks, make and receive voice calls, and send and receive SMS. * In the case of voice calls, the call downlink audio is routed to the phone's earpiece speaker and the phone's microphone serves as the source for the uplink audio, i.e., even though the LCD and keypad are dead with our fw, the earpiece and mic continue to function as in a conventional phone. FR, EFR and AMR codecs all work correctly (EFR and AMR were broken until recently), but our default build configuration has AMR disabled (the fw advertises to the GSM network that the MS only supports FR, HR and EFR codecs) to err on the side of safety: we are having some reliability issues with the L1_DYN_DSP_DWNLD feature (which is also disabled by default), and AMR is believed to depend on one of these dynamically downloaded DSP patches. There is also a highly experimental and minimally tested alternative mode of operation in which the traffic channel carrying FR or EFR codec bits (260 bits every 20 ms) is rerouted away from the internal vocoder to the external host, such that you can receive the downlink voice bits digitally instead of listening to them in the earpiece speaker, and you can substitute your own uplink bits instead of the microphone-fed internal vocoder output. See the TCH-special-feature write-up for more information. Target-specific usage instructions ================================== If you would like to play with our work-in-progress firmware and check it out for yourself, see the following target-specific instructions: Mot C1xx (Compal) Compal-Howto Openmoko GTA01/02 Freerunner-Howto Pirelli DP-L10 Pirelli-Howto