baseband-devel April 2014

baseband-devel@lists.osmocom.org

14 participants
31 discussions

Error: no such instruction: `eor %edx,%r15d,%r15d,ror'

by Ahmad Jan

Hi... I m trying to install osmocom-bb using following link: http://bb.osmocom.org/trac/wiki/Software/GettingStarted First of all i installed the Dependencies for the host. Then for target dependencies, i build my own toolchain using following: http://bb.osmocom.org/trac/wiki/GnuArmToolchain This toolchain building processes ended up saying: "Build complete! Add /home/arslan/dir/install/bin to your PATH to make arm-elf-gcc and friends accessible directly." (i don't know building my own toolchain is necessary or not). Then i went back for building osmocom-bb There i came across getting and updating the source. But in building the source section, what it says is: " Compiling both the target and the host code will happen with the following command. It assumes that the *arm-elf-gcc* is* inside the current path.*" I didn't understand it as my current path is osmocom-bb and there is no arm-elf-gcc Can anyone tell me what does it mean? Anyways, i just ignored it and went on executing the following command cd src/ make So i ended up with an error saying: /home/arslan/osmocom-bb/src/target/firmware/include/asm/swab.h:32: Error: no such instruction: `eor %edx,%r15d,%r15d,ror' make[4]: *** [gsmtap_util.lo] Error 1 I tried to figure it out from Internet. It really didn't work out. M stuck at this point. Can anyone help me resolving this problem?

11 years, 2 months

Re: Accessing the firmware of osmocom-bb compatible phone

by msokolov＠ivan.Harhan.ORG

Ahmad Jan <e10007a(a)gmail.com> wrote: > But is this possible (using osmocom-bb) to modify phone's original > firmware, compile it and then reload it back in to the phone to work > according to modification? Sure, you can take a flash dump as I described, make patches to the firmware binary code with a hex editor, then flash the modified image back into the phone. But that is not what you are asking for, is it? It seems to me that what you are really after is the *source* for the original firmware of, say, Motorola C1xx, or Pirelli DP-L10, right? Well, the problem in this case is that I don't know of anyone who has a copy of such sources, and there is a strong possibility that, as happens regularly with most proprietary abandonware, these sources, which existed inside the walls of Compal and Foxconn almost a decade ago, may have been lost altogether, went to the great bit bucket in the sky. I am, however, pursuing a project seeking to put together a new firmware for Calypso-based "dumbphones" that would function just like the original proprietary fw, intended for using the phone "normally" as an everyday phone, unlike OsmocomBB which is intended for hacking and security research instead. FreeCalypso is the name of my project, and it's being developed in this Mercurial repository: https://bitbucket.org/falconian/freecalypso-sw FreeCalypso does not have its own mailing list or home page yet, unfortunately. VLR, SF

11 years, 2 months

Re: Accessing the firmware of osmocom-bb compatible phone

by msokolov＠ivan.Harhan.ORG

Ahmad Jan <e10007a(a)gmail.com> wrote: > By using osmocom-bb, is this possible to access the firmware of osmocom-bb > compatible phone? Do you mean using osmocom-bb tools to read the phone's original fw and other flash content? Yes, I've used osmocom-bb tools to do this task before I wrote my own fc-loadtool to do it my own way, and using osmocom-bb tools is currently the only way to read Compal's flash - my FreeCalypso tools currently support only Openmoko and Pirelli phones. > If yes, then how? When you run osmocon, specify an appropriate loader.* target code image instead of layer1.*. Then open another terminal window and run osmoload memdump. HTH, SF

11 years, 2 months

Accessing the firmware of osmocom-bb compatible phone

by Ahmad Jan

By using osmocom-bb, is this possible to access the firmware of osmocom-bb compatible phone? If yes, then how?

11 years, 2 months

Re: strange crashes in current main branch

by Tim Ehlers

