Let me preface this post with a reminder of what the primary end goal of our project is: to have fully source-enabled firmware running on a Calypso GSM device that not only performs modem functions, but also includes a classic cellphone UI running on the device itself that would be usable to an end user, as opposed to a developer or hacker. Having the UI run on the Calypso together with the modem fw is the key, as otherwise we could call our work done with leo2moko.
The work between the fall of 2013 and earlier this spring entailed putting together a full source fw that matches the modem functionality of leo2moko, and the work still ahead of us is to make this firmware actually work - right now it runs on the FR's modem, but cannot successfully make a call yet. But all this effort has just been about modem functionality so far - the realm of Calypso-based UI has not yet been touched at all. If we had to reimplement the Calypso-based UI from scratch, i.e., if the functionality in the TI reference source leaks available to us stopped at the ACI, the task would be really daunting. But fortunately the situation is a little better - both of our reference sources (TCS211 for Calypso and TCS3.2 for LoCosto) do include what TI/Condat called "BMI", which stands for "Basic MMI", with MMI being the GSM industry's sexist term for the UI. In other words, the BMI component of TI's reference firmwares is their reference/prototype/demo UI. I knew that this BMI code was there all along, but I have yet to see with my own eyes what this UI looks like - and where does it lie on the axis between a demo-only prototype on one end and a potentially shippable end product on the other end. Well, I got some news: although I still don't have a way to see this UI actually running and working (more on this below), I found this document to be quite encouraging: http://scottn.us/downloads/peek/SW%20doc/TCS%20basic%20MMI%20specification.PDF If we are to believe this document, TI's BMI appears to be fully or almost fully usable as the UI of a shipping phone for end users! Of course it would still be very very useful to bring this UI up and see it working *before* we go through the very substantial work of integrating it into our gcc-built fw. It's the same situation as with the underlying modem fw: after a year and a half we have completed the task of putting it together, but it doesn't work, and we have debug it in order to make it work. The only practical way for us to debug it and make it work is by comparing against the working leo2moko reference running on the same FR modem - without this working reference the task would likely be hopeless. I predict we'll be in exactly the same situation when we reach the point of reintegrating TI's UI code: at first it won't work, and the only way we'll be able to debug it is by comparing against a working reference. (And sorry DS, Compal's or Pirelli's proprietary firmwares do NOT count as a usable working reference for this task, even with symbols and JTAG.) That was when I got a bright idea: what if we can build our known-working TCS211 reference fw in a configuration with the UI included, and get it working in that configuration? The TCS211 semi-src we got was originally built (by TI, presumably) for their pdt_2091 configuration, which is an AT command only config without UI. But the sources for the UI components (BMI, MFW and some others I have yet to understand) are included, hence I wondered for a long time if we could perhaps build a config with UI included. There is of course the problem of the binary libs: they've been built for just one specific config, and we don't have the corresponding source to rebuild them for a different one. But after some careful thought I realized that while certain configuration choices are set in stone with these libs and can't be changed (CSD, fax and GPRS enabled, TTY for the deaf disabled, in-modem TCP/IP, WAP and MMS also disabled), the differences between pdt_2091 (what we got) and pdt_2092 (its nearest sibling with BMI enabled) affect only those components for which we do have the original source - eureka! With this idea in mind, I performed an experiment last night: I took the leo2moko source, copied the binary libs etc under gsm_ac_<blah> to gsm_mf_<blah> (the aci vs. mfw difference for the TCS211 voodoo build system), and invoked that voodoo build system to build pdt_2092. And guess what, I got a successful build resulting in a gsm_<blah>.m0 image that could hypothetically (although not practically, see below) be flashed into a device. This experiment proves that the UI code we have in our copy of TCS211 is complete and buildable - nothing missing, mismatched or bitrotten. The next problem is that I don't have any suitable hardware I could try flashing that image into. The UI code that gets built if one were to take our TCS211 and build it for pdt_2092 targets the 176x220 pix LCD on TI's D-Sample development kit, but even if I somehow got a hold of one those kits (highly unlikely in itself), one *still* would not be able to flash the built image into that target and play with it: D-Sample had Clara RF instead of Rita, and the L1 binary libs are built for the Rita RF used in all commercial products of relevance to us. Bummer. Well, OK, there is a trick. The TCS211 fw image with UI included fits into just under 3.5 MiB (for comparison, the "standard" build w/o UI is just under 2.25 MiB), so we could squeeze it into the available flash on the GTA02 modem (I would need to tweak the linker script a little bit, no big deal), and the available RAM is sufficient too. Of course there is no Calypso-attached LCD or other UI hardware on the GTA02. The D-Sample LCD code writes into registers (write-only, apparently) in the nCS3 range, and on the FR's modem this chip select is unconnected, so the LCD writes will just go into the aether without affecting anything. Hence the code should run, but the LCD output will be invisible. Then I got another idea: what if we hack the LCD output code in TCS211 (which is in full source form) and make it send all LCD output as bitmap blits over RVTMUX? Then write a Unix/Linux host program that would receive these LCD bitmap blits over RVTMUX and display them in an X11 window on the development machine - that trick would turn our GTA02 modem into an equivalent of a complete dumbphone with UI on the Calypso - and we would get to exercise and experience TI's presumably stable and working UI code in its known-working form before we break it in our effort to port it to our gcc environment and to non-TI targets like Pirelli or Compal. Now on to the other thing I wanted to write about: if anyone here feels like investing a lot of time and effort into Compal or Pirelli targets, I very strongly discourage doing so. I believe that those targets can be somewhat useful side branches in our development, but they should *not* be our trunk. At the same time, the GTA02 modem is also a very imperfect choice for our "trunk" target: I currently use it not because it is somehow perfect, but because it's the only available target that satisfies my requirements as the principal developer - Compal and Pirelli both fail the criterion as they both stray too far from TI's reference designs. I believe that we as the FC community need to put a higher priority on building our own FC GSM development board. Make it pretty much the same as the GTA02 modem, i.e., modem hw only, no UI hw yet, but standalone, i.e., on a board by itself without Openmoko's application processor part. (We now have Openmoko's original gerbers for GTA02 up to rev A6, but if we sent them out to fab as-is, we would have to populate all those AP subsystem components in order to have an operable board, and procuring some of those extra components beyond the modem block may be mission impossible.) Throw in the common sense changes of triband->quadband and K5A3281->S71PL129NC0 while at it, and get this puppy actually built! In terms of its quality as a development platform, this dev board I am proposing would be only marginally more convenient than the existing GTA02 modem (more memory, JTAG available, no need to fuss with the AP), but its primary impact would be enabling more potential fw developers to come forth. Right now having to have a Neo Freerunner imposes a rather insurmountable barrier to entry: consider that at the present moment the only member of our community besides myself who has some realistic ability to contribute to fw development/debugging/bring-up does not have an FR, hence it is not currently possible for him to contribute to the project _in a way that is actually useful toward the realisation of our primary goals_. (C1xx and Pirelli hacks are fun, but don't contribute much toward the primary goals.) If we are to believe www.pulster.eu, the total number of *available* Neo FR units in the world currently stands at 3, and at the price point of 500 EUR per unit they are too expensive for me to buy one as a gift for whomever wishes to join our fw development in the earnest. And even if I did have that kind of money to spare, it would be better spent on getting our own hardware built. Getting our FC GSM dev board built will require two stages: 1) Design creation; 2) Physical production. Part 2 will require money, but part 1 (which needs to be done first) does not. Part 1 is pure desk work, all it requires is a qualified engineer to donate his or her time drawing schematics, choosing components for the BOM, drawing footprints for these components and laying out the PCB. I already made several starts at this task earlier, and if no volunteer steps forward to take it over, I will get back to it myself. If calibration weren't an issue, I would be very tempted to set the fw subproject aside right this moment and switch to the board design subproject. But calibration *is* an issue: when we build these boards, we'll need to get them calibrated in order for them to replace Neo FR modems that were calibrated on Om's production line. Calibration involves two parts: external test equipment (TI apparently used R&S CMU200, I looked on ebay and it seems that one can be bought at an affordable price) and code running on the device being calibrated that makes it do certain things like continuous Tx at specified VCXO and APC DAC settings etc. The external test equipment is "just" a matter of going to ebay and spending $$$, but the code running on the Calypso is something I would like to have better control over. When it comes to calibration, at the very least I will need to develop host side tools under rvinterf (probably add some commands to fc-tmsh) for commanding the L1TM code on the target to perform various RF test tasks. I don't know yet what the ETM command packets to be sent need to look like, but we have the L1TM target side code in full source form in the TCS3.2/LoCosto find. Our TCS211 version has this L1TM code in it too (Om would not have been able to run their production line calibration if this L1TM code weren't there), but it's in binary libs. :-( For this reason I would like to get the L1TM code from TCS3.2 integrated into FC gsm-fw and actually working before we start calibrating GSM devices of our own make. If I have to do all the work myself, i.e., if no one volunteers to take over certain parts and if no major financial sponsors come forth (the latter would enable me to hire another engineer to offload some of the work), I plan on proceeding in the following order: 1. Finish what I already started: debug our current non-working FC GSM fw on the gtamodem target by comparison against working leo2moko, and get ours to work as well. 2. Once our FC gsm-fw works on the gtamodem target no worse than leo2moko at the most basic level of functionality (make a call, receive a call, send and receive an SMS), proving that the tpudrv12 etc code is good, then add L1TM from TCS3.2. 3. Buy a CMU200 on ebay and prove to myself that I can recalibrate my Om-made Neo FR using FreeCalypso tools. 4. Switch my focus to designing and building our own FC GSM dev board. Now if we had a second developer available (either as a volunteer or as hired help given a sponsor), some of the above tasks could be done in parallel. I could continue working on part 1 above (getting our FC GSM fw working as well as TCS211 using gtamodem as the target) - I find it very doubtful that anyone else would be able to do this part - while someone else takes over the board design work. The two can be very easily done in parallel without clashes, as calibration won't be needed until after the new board has been physically built and brought up at a basic level - hence I can work on the fw while someone else works on the board design. Any takers? It goes without saying that once we have these GSM dev boards built and calibrated, I will provide them free of charge (or at most for the needed non-sunk production cost with zero profit margin) to anyone who makes a serious commitment to joining FreeCalypso fw development. The other thing I wanted to touch upon is the role to be played by Compal and Pirelli targets in our overall project. As I mentioned earlier, I see them as side branches which may or may not turn out to be necessary. Hypothetically speaking, if our project were to attract some major sponsorship/funding, we could skip these Compal and Pirelli targets altogether and proceed directly to building our own hardware as in not just a dev board, but a complete handset with plastics and all, using all new components besides surplus-sourced Calypso etc chips, so we can produce them in any desired quantity - and make this hw of our own the sole target for our fw. Yes, I know, getting funding of this magnitude is not a very realistic expectation, but a girl can always dream, right? Practically speaking, I think that we can table the question of whether or not we need to support Compal & Pirelli until after we get the following 3 major tasks done, in any order: 1: get our own GSM dev board built - the physical production part will require some money, but I predict that I'll be able to cover it myself without needing sponsors, as by the time we reach that point, my personal financial situation is expected to improve a little bit; 2: get our gcc-built FC GSM fw working no worse than TCS211 on our GSM dev board and/or on the GTA02 modem; 3: get TI's UI (BMI) working on sans-LCD targets by ferrying the bitmap output over RVTMUX to an external display application. If some sponsors come forth during the time it takes us to do the 3 tasks above, great: we could then talk to those sponsors and convince them that going directly to our own handset hw, without wasting energy on the crippled and soon-to-be-gone C1xx surplus, would be the best course of action. But if we get done with the 3 essentials above, no sponsors have come forth, and the core members of our community still yearn for a Free Dumb Phone to carry in our own pockets and purses, *then* we can bite the bullet and do the unpleasant work of porting our pretty fw to the ugly and crippled Compal/Foxconn hardware. So, what do others think? Happy hacking, Mychaela aka Space Falcon _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
