Hello again everyone, I've done some more work on the D-Sample board and discovered a really strange issue with its LCD. When running our TCS211-based Magnetite fw on this board with TI's UI enabled, the picture on the LCD looks as expected for the home screen and the various text display screens, but some of the main menu screens (each of the main menu items is a full screen icon in full color) look garbled.
Some of our long-timers may remember that this weekend with the D-Sample board is not the first time I took a peek at TI's 176x220 pix color UI - back in 2015 I hacked the code to emit this LCD output as raster blits on the RVTMUX serial port, and saw a few glimples of this 176x220 pix color UI with the firmware running on a GTA02 modem or on the Pirelli, with the virtual LCD output in an X11 window on my serially-connected x86 host. I wasn't able to go far with that approach because the huge amount of raster blit data was too much for the serial channel even at 812500 baud: 176x220 times 2 bytes per pixel (16-bit color) is 77440 bytes (almost 1 s at 812500 baud at line rate before overhead), and the code is structured in a such a way that the R2D layer (the place where I tapped it) ends up constantly refreshing the entire LCD. Back to the D-Sample LCD problem, I remember what the main menu screens looked like (again, each item in the main menu is a full screen icon), and they did not look garbled like they do on the physical LCD. Furthermore, not all of the icon screens look garbled, only some of them, and different icons get garbled to different degrees: some are only a little garbled, some are worse; the recent calls icon is the worst. Further investigation revealed that when a garbled icon is seen on the physical LCD, the image in the R2D framebuffer is perfectly good, nothing garbled in there. Now consider the implications: the LCD refresh code (you can see it in our FC Magnetite source tree in src/cs/drivers/drv_app/r2d/lcds/D_Sample/r2d_task_i.c) takes the 16-bit color words in this framebuffer (the one which I have verified through ETM memory reads to have the correct content) and writes them sequentially to the physical LCD. The LCD has a 16-bit parallel interface, mapped at a fixed address in the Calypso ARM7 address space, and one sends a picture to it by writing all of the pixels in the range to be written (given as a command ahead of time) sequentially into one fixed address that translates into a write cycle to the LCD controller, in the left-to-right, top-to-bottom order. Thus what we are seeing can only be a hardware problem with the interface from the Calypso to the LCD, or even inside the LCD module itself: what the hardware registers and displays is not what the ARM7 writes to it! The fact that only some icons are effected, some worse than others, and some of the other experiments I did indicate that the hw bug must be triggered by some particular pixel color values, or perhaps some pixel color values being sent before or after some others. Furthermore, I took a closer look at exactly how the picture is garbled, and here is what's happening: as the 176x220 array of pixels is being written sequentially to the LCD, some of the pixels get registered twice by the LCD module, i.e., the internal RAM write pointer inside the LCD controller seems to erroneously get incremented twice instead of once on some pixel writes. All subsequent pixels on the same horizonal line are then shifted one pixel to the right from where they should be, the last pixel on that line goes to the leftmost position of the next line, and so forth, with the whole picture being skewed afterward. On some icon screens only a few pixels trigger this bug, causing it to be only a little garbled, whereas if the picture contains a lot of pixels which trigger the bug, the added effect of all of these one-pixel shifts is a totally garbled picture. Furthermore, the effect is probabilistic: the garbled screens don't look the same every time, i.e., while certain pixel values or perhaps sequences of pixel values in some particular order are prone to trigger the bug, whether or not a given write of a "bad" pixel value causes the erroneous double increment of the internal RAM write pointer is a matter of probability. Sometimes the effect is an unsteady or "shaky" picture on the LCD, as the fw does nothing but keep refreshing the same screen over and over, and different refresh cycles trigger the hw bug differently. I have tried everything I could to fix this display bug by tweaking the LCD driver code: I tried some of the different LCD initialization settings from the E-Sample version, and I even tried changing the LCD interface configuration to the one used on E-Sample and later platforms with dedicated LCD interfaces. In the D-Sample version all 16 lines are wired from the Calypso to the LCD module in the handset part, so that the ARM7 can send each 16-bit pixel in RGB565 with a single strh instruction and a single bus cycle; on E-Sample and later versions only the low 8 lines are connected, and they use the dedicated LCD interface function of the Calypso+ and later chipsets (not present in the plain Calypso) to stream blits to an 8 bit wide LCD with the ARM7 CPU off-loaded. The actual LCD module appears to be the same and there is a configuration byte written that selects the interface; the two known choices are RGB565 color, 16-bit interface, one write cycle per pixel (the original D-Sample config) and RGB888 color, 8-bit interface, 3 write cycles per pixel, used on E-Sample and later. I tried changing the interface config to the E-Sample one and having the refresh code send 3 write cycles per pixel with RGB888 in the low byte on the bus; the behavior improved in that most icons were less garbled, but the recent calls icon (the one that has always been the worst) was still badly garbled. That last result of garbling still happening despite a total change of the interface structure makes me suspect that the problem is more likely to be inside the LCD module itself than in the interface from the Calypso to it. So, what do we do about it? My current tentative plan, subject to change at any moment as my feelings change on a day-to-day basis, is to still make an attempt to recover the tpudrv10 code from reverse eng of the ancient 20020917 fw image and try to make the radio work on this D-Sample board. If we can reconstruct the tpudrv10 code and get working GSM on this board, then I think I may be able to use this D-Sample environment for the critical step of hybrid UI migration and regression testing (see below), despite the LCD being broken in a way that I am not able to fix by software means: only the icon screens are garbled, and it seems that all of the screens with actual info content on them are just text, and TI's color scheme for text screens is too plain and boring to trigger the pixel-value-dependent LCD hw bug. Again, this is only a tentative plan and NOT a promise. Now aside from the hardware platform issues, let's review what is the actual UI software work that we need to do before we can have something for our end user folks to use on their C139 or possibly C11x phones - in other words, if someone were to give me a perfectly working hw platform with a defect-free D-Sample-like LCD that runs TCS211 fw with fully working GSM, what would I do with it? The first critical work step on the software side is that we need to get a UI-enabled fw configuration that builds on top of the new hybrid version of the underlying GSM modem, instead of the old one with blobs for the G23M PS component. Right now the only UI-enabled fw config we have (config name 2092 in Magnetite) uses the version of the UI code which we got with our copy of TCS211, running on top of the old TCS211 (Openmoko) version of ACI, which in turn runs on top of a G23M PS version which we have only as binary object libraries. For AT command modem operation without the UI, we already have a deblobbed hybrid config in which the TCS211 blob version of the G23M PS is replaced with the full source version from TI's TCS3/LoCosto program, with the ACI layer above it also replaced with the newer version from TCS3. This hybrid config works quite well in AT-command-controlled modem operation, but we don't have a firmware version yet that has the UI layers on top of this hybrid config. My first attempt was to build the BMI and MFW layers from TCS211 (the same UI code we are currently using) on top of the new TCS3 version of ACI. The result was immediate breakage, i.e., the old UI code won't compile against the new versions of cdginc and ACI headers. Then I tried importing the new versions of BMI and MFW from the LoCosto source (the same source from which we took our G23M PS and ACI for the hybrid config) and compiling them in the Magnetite environment. Once again I am facing a lot of breakage, as TI's uncaring sw engineers have added a bunch of non-Calypso-compatible LoCosto-isms which I have to find and revert one by one. I am still nowhere close to having it fully pass compilation, but I am slowly progressing one C module at a time, and this approach seems more promising and feels more right than complicating our hybrid even further by going back to the old TCS211 versions of BMI and MFW above the new ACI. What this situation practically means for those who are anxiously waiting for FreeCalypso on Mot C139 with a practically usable UI is that we need to get this hybrid UI configuration to first compile, then work without major regressions from the old TCS211 version before we can start making the changes to support the 96x64 pixel screen size on Mot C1xx. Right now it appears that the versions of BMI and MFW from TCS211 will need to be retired and replaced wholesale with the newer TCS3 versions going forward, and if this is the case, then any work done on the old BMI code will have to be either thrown away or ported (with major difficulty as always) to the new version. Thus I am not willing to spend my unpaid volunteer work time on implementing a UI for the C139 or any other C1xx in the old version of TI's BMI which appears to be slated for wholesale replacement. Thus my current work plan is to continue massaging the new BMI and MFW code from TCS3/LoCosto (now under src/ui3 in Magnetite) with the goal of getting it to pass compilation - this is a necessary work step that also has the benefit of not requiring any hardware. Once I can get it to compile and link, I will try running it on the D-Sample board in its current no-working-radio state, and get it to boot without crashing - then see if it can display the phonebook and stored messages from the SIM like the old version can do without a working radio. Then see where we can take it from there. Das Signal wrote: > Just a though, would it be possible to physically remove the screen > of a C139 (or even C11x) and replace it with a higher resolution screen? > This would enable the development of a better UI, than with the reduced > screen we currently have. I assume that you are not suggesting this idea as an end user mod - I don't think there are any higher pixel resolution LCDs out there that will fit into the same physical size as Motorola's C11x or C139 LCD. As I understand it, LCD physical sizes and pixel resolutions generally increase together - I haven't seen 128x160 pix in less than 1.77" diagonal or 176x220 pix in less than 2" diagonal, for example. And even if there exists a higher pixel resolution LCD of approximately right physical size and a compatible interface, the chances of it being such a perfect fit that it could be a drop-in end user mod are practically nil. OTOH, your idea is interesting indeed from a developer perspective: hack up a higher pixel resolution LCD to a disassembled C139 phone on a lab bench, without any attempt to put it back together as a usable phone. In this case the only higher pixel resolution I would be interested in is 176x220, for the purpose of exercising TI's UI code in its original form prior to small-screen changes. It might be possible to find a 176x220 pix color LCD with a SPI interface, and it might be possible to connect it with little hack-soldered wires to the LCD interface pads on a gutted C139 PCB. The first problem would be that the write-out of a 176x220 times 16 bits per pixel framebuffer would be *really* slow over Calypso's SPI/uWire, but then there is an even bigger problem that kills the idea: the whole purpose of this hack would be exercise TI's UI code in its original unstripped config, and this config needs more RAM than the C139 has. But it was definitely an interesting thought. Hasta la Victoria, Siempre, Mychaela aka The Mother _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community