--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/compal/audio/omr-guide	Sun Oct 10 19:53:35 2021 +0000
@@ -0,0 +1,40 @@
+When a C139 phone is booted up with a headset jack serial cable already
+inserted, it behaves in an interesting manner: if you *don't* perform the
+**16379# step, rvinterf running on the host won't see any output from the phone
+beyond a little bit on boot, but if you send an omr command through fc-tmsh,
+you get a response!  The same behaviour occurs if you first boot the phone
+normally with nothing in the headset jack, then insert the serial cable.  It
+looks like the electrical switch inside the phone is still set to connect the
+headset jack to the UART, but the firmware suppresses its continuous trace
+output beyond TM responses.
+
+Using this omr method, I was able to read the same DSP API words which we have
+previously read via tfc139 break-in method; the bytes read via omr out of DSP
+API memory locations corresponding to FIR coefficients and AEC config match what
+we got via tfc139 break-in followed by fc-loadtool peeking.
+
+Now comes the next ambitious part: we know that oabbr is broken in Compal's fw
+and thus can't be used to read ABB registers, but at least in TI's reference fw
+the writes to Iota VBC registers are done via the DSP, rather than via the MCU
+to ABB interface.  Does Compal's fw do likewise?  Can we read out DSP API words
+through which these VBC registers are written?  Let's give it a try!  We need
+to begin by calculating the absolute addresses which we will need to read via
+omr:
+
+DSP NDB start address is 0xFFD001A8
+
+d_vbctrl1 addr: 0xFFD001A8 + 0x44 = 0xFFD001EC
+d_vbctrl2 addr: 0xFFD001A8 + 0x2E = 0xFFD001D6
+d_vbuctrl addr: 0xFFD001A8 + 0x34 = 0xFFD001DC
+d_vbdctrl addr: 0xFFD001A8 + 0x36 = 0xFFD001DE
+
+Result: the bytes read out via omr do match what we got earlier by breaking in
+with tfc139 and reading the ABB registers via abbr in fc-loadtool!  This
+observation gives us hope: if we do build the special hardware hack for
+connecting to UART signal contact pads without going through the headset jack,
+then there is a good chance that we will be able to use omr to read out the
+firmware's audio settings for the handheld mode.  Furthermore, if we don't
+trigger the switch into headset mode and if we don't kill the fw with tfc139,
+then we may be able to do omr readouts while the fw is running with a SIM,
+connected to a GSM network, and making a call - a confidence boost for the
+audio settings, plus we may be able to figure out how volume control works.