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.