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
