Hi DS, > So far I understand the requirements for an acceptable chip would be: > > - full code source, ideally with the revision history (git or otherwise) > - ability to program the fuses with a controlled signing key, or the > possibility of completely disabling the signing check > - full documentation for the chip: hardware registers, OS functions, .. > - lack of unnecessary ARM cores for running a smartphone OS like Android
Yes, you've got it all summed up nicely. The "full documentation for the chip" bullet point also needs to include sufficient documentation for building boards with that chip, i.e., reference board schematics and PCB layout for the RF part. Naturally I am not holding my breath for something meeting all of these criteria to just show up from Qualcomm or MTK, but the fact that we do have such documentation and source code for the ancient 2G-only Calypso while no such sources or docs are available for anything newer gives me the continued justification to keep working on FreeCalypso and continue to promote/market our FC products. Yes, our greatest weakness at the moment is that we can only connect to GSM/2G networks, but for everyone who points this weakness out, I have this prepared canned response: We work with the very elderly Calypso chipset that only supports GSM/2G because all firmware semi-src leaks we have seen so far for newer 3G/4G-capable chipsets are just thin shims of source around a big mass of binary blobs, and are nothing like what we have for TI Calypso. Anyone who wants 3G or 4G, please find or obtain a firmware source for some newer 3G-capable chipset that would be no worse than what we have for TI's chipsets (at minimum we would need the full source for the dual-mode GSM+UMTS protocol stack and L1), and point us to that source. > Of course I may remember wrong, but I assumed OsmocomBB was based on the > classic method of white-room reverse-engineering, precisely to ensure the > produced code was free of bits from the TI leaks, and make the project > immune from possible legal threats. They've always readily admitted that they used the knowledge from the TSM30 source (no actual code reuse, but knowledge learned from studying the proprietary source leak) in order to learn how to talk to the DSP - the most critical part required in order to make the Calypso (or any other commercial GSM chipset) function as a GSM chip, as opposed to just a generic microprocessor taking button presses and putting characters on an LCD. However, the reality is that they used not only the TSM30 source as their source of knowledge for the most critical part of how to talk to the DSP, but also the L1 header files from the TCS211 semi-src - while they readily admit the former, they vehemently denied the latter when that subject came up. Why is it such an important distinction, why did they readily admit having used the TSM30 source leak but deny and cover up their use of knowledge that could have only come from the TCS211 semi-src version? The difference is that the TSM30 leak was published free to world (by a hero who chose to be identified as HispaPhreak) back in 2004, long before Openmoko or OsmocomBB, whereas the TCS211 semi-src targeting the correct chipset version (the one we have on the FCDEV3B and the one that both communities have been hacking on when we casually say "Calypso") only became available to unprivileged people like us in the fall of 2013, and prior to that date it was only available to the privileged inner circle of former Openmoko turned OsmocomBB core developers. Hence during the time between the founding of OsmocomBB (early 2010) and the full liberation of the TCS211 semi-src in the fall of 2013, the core people of OsmocomBB had a vested interest in denying and covering up the fact that they had access to and made absolutely critical use of a piece of leaked source which they were actively refusing to share with less privileged mere mortals like yours truly. The smoking-gun evidence that OsmocomBB people had access to this vital TCS211 semi-src and made critical use of it resides in the dsp_api.h and l1_environment.h header files under src/target/firmware/include/calypso in the osmocom-bb git repository, both dating from the 20100218 initial commit. I invite you to compare OsmocomBB's dsp_api.h against *our* l1_defty.h (based on TCS211), and likewise compare OsmocomBB's l1_environment.h against our l1_const.h, and draw your own conclusions. A few specific points of interest: * Near the beginning of OsmocomBB's dsp_api.h you will find this cutie: #if(L1_DYN_DSP_DWNLD == 1) #include "l1_dyn_dwl_defty.h" #endif Now the dynamic DSP patch download mechanism and its associated L1_DYN_DSP_DWNLD preprocessor symbol and l1_dyn_dwl_*.h header files exist only in TCS211 and LoCosto versions of TI's L1, and not in the TSM30 version - the latter contains no hint of any such thing, as it had not been invented back then. Thus the 3 lines quoted above are a direct proof right there that OsmocomBB must have used the version of 11_defty.h either from TCS211 or from LoCosto as their source, and not from the TSM30 version as the comment just above in dsp_api.h falsely claims. Furthermore, it must have been TCS211 and not LoCosto for the simple reason of chronology. The smoking-gun code in OsmocomBB is present in the initial commit dated 20100218, but the LoCosto leak *did not exist* prior to 20100625 - the chipset.zip release package from FGW that is the point of origin of the LoCosto leak has the latter date right in the ZIP metadata, so we know it could not have existed prior to that date. Thus we are left with the TCS211 semi-src as the only possible version which the core people of OsmocomBB could have used in early 2010 or late 2009. * The Calypso chip versions used in Motorola, Openmoko and Pirelli phones (and the closely related version used on our FCDEV3B) all have DSP ROM version 3606 in the silicon, usually abbreviated to just 36 for the purpose of C preprocessor symbols on the ARM firmware side. The code in OsmocomBB's dsp_api.h corresponding to TI's l1_defty.h has conditional lines like the following: #if (DSP == 33) || (DSP == 34) || (DSP == 35) || (DSP == 36) Once again, the above line could only have come from the TCS211 semi-src: the TSM30 version supports DSP versions only up to 35 (DSP version 36 probably didn't exist at the time when Purple Labs forked from TI), and because the TSM30 source *does not have* the knowledge of how to work with DSP ROM version 3606, it should be obvious right here that OsmocomBB *must* have used another source leak (like the TCS211 semi-src we are using) in order to gain the absolutely critical knowledge of how to talk to the DSP in the Calypso hardware version they are working with. (In the LoCosto L1 source the knowledge of DSP version numbers goes up to 39, but as we have learned experimentally, that L1 version's support for the Calypso is bitrotten to the point of being totally broken, and in any case the LoCosto leak did not exist prior to 20100625.) * The C preprocessor symbol that selects the ABB chip type (1 for Omega/Nausica, 2 for Iota, 3 for Syren) was originally named ANALOG, as seen in the TSM30 source and the MV100 source fragments, but was later renamed to ANLG_FAM - the latter name is used in the TCS211 semi-src and the LoCosto source. OsmocomBB's l1_environment.h proudly defines: #define ANLG_FAM 2 /* Iota */ and then there are conditionals like the following in both l1_environment.h and dsp_api.h: #if ((ANLG_FAM == 1) || (ANLG_FAM == 2) || (ANLG_FAM == 3)) It is so obvious that the origin of this code was the TCS211 semi-src version and not TSM30 like they claim. Also note how they #define CHIPSET to 12 in the same l1_environment.h. The correct CHIPSET number for Calypso C035 is 10, whereas CHIPSET 12 corresponds to the very different Calypso+ chipset. But it just so happens that the small bits of TI code present in OsmocomBB compile exactly the same whether CHIPSET is set to 10 or 12, hence the wrong CHIPSET setting has no practical effect. I reason that this wrong CHIPSET definition can only be a decoy, a futile attempt to disguise their use of critical definitions from the TCS211 semi-src. The only other possibility would be if they found another TI source leak targeting Calypso+, a leak whose existence is completely unknown to the rest of us - but I find the TCS211 semi-src possibility far more plausible, as we know for certain that *this* leak does exist and that the core people of OsmocomBB have had access to it for far longer than we have. But in any case, the myth that OsmocomBB is squeaky-clean unlike FreeCalypso needs to be put to rest - it is no better than a teenage girl's claim to being only just a little bit pregnant, but not really. Both projects have perfectly good reason to continue as they serve very different purposes: if your interest is in hacking/attacking GSM networks, sniffing other people's calls and intercepting SMS intended for others, then OsmocomBB would be a much better-suited tool for your purposes than FreeCalypso, but if instead all you wish to do is to use a phone running fully auditable and improveable source-enabled firmware to call your significant other and tell her how much you love her, using a GSM network as an honest subscriber with a legitimately-paid-for SIM in the process, then FreeCalypso firmware is much better suited for this job. But please knock off the BS with OsmocomBB being some kind of perfectly good and wholesome alternative to our lawbreaking project, for it is not. I also find it laughable that some people seem to seriously think that they can successfully port OsmocomBB to newer non-TI GSM chipsets like MT6260 - MTK's 2G-only GSM chipset. Whoever thinks that they can do such a feat must be so out of touch with reality that it isn't even funny. Whoever is considering that idea must have no clue as to the enormous complexity and intricacy of the interface between the DSP and ARM parts of L1 functionality - if the only way that currently existing OsmocomBB on the Calypso could have figured out how to operate the DSP was by extensively studying a *full source* L1 code (TSM30) for a slightly different but closely related chipset (an earlier Calypso variant with an earlier DSP ROM version), supplemented by header files for the correct chipset and DSP ROM version from the TCS211 semi-src, how do they think they are going to figure this magic out for a completely different chipset from a different vendor for which the relevant part of L1 is nothing but binary objects? All I can say is let them try... M~ _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community