Hello FC community, While I'm still waiting for San Diego PCB (www.sdpcb.com) to get back to me with a quote or estimate for the job of finishing our FCDEV3B PCB layout, I did a couple of hacks on the software front.
As I pointed out earlier, we have the source for TI's reference/demo cellphone UI code, but we had no way of seeing what this UI actually looks like or even what LCD size (in pixels) it is designed for. I got TI's D-Sample kit that includes the LCD+keypad on which TI developed their UI, but because this D-Sample has the wrong chipset that is not supported by our only available blob-laden copy of TCS211 firmware, it is of no help. Well, I just implemented a hack to shine a little bit of light on this subject of TI's UI code (BMI): I hacked up their physical LCD output code (which originally targeted the LCD on the D-Sample) to emit its raster blits as traces on the RVTMUX debug serial port, got this hacked-up, UI-enabled TCS211 fw to run on the GTA02 modem, and wrote a Unix/Linux host program to display this "virtual LCD" output in an X11 window on the x86 laptop which I use as my development system. This work can be found in the leo2moko-debug and freecalypso-sw repositories on bitbucket, for the target firmware and host LCD window utility, respectively. If anyone here would like to see TI's UI with your own eyes, here is the recipe: 1. Get the latest code from leo2moko-debug repository, compile it in the 2092 configuration (./winebuild.sh 2092), and flash it into your Freerunner's modem. DO NOT try running any of Openmoko's host software when this fw is in the modem, i.e., keep QtMoko etc fully shut down. 2. Connect the headset serial cable, do the magic on the GTA02 AP to connect it to the Calypso, but keep the modem powered off for now. You will need a serial cable that supports the non-standard high baud rate of 812500 baud. 3. With the latest version of rvinterf tools from freecalypso-sw compiled and installed, run a command like this: rvinterf -B812500 -X fc-lcdemu /dev/ttyXXX The argument after the -X option to rvinterf gives the command to be be run via popen(3) to which the LCD output will be fed. That command can have its own arguments, i.e., you can do something like this: rvinterf -B812500 -X 'fc-lcdemu -geom -100+20' /dev/ttyXXX Running the serial port at Calypso's maximum of 812500 baud is absolutely necessary for this hack. This version of TI's UI code which we got with our Calypso fw (the one leo2moko is based on) produces output for a 176x220 pix LCD (huge by Calypso dumbphone standards), with 16 bits per pixel (RGB 5:6:5), so the raster blits being sent over the serial channel (instead of going to an LCD wired directly to the Calypso) are monstrous. Even at 812500 baud the "virtual LCD" updates quite slowly, about 1 s per refresh, much slower than a real LCD on a real phone handset would. 4. Power up the Calypso (echo 1 > power_on). You should see trace output pouring in the rvinterf terminal window, and you should see the LCD output from the firmware in the fc-lcdemu window. If you have a valid SIM inserted, the fw with UI enabled will bring the radio up and connect to the network automatically, without needing to be commanded to do so like the more familiar AT-controlled version does. Not knowing what TI's intended UI color scheme was, I have no reliable way of knowing whether or not the 16-bit RGB values (5:6:5) coming from TI's R2D need to be inverted or not. To enable inversion, add -v to the rvinterf command line (at the rvinterf level, not at the fc-lcdemu level) - try it both ways and judge for yourself which color scheme looks more right. With the above method I was able to see the "idle" home screen with the GSM device auto-connected (no AT commands needed) to Operator 310260 (using this operator's SIM), and by making a call to the number of this SIM, I was also able to see the incoming call screen. The main observation that can be made from this experiment is that the UI code we have really does use the whole 176x220 pix LCD real estate - I was previously unsure if perhaps it might have been written for some smaller subset. (One TI document gave an impression of the UI design using 160 pixels total in the vertical dimension, but didn't say anything about horizontal - so I thought that maybe it was a 128x160 pixel UI design. But nope, the code we have is set up for the full 176x220 pix, the LCD size on the D-Sample and subsequent development kits from TI.) Thus when the time comes for us to build our own Calypso phone hw, the LCD size will be 176x220 pix: the choice is a no-brainer given that we have already working UI code (in full source form!) for such a fancy large screen, complete with pretty graphics and animations. Of course we could rework the UI design for a smaller screen if we really had or wanted to, but where is the fun in that? Given that we already have a UI that works with 176x220, I say better use this big LCD size and give our users more freedom to invent new UI features we never thought of. My experiments with displaying TI's UI from TCS211 GSM fw running on the GTA02 modem stopped at seeing the idle home screen and the incoming call screen. A cellphone UI expects to be driven by the user pressing buttons on the dial keypad, and of course there is no keypad connected to the Calypso on the GTA02. I looked at the code that handles keypad input to see if there can be some simple and obvious way to feed in virtual keypresses from the RVTMUX serial channel, but the code turned out to be quite complex, and I didn't stay on that subproject long enough to find a good place to inject the hack. Rather I tried a different hack: I made TCS211 fw run on the Pirelli. Yes, the blob-laden one! It was a whole series of hacks, but I got it to kinda-sorta-work. You can find it here: https://bitbucket.org/falconian/tcs211-pirelli It doesn't work very well, though: * At first the fw would spontaneously reboot as I was playing with GSM radio bring-up, at seemingly unpredictable times. This behavior stopped when I disabled deep sleep. Throughout this project we need to keep in mind that Pirelli is "alien" hardware, we have no schematics for it, and it contains some very complex extra hw for non-GSM functionality which is connected to the Calypso in non-understood ways. Even though that hw is for non-GSM functions we don't care for, it most certainly can affect the Calypso GSM core which we do care about - in totally non-understood ways. Perhaps something in that extra non-understood hw gets unhappy when the 13 MHz clock output suddently goes away, which is what happens in deep sleep. Obviously Pirelli's own fw has to handle it somehow, but we have no source for it, so it doesn't help. * The fw has a very difficult time connecting to the GSM network: most of the time it fails, and it can take more than 10 min of retries before it somehow finally succeeds. But once it gets connected (if it does at all: on some boot cycles it never succeeded at all), the connection seems to be fine. I was able to make calls and the voice codec worked correctly in both directions. * At first I was disabling deep sleep with at%sleep=2 via fc-shell; I would give this command prior to at+cops. But then I wanted to run the UI-enabled version, which connects to the network immediately upon boot w/o waiting for any AT commands. So I tried changing the default sleep mode setting in cst_pei.c. And now this TCS211-on-Pirelli hack-fw is unable to connect to the network at all: fails with DSP errors early on. Heck, I don't even know if this change in behaviour resulted from the sleep mode change, or if it was somehow coincidental - at that point I got sick of it and didn't feel like going any deeper down that particular rabbit hole. But I did get the UI-enabled version of TCS211 running on the Pirelli, and played with it despite network search failing - it was the same as if I were playing with a regular phone in a Faraday cage with no GSM service - all the UI menus etc still work. The LCD output went to the external host via serial at 812500 baud like before (didn't use Pirelli's LCD: how would you display a 176x220 pix UI on a 128x128 pix physical LCD?), but I did use the real keypad on the phone to drive this UI. I was able to step through the UI menus, browse through the SIM phonebook and read the saved SMS on this SIM - the UI for all of these functions looks OK for the most part, although there is some room for improvement. Going forward, I feel that we need a more methodical and focused plan of development, as opposed to going down every rabbit hole in sight: it's a whole minefield full of rabbit holes, and we won't get to any meaningful end goal by going down every one of them. The way I would like to proceed is as follows: 1. Get our FCDEV3B development board laid out and built, and have this board fully replace the GTA02 for all purposes within our project. Unlike the "alien" Pirelli (or heaven forbid, Compal) phones, this board is expected to run TCS211 exactly like Openmoko's modem of which it is a copy, i.e., solidly reliably. 2. Use that board to whip our full-source, gcc-built FC GSM fw into shape, i.e., make it work as well as TCS211, i.e., as well as how TCS211 currently works on the GTA02, and will hopefully work on the FCDEV3B. Just focus on the AT-command-controlled mode of operation at this stage, don't bring UI code into the picture yet - the experiments I just did should be seen as merely taking a quick peek at what lies ahead. 3. If the full-source, gcc-built FC GSM fw we bring up and whip into shape on the FCDEV3B just happens to work well on Compal or Pirelli targets as well, great - keep supporting those targets in that case, and pursue the possibility of bringing them up with UI, turning them into practically usable libre phones. But if something doesn't work, don't spend too much time and effort chasing after it: there is no point in expending Herculean efforts on undocumented, incompletely-understood "alien" hardware that is either in too short supply (Pirelli) or is too crippled for a high quality end user product (Compal). 4. Once we have 100% full-source, gcc-built firmware that reliably connects to GSM networks, makes and receives calls, sends and receives SMS etc, no worse than TCS211/leo2moko, running on our FCDEV3B board and possibly on other targets as well (the latter not required), even if it's just AT command control and no UI (scenario to consider in case both Compal and Pirelli turn out to be too-deep rabbit holes), we could approach the ultimate goal: building our own Calypso phone handset, with the Calypso core based on GTA02/FCDEV3B and with a 176x220 pix LCD and other peripherals needed in a complete handset. Of course such a step will be a lot of effort, but we'll be able to approach it with confidence once we have our fully liberated fw in a "shining" state. The immediate next step we need in order to move forward with the plan above is getting PADS PCB layout done for FCDEV3B. If we got our FCDEV3B board built, I would be able to use it with JTAG to track down the difference in DSP patch loading between TCS211 (which works correctly) and our current FC GSM fw (which produces the wrong checksum) and fix that bug. I'll be able to do that part on the FCDEV3B even before we get it calibrated, as the DSP patch loading happens right at boot and does not need any radio at all, and the error with the wrong checksum happens right at boot too, without involving any radio bring-up. Well, OK, since I got TCS211 kinda-sorta-working on the Pirelli, we could do this JTAG debugging on the Pirelli as well - the problems we have with TCS211 on Pirelli won't be an issue for this purpose just like lack of calibration won't be on FCDEV3B, for the same reason: the DSP patch download which we need to debug happens right at boot, before any of the other problems begin. However, I have a certain personal bias at play here: I spent a ton of work to create the ready-to-layout FCDEV3B design, and I am not willing to throw this work away. To put it bluntly, I want my FCDEV3B built, I want to see it turn from a tarball of design source files into a physical board on a lab bench. To that end, I am not particularly interested in doing any work such as DSP patch debug on the Pirelli that would diminish the need for FCDEV3B. Toward that end, my current plan, subject to change as my feelings evolve, is to pause further FreeCalypso work until someone steps forward to do the layout of the FCDEV3B board in PADS. Just the layout, i.e., pure desk work, nothing physical - once the layout is done, I'll find a way to get the board physically made. Therefore, anyone who would like to see FreeCalypso development continue to fruition, please help me find a willing PADS-using PCB layout engineer for the FCDEV3B subproject. Hasta la Victoria, Siempre, Mychaela aka Space Falcon _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
