--- a/Firmware-deblobbing	Tue Sep 29 07:26:45 2020 +0000
+++ b/Firmware-deblobbing	Tue Oct 13 05:51:30 2020 +0000
@@ -1,7 +1,7 @@
 The state of blobs vs. blob-free firmware in FreeCalypso
 ========================================================
 
-As of 2019, we have 3 different firmware versions for Standard Modem
+Since 2018, we have 3 different firmware versions for Standard Modem
 functionality:
 
 * Magnetite hybrid is the current production firmware version.  The only blobs
@@ -9,8 +9,9 @@
   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 currently
-  frozen for lack of suitable development hardware.
+  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
@@ -53,62 +54,26 @@
 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 two interlocking problems get in the way of FC Selenite:
-
-1) I (Mother Mychaela) am not willing to skip Selenite-470 and jump directly to
-   Selenite-gcc, as doing so would violate the fundamental principle of
-   incrementality: we need to be making one small change at a time, requiring
-   full stability after each incremental change before going to the next.
+following situation holds currently:
 
-2) I am not able to produce a reconstructed C source for certain parts of OSL
-   which would result in correct object code when compiled with TMS470: the
-   issue is potential race conditions in the OSL timer code.  The existing COFF
-   object code avoids the race, I can produce C code for compilation with gcc
-   which also avoids the race, but I don't know the requisite magic for C code
-   to be compiled with TMS470.
-
-At this point you are going to ask - OK, so what do we do if we can't find
-those 10 missing files?  The Mother's current plan is as follows: if these 10
-files are still missing when we get our handset UI development board built, I
-will create a third firmware source tree (not Magnetite, not Selenite, but to
-be named after some other mineral) with the following key properties:
-
-* Just like Selenite, it will be hybrid only, no legacy blob-laden
-  configurations;
-
-* Both modem and handset configurations will be included;
-
-* The compiler will be TMS470 - sorry, no gcc;
+* 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.
 
-* The version of Nucleus will be the new source-enabled one, same as Selenite;
-
-* I will do some careful surgery on the OSL/OSX blobs to make them work with
-  the new version of Nucleus.
-
-The result of these listed key properties is that the new firmware tree will
-have blobs for OSL and OSX and will use the TMS470 compiler as required by
-these blobs, but absolutely everything else will be source-enabled.  This
-situation will then persist until someone can wave a few million dollars in
-front of TI to convince their execs to direct their archivists to dig up the 10
-missing files, or until the world civilization collapses into a Mad Max world,
-allowing us to seize those archives with a Spetsnaz unit without police
-interference.
-
-Special modem applications
-==========================
-
-The above plan states that the third firmware source tree will be created as
-described if the original OSL and OSX source files are still missing when we
-get our handset UI development board built.  The reason for this coupling is
-that when we get this UIDB built, the floodgates will open for intensive
-handset UI development.  The latter work will need to be done without the
-clutter of Magnetite, yet Selenite is blocked by the lack of the 10 missing
-files - hence the case for the third firmware source tree as described above.
-
-Alternatively, a third fw source tree similar to the one described (but perhaps
-without the handset configuration) can be created if someone commissions
-significant work on modem firmware, work that is significant enough to call for
-a source tree that is as stable as Magnetite, but free of the clutter.
+* 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
 ===================