FreeCalypso > hg > fc-magnetite
view doc/D-Sample @ 686:59f07d67eb45
luna target split into luna1 and luna2
luna1 is FC Luna based on iWOW DSK v4.0 or v5.0 motherboard
luna2 is FC Luna based on FC Caramel2 MB
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Mon, 12 Oct 2020 18:51:24 +0000 |
parents | 0d66718e5f33 |
children |
line wrap: on
line source
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.