FreeCalypso > hg > tcs211-l1-reconst
view README @ 36:bd7effdeba68
l1_async.c: l1a_mmi_outen_cfg_process() fix, link passes now
author | Mychaela Falconia <falcon@ivan.Harhan.ORG> |
---|---|
date | Wed, 28 Oct 2015 03:13:17 +0000 |
parents | c7df31a89935 |
children | 53d8cb470dc7 |
line wrap: on
line source
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.