moko13-beta1 firmware release candidate

[Serg l]

Thank you for the update. I concur with the idea of binary releases for
specific targets. We could keep the rolling release for the source and just
tag where we cut specific binaries.
Just wondering, did you have a chance to run "make -j 2" for Magentite
builds? It runs way faster than linear make, keeping Wine environment from
dying after each source file. I ran MD5 checksum on the resulting binary
and it was different than produced in the linear build, but I didn't dig
into specifics.

On Tue, Aug 8, 2017 at 4:08 AM, Mychaela Falconia <
mychaela.falconia at gmail.com> wrote:

> 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
> _______________________________________________
> Community mailing list
> Community at freecalypso.org
> https://www.freecalypso.org/mailman/listinfo/community
>