FreeCalypso > hg > fc-magnetite
comparison doc/Handset-goal @ 374:3f2dce15278c
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. |