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. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community