The state of blobs vs. blob-free firmware in FreeCalypso
========================================================

Since 2018, we have 3 different firmware versions for Standard Modem
functionality:

* Magnetite hybrid is the current production firmware version.  The only blobs
  are Nucleus, OSL and OSX glue components of GPF, and TI's proprietary TMS470
  compiler.  Everything other than Nucleus and OSL/OSX is compiled from source,
  but the compiler is TI's proprietary TMS470.  The same Magnetite source tree
  also supports other configurations (maintained only for regression testing)
  which have more blobs, as well as handset configurations which are a separate
  subject.  The total amount of blob code in this version is 43052 bytes out of
  over 2 MiB firmware images.

* Selenite-470 is FC Selenite built with TI's TMS470 compiler: all code is
  compiled from source, no blobs other than the compiler and its RTS library
  (libc/libgcc equivalent).  The blob version of Nucleus is replaced with a
  different (slightly newer) version in full source form, while the blob
  versions of OSL and OSX glue components have been replaced with reconstructed
  sources, i.e., a reconstruction based on disassembly.  This fw version is
  currently considered experimental, not cleared for production, and the reason
  is OSL/OSX: the reconstruction is of uncertain correctness and known to be
  incomplete.

* Selenite-gcc is FC Selenite built with gcc.  This version has no blobs
  whatsoever (there is no support in the gcc+binutils toolchain for TI's TMS470
  ABI, thus it is physically impossible to include any of TI's COFF blobs in
  the link), and it is built with a FLOSS compiler.  However, it is even more
  experimental and not-for-production than Selenite-470: not only is the OSL/OSX
  issue still there, but there is also widespread breakage from the use of a
  different compiler which was never anticipated by the original developers.
  The old FC Citrine firmware (unmaintained since 2016) also suffers from all
  of the same problems, plus additional ones, and therefore should not be
  considered at all.

When it comes to the firmware, right now those OSL and OSX glue components of
GPF form the biggest bone in our collective throat.  Just 10 C source files are
missing:

os_com.c
os_drv.c
os_evt.c
os_isr.c
os_mem.c
os_mis.c
os_pro.c
os_sem.c
os_tim.c
osx.c

If we can ever find these 10 missing files (does not even need to be exactly
the same version as in TCS211 GPF), then Selenite-470 would immediately become
the new production firmware replacing Magnetite (the Nucleus change isn't the
problem, it's OSL and OSX), and the way would be cleared to begin work on
bringing Selenite-gcc up to par.  But in the absence of these 10 files, the
following situation holds currently:

* For my own personal use and enjoyment, I (Mother Mychaela) am quite happy
  with the current state of Magnetite hybrid, i.e., the few remaining blobs and
  the proprietary TMS470 compiler don't bother me.  Thus I currently have no
  incentive to work on further deblobbing unless one of two things happen: in
  order to be incentivized, I would need either a copy of the 10 missing files
  OR a highly paid commercial arrangement as described below.

* If someone really desires it and puts substantial money behind it, it IS
  possible to get to a blob-free, built with gcc state without the 10 missing
  files - but doing so would require investing major effort into our own
  disassembly-based reconstruction of OSL and OSX components.  The total code
  size in these bone-in-our-throat blob components is only 14992 bytes, but
  because I am a serious perfectionist, deblobbing/reconstructing these
  components to my high standard of satisfaction would require a very major
  effort.  Because of my high standards and because of the amount of effort
  that would be required to meet these high standards without getting a hold of
  the 10 missing files, I currently have no plans to do any more work in this
  direction in the absence of a commercial paid arrangement.

cdginc header files
===================

Another area of deblobbing that hasn't been done yet, but can be done when and
if a serious need arises, is the cdginc header file set.  The cdginc files which
are currently used for our hybrid config aren't blobs in the strict sense: they
are C header files included by the sources being recompiled, but they have been
auto-generated (from true human-editable sources which we do have) by a tool
(ccdgen) which currently exists only as a Windows binary sans source.

If anyone needs to make changes to cdginc, the proper course of action should
be to hire a Windows reverser to reverse ccdgen.exe and to produce a perfect
form, fit and function replacement.