moko13-beta1 firmware release candidate

Tue Aug 8 08:08:13 UTC 2017

Hello FC community,

While my primary interest is in making and selling new FreeCalypso
modem hardware products, I also feel a social responsibility to
provide continued support for the embedded GTA0x GSM modems made by
our predecessors at Openmoko, hence the present firmware release:

https://www.freecalypso.org/members/falcon/experimental-builds/moko13-beta1.tar.bz2

The mokoN firmware release schedule has definitely slowed down: the
interval between moko10 and moko11 was only a few months, but the
interval from moko11 (early 2009) to moko12 (late 2013) was over 4 y.
It has now been almost another 4 y since moko12, hence it is about
time for moko13.

Following the tradition established by my predecessors in Openmoko's
modem fw department, I am releasing the new firmware initially as
moko13-beta1, to be tested; if the test reports indicate that it is
good, the -beta1 designation will be dropped and the new fw will
become the official moko13.

Differences from previous mokoN fw versions that are potentially
visible to or may affect the end user:

* Some time in between moko8 and moko10 (there was no moko9 except
  -beta1) TI's support group sent OM a patched version of a pair of L1
  binary libs in a misguided attempt to fix the infamous bug #1024.
  The bug was later found to be purely in the hardware, without any fw
  component to it, and there is absolutely nothing that the modem fw
  can do to fix or even ameliorate the problem.  Given the just-stated
  fact, whatever TI-Taiwan did in that patch can only be a misguided
  change based on a misunderstanding of the problem, yet this L1 patch
  ended up being included not only in the moko9-beta1 build made as a
  test to see if it makes any difference, but also in the production
  moko10, moko11 and moko12 firmwares.

The new moko13 firmware build uses the deblobbed version of L1, i.e.,
the L1 component is now recompiled from the reconstructed C source
instead of the binary libs sans source used by the previous mokoN
versions.  The reconstructed C source matches the original 20070608
version of L1 (used in moko3 through moko8), without TI's support
patch from 20080421, thus the latter patch has effectively been
reverted in moko13.  Further notes about the reverted L1 patch:

* Because the patch originated as a misguided attempt to fix a pure hw
  problem that cannot be fixed or ameliorated in any way by anything
  on the fw side, it should have never been applied in the first place
  beyond the experiment proving that it did nothing, thus I do not
  anticipate any problems with it being reverted.  I have been running
  all of my tests on multiple targets (GTA02, FCDEV3B, C139, Pirelli)
  with the patch-reverted version of L1 for a long time without any
  problems.

* We have strong evidence that the patch from 20080421 was done in a
  special "customer support hacks" branch and never went into TI's
  mainline: the LoCosto (TCS3.2) version of L1 which we used as the
  starting point for our reconstruction turned out to match the
  20070608 original rather than the 20080421 patch after reverting
  the Calypso->LoCosto chipset changes.

* We don't know exactly what is in that 20080421 patch because it is
  in binary object form rather than source.  Anyone interested will
  need to analyze the differences in the disassembly.

Other potentially user-visible or user-affecting differences from
previous mokoN firmwares:

* When the Calypso is used as a basic modem like in the GTA0x, most of
  its peripheral interface signals are unused, and typically left
  unconnected in the hardware.  Previous fw versions configured many
  of the unconnected GPIO and multifunction pins as inputs, resulting
  in floating inputs.  Standard hw engineering wisdom says that
  floating inputs are generally bad.  The new fw configures all unused
  and unconnected GPIOs as well as the unused and unconnected
  DSR_MODEM/LPG signal as outputs instead, eliminating the floating
  input situation.

* In the process of deblobbing the init module a bogon was discovered
  (which existed in all previous fw versions) that configured the IO1
  output (output, not input!) to also act as an interrupt source.
  This bogon has been removed.

Changes visible only to developers who use the debug trace interface
provided on the headset jack, and I mean use it to talk to the fw as
it runs, rather than just for flashing:

