freerunner & fc-host-tools-r8

[Mychaela Falconia]

Hi David!

> There is no need to stop qtmoko running, the crucial thing to getting the
> loadtool prompt is joggling the values in the download and power_on files;
> on qtmoko these are in the /sys/bus/platform/devices/gta02-pm-gsm.0/
> directory. In normal operation these files contain 0 and 1 respectively. I
>
> The trick is to connect up with the unlock cable and in this order:-
> 1. put 0 in the power_on file
> 2. run fc-loadtool -h gta02 /dev/ttyUSB0
> 3. put 1 in both power_on and download files
> at which point you'll get a loadtool prompt. It's doable even without an
> ssh connection over usb although you may find that makes it a little more
> convenient.

My first thought was "how can this work if QtMoko still holds the
modem's ttySAC0 serial port open", but then I realized what the trick
is: when the modem is power-cycled (which is what happens when you
write 0 then 1 into the power_on "file", which is really not a file
but a sysfs hook into the kernel driver), the Calypso boot ROM listens
for interrupt-boot characters on both UARTs, and if an interrupt-boot
sequence is received on the IrDA (headset jack) UART where it is being
sent by fc-loadtool running on the external host, all further
communication happens through that IrDA UART, and QtMoko running on
the AP will be left wondering what happened to the GSM modem which it
thinks should still be running normally.

I personally still prefer the U-Boot method (going through NOR U-Boot
on GTA02 or NAND U-Boot on GTA01 devices for Calypso flashing
operations), as it is *completely* independent of whatever distro or
other software the user prefers to use for regular operation, but if
the QtMoko-based way works for you, use whatever works. :)

However, in your step 3 above, you should write 1 into the download
"file" first and then write 1 into the power_on "file" in this order:
this way the IrDA UART to headset jack channel will be solidly
connected when the Calypso boot path is executed.

> Finally a query about those host tools - I'm not sure which if any are
> expected to work with non freecalypso hardware.

I assume that what you really meant in this context is which tools are
useful with Openmoko devices, not "non-FC hardware" in general: the
tools which are needed for working with Mot C139 and other C1xx phones
are clearly documented.

When it comes to Openmoko devices, the query needs to be further
refined as which tools are useful for someone who needs his or her OM
GTA0x device to keep functioning as a useful phone.  In pure hardware
terms, Openmoko's modem is very similar to TI's Leonardo board (from
which it was derived) and to our FCDEV3B (which was derived from OM's
modem), and can be used (although not as conveniently as a proper
development board) for all kinds of development and tinkering on both
baseband and RF sides - but it stops functioning as a useful phone in
such development and tinkering usage.

The only FC host tools that are useful to a FreeRunner user who needs
their device to keep functioning as a phone are:

* fc-loadtool for flashing new FreeCalypso modem fw images;

* rvtdump for capturing the debug trace from the modem fw as it runs
in normal operation: if you encounter a problem which you believe to
be the modem's fault, I will ask you to capture this debug trace and
send it to me for analysis;

* rvinterf and fc-shell for more advanced debug scenarios in which it
may become necessary to not just passively capture the traces that are
emitted by default, but to enable some additional ones;

* fc-fsio and its rvinterf back end for making minor edits to the FFS
(flash file system) portion of the modem, which is separate from the
firmware portion:

- changing the IMEI if you have some need to do so (but please only do
it if you have a real need, please don't do it "just for the heck of
it" - just because you can doesn't mean that you should);

- completely optional, only if you are a perfectionist, fixing the
/gsm/com/rfcap file to reflect the true hardware band configuration of
your device (tri900 or tri850) instead of the "I am quadband" lie
written there by moko11 and earlier firmwares;

- also optional, for perfectionists only, writing a /aud/para0.vol
file into FFS to accompany OM's factory-programmed /aud/para0.cfg, so
that OM's long-broken AT at AUL="0" command will start working: see my
moko-fw-history.txt write-up, the section titled "OM's AT at AUL brokenness"
starting at line 777.  Fixing and activating this para0 audio config
will have the effect of setting up OM's FIR filter coefficients in the
voice downlink path, but I have no idea as to this FIR filter's merit
or lack thereof.

> In particular the User-phone-tools look interesting, but I had no luck there.

FC User Phone Tools *can* work just fine with Openmoko's modem, but
not in any useful way.  If you need your FreeRunner to function as a
phone, you need to have some program (like QtMoko) that runs on the AP,
maintains constant communication with the modem and notifies you of
incoming calls and SMS by lighting up the screen, showing the incoming
call or SMS and playing some ringtone.  If you try to use FC User Phone
Tools for SMS, that operation will conflict with whatever SMS handling
is implemented in your user distro (QtMoko etc), and you won't get any
good out of it.

Right now these FC User Phone Tools are only useful either with a
standalone modem board (FCDEV3B) or with a FreeRunner that is used as
if it were a standalone modem board (*without* QtMoko or other modem-
interfacing software on the AP), which implies giving up its function
as a phone.  One can make a very valid argument that the name "User
Phone Tools" is utterly wrong and misleading in this case, which is
true for the currently existing hardware options, but these tools will
become true User Phone Tools when used with a FreeCalypso dumbphone,
which can be brought into being in one of two ways: (1) if I build my
desired FC Libre Dumbphone hw, or (2) if some other community member
can overcome their fear of C programming in the FC firmware environment,
take the massive work I've already done toward making an FC Libre
Dumbphone Lite out of a Mot C139 hw unit, and bring it into a usable
state.

For anyone who likes the idea of making an FC Libre Dumbphone Lite by
way of aftermarket fw on Mot C139 hw, it would still be in your
interest to support my work of making my own FC handset board, at
least in the bare board phase without any expensive plastics: as soon
as I have this desired hw (but not before!) I will be able to do a
massive cleanup of the proof-of-concept UI code we've inherited from
TI, and after this code cleanup anyone who wishes to work in the C139
Libre Dumbphone Lite direction will have a *much* better starting point
than what we have currently.  Right now the UI code exists only in
Magnetite and not in Selenite, and the structure of Magnetite fw is
not friendly at all toward other-than-me aspiring developers.  We will
need a Selenite-like firmware (to be named after some other gem) with
handset UI components included in order to have a sensible platform
for aspiring developers seeking to take it in different directions,
and I will able to produce such a firmware tree as soon as I have my
desired hardware, but not before - right now I lack a suitable hw
platform.  (The alternative to building my desired FC handset board
would be to obtain a copy of schematics for TI's D-Sample board and
the missing tpudrv10.c Clara RF driver code, but building our own hw
is a lot more certain than trying to get unobtainium documentation and
code.)

In turn, anyone who would like to speed up the development of our own
FC handset board can bring the timeline forward a little bit by
donating 3 kUSD right now.  The issue at hand is sequentiality: I need
to build FCDEV3B V2 boards before I can proceed further with the FC
handset board and its other prerequisites, and a budget of about 3 kUSD
is needed for FCDEV3B V2 as the immediate next step.  The design files
for FCDEV3B V2 are done, all of the needed parts are physically in my
hands and already paid for, and the next needed step is PCB fabrication,
which needs the ~3 kUSD budget.  According to my current forecast of
my personal finances, I hope to be able to cover this cost on my own
around the beginning of September (but this is only a forecast, not a
guarantee!), thus if someone else can donate the needed money right
now, the timeline will be sped up by one month.

Hasta la Victoria, Siempre,
Mychaela aka The Mother