FreeCalypso > hg > freecalypso-ui-dev

comparison README @ 6:0775b86c4a28

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
README added
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 16 Mar 2018 03:50:38 +0000
parents
children d584d7b50f10
comparison
equal deleted inserted replaced
5:45c81216d964 6:0775b86c4a28
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
132 to 812500 bps in your Magnetite firmware build, follow these steps:
133
134 * Run ./configure.sh like you normally would, selecting the UI-enabled config
135 of interest for your target.
136
137 * Go into the build directory, and before running 'make', edit
138 config/swconfig.cfg - it is one of the config headers generated by the
139 configure.sh process. In that configuration header file, change the
140 TR_BAUD_CONFIG setting from TR_BAUD_115200 to TR_BAUD_812500.
141
142 * Run 'make' or 'make ram' as desired after editing the swconfig.cfg header.
143
144 And of course remember to pass the -B812500 option to rvinterf when talking to
145 such trace-speed-increased firmware.