C1xx fw release followed by change of direction

[Mychaela Falconia]

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