FreeCalypso > hg > fc-magnetite
comparison README @ 218:75ea63a3fce5
README updated for the current status of the project
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Sat, 15 Oct 2016 19:30:58 +0000 |
| parents | 9fb9f896bd77 |
| children | b05dba024f95 |
comparison
equal
deleted
inserted
replaced
| 217:2f17574d7001 | 218:75ea63a3fce5 |
|---|---|
| 22 | 22 |
| 23 The present FC Magnetite firmware is built on the principle of starting with | 23 The present FC Magnetite firmware is built on the principle of starting with |
| 24 the known working TCS211 code base, without any major restructuring, and making | 24 the known working TCS211 code base, without any major restructuring, and making |
| 25 small incremental evolutionary changes, testing at every step to ensure that | 25 small incremental evolutionary changes, testing at every step to ensure that |
| 26 nothing breaks. It is the direct opposite of the "rebuild from the ground up" | 26 nothing breaks. It is the direct opposite of the "rebuild from the ground up" |
| 27 approach taken with our previous Citrine firmware (aka "gsm-fw"), the approach | 27 approach taken with our previous Citrine firmware aka "gsm-fw". |
| 28 that produced very disappointing results. | |
| 29 | 28 |
| 30 Functionality | 29 Functionality |
| 31 ============= | 30 ============= |
| 32 | 31 |
| 33 TI's GSM mobile station firmware architecture supports two ways in which the | 32 TI's GSM mobile station firmware architecture supports two ways in which the |
| 34 GSM device may be controlled: via AT commands from an external host and/or via | 33 GSM device may be controlled: via AT commands from an external host and/or via |
| 35 a local UI on devices with LCD & keypad hardware. (I said "and/or" because the | 34 a local UI on devices with LCD & keypad hardware. (I said "and/or" because the |
| 36 two mechanisms can coexist.) At the present time, however, only the AT command | 35 two mechanisms can coexist.) The code we got from TI (TCS211) is very solid |
| 37 mode of operation is supported in FreeCalypso Magnetite. The effect of this | 36 and mature in the modem configuration (control via AT commands only, no UI, no |
| 38 limitation is that if you run this fw on a Motorola C139 or a Pirelli DP-L10, | 37 battery management, no traditional handset on/off control), but the additional |
| 39 the phone's LCD will stay dark, the buttons won't do anything, and the | 38 code layers that are needed for handset products but not for modems are in a |
| 40 phone-turned-modem can only be operated via AT commands sent via FreeCalypso | 39 very rough "proof of concept" condition, nowhere close to a usable product. |
| 41 host utility fc-shell. | |
| 42 | 40 |
| 43 The demo/prototype phone UI code in TI's reference fw delivery is written for | 41 The same situation currently exists in FreeCalypso Magnetite. As explained |
| 44 a 176x220 pixel 16-bit color LCD (such an LCD was used on TI's official | 42 below in the Build system section, a key feature of FC Magnetite is that many |
| 45 development platform called D-Sample), whereas our available Mot C139 and | 43 different firmware configurations can be built from the same source tree. One |
| 46 Pirelli targets have significantly smaller LCDs: 96x64 and 128x128 pixels, | 44 of the configuration choices is that you can build the fw either with or without |
| 47 respectively. Prior to the D-Sample, TI had used 84x48 pixel black&white | 45 the phone UI layers. The work we have done earlier in the tcs211-c139 side |
| 48 (1 bit per pixel) LCDs, and this old C-Sample LCD code is still there, albeit | 46 project (late 2015) has been integrated into Magnetite, properly conditionalized |
| 49 bitrotten. In late 2015 this author made a very dirty hack to resurrect TI's | 47 so that TI's original configuration is fully preserved when the target != c139. |
| 50 old C-Sample UI code and get it to display on the C139 phone LCD (84x48 is a | 48 However, if you build the UI-enabled configuration for any target other than |
| 51 proper subset of 96x64) - you can find this hack in the tcs211-c139 Hg tree. | 49 Mot C139, it will compile, but it won't do anything useful: it will try to |
| 50 display TI's 176x220 pixel color UI on the D-Sample LCD on Calypso chip select | |
| 51 nCS3, but this hardware doesn't exist on any of our supported targets. (The | |
| 52 Pirelli in particular has flash on that chip select instead, so it may interfere | |
| 53 with FFS operation.) | |
| 52 | 54 |
| 53 The upshot of this LCD situation is that porting TI's phone UI code to run on | 55 Further work on the handset firmware configuration (UI, battery management and |
| 54 Mot C139 or Pirelli DP-L10 will require major rework of the affected parts of | 56 other currently missing functionality required for a usable phone) will have to |
| 55 the firmware. While I would like to do it eventually, I am not willing to do | 57 wait until we build our own Handset Motherboard Prototype (HSMBP) with a 176x220 |
| 56 it right now - I would like to get this code running in its pristine state on | 58 pixel 16-bit color LCD, replicating TI's D-Sample - I personally am not too |
| 57 its native 176x220 pix LCD *before* I hack the holy **** out of it for the | 59 interested in doing this handset fw work on the very crippled Mot C139 or on |
| 58 C139/Pirelli port. I do have a real TI-made D-Sample kit with the right LCD, | 60 the Pirelli with its own host of issues, although others in the community are |
| 59 but unfortunately the main board has an older version of the core chipset for | 61 more than welcome to take a shot at it if someone is interested. |
| 60 which we lack the necessary fw support, hence it doesn't help. Therefore, we | |
| 61 will need to build our own Calypso board with a 176x220 pix 16-bit color LCD, | |
| 62 get the UI-enabled GSM firmware running on that board, and only then proceed | |
| 63 with C139 and/or Pirelli ports if such are still desired. | |
| 64 | 62 |
| 65 For now, modem or pseudo-modem operation with control via AT commands is all | 63 Until then, the primary current focus of the FC Magnetite project is the |
| 66 we have. | 64 AT-command-controlled modem configuration. Both TI's original modem fw (TCS211) |
| 65 and our recreation thereof in this Magnetite project support not only voice | |
| 66 calls and SMS, but also CSD, fax and GPRS. However, before we can really | |
| 67 exercise this functionality, we need to first build our long-overdue FCDEV3B | |
| 68 hardware. TI's standard fw architecture (kept unchanged in FC Magnetite) | |
| 69 assumes the availability of two UARTs: the modem UART presents a classic AT | |
| 70 command interface which includes the CSD, fax and GPRS functionality, whereas | |
| 71 the 2nd IrDA UART carries the debug trace channel (RVTMUX) essential for | |
| 72 developers. However, only one UART is practically accessible on Mot C139 and | |
| 73 Pirelli DP-L10 targets; because we could not give up RVTMUX, we gave up the | |
| 74 classic AT command UART channel instead. We have implemented a mechanism for | |
| 75 passing AT commands over RVTMUX, but this mechanism works only for the voice | |
| 76 and SMS AT commands, not CSD, fax or GPRS. Therefore, the latter functionality | |
| 77 remains inaccessible until we build our own proper Calypso board with both | |
| 78 UARTs brought out. | |
| 67 | 79 |
| 68 Build system | 80 Build system |
| 69 ============ | 81 ============ |
| 70 | 82 |
| 71 Even though FC Magnetite is essentially unchanged TCS211 code base and builds | 83 Even though FC Magnetite is essentially unchanged TCS211 code base and builds |
| 119 we do have what *seems* to be a suitable replacement source (or feasible ability | 131 we do have what *seems* to be a suitable replacement source (or feasible ability |
| 120 to reconstruct such) for every piece of TCS211 fw that came in binary-only form, | 132 to reconstruct such) for every piece of TCS211 fw that came in binary-only form, |
| 121 actually making this replacement without breaking functionality is a very | 133 actually making this replacement without breaking functionality is a very |
| 122 non-trivial endeavor. Our previous attempt to rebuild the firmware from the | 134 non-trivial endeavor. Our previous attempt to rebuild the firmware from the |
| 123 ground up, using source pieces lifted from different available leaks and | 135 ground up, using source pieces lifted from different available leaks and |
| 124 building with gcc so that no TMS470 COFF blobs could be used, produced very | 136 building with gcc so that no TMS470 COFF blobs could be used - see FreeCalypso |
| 125 disappointing results. | 137 Citrine - has produced only a very limited subset of the original functionality, |
| 138 and until very recently even the most basic function of voice calls did not work | |
| 139 reliably. | |
| 126 | 140 |
| 127 Instead the new FreeCalypso firmware approach implemented in FC Magnetite is to | 141 Instead the new FreeCalypso firmware approach implemented in FC Magnetite is to |
| 128 approach the blob-free goal incrementally. The new Magnetite build system is | 142 approach the blob-free goal incrementally. The new Magnetite build system is |
| 129 specifically designed to enable the transition from the use of blobs to | 143 specifically designed to enable the transition from the use of blobs to |
| 130 recompilation from source to be made with very fine granularity, down to the | 144 recompilation from source to be made with very fine granularity, down to the |
| 134 each individual case, and we make a test build of the firmware using the | 148 each individual case, and we make a test build of the firmware using the |
| 135 reconstructed or fitted component instead of the original blob. If the firmware | 149 reconstructed or fitted component instead of the original blob. If the firmware |
| 136 still works (doesn't break), we make this deblobbing transition permanent and | 150 still works (doesn't break), we make this deblobbing transition permanent and |
| 137 move on to the next component. | 151 move on to the next component. |
| 138 | 152 |
| 139 As of this writing, most of Layer 1 and a few housekeeping parts of the fw have | 153 See doc/Deblobbing for the current status of the deblobbing effort and for the |
| 140 already been deblobbed, i.e., are now recompiled from source. The G23M protocol | 154 description of the currently available configurations. |
| 141 stack is our next deblobbing target - we have a newer version of it in full | |
| 142 source form, and we are hoping to be able to retrofit this newer G23M version | |
| 143 into the TCS211 environment in order to replace the binary blob version we are | |
| 144 using currently. | |
| 145 | 155 |
| 146 Further reading | 156 Further reading |
| 147 =============== | 157 =============== |
| 148 | 158 |
| 149 For various instructions and notes specific to this FreeCalypso Magnetite | 159 For various instructions and notes specific to this FreeCalypso Magnetite |
