+
−Back In The Day TI had an official and well-supported platform for Calypso
+
−software development; this 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/
+
−
+
−I (Mychaela) have managed to obtain one of these historical D-Sample kits (the
+
−one pictured) back in 2015.  Given that this D-Sample board was the original
+
−and most native hw target for the TCS211 firmware program, and given that our
+
−FreeCalypso Magnetite firmware project is essentially a resurrection and
+
−continuation of that TCS211 fw program, I naturally have a strong desire to
+
−have our firmware run on this board in its full glory like it once ran in the
+
−offices or cubicles of TI's own software engineers who worked on various parts
+
−of TCS211 fw for the Calypso.
+
−
+
−The current state of support is that we have everything other than the GSM radio
+
−working.  We are currently unable to bring up the radio tract on the D-Sample
+
−board with our own Magnetite fw because of Clara RF: 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.  The 20020917 fw image that came flashed
+
−with this board does operate the RF hardware (tested and proven good with our
+
−CMU200 instrument), and we have tried extracting the elusive tpudrv10 bits from
+
−this original 20020917 fw.  Our current tpudrv10.c driver is an attempt to
+
−replicate what the original firmware appears to do, i.e., a translation of the
+
−mystery logic from disassembly to C.  But unfortunately it doesn't work, i.e.,
+
−when we flash our Magnetite fw into the board, we get non-working RF: in the Rx
+
−direction the Calypso DSP fails to receive the signal put out by the CMU200,
+
−and in the Tx direction the CMU200 detects no signal put out by the MS.
+
−
+
−Despite having no working radio, everything else works: we can flash our own
+
−Magnetite fw images into the board with our fc-loadtool (fc-host-tools-r8 or
+
−later; earlier versions did not support the 28F640W30B flash chip correctly),
+
−the SIM interface works, the audio subsystem driven by the Calypso DSP driven
+
−by our reconstructed TCS211 L1 works (can make beeps through the loudspeaker in
+
−the handset part of the kit), the handset keypad works, and when we run a
+
−firmware image built with the UI layers enabled, the 176x220 pixel color UI
+
−shows up on the big LCD.  Because the SIM interface works, one can play with
+
−this UI a fair bit despite having no working GSM radio: the UI behaves the same
+
−way as any regular phone would in the absence of coverage, so one can step
+
−through the menus, read SIM phonebook entries and stored messages.
+
−
+
−Apparent hardware defect in our D-Sample LCD
+
−============================================
+
−
+
−The one specific D-Sample board we have managed to score (might be the last one
+
−left in the world, who knows) appears to be an early board: it is PCB rev 3,
+
−but it has an early C05 version of the Calypso chip (F741979B), and it was made
+
−some time in 2002.  It came flashed with a firmware image built on 20020917,
+
−and this original image it came with did not light up the LCD at all - it only
+
−responded to AT commands.  (Examination of that fw image suggests that it has
+
−SMI instead of BMI+MFW, but I am not familiar with SMI at all - all I can tell
+
−is that it behaves functionally as if it were an ACI build.)  Thus the LCD part
+
−of this D-Sample hardware only got exercised for the first time when I ran our
+
−own Magnetite fw on it, and it exhibits some strange behaviour which I can only
+
−attribute to a hardware problem.
+
−
+
−The symptom is that the picture on the LCD sometimes appears garbled, and
+
−whether or not this LCD garbling happens (and if it does happen, how severely)
+
−appears to depend on the picture content.  Furthermore, the dependency is not
+
−only on the picture content, but seemingly also on some law of chance, as the
+
−same picture can get garbled more or less severely at different times.  Closer
+
−examination of exactly how the picture is garbled reveals that the misbehaviour
+
−appears to be some kind of double latching of write data inside the LCD module.
+
−
+
−The R2D driver maintains a software framebuffer in the r2d_lcd_memory_words[]
+
−array, and the r2d_refresh() function transfers the picture in this software
+
−FB to the hardware FB inside the LCD module by sequentially writing 176*220
+
−16-bit words into a fixed ARM7 memory address in the nCS3 range, causing a
+
−write cycle to be issued to the LCD module for each pixel.  When a garbled
+
−picture appears on the physical LCD, the picture maintained by the software in
+
−the r2d_lcd_memory_words[] array is correct (not garbled) as revealed by
+
−reading that array memory out via ETM memory read commands (see the tools in
+
−the freecalypso-ui-dev repository), and the picture on the physical LCD is
+
−garbled in such a way that it appears that at some point when the firmware sent
+
−a single pixel to it, the LCD module erroneously registered a double write,
+
−incrementing the internal FB RAM pointer by two pixels instead of one, with all
+
−subsequent pixels shifted accordingly.  The picture can be garbled more or less
+
−severely depending on how many pixels in the picture trigger this apparent
+
−double write effect.
+
−
+
−The end result is that even though we have a real TI-made D-Sample hardware kit,
+
−its usefulness to us for FreeCalypso UI development is rather limited because
+
−of both the lack of tpudrv10.c code resulting in no working GSM radio and the
+
−apparent hardware problem with the LCD module in the handset part of the kit.
+
−
+
−The Mother's plan is to 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.
+
−
+
−Different Calypso silicon versions
+
−==================================
+
−
+
−Because the D-Sample was a development board rather than a commercial end user
+
−product, different D-Sample boards at different points in time had different
+
−versions of the Calypso chip populated on them as the Calypso silicon itself
+
−evolved.  The board we got appears to be an early one, as it has Calypso chip
+
−version F741979B on it (C05 rev B, DSP ROM version 3311), but I can only reason
+
−that later D-Sample boards must have had Calypso C035 chips on them, either the
+
−original Calypso C035 with DSP ROM version 3416 or the final silicon with DSP
+
−ROM version 3606.
+
−
+
−Because we only have one D-Sample board and we have no idea whether or not there
+
−are any other DS boards out there in the world (ours may well be the world's
+
−last remaining unit), our dsample build target in FC Magnetite is set up for
+
−Calypso chip version c05b by default, which is the version we got.  If anyone
+
−else in the world has another D-Sample board and it has a different Calypso
+
−chip version on it, if you would like to run our FC Magnetite firmware on it,
+
−you will need to follow the instructions in the Calypso-version-override
+
−article.