FreeCalypso > hg > fc-magnetite

comparison doc/Handset-goal @ 374:3f2dce15278c

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc: new Handset-goal write-up replaces old Handset-configs
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 12 Jan 2018 01:39:11 +0000
parents doc/Handset-configs@5b1358df7e3c
children 3f1a587b3a84
comparison
equal deleted inserted replaced
373:9399a83cb394 374:3f2dce15278c
1 Work toward end user libre phone firmware
2 =========================================
3
4 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
6 additional layers of functionality beyond AT-command-controlled modem fw:
7
8 * The hardware-specific LCD driver, called R2D in TI's TCS211 program;
9 * The actual phone UI implementation, which the cellular industry calls by the
10 sexist term "MMI" - TI's implementation consists of two components called BMI
11 and MFW;
12 * Battery management (monitoring and charging);
13 * 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
15 failed but charging power source not unplugged yet.
16
17 The code we got from TI with the TCS211 delivery by Sotovik includes only a
18 very rudimentary implementation of the above functions that basically amounts
19 to nothing more than a proof of concept, and is absolutely not ready for driving
20 a real end user phone: the UI code contains crashing and other killer bugs, the
21 battery management driver officially endorsed by TI for the TCS211 program (LCC
22 for "low cost" unregulated chargers) is not appropriate for phones that use
23 simple charging circuits and regulated +5 VDC charging power sources (USB or
24 Motorola's C1xx charging adapters), and TI's older PWR battery management
25 driver (TI totally removed it from TCS211, but we pulled it from the older
26 MV100 source fragments) is bitrotten and just generally broken.
27
28 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
30 the "voice pseudo-modem" configuration (see doc/Voice-pseudo-modem), but we
31 still have the problem of the UI, namely, the lack of one that is practically
32 usable.
33
34 Because TI were in the business of making and selling chipsets rather than
35 complete phones, proper phone UI development was something they left to their
36 customers, and they provided only a very rough proof of concept implementation.
37 One difficulty which we face most immediately in our effort to turn this PoC UI
38 implementation into a practically usable one is the lack of support for our
39 desired target display sizes. Because TI apparently did not want to become
40 significantly involved in phone UI development, they did not provide a selection
41 of UI layouts for different LCD sizes; instead at each given point in TI's
42 history they only supported one display size - whatever their current
43 development platform at each moment had on it.
44
45 At the time of TCS211, TI's primary development platform was called D-Sample;
46 it consisted of a development board with the Calypso+Iota chipset on it (as
47 well as a GSM RF section based on their older Clara RF transceiver chip) plus
48 an attached test handset. Here are some pictures:
49
50 https://www.freecalypso.org/members/falcon/pictures/D-Sample/
51
52 The handset part of the D-Sample kit contains a 176x220 pixel color LCD, a
53 21-button main keypad just like on Mot C1xx and Pirelli DP-L10 phones, and 3
54 side buttons that almost match Pirelli's. This D-Sample was the main
55 development platform for the entire TCS211 program (basically everything except
56 the small parts specific to Rita RF for which they had their other Leonardo
57 development boards), including the UI - the latter was made to target the
58 176x220 pix LCD size on the D-Sample.
59
60 I (Mychaela) have managed to obtain one of these historical D-Sample kits (the
61 one pictured) back in 2015, and I have a strong desire to get the TCS211 PoC UI
62 up and running in its native 176x220 pixel size. However, the big difficulty
63 with getting our FC Magnetite firmware running on the original D-Sample board
64 (which, remember, is the original and most native hw target for TCS211!) is
65 that the D-Sample has Clara RF, not Rita, and we only got a stripped semi-src
66 version of TCS211 in which the *.c files for L1 were censored out and only
67 *.obj blobs were supplied instead. The latter blobs target Rita RF and not
68 Clara. We have now successfully reconstructed the lost C sources for the RF-
69 independent and Rita-specific L1 modules, and we have l1_rf10.c for Clara RF
70 from the MV100 source fragments, but we are still missing the tpudrv10.c module
71 which is also required for Clara RF.
72
73 Back in 2015 (when I first got this D-Sample kit) running our own firmware on
74 this historical board with an older version of the Calypso chip and with Clara
75 RF was absolutely out of the question, but since then we have made enormous
76 progress with our complete deblobbing of L1 and the init module and with our
77 FC Magnetite build system, and now that tpudrv10 module is literally the only
78 missing piece. Given these new circumstances, I plan on making some serious
79 effort to locate the TPU driver code in the ancient 20020917 fw image that came
80 with our DS board, and attempt to reconstruct the needed tpudrv10 code from
81 that.
82
83 We also have a fallback plan: if we are not able to get our FC Magnetite
84 firmware running on the historical TI-made D-Sample board, there is another way
85 to get TI's TCS211 UI code running in its original 176x220 pixel size, albeit
86 one that will require a lot of time, effort and expense: design and build our
87 own UI development board to take the place of TI's D-Sample, combining the good
88 version of the Calypso+Iota+Rita chipset for which we have good fw support with
89 a 176x220 pix color LCD of our own - it is one of the industry standard sizes,
90 so it should only be a matter of getting a semi-custom one with the right
91 interface (16-bit parallel) and the right polarizer orientation (6 o'clock
92 viewing direction). The proposed board would be a derivative of our current
93 FCDEV3B, keeping the core Calypso+RF block (originally from Openmoko) completely
94 unchanged, but adding the LCD, the keypad buttons and other handset peripherals,
95 resulting in a Handset Motherboard Prototype - HSMBP.
96
97 Once we get TI's TCS211 UI running in its original 176x220 pixel size like it
98 once ran in TI's own software development labs back in The Day, whether we do
99 it by way of TI's original DS board or our own HSMBP, the next step will be to
100 migrate it to the TCS2/TCS3 hybrid config, using the new versions of G23M PS
101 and ACI components. It will also be worthwhile to see if the new version of
102 this BMI+MFW code in the LoCosto version is any better than the one we got from
103 Sotovik. After these preliminary steps, the UI work can bifurcate:
104
105 * On the one hand, it will be worthwhile to produce a size-reduced version of
106 the UI that targets a 96x64 pixel LCD instead of 176x220 pix, but still full
107 color - thus fitting the LCD on Mot C139/140 phones on which we already run
108 our fw very successfully in the "voice pseudo-modem" config. We would then
109 be able to see if a Mot C139 phone running FreeCalypso fw can be a practically
110 usable end user phone, albeit a super-low-end one.
111
112 * On the other hand, it is my (Mychaela's) strong desire to have our own
113 FreeCalypso Libre Dumbphone hardware product; running FC fw on Mot C139 just
114 isn't enough to satisfy my ambition. My choice of LCD size for our own FC
115 Libre Dumbphone is 176x220 pix, matching TI's D-Sample, so that the rich UI
116 targeting this large LCD size can see the light of day as a real end user
117 product, and my planned HSMBP board is envisioned as not only an alternative
118 to the D-Sample, but also as the prototype motherboard for our FC Libre
119 Dumbphone.
120
121 Current state of the firmware
122 =============================
123
124 If we desire a libre phone for our pockets and purses (I do desire one for my
125 purse), we will have to bite the bullet and do the necessary work to transform
126 the UI and associated handset code from its current sorry state into something
127 usable, and I have started laying a little bit of the necessary foundation for
128 doing this work in FC Magnetite.
129
130 There is currently one Magnetite configuration (in the ./configure.sh sense)
131 that includes the UI layers, called 2092. 2092 is TI's bizarre "product"
132 number for the configuration that is just like the one we got from Sotovik
133 (called pdt_2091), but with BMI enabled. We previously had another config
134 called 2092-pwr that had TI's old PWR battery charging driver included, which
135 never worked because of severe bitrot - that config has now been dropped as the
136 regular 2092 config now includes our new and working FCHG battery charging
137 driver.
138
139 If you request the 2092 configuration for a target other than c139, i.e., for
140 fcdev3b, gtamodem or pirelli, you will get a successful build (to be pedantic,
141 if you pick gtamodem, you'll get a link failure unless you tweak the linker
142 script, but it's a minor nit), but if you then run that fw image on the
143 hardware, it won't do anything good: it will try to display TI's D-Sample UI
144 (176x220 pixels, color) on the D-Sample LCD attached to Calypso chip select
145 nCS3, but of course neither Openmoko's modem nor the Pirelli has a D-Sample LCD
146 on that chip select, thus the LCD output would fall into the aether. (It would
147 be even worse in the case of the Pirelli which has the 2nd flash bank on nCS3,
148 thus the D-Sample LCD writes could clash with the FFS code operating on that
149 flash - so don't do it.) However, because BMI is enabled, the fw will still
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.