FCDEV3B bring-up status

[Mychaela Falconia]

Hi Serg,

> Tried Magnetite hybrid and it worked without any problems with any SIM
> I have.

OK, so you have a SIM which works with Magnetite hybrid but not with
Citrine?  Is there anything special about that SIM, or is it just
another regular SIM from Operator 310260?

If Magnetite hybrid works but Citrine does not, the next logical step
in narrowing down the difference should be to try building Magnetite
in a hybrid config with FAX_AND_DATA and GPRS disabled (to match
Citrine), but such config has not been created yet.

> Compilation time is really long.

Yes, the long compilation time of Magnetite hybrid is really bothersome.

> I didn't really profile
> anything, but I noticed that wine is trying to setup graphical
> environment to run every command.

Yeah, I figured it was doing that.

> Have you considered wineconsole instead?

I've been ignorant of its existence.  You can try changing the nowhine
wrapper to invoke wineconsole instead of wine, and see if it makes a
difference.

> not working:
> GPF trace id=A7 ts=00019420 PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
> sat_enabled = 0, modus = 255"
>
> working:
> GPF trace id=A7 ts=00007F1B PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
> sat_enabled = 1, modus = 255"

You know that SAT is SIM Application Toolkit, right?

> I like Citrine flavor :) because it is built completely with GCC and
> it is really fast to recompile even from scratch.

I naturally also desire to have fw that builds with gcc and thus
avoids all that grossly inefficient Wine nastiness.  However, over the
years that I've been working on FreeCalypso, the 3 y that went by
since I did the fw approach that later became Citrine (our first
attempt at FreeCalypso GSM fw), my vision has evolved and changed, and
I no longer consider my original approach (that led to current Citrine)
of reintegrating the fw suite piece by piece from the bottom up to be
such a good idea.

Instead my current thinking is to approach the end goal of blob-free
gcc-built fw with full functionality of TCS211 incrementally, changing
one variable at the time, starting wtth TCS211.  The first change was
to deblob L1 one C module at a time, keeping everything else the same,
the next step (Magnetite hybrid) is to replace the blob version of
G23M with the source version, still keeping everything else the same
(including the compiler toolchain and the not-yet-deblobbed pieces),
and so forth.  Once all of Magnetite has been fully deblobbed one
piece at a time, then try migrating it to gcc with just a compiler
change, i.e., without moving header files around and changing the way
in which the configuration is set and all other big rearchitecturing
changes of Citrine which go beyond the compiler toolchain.

But of course the above is a very long-term plan.

> I was trying to figure out how do the trace flags work in Citrine

They work the same way in Citrine as in the original TCS211; read this
TI document:

https://www.freecalypso.org/LoCosto-docs/SW%20doc/frame_users_guide.pdf

and pay particular attention to the description of traces and the
TRACECLASS system primitive.  With our tools the way to send system
primitives to a running fw is the sp command in fc-shell.

[in the follow-up post]
> I have enabled function names tracing by directly applying trace TC_FUNC
> flag in InitializeTrace function. It seems to be not the right way of doing
> this, but it made the rick.

No, it is not the right way, see the TRACECLASS system primitive for
the right way.

> Please see a side-by-side trace of two equal runs, one where I got
> successful registration and the other when I was observing the issue.

All noise and no signal.  Enabling TC_FUNC traces across all entities
in the entire G23M stack is not a useful way to debug such issues,
instead you should begin by examining the flow of primitives between
entities and see where the first diff occurs, and then hopefully know
which protocol stack entity you should be looking at in more detail,
with more traces enabled.

TC_PRIM is the trace class you should start with, and I would not
recommend enabling it for all entities at once, as that would again
produce too much noise.  Instead begin with the MMI entity, then look
at the entities it communicates with, and go down from there.

I assume you've read my doc/Firmware_Architecture write-up in the
Citrine source tree - I have just updated the stale links to docs at
the end to their new FTP and web locations.

M~