Flashing

Thu Aug 22 16:06:04 UTC 2019

> I understand, but complexity is unavoidable in almost everything

I disagree in the case of phones: smartphones with separate application
and baseband processors (like Openmoko) did not exist until 2007 or so,
back in the late 1990s and early 2000s we all happily used dumbphones
which had just one processor inside (very similar to our beloved
Calypso) and which performed just basic telephony functions (make and
receive calls, send and receive SMS) without any smarts.  I simply
continue to live my life the same way how everyone else lived 15 y ago
or so, using dumbphones instead of smartphones, and will continue
living this way until the day I die.

> and most things can't be reverse engineered if made proprietary.

The Pirelli DP-L10 phone which I use currently is proprietary indeed,
but:

1) It has the exact same Calypso chipset inside as my desired but not
yet built dream phone, so I *can* run my own code on this phone to a
limited extent, I can backup and restore its flash etc.

2) Pirelli's proprietary fw is based on the same TCS211 starting point
from TI as Openmoko and FreeCalypso, thus wherever they left things
unchanged from TI, we have the freedom to hack.  Pirelli's fw still
uses TI's RVTMUX interface and freely exposes it on the phone's
built-in USB-serial port, so we can connect to it, Pirelli's debug
trace output is unchanged from TI, so we can parse and read it, their
flash file system format is unchanged from TI, so we can parse and
understand flash dumps, and they even support TI's TMFFS2 protocol
over their exposed RVTMUX, so we can manipulate their file system
"in vivo" with our fc-fsio tool.  All of these qualities are the
reasons why I use this Pirelli DP-L10 as opposed to any random
proprietary phone.

> So if I understand correctly the following change log part doesn't apply
> anymore?
>
> "moko13:
>
> This release has been made in order to bring Openmoko devices up to date
> with the recent FreeCalypso developments.  Because FreeCalypso is a
> living and actively maintained FOSS project unlike OM's proprietary fw,"

What makes you think that it no longer applies?  The first sentence
which says that moko13 was made in order to bring OM devices up to
date with recent FC developments is a historical fact: the year was
2017, we had successfully built our own FreeCalypso modem hw product
(FCDEV3B), we had our current FC Magnetite fw built for the fcdev3b
target, but the latest fw for the gtamodem target was still the
ancient-by-then leo2moko-r1 aka moko12 from 2013 - hence the moko13
release was made to bring the gtamodem target up to date.

The second sentence in that change log entry refers to the other
historical fact that back when Openmoko-Inc existed, they treated
their modem fw as proprietary, zealously guarded their source, and did
not allow people like me anywhere near.  The people whom they did hire
to work on their firmware behind NDA castle walls were nowhere near as
good as me, hence their firmware sucked.  The liberation of the
formerly proprietary Calypso modem fw happened in 2013, by that time
Om-Inc no longer existed, and their last fw release from 2009 (moko11)
had been aged 4 y with no maintenance or support.

Right at the time of the liberation back in 2013, I made the
leo2moko-r1 aka moko12 release which was basically a clean
recompilation (moko11 was miscompiled in that it contained some stale
objects which didn't get recompiled to account for shifted enum
constants - they changed a header file, but there was no make depend
and they forgot to recompile some objects) with just two of the worst
bogons (the rfcap bogosity and AT at SC) removed.  Then it took me
another 3 y period from 2013 till 2016 during which I tried some
failed approaches before I finally came up with what I named
FC Magnetite, which is our current unified source tree in which all
development happens and from which we make builds for different
targets.  What I was basically saying in that change log entry is that
our current development model based on the FC Magnetite Hg repository
and multi-target build system is a far cry from the proprietary
development model employed by Om-Inc when that company existed.

> Is there a significant technical improvement I need to be aware to
> consider flashing the fw?

I posted a little bit of description on the mostly-dead OM community
mailing list back in February:

http://lists.openmoko.org/pipermail/community/2019-February/069854.html

The fix for the floating inputs was already there in moko13 (but not
in the truly ancient moko11), whereas the sleep mode improvements are
new with the 20190128 version.  Other aspects to consider are:

* Moko13 was the last release built with the legacy 2007 blob version
of the G23M protocol stack.  When OM got their firmware baseline
delivery from TI, they got this G23M PS component in binary-only form,
and at the present time there exists no surviving copy of the
corresponding source for that 2007 G23M PS version, so it is binary
sans source.  Around 2018 we made the switch to the new hybrid config
in FreeCalypso, and this hybrid config is built using a newer 2009
version of the G23M PS (a version which OM never got - we got it from
a different source), and this newer version came as 100% genuine C
source from the beginning.  It took us till 2018 before we could
switch our production fw to this new version because hybridizing this
newer PS version with the solid TCS211 chipsetsw foundation was a very
non-trivial accomplishment, and it took us that long to shake the bugs
out.

* Moko10 through moko12 contain a bad version of L1, hacked up by
someone in TI-TW's support department who had no clue what they were
doing, in a misguided attempt to fix bug #1024.  Our current firmwares
use L1 which we compile from reconstructed source, and our
reconstructed source matches the 20070608 version of L1.

It basically comes down to which version you would rather run: a
version built by IP zealots who cared more about copyright and NDA
compliance than about technical quality, or a version built by a
professional GSM engineer who works transparently in the open.

> Have to make a paypal account to buy it and don't like running proprietary
> JS, but if there are significant improvements so be it.

Hmm, I suppose I could buy a small batch of cables from Sysmocom and
then resell them in a non-Paypal-requiring way.  Would you be willing
to give me your snail mail address so I could send you a cable?  Would
you be able and willing to reimburse me for it via Bitcoin?

Also if you send me anything off-list using one of your anonymous Tor
email providers, I may not receive it - right now all I have is Gmail,
I do NOT have the energy at the moment to set up a better email system
(if you wanna change this situation, you would need to make a big
donation toward the cost of my SRS - that would be the only thing that
can sufficiently motivate me in my present circumstances), and Gmail
seems to seriously dislike your current elude.in setup - your post to
which I am replying never showed up in my inbox, I can only see it via
the Pipermail archive on the freecalypso.org mailing list server.

> T60 with Guix user here, so If I buy the cable can I work with:
> https://guix.gnu.org/packages/fc-host-tools-10/ to flash the GSM?

I am deeply philosophically against distro packagers, and I only
support people who compile and install FC host tools directly from the
official source tarball, not via any third-party packages.  If you use
a version that has been messed with by those people whom I don't
approve of, you are on your own and I won't provide any support as a
matter of principle.  Why can't you just download the official source
tarball, cd into it, run 'make' and then 'make install' like we all
used to do for many decades before those gawddamn packaging things
were invented?

> Be prepared to take a test about Dutch civics in Dutch at your local
> embassy if you want to immigrate.

Nah, too much trouble.  Instead I am hoping to be able to buy a
sysmoBTS 1002 unit after my big surgery (can't spend that much money
before then) and set up my own personal BTS for myself.  My thinking
is that I can run a spectrum analyzer across the PCS band, find an
unused ARFCN (or rather one with the lowest dBm level of non-GSM junk
on it), squat on it, and set my BTS Tx power low enough to where I
won't get caught.

M~