Hello FC community, I have finished updating the documentation in the FC Magnetite source repository to reflect the current state of the software, and I just put out a binary fw release for C1xx phones containing 3 builds:
* Voice pseudo-modem fw for C11x/12x that requires permanent tethering to an external host for control via AT commands; * Similar VPM fw for C139/140; * Untethered phone fw for C139/140 includes the current proof-of-concept state of the UI. This binary release can be found here: ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/c1xx-fcmag-20180320.tar.bz2 Proper installation of this fw on a C1xx phone with RF calibration data migration and enabling of battery charging requires the just- released new version of FC host tools, i.e., fc-host-tools-r8. The specific instructions are inside the fw release tarball. VPM firmwares (the ones that require control via AT commands from a permanently connected external host) can be considered to be production quality, but the quality of the untethered phone fw is as poor as it ever was. Compared to what we had in 2015-2016, the new fw supports battery charging: if you have uploaded the charging config file with the new fc-host-tools-r8 version of fc-fsio during installation, when you plug in Motorola's charging power adapter, the battery will charge. However, there is still no connection between the battery management code (charging and discharge monitoring) and the UI, hence one cannot see any indication on the screen as to how the battery is doing. All of the other defects of the UI that is not only an unfinished proof of concept from TI, but also runs in the old C-Sample configuration (as opposed to the 176x220 pixel D-Sample UI which cannot be displayed on the C139's poor 96x64 pixel LCD) are still there, but there is also a "new" bug that appears to have come with the transition from the old TCS211 UI code to the new TCS3/LoCosto version: the first time you make a call, you can hear the ringback, but when the called party answers, the earpiece speaker suddenly goes silent. Until we can find and fix the bug in the code, the workaround is as follows: when the earpiece suddenly goes quiet like this, press the down-arrow button on the keypad. Pressing this button during a call brings up the volume control menu, and it has a side effect of bringing the earpiece speaker back to life, so you can hear what the other party is saying. Bugs or not, the new code version from TCS3 is what all further work needs to be based on: the old TCS211 versions of ACI and MFW+BMI are coupled to a G23M protocol stack version that exists only as blobs sans source, and those blobs need to go. The new TCS3 version of the protocol stack is full source, no more blobs, but it requires new versions of ACI and MFW+BMI to go with it. Therefore, at this point any further work on the old version of MFW+BMI (the UI code layers) would be a waste, and instead the effort needs to be put into the new TCS3-based code (what the present release is based on), which will have to include fixing any regression bugs: this volume shut-off bug appears to be one of them. And now comes the part which many of you will not like to hear. Because life is short and I never know how much I've got left, I have decided that I would rather spend my very limited energy on what I feel is right, rather than what is cheap. And that means working toward our own FreeCalypso Libre Phone hardware instead of hacking further on the unworthy crap from Motorola. Here is what it practically means: * Starting from now, I am redirecting my focus toward building the first prototype of my envisioned FreeCalypso phone with a 176x220 pix color LCD, a loudspeaker with the same driver circuit as on the FCDEV3B, and a USB port that combines charging with a built-in serial interface via a USB-serial chip like on the Pirelli - but unlike Pirelli, connect this USB-serial i/f to the MODEM UART on the Calypso, so we'll have a proper AT command interface for data functions and for the new SMS tools just recently released with fc-host-tools-r8. * I have no idea how long it will take me to build this first HSMBP (Handset Motherboard Prototype): I will need to get LCD modules with just the right specs (2" diagonal, 176x220 pix TFT, interface MUST be 16-bit parallel, the polarizer orientation MUST be for 6 o'clock viewing direction, may need to be made on a semi-custom basis with MOQ), I will need to have a custom FTDI adapter board made along with a custom FPC cable (similar to Openmoko's debug board arrangement), there will be some steps in the schematic design stage where it would really help to be able to hire a professional EE for assistance, and then PCB layout. I suspect it'll probably take me the rest of 2018 and likely most of 2019 to build this first HSMBP. * After I build my first HSMBP (but not before!), I will get back to the UI firmware, and whip it into shape to where it will become a practically usable phone. Because most of the code is target- independent, the usability of the C139 version will also automatically improve as a side benefit without explicit extra effort. But it will have to be after the HSMBP, not before, hence it won't be any time soon. This is the point where I have to very loudly and insistently repeat my call for someone else to take over the C139 branch of the FreeCalypso family of projects. Just because I am the founder and Mother of FreeCalypso does NOT mean that no one else is allowed to take my work and go further with it in a different direction - FreeCalypso is *free software*, and it is your natural right to take the code and do as you please with it! I have already done a MASSIVE amount of work over the past 5 y, including a ton of work that is specifically for C1xx targets which I have no personal interest in: the functional modem firmware (including C1xx target support) is now *free of blobs*, this blob-free modem fw appears to be rock solid, there is special support in fc-loadtool and friends to safely flash these brickable phones and deal with their different-from-TI boot process, thanks to the recent c1xx-calextr work FC running on C139 produces the right Tx power levels (so your phone does not become a rogue transmitter drawing the wrong kind of attention), there is a good battery charging driver designed and implemented from scratch by me, I've given you working drivers for the C139's LCD and keypad, and there is even a proof-of-concept UI implementation that kinda-sorta-works, giving you a place to start - all in the forward-looking blob-free configuration! But there comes a point where it is no longer reasonable for other people to expect me to continue to put in more and more work into something that will never give me any personal satisfaction, something that I would never want to use myself with a user hat on. Just to be clear, I am *not* giving up on FreeCalypso in general, instead what I am so fiercely against is forever limiting myself to the crippled C1xx hardware to the exclusion of the better FreeCalypso hw which I would rather build. The world is big enough to have room for diversity of opinion and diversity of preference. I want my own FreeCalypso Libre Dumbphone hardware, and will never be satisfied with Mot C1xx - but another person has every right to feel different, to actively prefer Mot C1xx hardware over FC hw, perhaps on the basis of cost and/or visual inconspicuousness. But the FLOSS community was never meant to be a one-way street in which one person or company does all the work and delivers software products while everyone else passively consumes - that is the way of proprietary sw, not the way of FLOSS. Instead the FLOSS model assumes that everyone scratches their own personal itch: I scratch *my* itch by producing various wares (both hard and soft) that do what *I* want, and if someone else desires something different from what I want (such as C1xx phone support as a priority over and against new FC phone hw), then it is YOUR duty as a FLOSS community member to stop being a passive consumer, brush up on your coding skills if necessary, and take the code into your own hands, make it do what you want. You've already been given a starting point that puts you many years ahead of where one would be if starting from scratch. If anyone is willing to take a stab at putting on the hat of a developer and trying their own hand at implementing and fixing those parts of FreeCalypso which I am not personally interested in (making FC-on-C139 into a usable phone ahead of my desired HSMBP), I recommend the following path to ease yourself into it: 1. Download, install and thoroughly familiarize yourself with FC host tools (the latest fc-host-tools-r8 release) first. You will need these tools before you can do anything else. 2. Download the binary fw release I just put out, and go through the process of installing it on a spare C139 phone. Do NOT put it on a phone which you use as your regular/main one, get a dedicated one just for development. You will need to become comfortable with the process of installing FC firmware on these phones before you can even think of doing your fw coding, so you may as well start the learning process with a known prebuilt binary version. 3. hg clone the fc-magnetite source tree from Bitbucket (yes, hg clone, not just download - install and learn Mercurial source control if you do not already have it and know it), and learn its configuration and build system. Get to a point where you can build your own fw images from so-far-unmodified source, and flash and run firmware which you have compiled yourself. The ###520# fw version screen shows the build date of the fw, which will be different if you do your own build instead of flashing a binary from me. 4. Only after you have done all of the above, start poking at the actual code. Thoroughly study and understand all of the Bourne shell magic in components/* and configs/* so you will know what code under src/ actually goes into your build - a lot of code there will only apply to other configs or not be used at all, so you need to be sure you aren't looking at the wrong code. Oh, and if anyone is considering making a libre phone out of a Pirelli DP-L10 rather than Mot C139, please be aware that because we don't know how to power down all of Pirelli's extra chips for WiFi, VoIP and the camera, with the current state of FC on this target there is a large parasitic current draw on the battery (I measured about 87 mA as the floor in total idle with all sleep modes enabled), and with this current draw it completely burns down a full battery in about 10 hours, i.e., about 10 h of just pure idle from 100% charged to emergency shut-off. Fixing this current draw, i.e., figuring out what Pirelli's original fw does to power down all those extra chips would require someone with reverse eng skills that are significantly better than mine, and a *lot* of dedication. Just keep this fact in mind before you decide to invest any time toward working on any other aspect of this Pirelli target. Also no one to my knowledge has yet reverse- engineered how to program Pirelli's loudspeaker driver chip, without which there is no loudspeaker and no ability to make the phone ring - although we do know how to turn on the vibrator. To the best of my knowledge, there are no similar show-stopping issues on the C139 - it just needs a fairly heavy amount of work of the most conventional sw engineering kind, no reversing or deep hardware digging, just high-level UI firmware work. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community