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. |
