The GSM firmware source and build tools contained in this directory have been contributed to the International Free Computing Task Force by a Russian mobile phone hacker who chose to be identified as Sotovik. We do not have any authoritative knowledge of where this source ultimately came from or what specific platform it targets, only guesses based on our own examination of the source itself. Examination of the source by FreeCalypso developer Michael Spacefalcon suggests the following: * The target platform appears to be some version of TI's Leonardo reference design - see schematics in the /pub/GSM/Calypso directory of this FTP site. I say so because the #define configuration settings under g23m/__out__/gsm_/config correspond to the Calypso/Iota/Rita chipset, and TI's PDF release notes included with the source say that the pdt_2091 configuration (the one selected by the included build.bat) is for Leonardo. * Setting up the Windows build environment as instructed in doc/Notes.txt and running build.bat (I used a real WinXP machine to run the installers and then Wine under Slackware 13.37 for the actual build) results in what appears to be a successful build, so the source appears to be complete. I say "appears to be" because I have no hardware on which to test the resulting image: that image is built for an 8 MiB flash chip; the selected entry for "_amd8" (FLASH 35) in g23m/system/busyb/unbusy_configset.xml lists it as "AMD AM29DL640GT" and says it's for "Leonardo Rev5". The actual image built in the pdt_2091 configuration is under 3 MiB, but it can only be flashed into an 8 MiB chip because of the way it's laid out. I'm guessing that TI built their development boards with large memories to accommodate all configurations, and it was up to the individual customers to reconfigure things for a smaller flash chip fitting their target feature set. * The specific Leonardo variant targeted by this source appears to be some tri-band one for which we don't have exact matching schematics, but otherwise seems very close to /pub/GSM/Calypso/Leonardo_plus_quadband_schem.pdf. I say so based on the TSPACT bit definitions found in chipsetsw/layer1/tpu_drivers/source0/tpudrv12.h - see lines 240 through 311, inclusive, compare against the just-mentioned schematic drawing, and draw your own conclusions. The comments in that header file refer to a quad-band configuration, the FEM_[789] definitions clearly refer to pins 7, 8 and 9 of the RF FEM (front-end module) shown on the Leonardo+ schematic drawing, but the actual functions of the 3 control signals don't match up: Signal Function on Leo+ schem Function defined in tpudrv12.h TSPACT02 (FEM_7) Tx low band Tx high band TSPACT01 (FEM_8) Tx high band Rx PCS TSPACT04 (FEM_9) Rx GSM-850 Tx low band All common GSM RF front-ends have two Tx switches, one for low bands and one for high bands, whether the design as a whole supports just one or two of each. The common 900/1800/1900 MHz tri-band front-ends also have a switch that steers the high band Rx path between DCS and PCS. OTOH, the quad-band RF FEM depicted on the Leonardo+ schematics has unswitched Rx paths for DCS and PCS, going through different SAW filters to different Rita inputs, but instead has a switch for GSM-850 Rx: it switches the Rx path going to the low band Rita input between 850 and 900 MHz. It is purely my (Michael Spacefalcon's) guess that perhaps there is a tri-band RF FEM with the same footprint and pinout as the quad-band one depicted in Leonardo_plus_quadband_schem.pdf (but with the switch functions correspondingly different for tri-band vs. quad-band), and perhaps some Leonardo+ boards had this tri-band FEM populated instead. (Development boards are just that, their purpose is to be a prototype for customer hardware being built, rather than an end product in themselves, so it wouldn't be surprising at all for these development boards to be populated differently, approximating whatever product is being built by the chipset customer.) It is also important to note that even though we have the tpudrv12.h header file with these critical definitions, we do NOT have the C source for whatever L1 module(s) include(s) this header and make(s) use of these definitions - instead all of L1 is in the form of binary object blobs. As a result of this unfortunate circumstance, it would not be possible to port this code to the Pirelli DP-L10, at least not without somehow replacing that blob with something we can modify: even though the Pirelli phone has the same RF band arrangement, it is wired differently (different TSPACT signals and opposite polarity), so the existing L1 blob will NOT work correctly - and might even fry something! More research needs to be done to see if perhaps there is some existing phone out there whose manufacturer made so few hw design changes relative to the Leonardo that this made-for-Leonardo code might run unchanged, but the more sensible long-term solution would be to get rid of all binary blobs by replacing them either with fitting pieces from other TI source leaks (the LoCosto one seems the best for this purpose, see /pub/GSM/LoCosto) or with pieces of hand- written C code made from disassembly of those blobs for which no corresponding source can be found anywhere. The LoCosto find should give us suitable source for all of L23 and much of L1, but there will be some parts of L1 - like the RFFE control part of current concern - which will have to be done the hard way, by disassembling the object blobs and writing new C code that reimplements the same logic with the same function and variable interfaces.