FreeCalypso end user libre phone goals======================================The Mother's primary goal in FreeCalypso is to create (design and build) ourown FreeCalypso libre phone handset (a Libre Dumbphone) that can replace theproprietary Pirelli DP-L10, retaining the following essential qualities of thelatter:* a "dumbphone" in the most classic "candybar" form factor with traditional dial buttons, NOT a smartphone;* a color LCD of a decent size (Pirelli's is 128x128 pixels, ours will be 176x220 pixels);* a loudspeaker that works for both hands-free calls and polyphonic ringtone melodies;* a USB port that combines charging with a built-in serial interface for computer interfacing.A secondary goal is to put together a firmware version that can be flashed intoa surplus Motorola C139 or C140 phone (obscenely cheap hardware) and turn thoseoriginally-proprietary phones into a sort of Libre Dumbphone Lite - functionallyinferior to our own FreeCalypso Libre Dumbphone because Mot C139/140 hardwareis significantly inferior to what I seek to build (no loudspeaker, no USB, muchsmaller LCD), but may be attractive to those cheap souls who are unwilling topay for higher-quality hardware. (Doing a similar feat with Pirelli DP-L10hardware - turning it into a Libre Dumbphone by way of aftermarket firmware -is not practically feasible: the effort to reverse-eng Pirelli's undocumentedhardware to the extent necessary for such a feat would cost at least as muchtime and money as designing and building our own Libre Dumbphone hardware,hence the latter is clearly preferable.)The primary goal of entirely new FreeCalypso Libre Phone hardware and thesecondary goal of FC on the C139 are not mutually exclusive: because we are aFLOSS project rather than proprietary sw, we do not artificially restrict whathardware our fw can run on and what functionality it can provide: while theprimary target for our Libre Dumbphone firmware will always be our own hw,whatever functionality can work on the more limited Mot C139 hw will work there,subject to the limitations of the crippled hw platform.However, in terms of timeline sequentiality, the critical point is that I,Mychaela Falconia, the Mother of FreeCalypso, am not willing to do any morework on the UI firmware (for any target) ahead of designing and building thefirst prototype of the just-outlined FC Libre Dumbphone hardware: when it comesto the work that *I* am doing, it has to be hardware first, then UI firmware.But the FreeCalypso codebase is free for everyone, it is free software whichanyone in the world is free to fork in whatever ways they like, hence for thosewho feel (contrary to my own personal stance) that aftermarket Libre Dumbphonefirmware for pre-existing hw platforms like Mot C139 is more important than newFreeCalypso Libre Dumbphone hardware, the correct solution for those people isto get over their fear of programming, roll up their sleeves and do somefirmware coding of their own.What we got from TI in terms of firmware========================================Phone handset firmware, i.e., fw that makes a phone device work as an untetheredphone and not just a serial-cable-controlled pseudo-modem, requires a fewadditional layers of functionality beyond AT-command-controlled modem fw:* The hardware-specific LCD driver, called R2D in TI's TCS211 program;* The actual phone UI implementation, which the cellular industry calls by the sexist term "MMI" - TI's implementation consists of two components called BMI and MFW;* Battery management (monitoring and charging);* Fairly complex on/off logic to handle all possible combinations of turn-on, turn-off, charging while "on", charging while "off", charging completed or failed but charging power source not unplugged yet.The bulk of the UI code resides in the BMI and MFW layers, which sit on top ofACI (Application Control Interface), which is the topmost layer of theunderlying GSM modem firmware stack. We got two different versions of thisMFW+BMI code from TI:* The version under src/aci2, used together with the original TCS211 versions of G23M PS and ACI components in the legacy 2092 config, has a very unclear origin: it came from the internal SVN of an obscure company that made AT-command-controlled Calypso modems (*not* complete phones with Calypso UI), those people did not use this code themselves at all (their environment was not even set up to be able to compile it), and it is totally unclear how they came to have that code which they did not use. It *might* correspond to the rest of TCS211 fw which we got from the same source, or it might not.* The version under src/ui3, used in our hybrid configs going forward, has a much clearer origin: we took it from TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src reference firmware for TI's later LoCosto chipset, which was published free to the world by Peek Inc. as that company was closing shop.We are now able to build UI-enabled firmware configs using both versions of TI'sMFW+BMI code, and there are no significant differences in the quality of thephone UI implementation: in both cases it is only a proof of concept, and isabsolutely not ready for driving a real end user phone: the UI code containscrashing and other killer bugs, the battery management driver officiallyendorsed by TI for TCS211 and later programs (LCC for "low cost" unregulatedchargers) is not appropriate for phones that use simple charging circuits andregulated +5 VDC charging power sources (USB or Motorola's C1xx chargingadapters), and TI's older PWR battery management driver (TI totally removed itfrom TCS211, but we pulled it from the older MV100 source fragments) isbitrotten and just generally broken.In FreeCalypso we have developed our own battery charging and dischargemonitoring driver (FCHG) that works on Mot C1xx and Pirelli DP-L10 phones inthe "voice pseudo-modem" configuration (see the Voice-pseudo-modem article),but we still have the problem of the UI, namely, the lack of one that ispractically usable. Because TI were in the business of making and sellingchipsets rather than complete phones, proper phone UI development was somethingthey left to their customers, and they provided only a very rough proof ofconcept implementation.What we have currently======================If you wish to play with our current work in progress based on TI's PoC UI code,you have 3 configurations (in the ./configure.sh sense) to choose from:2092 This is our first UI-enabled configuration; it got its name because it is a mostly unchanged replica of TI's pdt_2092 configuration in the original TCS211 program. This config uses the original TCS211 versions of G23M PS (blobs), ACI (source) and MFW+BMI (source) components. Data services (FAX_AND_DATA and GPRS) are enabled and cannot be disabled because of G23M PS blobs.hybrid-ui This config is the TCS2/TCS3 hybrid counterpart to the above, using the new full source versions of G23M PS, ACI and MFW+BMI from the TCS3.2/LoCosto source. FAX_AND_DATA and GPRS are still enabled.hybrid-ui-vo Same as hybrid-ui, but with FAX_AND_DATA and GPRS disabled, resulting in a lighter build.All 3 of the above configs can be usefully built for 3 hardware targets:dsample, fcdev3b and c139. The resulting firmware will work as follows:* If you have a real TI-made D-Sample board with the attached test handset (the platform that TI's own software engineers used when working on this UI code, at least before LoCosto), TI's 176x220 pixel color UI will be displayed on the LCD in the handset part of the kit, just the way TI meant it. However, because we are missing a piece of code for Clara RF, GSM radio won't work, and the UI can only be exercised as it would work in the absence of coverage: one can step through the menus and read SIM phonebook entries and saved messages, but no calls. See the D-Sample article for the details.* You can run a UI-enabled firmware build on our FCDEV3B modem board that has no physical LCD or keypad hardware, and display TI's 176x220 pixel color UI on a connected external host, sending simulated keypresses from the same - look in the freecalypso-ui-dev repository for the necessary tools.* When a UI-enabled firmware config is built for the C139 target, the UI config (Bourne shell variable UI_CONFIG in our configuration and Makefile generation system) is switched from TI's D-Sample UI (176x220 pix color, UI_CONFIG=bigcolor) to their older C-Sample UI: 84x48 pix black & white, UI_CONFIG=84x48. This 84x48 pix B&W C-Sample UI is then displayed on the 96x64 pixel physical LCD on the C139 phone.If you are interested in the Mot C139 hardware target and you are interested inturning our current state of affairs into something that would allow you to useyour C139 as a practically usable libre phone with FreeCalypso, the Motherstrongly recommends that you use the hybrid-ui-vo configuration as your startingpoint; working on the old src/aci2 UI code that is slated for retirement becauseit is coupled to a G23M PS version that exists only as binary blobs would be atotal waste. If you try to use our current hybrid-ui-vo firmware on the C139as a practical phone, the following problems will be the ones that hit you mostimmediately, and therefore would need to be fixed first:* The FCHG driver included in the fw build does monitor the battery state of charge as it discharges, and you can query it with the standard AT+CBC command using the AT-over-RVTMUX channel on the headset jack serial port, but it is not connected to the UI, hence the battery icon on the screen shows no useful info. Thus with an end user hat on, you would have no way of knowing if your battery is full or almost empty and about to die any second or anywhere in between.* The firmware similarly supports battery charging, but once again there is absolutely no indication in the UI as to the state of the charging process as in progress, completion or errors. Instead you can only observe this charging process by watching the debug trace output emitted on the headset jack serial port.* Every standard commercial end user phone implements a special mode of operation that is activated if the user plugs in the charging power source while the phone is off: the phone firmware boots just enough to manage the battery charging process (the LCD shows nothing but this charging process), but does not boot all the way to "full on" operation (SIM bring-up and network search) until and unless some designated button is pressed to request such full boot. The proof-of-concept code we got from TI does not implement this special "charging boot" mode; instead if you connect the charging power source to a fully-off phone, the result will be a full boot just as if you pressed the red power-on button. This lack of the expected "charging boot" mode is bad, as one really needs a "charge while off" mode in order to properly recover from a fully discharged battery.* Every standard commercial end user phone implements some timer logic for the power-on button, such that if the phone is fully off, the power button needs to be pressed not just momentarily, but held down for some time in order to make the phone turn on and boot. This logic provides necessary protection from accidental turn-ons: if you are in some place where your phone needs to be off and you have turned it off, you don't want it booting back up on its own because the button got pressed momentarily from the phone being in your pocket or purse. This logic is currently missing.* The LCD on Mot C139 phones is already small, only 96x64 pixels, but with the current firmware using the UI which TI originally created for their C-Sample and earlier development boards, the usable area is reduced even further to only 84x48 pixels. Likewise the physical LCD is color, but the UI is only black&white because the UI code "thinks" it's running on a C-Sample board which only had a black&white LCD. Massively reworking the UI code to make use of the full 96x64 pixel LCD real estate, along with some colors, ought to be essential before this UI can really become fit for end user operation.Some of these just-listed killer bugs are specific to the C139 target, whileothers will still be there when we have our own HSMBP with a 176x220 pix colorLCD like on the D-Sample. Those bugs which are not C139-specific will be fixedin the process of making our own FreeCalypso Libre Dumbphone based on our ownhardware, and by virtue of the common code the fixes will benefit the C139target as well. In the case of C139-specific bugs, i.e., those specific to thetiny screen size or to the weird (not TI-canonical) way in which the powerbutton is wired on C1xx phones, it is not currently known whether or not I(Mychaela aka The Mother) will ever be willing to invest significant work intothese C139-specific issues. Thus the message is loud and clear: those whodesire FreeCalypso as aftermarket libre phone fw for Mot C139 or other non-FChardware need to roll up their sleeves and start learning the code.