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 current build system is set up to target only one
D-Sample version, the one we've got: CHIPSET=8, DSP=33 for Calypso C05 rev B
silicon.  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 edit the targets/dsample.conf source file
(it's a Bourne shell script fragment sourced by configure.sh) and set the
CHIPSET and DSP settings correctly for your Calypso chip version.