Re: FCDEV3B bring-up status

[Serg l]

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.
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.

​
 citrine.htm

​

On Sat, May 6, 2017 at 8:40 PM, Serg l  wrote:

> Mychaela,
> Tried Magnetite hybrid and it worked without any problems with any SIM
> I have. Compilation time is really long. I didn't really profile
> anything, but I noticed that wine is trying to setup graphical
> environment to run every command. Have you considered wineconsole
> instead?
>
> I reviewed Citrine log from S/N1 and this is the 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=7F1B PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
> sat_enabled = 1, modus = 255"
>
> I like Citrine flavor :) because it is built completely with GCC and
> it is really fast to recompile even from scratch.
>
> I was trying to figure out how do the trace flags work in Citrine, I'd
> like to find out how we end up in the function cb_mmi_sat_cbch_req()
> after enabling CFUN=1
>
> General tracing seems to be enabled, but I need more details not only
> errors. If you have any suggestions, I would really appreciate this.
>
> -Serg
>
> On 5/6/17, Mychaela Falconia  wrote:
> > Hi Serg,
> >
> >> It worked once with different SIM card, but it is definitely not a
> >> hardware
> >> issue because Magnetite build works every time with the same SIM card.
> >> Maybe L1/DSP is configured a bit differently and if my calibration
> values
> >> are a bit off, Citrine may not be able to detect carriers.
> >
> > I don't see how the quality of calibration could be the cause of the
> > problem you are having with Citrine, as your log shows that the fw
> > does not even attempt to connect to a cell, i.e., the upper layers of
> > the G23M protocol stack are not commanding L1 to make a network sync
> > attempt.  And because L1 is not being commanded to do the operation in
> > question, I don't see how it could be an L1 or DSP problem either -
> > instead it must be some glitch higher up in the protocol stack code.
> >
> > The G23M PS used in Citrine is not too polished, i.e., it may still
> > have bugs that need to be shaken out, and the issue you are having
> > looks like one of them.  However, my preferred approach to debugging
> > these G23M PS problems is to debug them first in the TCS2/TCS3 hybrid
> > config of Magnetite (see doc/Modem-configs in the fc-magnetite source
> > tree), and then port to Citrine if there is commercial demand for the
> > latter.
> >
> > Thus you might want to try building Magnetite in the hybrid config
> > (different from the l1reconst config I currently use and recommend for
> > production use), and see if the SIM that's giving you trouble in
> > Citrine works in Magnetite TCS2/TCS3 hybrid or not - this experiment
> > would narrow the search for the bug.
> >
> > M~
> > ___
> > Community mailing list
> > Community@freecalypso.org
> > https://www.freecalypso.org/mailman/listinfo/community
> >
>
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: 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=7F1B 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@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

G23M protocol stack and its deblobbing

[Mychaela Falconia]

Hello FreeCalypso community,

It has been brought to my attention that even some of our long-timers
do not fully understand the difference between our Citrine and
Magnetite firmwares and between the classic/l1reconst and hybrid
configurations of FC Magnetite in terms of the G23M protocol stack
(a major firmware component), hence I am making this explanatory post.

In terms of our starting point, we have two versions of G23M: one
dated 20070608 and in the form of binary libs (came with our TCS211
semi-src), the other dated 20090327 (newer) in the form of C source
(came with TCS3/LoCosto source).  Well, OK, for the sake of
completeness we also have a third version, the one from TSM30, also in
full source form, but it dates from 2003 and has been heavily mutilated
by Purple Labs who did not like TI's fw architecture and changed it to
their own.  Prior to the discovery of the LoCosto/Peek leak (back in
early 2013 when FreeCalypso was no more than an idea and a cute name)
I was looking at the TSM30 version as the only available C source to
replace the blobs, but once we found the LoCosto version, TSM30 became
unnecessary.  The TSM30 source did help a little bit in the
reconstruction of TCS211 L1 where we needed to reverse TI's
Calypso->LoCosto changes, but G23M is chipset-independent, thus in the
case of G23M the full C source version from 20090327 is the only one
we need, no need to even look at the TSM30 version from 2003.

