FreeCalypso > hg > freecalypso-docs

comparison Firmware-deblobbing @ 35:14b8e532c966

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Firmware-deblobbing: update for the current situation
author Mychaela Falconia <falcon@freecalypso.org>
date Tue, 13 Oct 2020 05:51:30 +0000
parents f68ca40fa5c1
children
comparison
equal deleted inserted replaced
34:dd94e04b9539 35:14b8e532c966
1 The state of blobs vs. blob-free firmware in FreeCalypso 1 The state of blobs vs. blob-free firmware in FreeCalypso
2 ======================================================== 2 ========================================================
3 3
4 As of 2019, we have 3 different firmware versions for Standard Modem 4 Since 2018, we have 3 different firmware versions for Standard Modem
5 functionality: 5 functionality:
6 6
7 * Magnetite hybrid is the current production firmware version. The only blobs 7 * Magnetite hybrid is the current production firmware version. The only blobs
8 are Nucleus, OSL and OSX glue components of GPF, and TI's proprietary TMS470 8 are Nucleus, OSL and OSX glue components of GPF, and TI's proprietary TMS470
9 compiler. Everything other than Nucleus and OSL/OSX is compiled from source, 9 compiler. Everything other than Nucleus and OSL/OSX is compiled from source,
10 but the compiler is TI's proprietary TMS470. The same Magnetite source tree 10 but the compiler is TI's proprietary TMS470. The same Magnetite source tree
11 also supports other configurations (maintained only for regression testing) 11 also supports other configurations (maintained only for regression testing)
12 which have more blobs, as well as handset configurations which are currently 12 which have more blobs, as well as handset configurations which are a separate
13 frozen for lack of suitable development hardware. 13 subject. The total amount of blob code in this version is 43052 bytes out of
14 over 2 MiB firmware images.
14 15
15 * Selenite-470 is FC Selenite built with TI's TMS470 compiler: all code is 16 * Selenite-470 is FC Selenite built with TI's TMS470 compiler: all code is
16 compiled from source, no blobs other than the compiler and its RTS library 17 compiled from source, no blobs other than the compiler and its RTS library
17 (libc/libgcc equivalent). The blob version of Nucleus is replaced with a 18 (libc/libgcc equivalent). The blob version of Nucleus is replaced with a
18 different (slightly newer) version in full source form, while the blob 19 different (slightly newer) version in full source form, while the blob
51 If we can ever find these 10 missing files (does not even need to be exactly 52 If we can ever find these 10 missing files (does not even need to be exactly
52 the same version as in TCS211 GPF), then Selenite-470 would immediately become 53 the same version as in TCS211 GPF), then Selenite-470 would immediately become
53 the new production firmware replacing Magnetite (the Nucleus change isn't the 54 the new production firmware replacing Magnetite (the Nucleus change isn't the
54 problem, it's OSL and OSX), and the way would be cleared to begin work on 55 problem, it's OSL and OSX), and the way would be cleared to begin work on
55 bringing Selenite-gcc up to par. But in the absence of these 10 files, the 56 bringing Selenite-gcc up to par. But in the absence of these 10 files, the
56 following two interlocking problems get in the way of FC Selenite: 57 following situation holds currently:
57 58
58 1) I (Mother Mychaela) am not willing to skip Selenite-470 and jump directly to 59 * For my own personal use and enjoyment, I (Mother Mychaela) am quite happy
59 Selenite-gcc, as doing so would violate the fundamental principle of 60 with the current state of Magnetite hybrid, i.e., the few remaining blobs and
60 incrementality: we need to be making one small change at a time, requiring 61 the proprietary TMS470 compiler don't bother me. Thus I currently have no
61 full stability after each incremental change before going to the next. 62 incentive to work on further deblobbing unless one of two things happen: in
63 order to be incentivized, I would need either a copy of the 10 missing files
64 OR a highly paid commercial arrangement as described below.
62 65
63 2) I am not able to produce a reconstructed C source for certain parts of OSL 66 * If someone really desires it and puts substantial money behind it, it IS
64 which would result in correct object code when compiled with TMS470: the 67 possible to get to a blob-free, built with gcc state without the 10 missing
65 issue is potential race conditions in the OSL timer code. The existing COFF 68 files - but doing so would require investing major effort into our own
66 object code avoids the race, I can produce C code for compilation with gcc 69 disassembly-based reconstruction of OSL and OSX components. The total code
67 which also avoids the race, but I don't know the requisite magic for C code 70 size in these bone-in-our-throat blob components is only 14992 bytes, but
68 to be compiled with TMS470. 71 because I am a serious perfectionist, deblobbing/reconstructing these
69 72 components to my high standard of satisfaction would require a very major
70 At this point you are going to ask - OK, so what do we do if we can't find 73 effort. Because of my high standards and because of the amount of effort
71 those 10 missing files? The Mother's current plan is as follows: if these 10 74 that would be required to meet these high standards without getting a hold of
72 files are still missing when we get our handset UI development board built, I 75 the 10 missing files, I currently have no plans to do any more work in this
73 will create a third firmware source tree (not Magnetite, not Selenite, but to 76 direction in the absence of a commercial paid arrangement.
74 be named after some other mineral) with the following key properties:
75
76 * Just like Selenite, it will be hybrid only, no legacy blob-laden
77 configurations;
78
79 * Both modem and handset configurations will be included;
80
81 * The compiler will be TMS470 - sorry, no gcc;
82
83 * The version of Nucleus will be the new source-enabled one, same as Selenite;
84
85 * I will do some careful surgery on the OSL/OSX blobs to make them work with
86 the new version of Nucleus.
87
88 The result of these listed key properties is that the new firmware tree will
89 have blobs for OSL and OSX and will use the TMS470 compiler as required by
90 these blobs, but absolutely everything else will be source-enabled. This
91 situation will then persist until someone can wave a few million dollars in
92 front of TI to convince their execs to direct their archivists to dig up the 10
93 missing files, or until the world civilization collapses into a Mad Max world,
94 allowing us to seize those archives with a Spetsnaz unit without police
95 interference.
96
97 Special modem applications
98 ==========================
99
100 The above plan states that the third firmware source tree will be created as
101 described if the original OSL and OSX source files are still missing when we
102 get our handset UI development board built. The reason for this coupling is
103 that when we get this UIDB built, the floodgates will open for intensive
104 handset UI development. The latter work will need to be done without the
105 clutter of Magnetite, yet Selenite is blocked by the lack of the 10 missing
106 files - hence the case for the third firmware source tree as described above.
107
108 Alternatively, a third fw source tree similar to the one described (but perhaps
109 without the handset configuration) can be created if someone commissions
110 significant work on modem firmware, work that is significant enough to call for
111 a source tree that is as stable as Magnetite, but free of the clutter.
112 77
113 cdginc header files 78 cdginc header files
114 =================== 79 ===================
115 80
116 Another area of deblobbing that hasn't been done yet, but can be done when and 81 Another area of deblobbing that hasn't been done yet, but can be done when and