FreeCalypso > hg > freecalypso-reveng
view compal/audio/omr-guide @ 385:79e512a21e02
pirelli/audio-tones: busy tone captured
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Wed, 10 Nov 2021 02:35:20 +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.