FreeCalypso > hg > freecalypso-ui-dev
annotate README @ 7:d584d7b50f10
README: simplified way of setting TR_BAUD_CONFIG to TR_BAUD_812500
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Fri, 16 Mar 2018 04:13:40 +0000 |
| parents | 0775b86c4a28 |
| children | 0efa0f4081a0 |
| rev | line source |
|---|---|
| 6 | 1 This repository contains a couple of hack-utilities that have been developed as |
| 2 attempts at displaying TI's 176x220 pixel demo/prototype phone UI on an external | |
| 3 development host in the absence of a suitable Calypso target device with an LCD | |
| 4 of the needed large size. Two approaches have been tried, separated in time by | |
| 5 about 2.5 y: | |
| 6 | |
| 7 2015-09 approach | |
| 8 ================ | |
| 9 | |
| 10 A year before FreeCalypso Magnetite, when all we had was the TCS211 semi-src | |
| 11 from Sotovik with its original all-Windows build system, with all of the blobs | |
| 12 intact and no apparent hope of deblobbing, plus our first attempt at bottom-up | |
| 13 GSM fw with completely broken L1, we had built two hacked-up versions of TI's | |
| 14 TCS211 fw with TI's 176x220 pixel UI enabled: one running on the GTA02 modem, | |
| 15 the other running on the Pirelli DP-L10. Both were hacked up to emit raster | |
| 16 blits of the big 176x220 pix, 16 bits per pixel color UI on the RVTMUX serial | |
| 17 channel, running at Calypso's maximum baud rate of 812500 bps. These hacks | |
| 18 have not been touched since 2015-09, but they can still be found in the | |
| 19 historical leo2moko-debug and tcs211-pirelli Hg repositories on Bitbucket. | |
| 20 | |
| 21 A host utility named fc-lcdemu had been written to display these LCD blits | |
| 22 emitted by those hacked-up firmwares. It receives these blits via a pipe from | |
| 23 rvinterf and displays them in an X11 window; it thus naturally requires libX11 | |
| 24 to compile and an X11 display to run. X11 programming is a black art which | |
| 25 this author (Mychaela Falconia) once knew but now largely forgot, hence | |
| 26 fc-lcdemu was based on the HECterm project (an xterm-like terminal application | |
| 27 for X11) by the same author, but from a much earlier life phase. | |
| 28 | |
| 29 If you wish to resurrect and play with one of these external LCD output hacks | |
| 30 from 2015-09, you will need to invoke rvinterf with special arguments to tell | |
| 31 it to launch fc-lcdemu and to pass the LCD blits to it; the synopsis is as | |
| 32 follows: | |
| 33 | |
| 34 rvinterf -B812500 -X fc-lcdemu /dev/ttyXXX | |
| 35 | |
| 36 The -B812500 argument is needed to tell rvinterf to use this high baud rate, | |
| 37 and the -X option tells rvinterf to invoke the following named program (can be | |
| 38 a more complex shell command) with popen(3) and then feed it LCD blits received | |
| 39 from the target. If you use the new version of rvinterf that is about to be | |
| 40 released with fc-host-tools-r8, the old -v option is no longer needed and no | |
| 41 longer accepted. | |
| 42 | |
| 43 This 2015-09 approach was putting a huge load on the RiViera Trace mechanism, | |
| 44 hacks were required in the firmware to massively super-size the memory space | |
| 45 allotted to RVT and to run the RVTMUX serial channel at 812500 baud, and even | |
| 46 with the supersized memory allocation and the maximum serial baud rate there | |
| 47 were still some 'Lost Message' traces. The hacks on the firmware side which | |
| 48 implement this 2015-09 approach have NOT been included in our current Magnetite | |
| 49 firmware. | |
| 50 | |
| 51 2018-03 approach | |
| 52 ================ | |
| 53 | |
| 54 Rivisiting the phone UI subproject of FreeCalypso in 2018, I got another idea | |
| 55 for how to get the LCD framebuffer bits out of a Calypso device: instead of | |
| 56 having the firmware push them out to the trace buffer every time r2d_refresh() | |
| 57 is called, have the fw do nothing, and have the external host read the | |
| 58 framebuffer memory out at its own pace via ETM memory read commands. The new | |
| 59 fc-lcdpoll utility implements this approach; in order to avoid having to reopen | |
| 60 the X11 can of worms, I made fc-lcdpoll output the blits in the form which the | |
| 61 already-existing fc-lcdemu code from 2015 takes as input, so you run a pipeline | |
| 62 like this: | |
| 63 | |
| 64 fc-lcdpoll framebuffer_base_addr | fc-lcdemu | |
| 65 | |
| 66 fc-lcdpoll connects to rvinterf as a regular client, thus you would typically | |
| 67 have rvinterf running already when you run the above pipeline in another window. | |
| 68 fc-lcdpoll needs to know the address of the in-RAM framebuffer maintained by | |
| 69 the R2D firmware component, and this address needs to be given on the command | |
| 70 line. You can find it by grepping the linker-generated map file (fwimage.map | |
| 71 or ramimage.map as appropriate) for the _r2d_lcd_memory_words symbol. | |
| 72 | |
| 73 This new approach works with current FC Magnetite firmware, and has been tested | |
| 74 in a few different ways: | |
| 75 | |
| 76 * We have a real TI-made D-Sample board and we can run our Magnetite firmware | |
| 77 on it, but lacking the tpudrv10 driver code for Clara RF, we are running with | |
| 78 a non-functional placeholder stub for the TPU driver. The D-Sample board thus | |
| 79 has no GSM radio functionality when running our fw, and the firmware can only | |
| 80 do what any regular phone would do in an area with zero coverage: limited to | |
| 81 stepping through menus and examining SIM phonebook entries and stored | |
| 82 messages. The physical LCD output works, but is often garbled due to what | |
| 83 appears to be a hardware problem. Running fc-lcdpoll|fc-lcdemu against this | |
| 84 setup results in the virtual LCD mirroring the physical one, albeit with some | |
| 85 lag, and the virtual LCD shows what the physical one *should* display if it | |
| 86 weren't garbled. | |
| 87 | |
| 88 * One can run a UI-enabled Magnetite build on our FCDEV3B modem board and use | |
| 89 the fc-lcdpoll|fc-lcdemu pipe to display what the fw puts in the framebuffer. | |
| 90 Unlike the D-Sample, our FCDEV3B has perfectly working GSM radio, thus this | |
| 91 setup allows us to see the behaviour of the UI firmware with a working radio | |
| 92 and thus a working GSM network connection underneath. By calling the number | |
| 93 of the SIM inserted into this setup, one can see the incoming call screen | |
| 94 followed by the missed call indication. Because there is no physical keypad | |
| 95 on the FCDEV3B, it appears at first that the show stops here with no way to | |
| 96 feed keypresses to the firmware, but TI's firmware does have a mechanism for | |
| 97 sending simulated keystrokes via RVTMUX encoded in GPF system primitives, and | |
| 98 we have recently figured out how to use it. Our fc-shell utility now offers | |
| 99 the new key command for sending such simulated keypresses to the target, and | |
| 100 by combining this key entry mechanism with the present fc-lcdpoll|fc-lcdemu | |
| 101 display viewing mechanism, we've been able to exercise the UI a little | |
| 102 further. This approach definitely shows some promise. | |
| 103 | |
| 104 * The Pirelli DP-L10 target has also been tried. I was hoping that it would | |
| 105 make a good platform by virtue of having a working GSM radio (unlike the | |
| 106 D-Sample sans tpudrv10 code) and a physical keypad that is just like the | |
| 107 one on the D-Sample, but no joy. When running FreeCalypso on Pirelli's alien | |
| 108 hardware, among many other issues that kill any possibility of turning this | |
| 109 alien hw into a libre phone, we get this one highly bizarre misbehaviour for | |
| 110 which we have absolutely no explanation: the radio works OK *only if* the | |
| 111 firmware is built with deep sleep enabled in CST (i.e., enabled by default on | |
| 112 boot), and the Calypso gets to do some deep sleeps prior to the operator | |
| 113 manually bringing it up with AT commands. If deep sleep is disabled, as soon | |
| 114 as you try to bring the radio up, the Calypso DSP falls over with errors | |
| 115 which we naturally have no way of debugging. The most recent experiment has | |
| 116 revealed that this same DSP death behaviour (resulting in no working GSM | |
| 117 radio) occurs even when deep sleep is enabled if the firmware is built in the | |
| 118 MFW configuration (UI layers included) - as the UI layers command the radio | |
| 119 bring-up immediately on boot, the DSP falls over. Thus we are rudely reminded | |
| 120 once more than the Pirelli target is a dead end. | |
| 121 | |
| 122 Baud rate considerations | |
| 123 ======================== | |
| 124 | |
| 125 The ETM memory read approach implemented in fc-lcdpoll is a lock-step, one read | |
| 126 transaction at a time mechanism, not a continuous unstoppable stream of data | |
| 127 like the original 2015-09 approach - therefore, it does not impose any load on | |
| 128 the firmware's trace buffers, and it can work with RVTMUX running at any baud | |
| 129 rate, even plain 115200. However, the slower the RVTMUX serial channel runs, | |
| 130 the slower will the virtual LCD update, hence running the serial line at 812500 | |
| 131 baud is still preferable. To change the RVTMUX serial baud rate from 115200 bps | |
|
7
d584d7b50f10
README: simplified way of setting TR_BAUD_CONFIG to TR_BAUD_812500
Mychaela Falconia <falcon@freecalypso.org>
parents:
6
diff
changeset
|
132 to 812500 bps in your Magnetite firmware build, simply add a |
|
d584d7b50f10
README: simplified way of setting TR_BAUD_CONFIG to TR_BAUD_812500
Mychaela Falconia <falcon@freecalypso.org>
parents:
6
diff
changeset
|
133 TR_BAUD_CONFIG=TR_BAUD_812500 argument to your ./configure.sh line, |
|
d584d7b50f10
README: simplified way of setting TR_BAUD_CONFIG to TR_BAUD_812500
Mychaela Falconia <falcon@freecalypso.org>
parents:
6
diff
changeset
|
134 and remember to pass the -B812500 option to rvinterf when talking to such |
|
d584d7b50f10
README: simplified way of setting TR_BAUD_CONFIG to TR_BAUD_812500
Mychaela Falconia <falcon@freecalypso.org>
parents:
6
diff
changeset
|
135 trace-speed-increased firmware. |