view README @ 584:257b1c14db87

tpudrv12.c: TSPEN1 configuration fix for Pirelli DP-L10
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 07 Mar 2019 21:21:20 +0000
parents 39a226a06196
children c32c887ced3a
line wrap: on
line source

FreeCalypso Magnetite firmware project
======================================

As of A.D. 2018, FC Magnetite is the primary official Calypso firmware source
tree for the FreeCalypso family of projects.  This maintained and evolving
source can be built in many different configurations for several different
hardware targets, and is currently used in the following ways:

* The official production firmwares for our fully supported GSM+GPRS modem
  products (FCDEV3B and the modem part of Openmoko devices) are built from
  this source tree.  See doc/Modem-configs for this mode of usage.

* The work in progress toward a future complete FreeCalypso phone handset
  (also known as a Libre Dumbphone) is being done in this source tree.
  See doc/Handset-goal for more info about this project direction.

* One can play with FreeCalypso and get a taste for it using certain hardware
  that used to be readily available and which most people in the phone hacking
  scene already have: Motorola C1xx and Pirelli DP-L10.  Firmware images of the
  "hacking toy" sort can be built for these devices from the present source
  tree, and one can exercise most of the functions and capabilities of
  FreeCalypso (with the notable exception of CSD and GPRS) on this historical
  but available-to-most-people hardware.  See doc/C1xx-Howto, doc/Pirelli-Howto
  and doc/Voice-pseudo-modem for more information.

* If anyone besides the Mother has an original TI-made D-Sample hardware kit
  for Calypso software development, we are doing the best we can to support
  running our FreeCalypso firmware on this original TI hardware - see
  doc/D-Sample for more information.

Functionality
=============

TI's GSM mobile station firmware architecture supports two ways in which the
GSM device may be controlled: via AT commands from an external host and/or via
a local UI on devices with LCD & keypad hardware.  (I said "and/or" because the
two mechanisms can coexist.)  The code we got from TI (TCS211 and TCS3.2) is
very solid and mature in the modem configuration (control via AT commands only,
no UI, no battery management, no traditional handset on/off control), but the
additional code layers that are needed for handset products but not for modems
came in a very rough "proof of concept" condition, nowhere close to a usable
product.

In FC Magnetite we further maintain and support the solid code base we got for
the modem functionality, and we are also working to improve the support for
handset products and bring it into a practically usable state.  At the present
time the handset firmware work is on hold, paused until we design and build the
first prototype version of our own FreeCalypso handset hardware.  The reason
for this hold is that we are not able to use TI's original development board
(see doc/D-Sample for the issues), hence we need to build our own hardware that
will serve in its place.  Until then we focus on maintaining and supporting the
good working modem functionality.

Both TI's original modem fw (TCS211) and our recreation thereof in this
Magnetite project support not only voice calls and SMS, but also CSD, fax and
GPRS.  This advanced functionality is fully supported on our own GSM MS
development board (FCDEV3B), where both Calypso UARTs are presented directly to
the developer, as well as on the embedded Calypso modem in Openmoko GTA01/02
smartphones, where the AT command channel with CSD, fax and GPRS capabilities
is connected to the phone's application processor.

Build system
============

Even though FC Magnetite is essentially unchanged TCS211 code base and builds
using TI's proprietary TMS470 compiler under Wine, the build system is entirely
new.  TI's TCS211 build system, called BuSyB, works by way of a Java tool
generating a customized makefile for each desired build configuration, based on
lots of magic contained in a big repository of XML files.  There are a bunch of
Perl scripts involved as well.  The Java tool that does the heavy lifting exists
only as compiled Java bytecode sans source, and the surrounding Perl scripts
aren't very understandable either.  And the whole thing thoroughly assumes a
Windows environment (drive letters, backslashes, case-insensitive file system)
throughout.  As a result, when working with TCS211 fw with its original build
system, we had to treat these BuSyB-generated makefiles almost as being blobs in
themselves: regenerating a makefile from XML magic required major effort, there
were some bugs in the makefile generation which we couldn't fix and thus we had
to edit the makefiles manually after each regeneration - it was an utter mess,
and absolutely not an acceptable way to build a forward-looking, community-
serving project.

In FC Magnetite I have recreated the relevant parts of the TCS211 build system,
using Bourne shell magic instead of Java and XML.  Just like TI's BuSyB, ours
is a makefile generation system: in order to compile the firmware in a
particular desired configuration, you run a shell script to select the config
you would like.  This shell script will create a dedicated build directory tree
to fully contain this build, and populate it with generated Makefiles and some
other bits - then you go into the just-created build directory and run make
there.  The source and build trees are thus cleanly separated.  See
doc/Compiling for detailed instructions.