On Sun, 6 Apr 2014, Christophe Devine wrote: Hi Christophe, > A year ago, you reported strange crashes in current branch. Did you > resolve the issue? It seems we are having a similar problem, where > layer1 would crash eventually. yes, I tracked it down to the charging code. I think it comes from the fact, that layer1 is periodically polled by layer23 (mobile) about the current battery-status. And there seems to be a problem with queueing these things over the serial line. So if battery-status is polled and other things are going through serial at the same time, layer1 crashes eventually. Thats my interpretation, but fact is, if you revert the patch attached to the mail, the crashes are gone, but you can't charge. :) I modified the mobile battery, removing the battery itself, and replacing it with a 3.7V AC-Adapter, so that I don't need the charging. Maybe you can investigate it in more detail? Or better I send it to the list too, so the problem could be discussed in the big round again. Best Tim

11 years, 2 months

Re: Motorola C139 V1.9.24 Won't Load from osmocom-bb

by Rusty Dekema

>> Is it "official" PCS1900 support, or are you seeing some of the >> received RF energy in the PCS band (in a very strong signal area, >> presumably) seep through the imperfect 1800 MHz SAW filter with the >> antenna switch set to DCS? My apologies for the blank message which went out a moment ago; that was a mis-click on the send button. I have found that the PCS1900 support on this C123 is sufficient to run the phone as a BTS using layer23/transceiver (with some code edits). PCS1900-only handsets in the same room can connect and exchange SMS/USSD messages when the C123 is operated in this manner. Using layer23/mobile, the C123 sees a PCS1900 control channel. When I try to camp on that channel, the host (PC) side of layer23/mobile segfaults, and I have not yet attempted to debug this. But it seems reasonable to expect that the phone would be able to camp on that cell were it not for whatever is making it crash. For what it's worth, on a standard PCS1900 phone, this particular control channel in the location where I am testing shows an RSSI somewhere between -87 and -97 dBm. On the C123 running layer23/mobile, it is usually closer to -97 dBm, but it seems like there should be more attenuation than that if it was passing through an imperfect 1800 MHz filter (at least, I would think). Another thing I intend to try (if I can) is to change the C123's menu language from Chinese to English, and then see if its built-in software can camp on the PCS1900 cell in question. Cheers, Rusty D

11 years, 2 months

Re: Motorola C139 V1.9.24 Won't Load from osmocom-bb

by msokolov＠ivan.Harhan.ORG