* An additional AT command channel is provided over RVTMUX, in addition
  to the standard one going to the phone's AP.  This mechanism makes
  it possible to exercise the modem to a large extent from an external
  host with no working software on the FreeRunner itself except U-Boot.

* The FFS access protocol has been changed from TMFFS1 to TMFFS2.  The
  new protocol is supported by our fc-fsio GSM device file system
  manipulation utility, but some old Windows tools that must have been
  used by Openmoko (of which I never found a copy, thus it is not
  known for certain if this sw still exists anywhere at all or not)
  may stop working.

* TI's GPF misfeature that suppressed the responses to "system primitive"
  commands has been fixed: if you send an sp command through fc-shell,
  you'll get the expected response as per GPF documentation.

The developer-visible features listed above have been standard in
FreeCalypso for the past two years and are now taken for granted when
doing any FC work, but they had not made their way into a mokoN fw
release until now.

For FCDEV3B users: all of the functional features of moko13 listed
above (with the exception of those specific to Openmoko's hw wiring
where it differs from ours) are also present in the standard production
fw for the FCDEV3B (i.e., fw that the next batch of boards will ship
with), but the actual fw images are different: please don't try to
flash an image built for one target into a different one!

Firmware version identification: in common with FreeCalypso firmwares
for other targets, fw versions from moko13 onward no longer return a
hard-coded fw version ID string in response to AT+CGMR, instead the
AT+CGMR response will look like this:

GTA02BV4/FreeCalypso

where "GTA02BV4" is the hardware revision string programmed into FFS
by OM's factory.  To distinguish between different FC firmware
versions, you will need to issue TI's non-standard AT%VER command.  It
used to return a fairly long response giving separate version strings
with build timestamps for each component of the G23M PS (and limited
to just G23M PS and not other fw components), but the new FreeCalypso
AT%VER response is much more sensible, a single line like this:

FreeCalypso Magnetite l1reconst, build date 2017-08-08T02:47:30Z

Each FreeCalypso fw image from now onward (at least on the
Magnetite->Selenite main line, dunno what will happen with Citrine,
see my previous post) has an automatically generated timestamped ID
string of the above form, and this firmware build ID can be found in
three ways:

* Doing strings on the firmware binary;
* Watching the modem's debug trace output (on the headset jack serial
  port in the case of OM hardware) as it boots;
* Querying the modem with AT%VER.

Labels like "moko13" and "moko13-beta1" are strictly for community
reference and do not actually appear anywhere in the fw image itself;
as a Kantian thing-in-itself, the present fw image is just
FreeCalypso Magnetite l1reconst, build date 2017-08-08T02:47:30Z.

Production firmware release tarballs are just binaries; the
Corresponding Source for each binary fw release is simply a given Hg
commit in the fc-magnetite repository; an ASCII note in the tarball
with each binary release will indicate exactly which Hg commit ID is
the Corresponding Source.

I considered the idea of doing "all targets" firmware releases, i.e.,
having each release be a source snapshot tarball along with binaries
for each supported target and config (l1reconst vs. hybrid etc) built
from that source, but rejected that approach for practical reasons.

In an arrangement where the same source tree supports many different
targets and configs (which is what we have in FC Magnetite) what
typically ends up happening is that a bunch of development will occur
that affects a given target (e.g., GTA0x only or FCDEV3B only) or a
given config (e.g., hybrid only); meanwhile the firmware for other
targets and configs will have no effective changes except a different
build timestamp and possibly some internal rearrangement of no
functional impact.  To me it makes no sense to ask users to reflash
their fw to a "new" version that differs only in timestamps or some
invisible internal rearrangement, thus I decided to make binary
releases of the fw for specific hw targets in specific configurations
as dictated by developments relevant to that target config.

Hasta la Victoria, Siempre,
Mychaela aka The Mother