Newer MTK chipsets

[Mychaela Falconia]

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~