FreeCalypso > hg > tcs211-l1-reconst
view chipsetsw/layer1/tpu_drivers/source0/tpudrv12.notes @ 337:34166dff7280
g23m/copyblobs.sh: l1p_* deblobbed
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 29 Oct 2017 18:51:34 +0000 |
parents | 595cdc5ff4e5 |
children |
line wrap: on
line source
The reconstruction of tpudrv12.c was done back in 2014, before many of the later lessons were learned and before the current reconstruction approach has been adopted. Therefore, a new audit is needed to check if the logic of the reconstructed version truly matches that of the original or not. This notes file will serve to record our analysis of the differences. Diff at the profile and section level: no diff in the set of exported or referenced symbols, but the synth_900, synth_1800, synth_1900 and synth_850 global data objects have been changed from initialized writable data to const. The resulting diff at the object level is that these objects have left .bss, the object now has a .const section with these objects, and .cinit now only fills rf_path[], which is still initialized writable data. .bss section: aside from the synth_* move described above, the only .bss diff is that the original object had a static variable named rf_data, described below. calc_a_b(): the original and our reconstruction match exactly up to the point where the "n" absolute frequency is computed. Then it needs to be offset as required by Rita hardware. The original code does it in a more convoluted manner involving a local variable named a; our code is much simpler and shorter, but produces exactly the same result. Convert_l1_radio_freq(): the original code expression was a little different, but the logic is exactly the same. rf_init() and all subsequent functions that use the TSP_TO_RF() macro: wherever we use this macro in our reconstruction, the original code does something very weird: it first writes the 16-bit value we pass to the macro into a static var named rf_data, then when it writes the upper byte to the TPU, the TPU word is computed directly, but when it writes the lower byte to the TPU, it reads it back from the rf_data var. Our diffs are due to the elimination of this weirdness. rf_init_light(): empty function, trivial match. arfcn_to_rf_index(): perfect match. rf_program(): logic verified to match, the diffs are the TSP_TO_RF() oddity and reversed order of if-else clauses. l1dmacro_agc(): having no idea what the original C code looked like, I made a literal translation from disassembly to C. But the recompilation of the resulting C code produces quite different assembly. But the logic has been verified to match. l1dmacro_rx_synth(): perfect match. l1dmacro_tx_synth(): perfect match. l1dmacro_rx_up(): logic manually verified match, same issues with literal translation from disasm to C and TSP_TO_RF(). l1dmacro_rx_down(): logic verified to match, TSP_TO_RF() appears to be the only source of diffs, perfect match otherwise. l1dmacro_tx_up(): same as above. l1dmacro_tx_down(): same story. l1dmacro_rx_nb() through l1dmacro_reset_hw(): perfect match. l1dmacro_RF_sleep(): logic verified to match, TSP_TO_RF() appears to be the only source of diffs, perfect match otherwise. l1dmacro_RF_wakeup(): TSP_TO_RF() diffs, same diff in compiler behaviour as in l1dmacro_rx_up() where the new code reads TP_Ptr every time but the old code doesn't, and I also unrolled a loop in one place in my original reconstruction. Logic compared to match. l1dmacro_init_hw(): perfect match. l1dmacro_init_hw_light(): ditto.