FreeCalypso > hg > fc-magnetite

comparison doc/D-Sample @ 460:4d4f0bba9469

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/D-Sample written
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 19 Mar 2018 18:45:16 +0000
parents
children ed403a239ec6
comparison
equal deleted inserted replaced
459:117bf0fb1e78 460:4d4f0bba9469
1 Back In The Day TI had an official and well-supported platform for Calypso
2 software development; this platform was called D-Sample. It consisted of a
3 development board with the Calypso+Iota chipset on it (as well as a GSM RF
4 section based on their older Clara RF transceiver chip) plus an attached test
5 handset. Here are some pictures:
6
7 https://www.freecalypso.org/members/falcon/pictures/D-Sample/
8
9 I (Mychaela) have managed to obtain one of these historical D-Sample kits (the
10 one pictured) back in 2015. Given that this D-Sample board was the original
11 and most native hw target for the TCS211 firmware program, and given that our
12 FreeCalypso Magnetite firmware project is essentially a resurrection and
13 continuation of that TCS211 fw program, I naturally have a strong desire to
14 have our firmware run on this board in its full glory like it once ran in the
15 offices or cubicles of TI's own software engineers who worked on various parts
16 of TCS211 fw for the Calypso.
17
18 The current state of support is that we have everything other than the GSM radio
19 working. We are currently unable to bring up the radio tract on the D-Sample
20 board with our own Magnetite fw because of Clara RF: we only got a stripped
21 semi-src version of TCS211 in which the *.c files for L1 were censored out and
22 only *.obj blobs were supplied instead; the latter blobs target Rita RF and not
23 Clara. We have now successfully reconstructed the lost C sources for the RF-
24 independent and Rita-specific L1 modules, and we have l1_rf10.c for Clara RF
25 from the MV100 source fragments, but we are still missing the tpudrv10.c module
26 which is also required for Clara RF. Right now if one builds our current
27 Magnetite fw for target dsample, a placeholder stub version of tpudrv10.c is
28 used - it allows the firmware to link, but does not do any actual RF control,
29 thus any attempts to bring up the radio immediately fail.
30
31 Despite having no working radio, everything else works: we can flash our own
32 Magnetite fw images into the board with our fc-loadtool (fc-host-tools-r8 or
33 later; earlier versions did not support the 28F640W30B flash chip correctly),
34 the SIM interface works, the audio subsystem driven by the Calypso DSP driven
35 by our reconstructed TCS211 L1 works (can make beeps through the loudspeaker in
36 the handset part of the kit), the handset keypad works, and when we run a
37 firmware image built with the UI layers enabled, the 176x220 pixel color UI
38 shows up on the big LCD. Because the SIM interface works, one can play with
39 this UI a fair bit despite having no working GSM radio: the UI behaves the same
40 way as any regular phone would in the absence of coverage, so one can step
41 through the menus, read SIM phonebook entries and stored messages.
42
43 Apparent hardware defect in our D-Sample LCD
44 ============================================
45
46 The one specific D-Sample board we have managed to score (might be the last one
47 left in the world, who knows) appears to be an early board: it is PCB rev 3,
48 but it has an early C05 version of the Calypso chip (F741979B), and it was made
49 some time in 2002. It came flashed with a firmware image built on 20020917,
50 and this original image it came with did not light up the LCD at all - it only
51 responded to AT commands. (Examination of that fw image suggests that it has
52 SMI instead of BMI+MFW, but I am not familiar with SMI at all - all I can tell
53 is that it behaves functionally as if it were an ACI build.) Thus the LCD part
54 of this D-Sample hardware only got exercised for the first time when I ran our
55 own Magnetite fw on it, and it exhibits some strange behaviour which I can only
56 attribute to a hardware problem.
57
58 The symptom is that the picture on the LCD sometimes appears garbled, and
59 whether or not this LCD garbling happens (and if it does happen, how severely)
60 appears to depend on the picture content. Furthermore, the dependency is not
61 only on the picture content, but seemingly also on some law of chance, as the
62 same picture can get garbled more or less severely at different times. Closer
63 examination of exactly how the picture is garbled reveals that the misbehaviour
64 appears to be some kind of double latching of write data inside the LCD module.
65
66 The R2D driver maintains a software framebuffer in the r2d_lcd_memory_words[]
67 array, and the r2d_refresh() function transfers the picture in this software
68 FB to the hardware FB inside the LCD module by sequentially writing 176*220
69 16-bit words into a fixed ARM7 memory address in the nCS3 range, causing a
70 write cycle to be issued to the LCD module for each pixel. When a garbled
71 picture appears on the physical LCD, the picture maintained by the software in
72 the r2d_lcd_memory_words[] array is correct (not garbled) as revealed by
73 reading that array memory out via ETM memory read commands (see the tools in
74 the freecalypso-ui-dev repository), and the picture on the physical LCD is
75 garbled in such a way that it appears that at some point when the firmware sent
76 a single pixel to it, the LCD module erroneously registered a double write,
77 incrementing the internal FB RAM pointer by two pixels instead of one, with all
78 subsequent pixels shifted accordingly. The picture can be garbled more or less
79 severely depending on how many pixels in the picture trigger this apparent
80 double write effect.
81
82 The end result is that even though we have a real TI-made D-Sample hardware kit,
83 its usefulness to us for FreeCalypso UI development is rather limited because
84 of both the lack of tpudrv10.c code resulting in no working GSM radio and the
85 apparent hardware problem with the LCD module in the handset part of the kit.
86
87 The Mother's plan is to design and build our own UI development board to take
88 the place of TI's D-Sample, combining the good version of the Calypso+Iota+Rita
89 chipset for which we have good fw support with a 176x220 pix color LCD of our
90 own - it is one of the industry standard sizes, so it should only be a matter
91 of getting a semi-custom one with the right interface (16-bit parallel) and the
92 right polarizer orientation (6 o'clock viewing direction). The proposed board
93 would be a derivative of our current FCDEV3B, keeping the core Calypso+RF block
94 (originally from Openmoko) completely unchanged, but adding the LCD, the keypad
95 buttons and other handset peripherals, resulting in a Handset Motherboard
96 Prototype - HSMBP.
97
98 Different Calypso silicon versions
99 ==================================
100
101 Because the D-Sample was a development board rather than a commercial end user
102 product, different D-Sample boards at different points in time had different
103 versions of the Calypso chip populated on them as the Calypso silicon itself
104 evolved. The board we got appears to be an early one, as it has Calypso chip
105 version F741979B on it (C05 rev B, DSP ROM version 3311), but I can only reason
106 that later D-Sample boards must have had Calypso C035 chips on them, either the
107 original Calypso C035 with DSP ROM version 3416 or the final silicon with DSP
108 ROM version 3606.
109
110 Because we only have one D-Sample board and we have no idea whether or not there
111 are any other DS boards out there in the world (ours may well be the world's
112 last remaining unit), our current build system is set up to target only one
113 D-Sample version, the one we've got: CHIPSET=8, DSP=33 for Calypso C05 rev B
114 silicon. If anyone else in the world has another D-Sample board and it has a
115 different Calypso chip version on it, if you would like to run our FC Magnetite
116 firmware on it, you will need to edit the targets/dsample.conf source file
117 (it's a Bourne shell script fragment sourced by configure.sh) and set the
118 CHIPSET and DSP settings correctly for your Calypso chip version.