FreeCalypso > hg > fc-magnetite
comparison doc/Handset-configs @ 219:b05dba024f95
doc/Handset-configs and doc/Modem-configs written
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 15 Oct 2016 22:41:38 +0000 |
parents | |
children | 5b1358df7e3c |
comparison
equal
deleted
inserted
replaced
218:75ea63a3fce5 | 219:b05dba024f95 |
---|---|
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 code doesn't work (fails to even monitor the battery voltage | |
22 in the discharging state, and I haven't even got to trying to charge), and the | |
23 on/off logic is broken in several ways. | |
24 | |
25 If we desire a libre phone for our pockets and purses (I do desire one for my | |
26 purse), we will have to bite the bullet and do the necessary work to transform | |
27 the UI and associated handset code from its current sorry state into something | |
28 usable, and I have started laying a little bit of the necessary foundation for | |
29 doing this work in FC Magnetite. | |
30 | |
31 There are currently two Magnetite configurations (in the ./configure.sh sense) | |
32 that include the UI layers: 2092 and 2092-pwr. 2092 is TI's bizarre "product" | |
33 number for the configuration that is just like the one we got from Sotovik | |
34 (called pdt_2091), but with BMI enabled. The difference between the plain 2092 | |
35 config and 2092-pwr is that the latter includes TI's battery management code in | |
36 the form of the old RiViera Software Entity (SWE) called PWR. (I tested the | |
37 latter on the C139 and found it to be broken.) | |
38 | |
39 If you request the 2092 configuration for a target other than c139, i.e., for | |
40 fcdev3b, gtamodem or pirelli, you will get a successful build (to be pedantic, | |
41 if you pick gtamodem, you'll get a link failure unless you tweak the linker | |
42 script, but it's a minor nit), but if you then run that fw image on the | |
43 hardware, it won't do anything good: it will try to display TI's D-Sample UI | |
44 (176x220 pixels, color) on the D-Sample LCD attached to Calypso chip select | |
45 nCS3, but of course neither Openmoko's modem nor the Pirelli has a D-Sample LCD | |
46 on that chip select, thus the LCD output would fall into the aether. (It would | |
47 be even worse in the case of the Pirelli which has the 2nd flash bank on nCS3, | |
48 thus the D-Sample LCD writes could clash with the FFS code operating on that | |
49 flash - so don't do it.) However, because BMI is enabled, the fw will still | |
50 automatically bring up the GSM radio and register to the default network | |
51 immediately upon boot like a typical UI-enabled phone does, even though the | |
52 associated LCD output will be invisible. Needless to say, this configuration | |
53 is not something I would ever advise actually running. | |
54 | |
55 However, if you build the 2092 config for the c139 target, the Magnetite build | |
56 system will enable the same hack which was originally implemented in the | |
57 tcs211-c139 side project in late 2015. Prior to the D-Sample with its fancy | |
58 176x220 pix color LCD, TI's previous development platforms (C-Sample and | |
59 earlier) had 84x48 pix black&white (1 bit per pixel) LCDs, and this old C-Sample | |
60 LCD support is still there in TCS211, albeit in a bitrotten form that wouldn't | |
61 even compile without a lot of fixing. In our late-2015 tcs211-c139 side project | |
62 we had resurrected this C-Sample UI configuration, and this work has now been | |
63 integrated into Magnetite. When you build Magnetite in the 2092 configuration | |
64 for the c139, you will get our C139 LCD driver that pretends to be C-Sample to | |
65 the upper layers, and you will get TI's old 84x48 pix B&W UI displayed on the | |
66 phone's 96x64 pixel color LCD. IOW, only 84x48 out of the available 96x64 | |
67 pixels are used, and only 2 out of the available 65536 colors. Yes, pretty | |
68 pathetic, I know. | |
69 | |
70 My (Mychaela's) plan going forward is to build our own more proper hardware | |
71 before digging any deeper into TI's broken UI code. I am not happy at all | |
72 about having had to disable TI's D-Sample UI (the 176x220 pix color one) and | |
73 resurrect the ancient pathetic C-Sample one instead, and given the long list of | |
74 show-stopping bugs this UI code currently exhibits, I can never be sure which | |
75 of these bugs were already there in the D-Sample config this code was made for, | |
76 vs. which of these bugs could be a result of re-enabling the very bitrotten | |
77 C-Sample UI config - remember, it wouldn't even compile at first. | |
78 | |
79 As much as I would love to have a libre phone in my purse, my desire to see | |
80 TI's UI code running in its native 176x220 pix color form is even greater, hence | |
81 I have decided that I shall abstain from doing any further UI work targeting | |
82 the C139 or the Pirelli until *after* we have built my desired HSMBP: Handset | |
83 Motherboard Prototype, a Calypso board with a 176x220 pix color LCD just like | |
84 on TI's D-Sample. | |
85 | |
86 However, if anyone else in the community has a different view and sees the | |
87 making of a libre phone based on Mot C1xx or Pirelli hardware as more important | |
88 than building our own hw, please feel free to take a stab at the code yourself: | |
89 the whole point of FLOSS projects is that anyone can do what s/he wants with | |
90 the code and the project without being beholden to the leader's views. At least | |
91 some of the necessary foundation has already been laid for you. | |
92 | |
93 Deblobbing status | |
94 ================= | |
95 | |
96 The current 2092 and 2092-pwr configs are based on the l1reconst modem config | |
97 (see the Modem-configs write-up), i.e., L1 is mostly rebuilt from source, but | |
98 the versions of G23M PS and ACI are the original TCS211 ones, thus the G23M PS | |
99 component is all blobs. In order to build a G23M-deblobbed UI-enabled config, | |
100 we would need to build the UI layers (MFW and BMI) on top of the new TCS3.2 | |
101 version of ACI used in the deblobbed hybrid config, and no such feat has been | |
102 attempted yet. I personally plan on tackling this direction only after we have | |
103 built my desired D-Sample-like HSMBP and brought up the original TCS211 UI in | |
104 its original form, but once again, anyone else whose priorities are different | |
105 from mine should feel free to delve into the code themselves. |