# HG changeset patch # User Mychaela Falconia # Date 1445563597 0 # Node ID c7df31a89935bcf8b321a8b054a8ef3b6649e82f # Parent 2a63c80c59d5d49c4bcd34258f7352ee7c9703ad tcs211-l1-reconst README updated diff -r 2a63c80c59d5 -r c7df31a89935 README --- 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.