The purpose of this Hg tree (derived from leo2moko-debug) is to facilitate an
attempt at reconstructing an L1 source that would match the binary object
version we got with our TCS211 semi-src delivery from Sotovik.

The idea is to deblob TCS211 L1 one module or small group of modules at a time.
Take individual C modules from the LoCosto L1 source and get them to compile
in the TCS211 environment with TCS211 versions of all include files, producing
new from-source objects that would serve as candidate replacements for the ones
we got as blobs.  An absolutely essential aspect of this approach is
incrementality: we should be able to deblob just a few L1 objects (replace them
with build-from-source versions) while keeping the original blobs for all other
parts of L1 we haven't reached yet, and regression-test at each step to ensure
that the firmware still works.

TI's build system for this fw does not provide very fine granularity as far as
compiling each individual module from source or taking it as a delivered blob.
Instead it operates on the granularity of libs, or sometimes (as in the case of
L1) groups of libs.  In the case of L1, this tree has the build system set up
to rebuild l1_ext.lib and l1_int.lib from source, which necessarily includes
_everything_ that goes into these libs.  We are nowhere close to having a
working reconstructed source for every module in these two libs, thus we have
dummies in the place of most of them to appease BuSyB.  Therefore, if you
simply run ./winebuild.sh to build this fw version, the link step will fail.

Instead this fw has to be built in a somewhat convoluted way:

1. Run ./winebuild.sh initially to compile everything leading up to the link
   step, and let it fail.

2. Go into g23m/__out__/gsm*/obj/l1_ext, and copy in original blob objects for
   all those modules which have not been source-reconstructed yet.  Do likewise
   for l1_int.

3. Run ./winebuild.sh again.  As long as the dummy C files have not been
   touched and the copied-in objects have newer timestamps, the dummies won't
   be recompiled and the copied-in objects won't get blown away.  TI's make
   will rerun the ar packaging step to produce l1_ext.lib and l1_int.lib from
   the mix of objects (some compiled from source, others copied-in blobs) in
   the obj directories, and then the final link should succeed.

The development process is as follows:

1. Choose an individual L1 C module to work on.

2. Copy the source for the chosen module from the LoCosto source in the place
   of the dummy in this tree.

3. Run ./winebuild.sh in the g23m directory and examine the output in
   report.txt.  If the imported C module fails to compile, massage it until it
   passes compilation.

4. Once compilation passes, look at the generated COFF object in
   g23m/__out__/gsm*/obj/l1_{ext,int}.  Disassemble it with the tiobjd tool
   from freecalypso-reveng, and compare against the disassembly of the
   original ("official") binary blob version we got.  Massage the reconstructed
   source until it compiles into object code that matches the original.