# HG changeset patch # User Mychaela Falconia # Date 1521485116 0 # Node ID 4d4f0bba94695b74cbed7ba59bed5082db451190 # Parent 117bf0fb1e78bab945707c1f79c529ab54a91fac doc/D-Sample written diff -r 117bf0fb1e78 -r 4d4f0bba9469 doc/D-Sample --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/D-Sample Mon Mar 19 18:45:16 2018 +0000 @@ -0,0 +1,118 @@ +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. Right now if one builds our current +Magnetite fw for target dsample, a placeholder stub version of tpudrv10.c is +used - it allows the firmware to link, but does not do any actual RF control, +thus any attempts to bring up the radio immediately fail. + +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.