view compal/audio/omr-guide @ 395:00f5287db832

se_k200i/flash-notes: fix wrong number of zeros in 0x20000 address
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 01 Jan 2023 01:42:04 +0000
parents a760a5eeed65
children
line wrap: on
line source

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.