# HG changeset patch # User Mychaela Falconia # Date 1602568290 0 # Node ID 14b8e532c9666bdaa182d7337575f0d3b6f5a667 # Parent dd94e04b953905967269a87c3a0b46b006aa7a07 Firmware-deblobbing: update for the current situation diff -r dd94e04b9539 -r 14b8e532c966 Firmware-deblobbing --- 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 ===================