FreeCalypso hardware update

[Spacefalcon the Outlaw]

Hello FC community,

I got some interesting news: by sheer luck and serendipity I managed
to come across a physical piece of hardware made by TI for Calypso fw
development back in the very distant days when this stuff was current.
(It can't be any newer than 2003 at the latest, at least in terms of
the baseline design date.)  The specific development kit I found (TI
had a bunch of different ones in those days) is called D-Sample; the
one I scored is coming to me from Singapore and may take up to a whole
month to arrive, but I already got the photos of what I'll be getting:

https://www.freecalypso.org/boards/ds-pics/

Unfortunately, there is one factor which will likely diminish the
practical value of this acquisition to little more than a toy: TI's
original D-Sample predated Rita RF (the one in Openmoko, Motorola and
Pirelli phones) and had the earlier Clara RF instead.  Now the
D-Sample I am getting is rev 3 (says so on the board as one can see in
the photos), but I have no idea how it differs from revisions 1 and 2.
There is a slight chance that TI may have changed from Clara to Rita
RF on later D-Sample versions while continuing to call it D-Sample,
and if we are lucky enough to have got a Rita version, we'll be able
to do a lot with it.  But the far more likely possibility is that the
D-Sample I'll be getting has Clara RF, in which case the kit will be
little more than s souvenir.

The problem with Clara RF is that we have no full source for TCS211
(the official fw for the Calypso), only a half-source, half-binary
version built for some customer that used the Calypso/Iota/Rita
chipset.  L1 is 100% binary objects in our TCS211, and it's built for
Rita RF.  As far as Clara RF goes, we have neither a source for its
respective driver nor even a binary to reverse-eng from, hence no
place to start. :(  (In the case of our own gcc-built gsm-fw, most of
L1 source came from LoCosto, but that one has no code for either Clara
or Rita RF.  In the case of Rita RF I was able to reconstruct the code
from disassembly of our available TCS211 object blob, but we have no
such option for Clara RF.)

If we are lucky, the D-Sample board will come with some fw image in
its flash - maybe even one that puts some UI on that fancy 176x220 pix
LCD.  But it'll be just a binary image with no symbols, no COFF
objects, no linker map, no str2ind.tab, hence we won't be able to do
much with it beyond staring at whatever picture it puts on the LCD, if
any.  There is also a chance that the board might come with some
interesting content in its FFS (flash file system) - it would be
awesome if we could find some ringtones in TI's Melody E1/E2 format.
But beyond the possibility of harvesting some ringtone or UI artwork
files from the FFS, we won't be able to do much of anything with this
D-Sample if it has Clara RF like I suspect. :(

Which is a total shame, as the hardware kit is pure awesomeness:
notice how it is not just a bare board, but also includes the attached
handset part.  The latter features a 176x220 pix LCD (huge for a
Calypso dumbphone or a devkit for building such dumbphones), a keypad
with the same 21-button layout as on Mot C1xx and Pirelli DP-L10,
microphone and speaker, and possibly even the vibrator.  In other
words, it's the *perfect* hardware for firmware development and
debugging, were it not for the slightly wrong chipset version and the
lack of full source code on our part.

TI's next full development kit after D-Sample was E-Sample.  As far as
I can tell, the attached handset part is the same between the two, and
as I already mentioned on this list previously, we have the PCB layout
file for a version of the E-Sample board:

ftp://ftp.freecalypso.org/pub/GSM/PCB/Esam-406.zip

We could easily build a physical E-Sample board from this PADS PCB
file and connect it to the handset from the D-Sample, reconstructing a
full E-Sample kit.  But once again, it won't do us any good: E-Sample
is Calypso+, a chip for which we have absolutely no documentation and
no firmware of any kind, neither source nor binary - hence it would be
a paperweight. :(

So it looks like we still need to design and build our own FreeCalypso
GSM development board with the Calypso/Iota/Rita chipset for which we
have a working fw reference in the form of TCS211 firmware semi-src.
I considered building this board in the form factor of TI's D and E
boards, so it could be connected to TI's D/E handset part, but I think
it would be rather pointless - the D-Sample kit I was able to find and
the handset it comes with appears to be the only one left in existence
in the whole world, whereas I would like to make our own FreeCalypso
GSM dev board usable to more than just me.

So it looks like we need to go back to our original plan of building
our FC GSM dev board as just a "bare" Calypso board without any LCD,
keypad or connections for such, and do UI development via PC emulation:
hack the firmware (our TCS211 has this part in real source form) to
send bitmap blits intended for the LCD over to the external host
instead (over RVTMUX serial channel), take key presses from the same,
and put up an X11 window on the development PC with the virtual LCD
and keypad.  Not as cool as TI's D/E-sample kits with a real physical
handset, but with a lower barrier to entry in return, as we should be
able to make our simplified dev boards available to anyone who would
like one.

The FC GSM dev board I have in mind will take battery-emulating power
input via the same type of connector as you can see in the D-Sample
kit photos, and it will have the same type of SMA coax connector for
connecting the antenna or the RF test & calibration station.  It will
have a SIM socket and power-on and reset buttons just like you can see
on the D-Sample board, but I won't bother with replicating RS-232: the
UARTs will be brought out as native 2.8V (3.3V-compatible) interfaces
on a simple header.  The intent is to connect them to a "bare" 3.3V
(no RS-232 levels) USB-serial dongle with a simple ribbon cable.  And
of course there will be a header for connecting OpenOCD JTAG just like
on TI's boards.

My progress toward this board design is that I am working on a PADS
library with the footprints ("PCB part decals" in PADS terminology)
and "part types" (a PADS-ism) for the new components which need to be
added to the modem section of GTA02 in order to turn it into our desired
FCDEV3B.  I am making what PADS calls an ECO file - it is an ASCII
text file in a PADS-defined language that acts as a sort of script for
changing the netlist of a board: when one loads this ECO script into
PADS with Openmoko's GTA02 layout loaded without any manual edits, it
will delete all parts which we don't want (Om's application processor
subsystem), keep all parts which we wish to keep (the GSM modem
section) with all their routing intact, add the new parts we need to
add (unplaced and unrouted initially), and set up the new netlist
connections we need (again, unrouted initially, i.e., rat's nest in
PCB layout jargon).

Once I have this ECO file, I will then need to hand this FCDEV3B job
off to a PADS-using (PADS-experienced) PCB layout professional to
finish the layout as in placing and routing the new components,
changing the board outline and removing other remnants of GTA02 PCB
layout which the ECO mechanism does not handle automatically.  But
before I can have the ECO file ready for hand-off, I need to draw the
footprints for the new parts myself, as least in an initial rough
draft version: when PADS processes an "add part" directive in an ECO
file, it requires the new part type to be present in the library.  If
the new part type is not found, the "add part" ECO directive is
rejected, and so are all subsequent netlist connections to that new
part.  Therefore, I have to produce a PADS library with part types and
part decals (PADS terms) for all newly added components (connectors
etc) in order for my ECO netlist to be accepted.  This part library
creation is what I'm working on now.

Happy hacking,
SF