FreeCalypso > hg > fc-magnetite

comparison doc/Handset-goal @ 463:712c5cc0b2a9

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/Handset-goal: update for the current situation
author Mychaela Falconia <falcon@freecalypso.org>
date Tue, 20 Mar 2018 01:29:44 +0000
parents 3f1a587b3a84
children
comparison
equal deleted inserted replaced
462:78e19122fa2b 463:712c5cc0b2a9
1 Work toward end user libre phone firmware 1 FreeCalypso end user libre phone goals
2 ========================================= 2 ======================================
3
4 The Mother's primary goal in FreeCalypso is to create (design and build) our
5 own FreeCalypso libre phone handset (a Libre Dumbphone) that can replace the
6 proprietary Pirelli DP-L10, retaining the following essential qualities of the
7 latter:
8
9 * a "dumbphone" in the most classic "candybar" form factor with traditional
10 dial buttons, NOT a smartphone;
11 * a color LCD of a decent size (Pirelli's is 128x128 pixels, ours will be
12 176x220 pixels);
13 * a loudspeaker that works for both hands-free calls and polyphonic ringtone
14 melodies;
15 * a USB port that combines charging with a built-in serial interface for
16 computer interfacing.
17
18 A secondary goal is to put together a firmware version that can be flashed into
19 a surplus Motorola C139 or C140 phone (obscenely cheap hardware) and turn those
20 originally-proprietary phones into a sort of Libre Dumbphone Lite - functionally
21 inferior to our own FreeCalypso Libre Dumbphone because Mot C139/140 hardware
22 is significantly inferior to what I seek to build (no loudspeaker, no USB, much
23 smaller LCD), but may be attractive to those cheap souls who are unwilling to
24 pay for higher-quality hardware. (Doing a similar feat with Pirelli DP-L10
25 hardware - turning it into a Libre Dumbphone by way of aftermarket firmware -
26 is not practically feasible: the effort to reverse-eng Pirelli's undocumented
27 hardware to the extent necessary for such a feat would cost at least as much
28 time and money as designing and building our own Libre Dumbphone hardware,
29 hence the latter is clearly preferable.)
30
31 The primary goal of entirely new FreeCalypso Libre Phone hardware and the
32 secondary goal of FC on the C139 are not mutually exclusive: because we are a
33 FLOSS project rather than proprietary sw, we do not artificially restrict what
34 hardware our fw can run on and what functionality it can provide: while the
35 primary target for our Libre Dumbphone firmware will always be our own hw,
36 whatever functionality can work on the more limited Mot C139 hw will work there,
37 subject to the limitations of the crippled hw platform.
38
39 However, in terms of timeline sequentiality, the critical point is that I,
40 Mychaela Falconia, the Mother of FreeCalypso, am not willing to do any more
41 work on the UI firmware (for any target) ahead of designing and building the
42 first prototype of the just-outlined FC Libre Dumbphone hardware: when it comes
43 to the work that *I* am doing, it has to be hardware first, then UI firmware.
44
45 But the FreeCalypso codebase is free for everyone, it is free software which
46 anyone in the world is free to fork in whatever ways they like, hence for those
47 who feel (contrary to my own personal stance) that aftermarket Libre Dumbphone
48 firmware for pre-existing hw platforms like Mot C139 is more important than new
49 FreeCalypso Libre Dumbphone hardware, the correct solution for those people is
50 to get over their fear of programming, roll up their sleeves and do some
51 firmware coding of their own.
52
53 What we got from TI in terms of firmware
54 ========================================
3 55
4 Phone handset firmware, i.e., fw that makes a phone device work as an untethered 56 Phone handset firmware, i.e., fw that makes a phone device work as an untethered
5 phone and not just a serial-cable-controlled pseudo-modem, requires a few 57 phone and not just a serial-cable-controlled pseudo-modem, requires a few
6 additional layers of functionality beyond AT-command-controlled modem fw: 58 additional layers of functionality beyond AT-command-controlled modem fw:
7 59
12 * Battery management (monitoring and charging); 64 * Battery management (monitoring and charging);
13 * Fairly complex on/off logic to handle all possible combinations of turn-on, 65 * Fairly complex on/off logic to handle all possible combinations of turn-on,
14 turn-off, charging while "on", charging while "off", charging completed or 66 turn-off, charging while "on", charging while "off", charging completed or
15 failed but charging power source not unplugged yet. 67 failed but charging power source not unplugged yet.
16 68
17 The code we got from TI with the TCS211 delivery by Sotovik includes only a 69 The bulk of the UI code resides in the BMI and MFW layers, which sit on top of
18 very rudimentary implementation of the above functions that basically amounts 70 ACI (Application Control Interface), which is the topmost layer of the
19 to nothing more than a proof of concept, and is absolutely not ready for driving 71 underlying GSM modem firmware stack. We got two different versions of this
20 a real end user phone: the UI code contains crashing and other killer bugs, the 72 MFW+BMI code from TI:
21 battery management driver officially endorsed by TI for the TCS211 program (LCC 73
22 for "low cost" unregulated chargers) is not appropriate for phones that use 74 * The version under src/aci2, used together with the original TCS211 versions
23 simple charging circuits and regulated +5 VDC charging power sources (USB or 75 of G23M PS and ACI components in the legacy 2092 config, has a very unclear
24 Motorola's C1xx charging adapters), and TI's older PWR battery management 76 origin: it came from the internal SVN of an obscure company that made
25 driver (TI totally removed it from TCS211, but we pulled it from the older 77 AT-command-controlled Calypso modems (*not* complete phones with Calypso UI),
26 MV100 source fragments) is bitrotten and just generally broken. 78 those people did not use this code themselves at all (their environment was
79 not even set up to be able to compile it), and it is totally unclear how they
80 came to have that code which they did not use. It *might* correspond to the
81 rest of TCS211 fw which we got from the same source, or it might not.
82
83 * The version under src/ui3, used in our hybrid configs going forward, has a
84 much clearer origin: we took it from TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src
85 reference firmware for TI's later LoCosto chipset, which was published free
86 to the world by Peek Inc. as that company was closing shop.
87
88 We are now able to build UI-enabled firmware configs using both versions of TI's
89 MFW+BMI code, and there are no significant differences in the quality of the
90 phone UI implementation: in both cases it is only a proof of concept, and is
91 absolutely not ready for driving a real end user phone: the UI code contains
92 crashing and other killer bugs, the battery management driver officially
93 endorsed by TI for TCS211 and later programs (LCC for "low cost" unregulated
94 chargers) is not appropriate for phones that use simple charging circuits and
95 regulated +5 VDC charging power sources (USB or Motorola's C1xx charging
96 adapters), and TI's older PWR battery management driver (TI totally removed it
97 from TCS211, but we pulled it from the older MV100 source fragments) is
98 bitrotten and just generally broken.
27 99
28 In FreeCalypso we have developed our own battery charging and discharge 100 In FreeCalypso we have developed our own battery charging and discharge
29 monitoring driver (FCHG) that works on Mot C1xx and Pirelli DP-L10 phones in 101 monitoring driver (FCHG) that works on Mot C1xx and Pirelli DP-L10 phones in
30 the "voice pseudo-modem" configuration (see the Voice-pseudo-modem article), 102 the "voice pseudo-modem" configuration (see the Voice-pseudo-modem article),
31 but we still have the problem of the UI, namely, the lack of one that is 103 but we still have the problem of the UI, namely, the lack of one that is
32 practically usable. 104 practically usable. Because TI were in the business of making and selling
33 105 chipsets rather than complete phones, proper phone UI development was something
34 Because TI were in the business of making and selling chipsets rather than 106 they left to their customers, and they provided only a very rough proof of
35 complete phones, proper phone UI development was something they left to their 107 concept implementation.
36 customers, and they provided only a very rough proof of concept implementation. 108
37 One difficulty which we face most immediately in our effort to turn this PoC UI 109 What we have currently
38 implementation into a practically usable one is the lack of support for our 110 ======================
39 desired target display sizes. Because TI apparently did not want to become 111
40 significantly involved in phone UI development, they did not provide a selection 112 If you wish to play with our current work in progress based on TI's PoC UI code,
41 of UI layouts for different LCD sizes; instead at each given point in TI's 113 you have 3 configurations (in the ./configure.sh sense) to choose from:
42 history they only supported one display size - whatever their current 114
43 development platform at each moment had on it. 115 2092 This is our first UI-enabled configuration; it got its name
44 116 because it is a mostly unchanged replica of TI's pdt_2092
45 At the time of TCS211, TI's primary development platform was called D-Sample; 117 configuration in the original TCS211 program. This config uses
46 it consisted of a development board with the Calypso+Iota chipset on it (as 118 the original TCS211 versions of G23M PS (blobs), ACI (source)
47 well as a GSM RF section based on their older Clara RF transceiver chip) plus 119 and MFW+BMI (source) components. Data services (FAX_AND_DATA
48 an attached test handset. Here are some pictures: 120 and GPRS) are enabled and cannot be disabled because of G23M PS
49 121 blobs.
50 https://www.freecalypso.org/members/falcon/pictures/D-Sample/ 122
51 123 hybrid-ui This config is the TCS2/TCS3 hybrid counterpart to the above,
52 The handset part of the D-Sample kit contains a 176x220 pixel color LCD, a 124 using the new full source versions of G23M PS, ACI and MFW+BMI
53 21-button main keypad just like on Mot C1xx and Pirelli DP-L10 phones, and 3 125 from the TCS3.2/LoCosto source. FAX_AND_DATA and GPRS are
54 side buttons that almost match Pirelli's. This D-Sample was the main 126 still enabled.
55 development platform for the entire TCS211 program (basically everything except 127
56 the small parts specific to Rita RF for which they had their other Leonardo 128 hybrid-ui-vo Same as hybrid-ui, but with FAX_AND_DATA and GPRS disabled,
57 development boards), including the UI - the latter was made to target the 129 resulting in a lighter build.
58 176x220 pix LCD size on the D-Sample. 130
59 131 All 3 of the above configs can be usefully built for 3 hardware targets:
60 I (Mychaela) have managed to obtain one of these historical D-Sample kits (the 132 dsample, fcdev3b and c139. The resulting firmware will work as follows:
61 one pictured) back in 2015, and I have a strong desire to get the TCS211 PoC UI 133
62 up and running in its native 176x220 pixel size. However, the big difficulty 134 * If you have a real TI-made D-Sample board with the attached test handset (the
63 with getting our FC Magnetite firmware running on the original D-Sample board 135 platform that TI's own software engineers used when working on this UI code,
64 (which, remember, is the original and most native hw target for TCS211!) is 136 at least before LoCosto), TI's 176x220 pixel color UI will be displayed on
65 that the D-Sample has Clara RF, not Rita, and we only got a stripped semi-src 137 the LCD in the handset part of the kit, just the way TI meant it. However,
66 version of TCS211 in which the *.c files for L1 were censored out and only 138 because we are missing a piece of code for Clara RF, GSM radio won't work,
67 *.obj blobs were supplied instead. The latter blobs target Rita RF and not 139 and the UI can only be exercised as it would work in the absence of coverage:
68 Clara. We have now successfully reconstructed the lost C sources for the RF- 140 one can step through the menus and read SIM phonebook entries and saved
69 independent and Rita-specific L1 modules, and we have l1_rf10.c for Clara RF 141 messages, but no calls. See the D-Sample article for the details.
70 from the MV100 source fragments, but we are still missing the tpudrv10.c module 142
71 which is also required for Clara RF. 143 * You can run a UI-enabled firmware build on our FCDEV3B modem board that has
72 144 no physical LCD or keypad hardware, and display TI's 176x220 pixel color UI
73 Back in 2015 (when I first got this D-Sample kit) running our own firmware on 145 on a connected external host, sending simulated keypresses from the same -
74 this historical board with an older version of the Calypso chip and with Clara 146 look in the freecalypso-ui-dev repository for the necessary tools.
75 RF was absolutely out of the question, but since then we have made enormous 147
76 progress with our complete deblobbing of L1 and the init module and with our 148 * When a UI-enabled firmware config is built for the C139 target, the UI config
77 FC Magnetite build system, and now that tpudrv10 module is literally the only 149 (Bourne shell variable UI_CONFIG in our configuration and Makefile generation
78 missing piece. Given these new circumstances, I plan on making some serious 150 system) is switched from TI's D-Sample UI (176x220 pix color,
79 effort to locate the TPU driver code in the ancient 20020917 fw image that came 151 UI_CONFIG=bigcolor) to their older C-Sample UI: 84x48 pix black & white,
80 with our DS board, and attempt to reconstruct the needed tpudrv10 code from 152 UI_CONFIG=84x48. This 84x48 pix B&W C-Sample UI is then displayed on the
81 that. 153 96x64 pixel physical LCD on the C139 phone.
82 154
83 We also have a fallback plan: if we are not able to get our FC Magnetite 155 If you are interested in the Mot C139 hardware target and you are interested in
84 firmware running on the historical TI-made D-Sample board, there is another way 156 turning our current state of affairs into something that would allow you to use
85 to get TI's TCS211 UI code running in its original 176x220 pixel size, albeit 157 your C139 as a practically usable libre phone with FreeCalypso, the Mother
86 one that will require a lot of time, effort and expense: design and build our 158 strongly recommends that you use the hybrid-ui-vo configuration as your starting
87 own UI development board to take the place of TI's D-Sample, combining the good 159 point; working on the old src/aci2 UI code that is slated for retirement because
88 version of the Calypso+Iota+Rita chipset for which we have good fw support with 160 it is coupled to a G23M PS version that exists only as binary blobs would be a
89 a 176x220 pix color LCD of our own - it is one of the industry standard sizes, 161 total waste. If you try to use our current hybrid-ui-vo firmware on the C139
90 so it should only be a matter of getting a semi-custom one with the right 162 as a practical phone, the following problems will be the ones that hit you most
91 interface (16-bit parallel) and the right polarizer orientation (6 o'clock 163 immediately, and therefore would need to be fixed first:
92 viewing direction). The proposed board would be a derivative of our current 164
93 FCDEV3B, keeping the core Calypso+RF block (originally from Openmoko) completely 165 * The FCHG driver included in the fw build does monitor the battery state of
94 unchanged, but adding the LCD, the keypad buttons and other handset peripherals, 166 charge as it discharges, and you can query it with the standard AT+CBC command
95 resulting in a Handset Motherboard Prototype - HSMBP. 167 using the AT-over-RVTMUX channel on the headset jack serial port, but it is
96 168 not connected to the UI, hence the battery icon on the screen shows no useful
97 Once we get TI's TCS211 UI running in its original 176x220 pixel size like it 169 info. Thus with an end user hat on, you would have no way of knowing if your
98 once ran in TI's own software development labs back in The Day, whether we do 170 battery is full or almost empty and about to die any second or anywhere in
99 it by way of TI's original DS board or our own HSMBP, the next step will be to 171 between.
100 migrate it to the TCS2/TCS3 hybrid config, using the new versions of G23M PS 172
101 and ACI components. It will also be worthwhile to see if the new version of 173 * The firmware similarly supports battery charging, but once again there is
102 this BMI+MFW code in the LoCosto version is any better than the one we got from 174 absolutely no indication in the UI as to the state of the charging process as
103 Sotovik. After these preliminary steps, the UI work can bifurcate: 175 in progress, completion or errors. Instead you can only observe this
104 176 charging process by watching the debug trace output emitted on the headset
105 * On the one hand, it will be worthwhile to produce a size-reduced version of 177 jack serial port.
106 the UI that targets a 96x64 pixel LCD instead of 176x220 pix, but still full 178
107 color - thus fitting the LCD on Mot C139/140 phones on which we already run 179 * Every standard commercial end user phone implements a special mode of
108 our fw very successfully in the "voice pseudo-modem" config. We would then 180 operation that is activated if the user plugs in the charging power source
109 be able to see if a Mot C139 phone running FreeCalypso fw can be a practically 181 while the phone is off: the phone firmware boots just enough to manage the
110 usable end user phone, albeit a super-low-end one. 182 battery charging process (the LCD shows nothing but this charging process),
111 183 but does not boot all the way to "full on" operation (SIM bring-up and
112 * On the other hand, it is my (Mychaela's) strong desire to have our own 184 network search) until and unless some designated button is pressed to request
113 FreeCalypso Libre Dumbphone hardware product; running FC fw on Mot C139 just 185 such full boot. The proof-of-concept code we got from TI does not implement
114 isn't enough to satisfy my ambition. My choice of LCD size for our own FC 186 this special "charging boot" mode; instead if you connect the charging power
115 Libre Dumbphone is 176x220 pix, matching TI's D-Sample, so that the rich UI 187 source to a fully-off phone, the result will be a full boot just as if you
116 targeting this large LCD size can see the light of day as a real end user 188 pressed the red power-on button. This lack of the expected "charging boot"
117 product, and my planned HSMBP board is envisioned as not only an alternative 189 mode is bad, as one really needs a "charge while off" mode in order to
118 to the D-Sample, but also as the prototype motherboard for our FC Libre 190 properly recover from a fully discharged battery.
119 Dumbphone. 191
120 192 * Every standard commercial end user phone implements some timer logic for the
121 Current state of the firmware 193 power-on button, such that if the phone is fully off, the power button needs
122 ============================= 194 to be pressed not just momentarily, but held down for some time in order to
123 195 make the phone turn on and boot. This logic provides necessary protection
124 If we desire a libre phone for our pockets and purses (I do desire one for my 196 from accidental turn-ons: if you are in some place where your phone needs to
125 purse), we will have to bite the bullet and do the necessary work to transform 197 be off and you have turned it off, you don't want it booting back up on its
126 the UI and associated handset code from its current sorry state into something 198 own because the button got pressed momentarily from the phone being in your
127 usable, and I have started laying a little bit of the necessary foundation for 199 pocket or purse. This logic is currently missing.
128 doing this work in FC Magnetite. 200
129 201 * The LCD on Mot C139 phones is already small, only 96x64 pixels, but with the
130 There is currently one Magnetite configuration (in the ./configure.sh sense) 202 current firmware using the UI which TI originally created for their C-Sample
131 that includes the UI layers, called 2092. 2092 is TI's bizarre "product" 203 and earlier development boards, the usable area is reduced even further to
132 number for the configuration that is just like the one we got from Sotovik 204 only 84x48 pixels. Likewise the physical LCD is color, but the UI is only
133 (called pdt_2091), but with BMI enabled. We previously had another config 205 black&white because the UI code "thinks" it's running on a C-Sample board
134 called 2092-pwr that had TI's old PWR battery charging driver included, which 206 which only had a black&white LCD. Massively reworking the UI code to make
135 never worked because of severe bitrot - that config has now been dropped as the 207 use of the full 96x64 pixel LCD real estate, along with some colors, ought to
136 regular 2092 config now includes our new and working FCHG battery charging 208 be essential before this UI can really become fit for end user operation.
137 driver. 209
138 210 Some of these just-listed killer bugs are specific to the C139 target, while
139 If you request the 2092 configuration for a target other than c139, i.e., for 211 others will still be there when we have our own HSMBP with a 176x220 pix color
140 fcdev3b, gtamodem or pirelli, you will get a successful build (to be pedantic, 212 LCD like on the D-Sample. Those bugs which are not C139-specific will be fixed
141 if you pick gtamodem, you'll get a link failure unless you tweak the linker 213 in the process of making our own FreeCalypso Libre Dumbphone based on our own
142 script, but it's a minor nit), but if you then run that fw image on the 214 hardware, and by virtue of the common code the fixes will benefit the C139
143 hardware, it won't do anything good: it will try to display TI's D-Sample UI 215 target as well. In the case of C139-specific bugs, i.e., those specific to the
144 (176x220 pixels, color) on the D-Sample LCD attached to Calypso chip select 216 tiny screen size or to the weird (not TI-canonical) way in which the power
145 nCS3, but of course neither Openmoko's modem nor the Pirelli has a D-Sample LCD 217 button is wired on C1xx phones, it is not currently known whether or not I
146 on that chip select, thus the LCD output would fall into the aether. (It would 218 (Mychaela aka The Mother) will ever be willing to invest significant work into
147 be even worse in the case of the Pirelli which has the 2nd flash bank on nCS3, 219 these C139-specific issues. Thus the message is loud and clear: those who
148 thus the D-Sample LCD writes could clash with the FFS code operating on that 220 desire FreeCalypso as aftermarket libre phone fw for Mot C139 or other non-FC
149 flash - so don't do it.) However, because BMI is enabled, the fw will still 221 hardware need to roll up their sleeves and start learning the code.
150 automatically bring up the GSM radio and register to the default network
151 immediately upon boot like a typical UI-enabled phone does, even though the
152 associated LCD output will be invisible. Needless to say, this configuration
153 is not something I would ever advise actually running - but it is there in
154 anticipation of my idea of running our fw on the original D-Sample board as
155 described above.
156
157 However, if you build the 2092 config for the c139 target, the Magnetite build
158 system will enable the same hack which was originally implemented in the
159 tcs211-c139 side project in late 2015. Prior to the D-Sample with its fancy
160 176x220 pix color LCD, TI's previous development platforms (C-Sample and
161 earlier) had 84x48 pix black&white (1 bit per pixel) LCDs, and this old C-Sample
162 LCD support is still there in TCS211, albeit in a bitrotten form that wouldn't
163 even compile without a lot of fixing. In our late-2015 tcs211-c139 side project
164 we had resurrected this C-Sample UI configuration, and this work has now been
165 integrated into Magnetite. When you build Magnetite in the 2092 configuration
166 for the c139, you will get our C139 LCD driver that pretends to be C-Sample to
167 the upper layers, and you will get TI's old 84x48 pix B&W UI displayed on the
168 phone's 96x64 pixel color LCD. IOW, only 84x48 out of the available 96x64
169 pixels are used, and only 2 out of the available 65536 colors. Yes, pretty
170 pathetic, I know.
171
172 Going forward, the plan is as outlined above - I wish to see this UI code run
173 in the proper 176x220 pix color display config that once existed in TI's own
174 development environment before I do anything else to it. I am not happy at all
175 about having had to disable TI's D-Sample UI (the 176x220 pix color one) and
176 resurrect the ancient pathetic C-Sample one instead, and given the long list of
177 show-stopping bugs this UI code currently exhibits, I can never be sure which
178 of these bugs were already there in the D-Sample config this code was made for,
179 vs. which of these bugs could be a result of re-enabling the very bitrotten
180 C-Sample UI config - remember, it wouldn't even compile at first.
181
182 Deblobbing status
183 =================
184
185 The current 2092 config is based on the l1reconst modem config (see the
186 Modem-configs write-up), i.e., the entire chipsetsw division of the fw
187 including all of L1 and the init code in main.lib is fully rebuilt from source,
188 but the versions of G23M PS and ACI are the original TCS211 ones, thus the G23M
189 PS component is all blobs. In order to build a G23M-deblobbed UI-enabled
190 config, we would need to build the UI layers (MFW and BMI) on top of the new
191 TCS3.2 version of ACI used in the deblobbed hybrid config, and no such feat has
192 been attempted yet. My current plan is to work in this direction after we
193 either get our fw running on the historical D-Sample board or build our own
194 HSMBP.