Rusty Dekema <rdekema(a)gmail.com> wrote: > Although I would still like to eventually get a C139 working (mainly > for its 850 MHz support), Given your interest in the 850 MHz band, I gather that you must be somewhere in North America. Anywhere near Southern California perchance? > I obtained a C118 yesterday and it works > with osmocom-bb like a charm, right out of the box. (It also has at > least some support for the PCS1900 band, which was a pleasant > surprise.) Is it "official" PCS1900 support, or are you seeing some of the received RF energy in the PCS band (in a very strong signal area, presumably) seep through the imperfect 1800 MHz SAW filter with the antenna switch set to DCS? > Now, back to the C139. If anyone has any further suggestions, please > let me know. If all else fails, I reason that one should be able to disassemble the phone, desolder the flash chip, reprogram it with a known good boot- loader using a standalone device programmer, then solder it back onto the board. But I'm guessing that flash chip is probably a micro-BGA (IIRC it's a flash+pSRAM MCP), so it wouldn't be a home soldering job, but rather something to be sent to a professional lab. If you fancy going down that road, I would suggest talking to Technotronix in Anaheim, California - ask for Gopal, and tell him you were referred by Michael S. from Harhan. > The phone never sends a PROMPT1 for reasons discovered later and > described above. Yup, a definite indicator that the bootloader our tools need to talk to has been removed in the firmware version in your phone, just like in Tracfone's version. > Yes, it's definitely 1.9.24 both on the sticker and the #02# screen. Thanks for the info about the #02# screen, I didn't know about that one before. > When I run the mot931c program, follow the directions, and click > Unlock, I get the output: "Error 2" followed by "Phone not found". Of > note, if I unplug the phone from the computer and do the same, I get > only the "Phone not found" message. Then again, the title of the > mot931c application is "Tracfone mobile unlock 1.0 by Lawer," After I made my previous post, I did run that mot931c program under wine with the Tracfone connected, and it did reflash that phone with a bootloader that is compatible with osmocom-bb/DMTool/fc-loadtool etc. Unfortunately I failed to capture the bytes exchanged between the Weendoze program and the phone - trying to run wine under strace was a little too much for me. So now I need to get another Tracfone C139 from ebay, and be more careful this time.. I'm thinking about hacking the Linux kernel driver for the USB-serial chip in my cable (the PL-something) and making it log the Rx/Tx activity into a RAM buffer which I would then read out - an incredibly ugly hack, but one that would be more within the range of my skills, as compared to instrumenting wine... > and mine is not a Tracfone. Would you mind telling us which branding it is? It seems that Cingular units have bootloaders that work out of box, for Tracfones there is another method that has been proven to work, so what other brandings are out there? > > It should be noted that the new bootloader is very limited (no charging, no > > loading of the regular phone os). It appears that what this tool does (at least on Tracfones with V8.8.17 firmware) is it erases and rewrites the first 64 KiB sector of the flash. The new bits written into this sector appear to be contained as a 65536-byte payload within the mot931c.exe binary; and it looks like whoever wrote this tool replaced the first 8192 bytes with a "good" C139/140 bootloader, while leaving the remaining 56 KiB unchanged from V8.8.17 firmware. So the phone ought to retain its firmware unchanged, but gain the ability to break into the bootloader like we are used to doing. But apparently the firmware checksums itself, as doing a normal boot (w/o serial download) results in a message on the LCD (with the backlight off, so hard to read) about the firmware being corrupted or something to that effect. > The DLTool/"DM Tool" software in this package does not seem to be able > to "see" or communicate with the phone. Which is not surprising at all, as this tool (appears to be Compal's official flasher) connects to the phone in the same manner as osmocon -m c140xor, so one doesn't work, neither will the other. > Perhaps this is not surprising, since the > mot931c tool was not able to "unlock" whatever it was supposed to > unlock on this phone. See above - that mot931c tool doesn't really "unlock" anything, it simply rewrites sector 0 of the flash with a "good" bootloader. VLR, SF

11 years, 2 months

Re: Motorola C139 V1.9.24 Won't Load from osmocom-bb

by msokolov＠ivan.Harhan.ORG

Christophe Devine <devinechristophe(a)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=shari… 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

11 years, 2 months

Motorola C139 V1.9.24 Won't Load from osmocom-bb

by Rusty Dekema

Greetings, I have a Motorola C139 handset with SW Ver 1.9.24 and a CP2102 USB/UART adapter, which I hope(d) to use with osmocom-bb. In Ubuntu 13.10 (running on [non-virtualized] hardware with an Intel i5-750 CPU), I compiled the toolchain, prerequisites, and osmocom-bb, but when I run the following command (and then briefly press the phone's power button) : ./osmocon -p /dev/ttyUSB0 -m c140 ../../target/firmware/board/compal_e86/loader.compalram.bin I get the following output: got 7 bytes from modem, data looks like: 66 74 6d 74 6f 6f 6c ftmtool Received FTMTOOL from phone, ramloader has aborted got 1 bytes from modem, data looks like: 65 e got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 72 r If I briefly press the power button repeatedly, I receive similar output. I would greatly appreciate any suggestions as to how I might be able to coax this into working. Thanks, Rusty D

11 years, 2 months

An OsmocomBB-compatible phone as transceiver for OpenBTS

by Ahmad Jan

I was going through different pages of osmocom-bb when i came through that statement: "The following how-to will guide you through the steps needed for using an OsmocomBB-compatible phone as transceiver for OpenBTS." on the following page: http://bb.osmocom.org/trac/wiki/Software/Transceiver As i have running OpenBTS on USRP1 board with 2 RFX900 daughter boards as Tx & Rx. I really didn't understand the meaning of the statement i mentioned above. What does it mean? Can anyone help me out?

11 years, 3 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel April 2014