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 _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
