FreeCalypso > hg > tcs211-l1-reconst

comparison README @ 31:c7df31a89935

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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
comparison
equal deleted inserted replaced
30:2a63c80c59d5 31:c7df31a89935
1 The purpose of this Hg tree (derived from leo2moko-debug) is to facilitate an 1 The purpose of this Hg tree (derived from leo2moko-debug) is to facilitate an
2 attempt at reconstructing an L1 source that would match the binary object 2 attempt at reconstructing an L1 source that would match the binary object
3 version we got with our TCS211 semi-src delivery from Sotovik. 3 version we got with our TCS211 semi-src delivery from Sotovik.
4 4
5 The source tree contained herein does NOT compile all the way into a complete 5 The idea is to deblob TCS211 L1 one module or small group of modules at a time.
6 firmware image, instead the link step currently fails because most L1 modules 6 Take individual C modules from the LoCosto L1 source and get them to compile
7 have been replaced with dummies. The purpose of this tree is not to produce a 7 in the TCS211 environment with TCS211 versions of all include files, producing
8 complete fw image, but to facilitate compilation of individual C modules pulled 8 new from-source objects that would serve as candidate replacements for the ones
9 from the LoCosto L1 source in the TCS211 environment. 9 we got as blobs. An absolutely essential aspect of this approach is
10 incrementality: we should be able to deblob just a few L1 objects (replace them
11 with build-from-source versions) while keeping the original blobs for all other
12 parts of L1 we haven't reached yet, and regression-test at each step to ensure
13 that the firmware still works.
10 14
11 The envisioned mode of usage is as follows: 15 TI's build system for this fw does not provide very fine granularity as far as
16 compiling each individual module from source or taking it as a delivered blob.
17 Instead it operates on the granularity of libs, or sometimes (as in the case of
18 L1) groups of libs. In the case of L1, this tree has the build system set up
19 to rebuild l1_ext.lib and l1_int.lib from source, which necessarily includes
20 _everything_ that goes into these libs. We are nowhere close to having a
21 working reconstructed source for every module in these two libs, thus we have
22 dummies in the place of most of them to appease BuSyB. Therefore, if you
23 simply run ./winebuild.sh to build this fw version, the link step will fail.
24
25 Instead this fw has to be built in a somewhat convoluted way:
26
27 1. Run ./winebuild.sh initially to compile everything leading up to the link
28 step, and let it fail.
29
30 2. Go into g23m/__out__/gsm*/obj/l1_ext, and copy in original blob objects for
31 all those modules which have not been source-reconstructed yet. Do likewise
32 for l1_int.
33
34 3. Run ./winebuild.sh again. As long as the dummy C files have not been
35 touched and the copied-in objects have newer timestamps, the dummies won't
36 be recompiled and the copied-in objects won't get blown away. TI's make
37 will rerun the ar packaging step to produce l1_ext.lib and l1_int.lib from
38 the mix of objects (some compiled from source, others copied-in blobs) in
39 the obj directories, and then the final link should succeed.
40
41 The development process is as follows:
12 42
13 1. Choose an individual L1 C module to work on. 43 1. Choose an individual L1 C module to work on.
14 44
15 2. Copy the source for the chosen module from the LoCosto source in the place 45 2. Copy the source for the chosen module from the LoCosto source in the place
16 of the dummy in this tree. 46 of the dummy in this tree.