--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/chipsetsw/layer1/tpu_drivers/source0/tpudrv12.notes	Wed Mar 15 07:26:03 2017 +0000
@@ -0,0 +1,73 @@
+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.