Newer MTK chipsets

[Serg l]

This is a sin of any Open Source work that you have to rely on your own
work or similar open source, properly licensed products which allow reuse
of their code base. In the closed source world it is a war zone, things get
literally stolen using industrial espionage methods, nobody has any respect
of any IP rights as long as it is not obvious that the product contains
someone's else code. Developers are instructed not to raise any concerns
regarding legal issues as they keep armies of lawyers to cover up all the
illegal activities professionally.
I do have a lot of respect to engineers and companies investing a lot of
time and money into their work, but you are right, it is not possible to be
a little bit pregnant.

Looking forward the only option to get this up from the ground is actually
try to guess where the industry is moving to and stay ahead of the curve.
For example VoLTE only solution. For example the base station part is
actually available https://myriadrf.org/blog/open-source-lte/ why don't we
try to come up with a power inefficient, features impaired, but open and
free client side of this equation? Commercial operators are actually
deploying more VoLTE and shrinking their switched voice channels
capacities. FC project gained a huge deal of experience even by producing
all the host and development tools which work nicely with the
upstream(downstream?) codebase and a lot of materials can be actually
reused just like it is done in big guys shops.

Just my 2c

On Thu, Apr 20, 2017 at 12:00 PM, Mychaela Falconia <
mychaela.falconia at gmail.com> wrote:

> 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 at freecalypso.org
> https://www.freecalypso.org/mailman/listinfo/community
>