Another key difference from our previous TCS211-based firmware offerings is that
even though we still have to run TI's compiler binaries under Wine, the Wine
invokation has been moved from the top (root) of the build process to the
bottom leaves.  With our previous TCS211-based works you would run Wine at the
top, and then the entire build process would proceed in the Windows environment,
using Windows versions of make and other nonsense.  Not so in FC Magnetite:
in this firmware project all shell scripts, Makefiles, Perl scripts and other
build system accessories run at the native Unix level, and Wine is only invoked
at the lowest level by individual tool wrappers: for example, TI's compiler
binary cl470.exe is encapsulated in a Unix shell script called cl470 that
invokes Wine to run the Windows binary, presenting the illusion of a native
Unix tool to all upper levels.

As yet another defenestration measure, all source files are checked into this
tree with Unix line endings.

Two versions of the G23M protocol stack
=======================================

A major component of all functional firmware configurations is the mass of code
that implements layers 2 and 3 of the GSM+GPRS protocol stack, called G23M.  In
FC Magnetite we have the option of using one of two different versions of this
key firmware component:

* The original G23M version from Openmoko: this version is believed to be very
  stable because it has been used (successfully to the best of our knowledge)
  by Openmoko, and it came from TI's TCS211 program that officially targeted
  the Calypso chipset - but it exists only as binary object libraries with no
  corresponding source.  The lack of source means no ability to change the
  feature configuration (what is enabled and what is disabled), very difficult
  to debug if something does go wrong - all of the usual problems of software
  without source.

* A newer version from TI's TCS3/LoCosto program.  This version came to us in
  the form of full C source, and because this fw component is chipset-
  independent (unlike L1), we have successfully produced a TCS2/TCS3 hybrid in
  which the new G23M code from TCS3.2 is grafted onto the chipsetsw foundation
  from TCS211, which we have reconstructed into full C source form as well.

Each of the two G23M PS versions also has its own version of the Application
Control Interface (ACI) layer to go with it, which we call aci2 and aci3 -
except that in the case of ACI, we have the full source for both versions.
Furthermore, in the case of firmware builds that have the phone UI layers
enabled (BMI and MFW, sitting on top of ACI), we likewise have different TCS2
and TCS3 versions of these BMI and MFW layers, also with full source for both
versions.  Thus the chipsetsw foundation is always the same TCS211, but then we
bifurcate: we can build either a pure TCS211 config using TCS211 versions of
G23M PS (blobs), ACI (source) and MFW+BMI (source), or a TCS2/TCS3 hybrid config
using the new TCS3 versions of G23M PS, ACI and MFW+BMI, all in full C source
form.

The new TCS2/TCS3 hybrid config is the way forward, as our goal is to have no
blobs in our firmware - having the full source is a prerequisite for maintaining
a software product.  FC Magnetite supports building both configurations in order
to facilitate the transition.  As of this writing, the hybrid config is believed
to have reached feature parity with Openmoko-mimicking classic and l1reconst
configs, i.e., unless we missed or broke something, every feature that worked
correctly on Openmoko's original modem should work just as well with our hybrid
firmware.  All functionality (both standard and OM-custom) that can be tested
in our lab appears to work flawlessly; the new hybrid modem fw now needs to be
tested by a larger number of users in real-life usage.

Other blobs
===========

Our TCS2/TCS3 hybrid firmware is built almost entirely from source; the only
components which are linked in the form of prebuilt objects or libraries are
certain glue components in GPF (specifically OSL and OSX), the Nucleus PLUS RTOS
and the TMS470 compiler's equivalent of libc/libgcc.  In the case of Nucleus we
have another version of it in full source form, but switching to a different
version of Nucleus is outside the scope of FC Magnetite - see the next section.
In the case of OSL and OSX, we have a reconstructed source and one can build a
Magnetite config (hybrid-osl) that uses these reconstructed versions of OSL and
OSX instead of the blobs, but we are not 100% confident in the quality of this
reconstruction, hence this hybrid-osl config is currently considered
experimental, not production.

Blob-free, gcc-built version
============================

For those who require or desire a firmware version that is completely free of
any blobs and builds with a FLOSS compiler, we now have a new experimental
firmware project called FreeCalypso Selenite:

https://bitbucket.org/falconian/fc-selenite

FC Selenite is based on FC Magnetite (just the modem functionality, no work-in-
progress phone UI, and only the hybrid code version), but it uses the new
full-source version of Nucleus and our reconstructed versions of OSL and OSX,
and it offers the option of building either with the original TMS470 compiler
or with gcc.  The gcc-built version also uses entirely new implementations of
all assembly components and linker script magic, as the two toolchain
environments are entirely different in this regard.

This new Selenite firmware is expected to fully supplant our earlier and now
completely unmaintained Citrine fw (our first attempt at gcc-built fw), but it
is still highly experimental: as of this writing, GPRS does not work at all in
Selenite-gcc (Citrine does not have any GPRS support either), and even the
GSM-only config with GPRS disabled exhibits some intermittent glitches.  Thus
the stable production fw is still TMS470-built FC Magnetite for the time being.

Further reading
===============

For various instructions and notes specific to this FreeCalypso Magnetite
firmware, look in the doc directory.  For more information about the overall
FreeCalypso project and our hardware building aspirations, go to our website:

https://www.freecalypso.org/