This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Michael Spacefalcon msokolov at ivan.Harhan.ORGChristophe Devine <devinechristophe at gmail.com> wrote: > I had a similar problem with a tracfone branded c139 (ftmtool error). I guess I was lucky that the first two C139s I got from ebay were the Cingular branded version, which has the classic Compal bootloader enabled. But I just opened the one that came in Tracfone packaging, and indeed the bastards have disabled this bootloader in TF firmware: it proceeds directly to the ftmtool crap, without ever sending PROMPT1 or pausing to check for a possible download. > On IRC, Hoernchen mentioned an older post where the author "fixed" the > bootloader. He also mentioned a pastebin that referenced a tool called > mot931c. I managed to find it and could successfully reflah my tracfone's > bootloader, which now loads osmocom-bb without issue. Here's the reuploaded > software package: > > https://drive.google.com/file/d/0ByHQWL5Q6bSwdkJReUlJWUQ1Z3M/edit?usp=sharing Thanks for sharing. I'm trying to understand how this works. It looks like with both Calypso and Compal bootloaders disabled, the only way to make the initial break-in on a TF C139 is through the firmware's RVTMUX interface. I have not yet tried running that mot931c.exe Weendoze binary under Wine; I've only run strings on it so far, and I saw the instruction to enter **16379#. Keying this magic incantation into a C139 or C140 (both TF and vanilla) yields a menu that allows switching the headset jack between headset and trace functions. Selecting trace causes the jack to be switched back to the UART (like it is on power-up), and looking at the data the running fw spits out, I see TI's classic RVTMUX interface, albeit at 57600 baud instead of TI's default of 115200. But this is where I get stuck: even though the interface is clearly RVTMUX and includes the ETM module (TI's Enhanced Trace Mode), none of the classic ETM command packets do anything. I get ETM packets back with the correct checksum, so I infer that ETM must be present in the fw, but all response packets I could get consisted of just a 0x0E error code octet instead of the expected ETM_CORE responses. Has anyone figured out just what this (presumably) closed source mot931c.exe binary sends to the phone? About to try running it under Wine, and if that succeeds, then strace... VLR, SF