modem firmware

Mychaela Falconia mychaela.falconia at gmail.com
Tue Aug 29 06:33:03 UTC 2017


joerg Reisenweber wrote:

> Please carefully note that this update is not based on the original licensed
> firmware for Openmoko devices,

Your original licensed firmware has bugs in it; the updated firmware
has some of these bugs fixed.  Want examples?  Here are just a few in
no particular order:

* Your firmware configures many Calypso signals which are unconnected
in the hardware as inputs, resulting in floating inputs.  As an EE you
surely know that floating digital inputs are generally bad.  I even
found a document from TI specific to the chips in question that says
that such floating inputs can result in excessive current draw, wasting
the battery:

https://www.freecalypso.org/LoCosto-docs/SW%20doc/0002_4006_power_consumption_APN.PDF

* In April of 2008 some clueless moron at TI-Taiwan sent you a patch
for L1 in the form of a binary blob with mystery content that attempted
to fix the infamous bug #1024.  Later you figured out that it was a
hardware bug that cannot be fixed by firmware means, but even before
that realization you knew that TI's patch from 20080421 did not improve
anything, and you even knew that the patch in question was unofficial
from TI's perspective and had not passed TI's internal quality assurance
processes:

http://lists.openmoko.org/pipermail/openmoko-devel/2008-April/002582.html

Yet you included that bogus patch in moko10 and moko11, and unfortunately
I also kept it in moko12 (my first post-OM-Inc fw from late 2013) because
I didn't know any better back then.  In moko13 the bogon has been
removed, restoring L1 to the way it was in TI's baseline TCS211 firmware,
but even better, I have successfully reconstructed recompilable C source
that compiles into a bit-for-bit match to the original blobs, i.e.,
essentially the lost source which TI had wrongfully withheld from various
customers including OM has been reconstructed and We The People now have
the Corresponding Source to what used to be a bunch of blobs.

* A different clueless moron (this one had to be an employee of OM, as
the bogon in question is present in your code but not in TI's reference
version) has put in a "gem" in fw versions moko6 through moko11,
inclusive, that tells the RR (Radio Resource) layer of the G23M protocol
stack that the hardware is quadband, when it is only triband in reality.
As a result the fw will attempt to search for GSM cells in all 4 bands,
and you even posted on this list back in 2014 that you had a US-band
FreeRunner kinda-sorta-work in the 900 MHz band.

However, the factory production line calibration on GTA01/02 devices
was only performed for the 3 properly supported bands, not for the 4th
band, hence if the fw allows the use of that 4th band and the modem's
Rx tract manages to pick up a particularly strong signal that passes
through the wrong-band SAW filter, when the modem subsequently turns
its transmitter on in that band, it will be transmitting without
calibration.  When no calibration has been done for a given Tx band,
the fw will use its hard-coded values, but because you have always said
that you only got binary blobs and no source for that part of the fw,
I have every good reason to assume that those hard-coded values (which
are overridden by factory calibration values written into FFS for the
3 properly supported bands) are not correct for Openmoko hardware at
all, and were probably set up for some earlier TI board, most likely
Leonardo.  The RF tract on TI's historical Leonardo boards was quite
different from yours, including a different RF PA, hence when your
bogus firmware operates the modem in an uncalibrated band, the Tx
power levels are going to be wildly out of spec.  I will have some
actual measured dBm numbers for you in a few months when I save up the
money to get my CMU200 properly recalibrated by Rohde&Schwarz.

The firmware bug in question has been fixed in moko12 and moko13: these
newer fw versions no longer overwrite the /gsm/com/rfcap file in FFS
on every boot, so if you do a 'set-rfcap tri900' or 'set-rfcap tri850'
via fc-fsio as appropriate to your GTA01/02 hw variant, your correct
rfcap setting will stay, the modem will no longer waste time trying to
receive in the unsupported 4th band, and it will never act as an out-
of-spec transmitter in that 4th band.

> has not been checked and is not endorsed by
> original manufacturer Openmoko

And what exactly is the worth of an endorsement by the dead ghosts of
a no-longer-existing company that did a shitty job of supporting this
modem back when it was in business?

> and thus will void your device's (FCC/CE/...)
> approval

The fact that a modem running your official firmware that falsely
believes itself to be quadband when running on triband-calibrated hw
VIOLATES the actual technical specs for the transmitted signals can
only mean that the approval you got was fraudulent or at least
erroneous (the certification testers overlooked the technical spec
violation), and the actual radio operation of the modem with my fw is
in BETTER compliance with the specs than with your fw.

> thus rendering any operation of the device outside controlled self-
> contained lab environment illegal.

Yup, just like using hormonal birth control from an overseas pharmacy
without allowing a doctor to sexually violate you under the guise of a
necessary exam.  Laws like that are MEANT to be broken.

Oh, and on the subject of Openmoko IMEIs: unfortunately for you but
fortunately for the FreeCalypso community, your instruction to GTA0x
device owners to not participate in my survey came a little too late,
and I have already gathered all of the info I needed from the numerous
helpful off-list responses I got.

And yes, if I ever make a production run of new GTA02 devices verbatim-
identical to Openmoko-made ones (such that if you were given two FRs,
one made by OM and the other made by me, you would not be able to tell
which is which without looking at manufacturing dates and IMEIs and
such), they will most certainly be numbered from the same TAC 35465101
which you used for your GTA01 and GTA02 devices, and I already know
which number ranges are virtually certain to be unused.  You have
already violated the official rules of the IMEI registry by reusing
the GTA01 TAC for the GTA02 and even more seriously by using the same
TAC for 900/1800/1900 and 850/1800/1900 band devices, so you rebuking
me for making further reuse of that TAC for new production of very
faithful clones of your hw is the pot calling the kettle black.

Shitty regards,
Miss Mychaela

P.S. Yes, I know how to be a bitch when you leave me with no other option.

P.P.S. I am currently using Gmail (the personal mail server I had in
my old male life is down and will never come back up, and I have not
yet set up a new one for my new female identity), and there is some
problem between the elderly lists.openmoko.org server and Gmail, with
the result being that Gmail does not receive any OM list mail at all,
and I can only see list activity through the web archive.  I don't know
what will happen if you send me a unicast email from your openmoko.org
domain, but Gmail might blackhole that one as well, so if you ever feel
inclined to actually talk to me beyond just posting negativity on the
list, you might need to use a different domain.



More information about the community mailing list