FCDEV3B bring-up status

Tue May 16 13:49:36 UTC 2017

I tried to run "make -j 2" in order to force make to run 2 recipes in
parallel and it greatly improved the build time. I noticed that wineserver
process was not exiting and CPU load was consistently high, as expected.
However a hash of the resulting image did not match the image produced by
the linear process. Possibly just because the artifacts were placed into
libraries in different order or maybe there are more serious problems.

Out of curiosity I ran "make -j 8" and it produced an image in about 5
minutes!!! Not sure if it is functional though...Didn't have a chance to
validate the process and results.

On Mon, May 8, 2017 at 9:42 PM, Serg l <serg at tvman.us> wrote:

> Excellent! I could see all that infrastructure, but could not figure out
> how the trace flags are set up. TRACECLASS does real magic. I flashed
> Citrine and trying to capture some traces of states and primitives sent
> between entities. I was able to observe few successful runs when board was
> able to register. When it does register, it works just fine, otherwise it
> is getting stuck for unknown reason. I will collect more details and report
> back if anybody is still interested in working with Citrine which actually
> works without AT%SLEEP=0 :)
>
> BTW I checked wineconsole and it looks like not the right tool as it does
> even more work than regular wine for console applications. I also noticed
> that wineserver is restarted for every command, maybe if we can make use of
> persistent wineserver, some performance improvement could be observed.
> Another option is to split the build into multiple parallel jobs because
> CPU load is almost zero during the compilation. This should speed up the
> process, IMHO
>
> On Sun, May 7, 2017 at 12:23 PM, Mychaela Falconia <
> mychaela.falconia at gmail.com> wrote:
>
>> 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~
>> _______________________________________________
>> Community mailing list
>> Community at freecalypso.org
>> https://www.freecalypso.org/mailman/listinfo/community
>>
>
>