FreeCalypso > hg > fc-magnetite
view doc/Handset-goal @ 384:56ac93768594
README: update for C11x support
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 14 Jan 2018 21:00:21 +0000 |
parents | 3f1a587b3a84 |
children | 712c5cc0b2a9 |
line wrap: on
line source
Work toward end user libre phone firmware ========================================= Phone handset firmware, i.e., fw that makes a phone device work as an untethered phone and not just a serial-cable-controlled pseudo-modem, requires a few additional layers of functionality beyond AT-command-controlled modem fw: * The hardware-specific LCD driver, called R2D in TI's TCS211 program; * The actual phone UI implementation, which the cellular industry calls by the sexist term "MMI" - TI's implementation consists of two components called BMI and MFW; * Battery management (monitoring and charging); * Fairly complex on/off logic to handle all possible combinations of turn-on, turn-off, charging while "on", charging while "off", charging completed or failed but charging power source not unplugged yet. The code we got from TI with the TCS211 delivery by Sotovik includes only a very rudimentary implementation of the above functions that basically amounts to nothing more than a proof of concept, and is absolutely not ready for driving a real end user phone: the UI code contains crashing and other killer bugs, the battery management driver officially endorsed by TI for the TCS211 program (LCC for "low cost" unregulated chargers) is not appropriate for phones that use simple charging circuits and regulated +5 VDC charging power sources (USB or Motorola's C1xx charging adapters), and TI's older PWR battery management driver (TI totally removed it from TCS211, but we pulled it from the older MV100 source fragments) is bitrotten and just generally broken. In FreeCalypso we have developed our own battery charging and discharge monitoring driver (FCHG) that works on Mot C1xx and Pirelli DP-L10 phones in the "voice pseudo-modem" configuration (see the Voice-pseudo-modem article), but we still have the problem of the UI, namely, the lack of one that is practically usable. Because TI were in the business of making and selling chipsets rather than complete phones, proper phone UI development was something they left to their customers, and they provided only a very rough proof of concept implementation. One difficulty which we face most immediately in our effort to turn this PoC UI implementation into a practically usable one is the lack of support for our desired target display sizes. Because TI apparently did not want to become significantly involved in phone UI development, they did not provide a selection of UI layouts for different LCD sizes; instead at each given point in TI's history they only supported one display size - whatever their current development platform at each moment had on it. At the time of TCS211, TI's primary development platform was called D-Sample; it consisted of a development board with the Calypso+Iota chipset on it (as well as a GSM RF section based on their older Clara RF transceiver chip) plus an attached test handset. Here are some pictures: https://www.freecalypso.org/members/falcon/pictures/D-Sample/ The handset part of the D-Sample kit contains a 176x220 pixel color LCD, a 21-button main keypad just like on Mot C1xx and Pirelli DP-L10 phones, and 3 side buttons that almost match Pirelli's. This D-Sample was the main development platform for the entire TCS211 program (basically everything except the small parts specific to Rita RF for which they had their other Leonardo development boards), including the UI - the latter was made to target the 176x220 pix LCD size on the D-Sample. I (Mychaela) have managed to obtain one of these historical D-Sample kits (the one pictured) back in 2015, and I have a strong desire to get the TCS211 PoC UI up and running in its native 176x220 pixel size. However, the big difficulty with getting our FC Magnetite firmware running on the original D-Sample board (which, remember, is the original and most native hw target for TCS211!) is that the D-Sample has Clara RF, not Rita, and we only got a stripped semi-src version of TCS211 in which the *.c files for L1 were censored out and only *.obj blobs were supplied instead. The latter blobs target Rita RF and not Clara. We have now successfully reconstructed the lost C sources for the RF- independent and Rita-specific L1 modules, and we have l1_rf10.c for Clara RF from the MV100 source fragments, but we are still missing the tpudrv10.c module which is also required for Clara RF. Back in 2015 (when I first got this D-Sample kit) running our own firmware on this historical board with an older version of the Calypso chip and with Clara RF was absolutely out of the question, but since then we have made enormous progress with our complete deblobbing of L1 and the init module and with our FC Magnetite build system, and now that tpudrv10 module is literally the only missing piece. Given these new circumstances, I plan on making some serious effort to locate the TPU driver code in the ancient 20020917 fw image that came with our DS board, and attempt to reconstruct the needed tpudrv10 code from that. We also have a fallback plan: if we are not able to get our FC Magnetite firmware running on the historical TI-made D-Sample board, there is another way to get TI's TCS211 UI code running in its original 176x220 pixel size, albeit one that will require a lot of time, effort and expense: design and build our own UI development board to take the place of TI's D-Sample, combining the good version of the Calypso+Iota+Rita chipset for which we have good fw support with a 176x220 pix color LCD of our own - it is one of the industry standard sizes, so it should only be a matter of getting a semi-custom one with the right interface (16-bit parallel) and the right polarizer orientation (6 o'clock viewing direction). The proposed board would be a derivative of our current FCDEV3B, keeping the core Calypso+RF block (originally from Openmoko) completely unchanged, but adding the LCD, the keypad buttons and other handset peripherals, resulting in a Handset Motherboard Prototype - HSMBP. Once we get TI's TCS211 UI running in its original 176x220 pixel size like it once ran in TI's own software development labs back in The Day, whether we do it by way of TI's original DS board or our own HSMBP, the next step will be to migrate it to the TCS2/TCS3 hybrid config, using the new versions of G23M PS and ACI components. It will also be worthwhile to see if the new version of this BMI+MFW code in the LoCosto version is any better than the one we got from Sotovik. After these preliminary steps, the UI work can bifurcate: * On the one hand, it will be worthwhile to produce a size-reduced version of the UI that targets a 96x64 pixel LCD instead of 176x220 pix, but still full color - thus fitting the LCD on Mot C139/140 phones on which we already run our fw very successfully in the "voice pseudo-modem" config. We would then be able to see if a Mot C139 phone running FreeCalypso fw can be a practically usable end user phone, albeit a super-low-end one. * On the other hand, it is my (Mychaela's) strong desire to have our own FreeCalypso Libre Dumbphone hardware product; running FC fw on Mot C139 just isn't enough to satisfy my ambition. My choice of LCD size for our own FC Libre Dumbphone is 176x220 pix, matching TI's D-Sample, so that the rich UI targeting this large LCD size can see the light of day as a real end user product, and my planned HSMBP board is envisioned as not only an alternative to the D-Sample, but also as the prototype motherboard for our FC Libre Dumbphone. Current state of the firmware ============================= If we desire a libre phone for our pockets and purses (I do desire one for my purse), we will have to bite the bullet and do the necessary work to transform the UI and associated handset code from its current sorry state into something usable, and I have started laying a little bit of the necessary foundation for doing this work in FC Magnetite. There is currently one Magnetite configuration (in the ./configure.sh sense) that includes the UI layers, called 2092. 2092 is TI's bizarre "product" number for the configuration that is just like the one we got from Sotovik (called pdt_2091), but with BMI enabled. We previously had another config called 2092-pwr that had TI's old PWR battery charging driver included, which never worked because of severe bitrot - that config has now been dropped as the regular 2092 config now includes our new and working FCHG battery charging driver. If you request the 2092 configuration for a target other than c139, i.e., for fcdev3b, gtamodem or pirelli, you will get a successful build (to be pedantic, if you pick gtamodem, you'll get a link failure unless you tweak the linker script, but it's a minor nit), but if you then run that fw image on the hardware, it won't do anything good: it will try to display TI's D-Sample UI (176x220 pixels, color) on the D-Sample LCD attached to Calypso chip select nCS3, but of course neither Openmoko's modem nor the Pirelli has a D-Sample LCD on that chip select, thus the LCD output would fall into the aether. (It would be even worse in the case of the Pirelli which has the 2nd flash bank on nCS3, thus the D-Sample LCD writes could clash with the FFS code operating on that flash - so don't do it.) However, because BMI is enabled, the fw will still automatically bring up the GSM radio and register to the default network immediately upon boot like a typical UI-enabled phone does, even though the associated LCD output will be invisible. Needless to say, this configuration is not something I would ever advise actually running - but it is there in anticipation of my idea of running our fw on the original D-Sample board as described above. However, if you build the 2092 config for the c139 target, the Magnetite build system will enable the same hack which was originally implemented in the tcs211-c139 side project in late 2015. Prior to the D-Sample with its fancy 176x220 pix color LCD, TI's previous development platforms (C-Sample and earlier) had 84x48 pix black&white (1 bit per pixel) LCDs, and this old C-Sample LCD support is still there in TCS211, albeit in a bitrotten form that wouldn't even compile without a lot of fixing. In our late-2015 tcs211-c139 side project we had resurrected this C-Sample UI configuration, and this work has now been integrated into Magnetite. When you build Magnetite in the 2092 configuration for the c139, you will get our C139 LCD driver that pretends to be C-Sample to the upper layers, and you will get TI's old 84x48 pix B&W UI displayed on the phone's 96x64 pixel color LCD. IOW, only 84x48 out of the available 96x64 pixels are used, and only 2 out of the available 65536 colors. Yes, pretty pathetic, I know. Going forward, the plan is as outlined above - I wish to see this UI code run in the proper 176x220 pix color display config that once existed in TI's own development environment before I do anything else to it. I am not happy at all about having had to disable TI's D-Sample UI (the 176x220 pix color one) and resurrect the ancient pathetic C-Sample one instead, and given the long list of show-stopping bugs this UI code currently exhibits, I can never be sure which of these bugs were already there in the D-Sample config this code was made for, vs. which of these bugs could be a result of re-enabling the very bitrotten C-Sample UI config - remember, it wouldn't even compile at first. Deblobbing status ================= The current 2092 config is based on the l1reconst modem config (see the Modem-configs write-up), i.e., the entire chipsetsw division of the fw including all of L1 and the init code in main.lib is fully rebuilt from source, but the versions of G23M PS and ACI are the original TCS211 ones, thus the G23M PS component is all blobs. In order to build a G23M-deblobbed UI-enabled config, we would need to build the UI layers (MFW and BMI) on top of the new TCS3.2 version of ACI used in the deblobbed hybrid config, and no such feat has been attempted yet. My current plan is to work in this direction after we either get our fw running on the historical D-Sample board or build our own HSMBP.