diff README @ 31:c7df31a89935

tcs211-l1-reconst README updated
author Mychaela Falconia <falcon@ivan.Harhan.ORG>
date Fri, 23 Oct 2015 01:26:37 +0000
parents 3f44bb6108b9
children 53d8cb470dc7
line wrap: on
line diff
--- a/README	Fri Oct 23 00:05:52 2015 +0000
+++ b/README	Fri Oct 23 01:26:37 2015 +0000
@@ -2,13 +2,43 @@
 attempt at reconstructing an L1 source that would match the binary object
 version we got with our TCS211 semi-src delivery from Sotovik.
 
-The source tree contained herein does NOT compile all the way into a complete
-firmware image, instead the link step currently fails because most L1 modules
-have been replaced with dummies.  The purpose of this tree is not to produce a
-complete fw image, but to facilitate compilation of individual C modules pulled
-from the LoCosto L1 source in the TCS211 environment.
+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.
 
-The envisioned mode of usage is as follows:
+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.