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.sig...@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 _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
