# HG changeset patch # User Mychaela Falconia # Date 1633895615 0 # Node ID a760a5eeed65e7f3a47498cfc4c0f5e24c09b207 # Parent 82fb5a70c9fd24b6d8da9f5d2871974e46d24803 compal/audio/omr-guide: another avenue of investigation diff -r 82fb5a70c9fd -r a760a5eeed65 compal/audio/omr-guide --- /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.