FreeCalypso > hg > tcs211-l1-reconst
comparison README.old @ 290:95f308ba55c7
README for the almost fully reconstructed state
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Mon, 20 Mar 2017 00:37:25 +0000 |
| parents | README@53d8cb470dc7 |
| children |
comparison
equal
deleted
inserted
replaced
| 289:f2f7f4dff6d7 | 290:95f308ba55c7 |
|---|---|
| 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 | |
| 3 version we got with our TCS211 semi-src delivery from Sotovik. | |
| 4 | |
| 5 The idea is to deblob TCS211 L1 one module or small group of modules at a time. | |
| 6 Take individual C modules from the LoCosto L1 source and get them to compile | |
| 7 in the TCS211 environment with TCS211 versions of all include files, producing | |
| 8 new from-source objects that would serve as candidate replacements for the ones | |
| 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. | |
| 14 | |
| 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 [Update: the copyblobs.sh script does this job now.] | |
| 35 | |
| 36 3. Run ./winebuild.sh again. As long as the dummy C files have not been | |
| 37 touched and the copied-in objects have newer timestamps, the dummies won't | |
| 38 be recompiled and the copied-in objects won't get blown away. TI's make | |
| 39 will rerun the ar packaging step to produce l1_ext.lib and l1_int.lib from | |
| 40 the mix of objects (some compiled from source, others copied-in blobs) in | |
| 41 the obj directories, and then the final link should succeed. | |
| 42 | |
| 43 The development process is as follows: | |
| 44 | |
| 45 1. Choose an individual L1 C module to work on. | |
| 46 | |
| 47 2. Copy the source for the chosen module from the LoCosto source in the place | |
| 48 of the dummy in this tree. | |
| 49 | |
| 50 3. Run ./winebuild.sh in the g23m directory and examine the output in | |
| 51 report.txt. If the imported C module fails to compile, massage it until it | |
| 52 passes compilation. | |
| 53 | |
| 54 4. Once compilation passes, look at the generated COFF object in | |
| 55 g23m/__out__/gsm*/obj/l1_{ext,int}. Disassemble it with the tiobjd tool | |
| 56 from freecalypso-reveng, and compare against the disassembly of the | |
| 57 original ("official") binary blob version we got. Massage the reconstructed | |
| 58 source until it compiles into object code that matches the original. | |
| 59 | |
| 60 [Update: use the scripts under g23m/objdiff to facilitate the disassembly | |
| 61 and diffing.] |