Firmware bring-up status

[Spacefalcon the Outlaw]

Hello project followers,

I got some more progress since the last update: when I looked into why
our fw was failing on the AT+COPS command, I started reviewing the
rvtdump log, and the first thing I noticed was that the numbers in the
RXL_R and RXL_I traces from L1 were totally bogus.  This is the
exchange between ALR (requestor) and L1 (responder to and executor of
the commands in question) for Rx power level measurement across all
channels in a given band or pair of bands - this power measurement is
the proper and expected first step in the process of trying to connect
to a network.

As I dug into just why our L1 seemed to be receiving total garbage
from ALR in the power_array_size field, I found an error in my earlier
reconstruction of osx.c from osx.obj which I did almost a year ago,
back on 2014-07-01.  You can read about just what this OSX layer does
in my new fw architecture write-up (see below) and you can see my fix
(and the earlier incorrect reconstruction of the lost original source)
in Mercurial, but the short version is that with this bug fixed, the
AT+COPS command now succeeds, and a subsequent AT+COPS? query shows
that the firmware knows it's connected to Operator 310260!

But don't break out the champagne yet: even though it says in the AT
command interface that it's connected to the network, attempts to dial
an MO call fail, and trying to call the SIM in the FR resulted in the
calling phone reaching voicemail (on the network side) and no visible
activity in the experimental fw.  The rvtdump output (which I only
examined very briefly so far) also indicates that something must be
amiss, as it's doing a bunch of BAND_R/BAND_C switches, which
definitely should not be happening when an MS is in steady registered
state with a network.

Seeing that DS has created a directory for trace logs on our web
server, I'm going to upload my logs after I send this one off.

Another update: I spent today writing a detailed document describing
the internal architecture of our firmware, so that if anyone feels
like diving into debugging, he or she will have a better chance of
actually making sense of things.  This document is now checked into
Hg under freecalypso-sw/doc/Firmware_Architecture.

Das Signal <das.signal at freecalypso.org> wrote:

> As for me I've been able to enable more traces in the C118 R87.2.1.03
> firmware, by patching InitializeTrace and pf_TaskEntry to fill the TraceMask
> array with 0xff; this way, the tests in vsi_*_trace always succeed.

It's too bad that we don't have a copy of str2ind.tab to go with that
firmware image - as you can read in my description of GPF compressed
tracing in my new Firmware_Architecture document, these traces from
"foreign" fw versions are mostly useless without a copy of str2ind.tab
corresponding to that fw. :-(

> OTOH the DP-L10 trace
> is super detailed, and should provide a good overview of what's going on.

I've been staring at Pirelli's trace output ever since I wrote rvtdump,
so not much new for me to see there. :-)  Well, OK, your version has
verbose GPF traces enabled which I never did on Pirelli's fw, but once
again without a copy of str2ind.tab corresponding to that fw the index
numbers it emits are rather useless. :-(

> The L1 trace seems to go through a different code path, this will also
> require further research.

Yes, L1 trace is different from GPF trace, see my write-up thereof in
the Firmware_Architecture document.

> By the way, I had a question for Mychaela: do you happen to know by
> any chance which function would be responsible, in the Compal fw,
> for switching off the modem uart from the jack socket? You mentioned
> it is based on a GPIO, but I'm not sure how it is configured on or
> off by the software.

The schematics show that control line coming from GPIO 2, so it should
be controlled by bit 2 of the ARMIO_LATCH_OUT register at 0xFFFE4802.
In TI's TCS211 fw (copied in ours) the functions for twiddling GPIO
outputs are AI_ResetBit() and AI_SetBit(), and I see that they do
appear in R87.2.1.03.map - so try those.  Or you could try setting a
JTAG data breakpoint on writes to 0xFFFE4802, catch the write that
does the dirty deed, and do a stack backtrace to see the chain that
led there.

Happy hacking,
Mychaela