The 20090327 version of G23M is used in Citrine and in the TCS2/TCS3
hybrid config of Magnetite, and the current official status of both
firmwares is still "experimental, not for production use".  The
20070608 all-blobs version of G23M is used in the classic and l1reconst
configurations of Magnetite, and this is the version that is currently
considered fit for production use, thanks to having been proven for
the latter kind of use by Openmoko.  Obviously a major goal of the
FreeCalypso family of projects is to have a fit-for-production-use
firmware version that is blob-free, but this goal has not been
achieved yet.

The next step on the road to blob-free, fit-for-production-use fw is
to thoroughly exercise the TCS2/TCS3 hybrid config of Magnetite, shake
out its bugs (no known major ones, but probably a slew of little ones)
and get to a point where it can be used with confidence in the place
of the currently-stable l1reconst config that uses the 20070608 blob
version of G23M.  I created this TCS2/TCS3 hybrid config in Magnetite
and proved it basically working back in the fall of 2016, but further
work on this version was paused until we have proper hardware.  Now
that we finally do have proper hw in the form of FCDEV3B, it is now a
good time to start exercising this TCS2/TCS3 hybrid config and
comparing against the stable l1reconst version.

Who can do the above?  I am still busy with FCDEV3B hardware and
calibration issues and not really available for sw/fw work, Serg has
his own project (a specialized application of FreeCalypso hw and sw),
but we also have one more community member with developer
qualifications: Das Signal.  He does not have an FCDEV3B yet, but I am
in the process of preparing a board to send to him, and when he gets
this board, it is possible that he might be able to help us a little
on the sw/fw side of things.  And if not DS or Serg, then I'll tackle
it myself at a later time after I'm done with FCDEV3B hardware and
calibration issues I'm currently working on.

Hasta la Victoria, Siempre,
Mychaela aka The Mother
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Power supply for FCDEV3B

[Mychaela Falconia]

For those of you who already have an FCDEV3B or are expecting one, I
have what I believe to be the perfect power supply for it: Keti
SA06-8S03R-V, apparently also known as SA06-8S036-V-A2R.  I was lucky
to find this PS back in 2015-08 when I scored an original TI D-Sample
kit which needs battery-emulating power just like our FCDEV3B, and I
bought one of these power supplies at that time; later I bought
another 10 in 2016-05.

This power supply is a small brick (about 9x5x3.5 cm), it takes AC
mains power in (full international range) through the same type of AC
entry connector as on desktop PC power supplies, and the output is
3.6 VDC rated at 2.2 A.  The DC output is on a directly attached cord;
this cord originally terminated in a round plug, but I cut those round
plugs off and installed Weidmuller 171633 connectors in their
place, to mate with Weidmuller 151046 on the FCDEV3B or on TI's
D-Sample, Leonardo and earlier boards.

The only problem with these power supplies is that I have not found
any place to get more of them: neither the place where I bought my
first nor the place where I bought the other 10 has them listed any
more. :-(  These power supplies are only needed for development boards,
they won't be needed for complete phones or other potential commercial
products we've been considering, so their shortage won't affect our
ability to build complete phones or other commercial FreeCalypso
products in volume, but if we get a significant demand for our
development boards (from hackers/tinkerers and whatnot), we won't be
able to provide our users with convenient power supplies unless

(a) we can find more of these Keti power supplies somewhere, or

(b) we custom-order some power supply manufacturer to custom-make a
big batch of similar power supplies for us, already with the right
connectors in this case.

The 10 Keti power supplies I currently have are reserved for the most
active FreeCalypso developers and supporters of our project, and they
have already been fitted with Weidmuller connectors for our FCDEV3B.
One of these power supplies will accompany the board that is going to
Das Signal.

If anyone happens to know of some other suitable power supply option
that is comparable to these Keti ones in terms of compactness and
convenience, please post here!

Hasta la Victoria, Siempre,
Mychaela aka The Mother
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community