Another letter to TI

Sun Oct 13 03:01:33 UTC 2019

Thanks for the effort Mychaela,

We really endorse your position and really believe there is no reason
why TI would not open up the missing bits FC needs to get 100% source
compilable.

Hasta!
Rafael

On 10/12/19 4:19 PM, Mychaela Falconia wrote:
> Hello FreeCalypso community,
> 
> I have just sent another outreach letter to TI:
> 
> https://www.freecalypso.org/members/falcon/TI-outreach/letter-20191011.pdf
> 
> I sent this letter to TI's Dallas headquarters, addressed to R. Gregory
> Delagi from the leadership team:
> 
> http://www.ti.com/corp/docs/investor_relations/leadership.html
> 
> To be clear, my primary motivation for making these repeated outreach
> attempts to TI is not because of the licensing nonsense, but because
> of the missing bits: while we have recovered most of the source and
> documentation materials related to the Calypso chipset, there are still
> a few bits missing, and because of extreme obscurity, it is possible
> that these last missing bits might not exist anywhere except TI's deep
> archives, stashed behind a tall and solid wall of indifference.
> Breaking through that wall of indifference at TI will probably require
> a lot more than just a letter, what we really need is to have a crowd
> of a hundred people camping out on a sidewalk in front of TI's HQ day
> and night for a few months, demanding the release of those materials -
> but we have to start somewhere, and the letter I just sent them is a
> start.
> 
> The 10 source files (os_???.c and osx.c) which I asked for in the
> current letter are not the only bits which we don't have, which may
> exist in TI's deep archives and which would be highly valuable to the
> mission of FreeCalypso.  There is the source code for the Calypso DSP
> ROM, sources for Windows tools ccdgen.exe and str2ind.exe which we
> currently limp without, schematics or other hw documentation for the
> historical D-Sample board would also be very valuable (much richer
> developer-oriented functionality than on our FCDEV3B), a copy of the
> PADS PCB layout file for their quadband Leonardo board would be a very
> useful additional reference - the list goes on, and this is just for
> Calypso/2G.  In addition to their post-Calypso 2G chips (LoCosto and
> E-Costo) which aren't too interesting to us, TI also had a working
> solution for UMTS/3G - I personally knew a former TI engineer who
> worked on it at their San Diego office, so I know their 3G solution
> was working for real - but they threw it in the trash along with their
> 2G stuff when they exited that business because they felt they couldn't
> compete against Qualcomm and MTK.
> 
> And no, I am not holding my breath for those os_???.c and osx.c files
> I asked for in this letter - I will continue with my hardware plans
> regardless of whether we ever recover those files or not - but I do
> need to clarify to our FC community that I will not be able to work on
> migrating from TI's proprietary compiler to gcc unless we obtain those
> 10 missing files.  We do have FC Selenite firmware which can be built
> with gcc, using a not-too-trustworthy source reconstruction of OSL and
> OSX from 2014 - but this fw is experimental, not production quality,
> and it will remain so until and unless we recover those missing files.
> It would be conceptually possible to do the compiler migration without
> those original source files, working with disassembly-based
> reconstruction only, but it would be an extremely unpleasant job, and
> I am not currently motivated enough to take on a project direction of
> such unpleasantness.  Thus as things stand, I will only be able to
> produce gcc-built firmware that fully supplants the current TMS470-
> built Magnetite version *if* we can recover those 10 missing files.
> 
> My FreeCalypso hardware work will continue no matter what, regardless
> of whether we ever succeed in getting anything out of TI or not - as I
> see it, I will spend the rest of my natural biological lifespan
> (probably got some 30-40 y left) working two directions in parallel,
> advancing FC hardware on one front (there is plenty more that can be
> done on the hw front using the materials and know-how we already have)
> and keeping up the social pressure on TI for the missing bits on the
> other front.
> 
> However, there is also a place where the wider community can come in
> very usefully, and this call to the community is the primary purpose
> of the present announcement.  Breaking through the indifference at TI
> and convincing them to dig up and release the ancient archival
> materials we are after (as well as the whole license silliness) will
> probably require a lot more than just my letters, we would also need
> larger community pressure.  Specifically, if the letter I just sent to
> TI fails to elicit any response just like my two previous letters sent
> to their San Diego office produced no response, the proper next step
> would be to amplify the demand with more people - it is easy to brush
> off one person sending letters, but if we had a hundred people sending
> them letters, that pressure would be more difficult to ignore.  The
> present announcement is a heads-up to what is coming; if a couple of
> months go by with no response from TI, then I will post again with
> more ideas as to exactly how other community members can get involved
> with further letter writing or other public pressure.
> 
> Meanwhile I keep working along my FC hardware roadmap.  On the hw
> front my next coming-up project is MMTB1, a modem module test board
> that will work with the already existing GTM900-B (and maybe GTM900-P)
> modules, but is also expected to work with my proposed FCM40 module.
> I already got the MMTB1 design done at the schem+bom level and got all
> of the component footprints captured; the next step is the actual PCB
> layout, which still remains to be done.  I will probably have MMTB1
> done before my big surgery, but the more exciting FCM40 (the actual
> ambition for which MMTB1 is a preparatory step) will probably have to
> wait until after.
> 
> As for FCM40, my motivation there is two-fold: on the one hand it will
> be our first hw product that is officially intended to serve as a
> component to be integrated into larger systems (FCDEV3B is a development
> board for lab bench use only, not for incorporation into larger
> systems), and on the other hand it would be a perfect opportunity for
> us to escape from the proprietary clutches of Altium.  The PCB data
> model and ASCII file format of PADS are well-understood (at least by
> me), and as soon as we have a FOSS PCB tool to migrate to (would need
> to be a custom fork of either geda-pcb or pcb-rnd with some data model
> changes), we have a ready migration path to move our OM-based modem
> core PCB layout from PADS to FOSS.  But with Altium the situation is
> much worse, i.e., the data model and file format of Altium are much
> more hostile than PADS.
> 
> Because of the way things worked out back in 2015-2016, the PCB layout
> work for FCDEV3B was done for us by certain people on a barter basis,
> as opposed to a contractor hired with money.  Those people had moved
> the design from PADS to Altium against my protests, and we've been
> stuck with Altium for FCDEV3B ever since, held hostage to it.  Because
> I don't have much hope for a migration path from Altium to FOSS, a
> move to FOSS would require giving up all of the new layout work done
> for FCDEV3B and going back to our OM GTA02 starting point, which is in
> PADS format.  Throwing away our FCDEV3B PCB layout is not an option,
> hence FCDEV3B remains stuck in Altium - but hopefully it won't need
> any more changes beyond our current V2.
> 
> Now enter my FCM40 idea: that modem module won't need any of the
> peripherals featured on the FCDEV3B, instead it will be just the modem
> core (straight from GTA02) with just one FPC interface connector added.
> That is a perfect opportunity to go back to GTA02 and to do the new
> project right, do it without Altium, using only PADS and FOSS instead!
> It is something I plan on working on in 2020-2021.
> 
> Finally what matters at the end of the day is this: even if we never
> succeed in getting anything more out of TI than what we already have,
> even if we never get a blob-free gcc-built fw version of production
> quality, even if our current 98% source, 1.8% blob FC Magnetite fw
> built with TI's ancient proprietary compiler is the best we ever have,
> it is a still a quantum leap ahead of the competition!  Why?  Because
> look at how unfree our competition is: our competitors (GSM/2G chipset
> vendors) are MTK, Spreadtrum and RDA, and they are just as closed as
> Qualcomm.  Just look at any of those MTK "source" leaks: *everything*
> from the DSP-interfacing bottom of L1 to what they call L4 (seems to
> be an approx equivalent of our ACI) is all binary objects, not one bit
> of actual source for any of the interesting parts.  And it isn't just
> the firmware, the available leaks in terms of chip register
> documentation are just as bleak - nothing in comparison to the docs we
> have for Calypso.
> 
> Therefore, unless MTK or Spreadtrum or RDA suddenly change their
> stance and freely publish their complete chip documentation and
> reference firmware source code (not to be expected obviously), we
> still have a legitimate case for needing to produce and market our
> FreeCalypso modems: despite the remaining few blob bits and despite
> the lack of a FOSS license, our *published source* FreeCalypso
> solution is still a monumental quantum improvement over the mainstream
> MTK/Spreadtrum/RDA/Qualcomm status quo.  But if we can convince TI to
> release those last missing bits which I am after, then our FreeCalypso
> solution can be made even better and even more free, which is why we
> need to continue a sustained campaign of public pressure on TI for as
> long as it takes, however many years.
> 
> Hasta la Victoria, Siempre,
> Mychaela aka The Mother
> _______________________________________________
> Community mailing list
> Community at freecalypso.org
> https://www.freecalypso.org/mailman/listinfo/community
> 