From osmocom at ehlers.info Sun Apr 6 20:02:46 2014 From: osmocom at ehlers.info (Tim Ehlers) Date: Sun, 6 Apr 2014 22:02:46 +0200 (CEST) Subject: strange crashes in current main branch Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: revert-charging.patch Type: text/x-patch Size: 30978 bytes Desc: URL: From Max.Suraev at fairwaves.co Thu Apr 10 10:39:24 2014 From: Max.Suraev at fairwaves.co (Max.Suraev at fairwaves.co) Date: Thu, 10 Apr 2014 12:39:24 +0200 Subject: strange crashes in current main branch In-Reply-To: References: Message-ID: <534674DC.9070600@fairwaves.co> 06.04.2014 22:02, Tim Ehlers ?????: > 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. > Interesting - can you describe those modifications in more details? Which adapter have you used? How did you connect it exactly? Some pics? thanks, Max. From osmocom at ehlers.info Thu Apr 10 18:44:38 2014 From: osmocom at ehlers.info (Tim Ehlers) Date: Thu, 10 Apr 2014 20:44:38 +0200 (CEST) Subject: strange crashes in current main branch In-Reply-To: <534674DC.9070600@fairwaves.co> References: <534674DC.9070600@fairwaves.co> Message-ID: On Thu, 10 Apr 2014, Max.Suraev at fairwaves.co wrote: >> 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. > > Interesting - can you describe those modifications in more details? > Which adapter have you used? How did you connect it exactly? Some pics? ohh, this is no "advanced" modification. I just read on the battery, that it outputs 3.7V, then I found for an ACDC-adapter, outputing 3.3V DC (this is enough, but the phone tells you that the battery is nearly empty if you boot the original firmware; but we use osmocom :). I openened the white plastic cover (or more correct, opened the sticker around the battery), removed the Li-ION battery from the little electronic parts and soldered the DC-adapter there instead. Cheers Tim From devinechristophe at gmail.com Wed Apr 23 17:48:00 2014 From: devinechristophe at gmail.com (Christophe Devine) Date: Wed, 23 Apr 2014 19:48:00 +0200 Subject: strange crashes in current main branch In-Reply-To: References: <534674DC.9070600@fairwaves.co> Message-ID: Tim, Following your advice, I disassembled a battery, and directly connected the output of a 3.6v motorola charger to gnd and positive side of the charging pcb (of course the lithium cell is completely disconnected). See pictures below, gnd is the middle pad whereas the positive pad is on the left. When doing so be careful not to heat or pierce the lithium battery, and afterwards put some tape to ensure electrical isolation: https://drive.google.com/file/d/0ByHQWL5Q6bSwOHVPNlV5T2ZyZndLZmwtMF9JQ2V0eHhSNFhn/edit?usp=sharing https://drive.google.com/file/d/0ByHQWL5Q6bSwTGNfeUFOVFM5cldPNFZ3djMyMmlSNVZ5dlNZ/edit?usp=sharing https://drive.google.com/file/d/0ByHQWL5Q6bSwUm9XUnBOcU5SRFg4T3VpNEFZOUFHaUFSUEk0/edit?usp=sharing The result appears to work although strangely sometimes after unplugging the charger for some time and replugging it the microcontroller on the pcb will not wake up. However it does immediately wake up if I measure the current between the + and - output with a basic multimeter, but with the black probe on the + and the red probe on the - (other way does not work). There's probably something I'm missing here, but it's not that big a deal. Maybe this is caused by a quirk in the microcontroller, as I've tried the same procedure on a new compatible battery (branded "OTB", see http://pmcdn.priceminister.com/photo/926610349.jpg) and it doesn't have this problem, the microcontroller wakes up immediately and powers the phone. The voltage might be a bit too high, but the phone seems to work fine (firmware reports a full battery - also it gets slightly hotter). On Wed, Apr 23, 2014 at 3:05 PM, Christophe Devine < devinechristophe at gmail.com> wrote: > Tim, > > Following your advice, I disassembled a battery, and directly connected > the output of a 3.6v motorola charger to gnd and positive side of the > charging pcb (of course the lithium cell is completely disconnected). See > pictures below, gnd is the middle pad whereas the positive pad is on the > left. When doing so be careful not to heat or pierce the lithium battery, > and afterwards put some tape to ensure electrical isolation. > > The result appears to work although strangely sometimes after unplugging > the charger for some time and replugging it the microcontroller on the pcb > will not wake up. However it does immediately wake up if I measure the > current between the + and - output with a basic multimeter, but with the > black probe on the + and the red probe on the - (other way does not work). > There's probably something I'm missing here, but it's not that big a deal. > > Maybe this is caused by a quirk in the microcontroller, as I've tried the > same procedure on a new compatible battery (branded "OTB", see > http://pmcdn.priceminister.com/photo/926610349.jpg) and it doesn't have > this problem, the microcontroller wakes up immediately and powers the > phone. The voltage might be a bit too high, but the phone seems to work > fine (firmware reports a full battery). > > Christophe > > > On Thu, Apr 10, 2014 at 8:44 PM, Tim Ehlers wrote: > >> On Thu, 10 Apr 2014, Max.Suraev at fairwaves.co wrote: >> >> 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. >>>> >>> >>> Interesting - can you describe those modifications in more details? >>> Which adapter have you used? How did you connect it exactly? Some pics? >>> >> >> ohh, this is no "advanced" modification. I just read on the battery, that >> it outputs 3.7V, then I found for an ACDC-adapter, outputing 3.3V DC (this >> is enough, but the phone tells you that the battery is nearly empty if you >> boot the original firmware; but we use osmocom :). >> >> I openened the white plastic cover (or more correct, opened the sticker >> around the battery), removed the Li-ION battery from the little electronic >> parts and soldered the DC-adapter there instead. >> >> Cheers >> >> Tim >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From devinechristophe at gmail.com Thu Apr 24 17:10:30 2014 From: devinechristophe at gmail.com (Christophe Devine) Date: Thu, 24 Apr 2014 19:10:30 +0200 Subject: strange crashes in current main branch In-Reply-To: References: <534674DC.9070600@fairwaves.co> Message-ID: Quick heads up: I finally ended up using a LM 317T to lower the output voltage to ~4V, using R1=220, R2=550 and a 1uF capacitor, plus a OTB battery pcb. The phone doesn't get as hot as before, and the "battery" powers without delay. https://drive.google.com/file/d/0ByHQWL5Q6bSwTWo3ZnBHTS1KeXc/edit?usp=sharing https://drive.google.com/file/d/0ByHQWL5Q6bSwM1FPeS1iVlBYX3M/edit?usp=sharing -------------- next part -------------- An HTML attachment was scrubbed... URL: From devinechristophe at gmail.com Fri Apr 25 15:36:04 2014 From: devinechristophe at gmail.com (Christophe Devine) Date: Fri, 25 Apr 2014 17:36:04 +0200 Subject: c139/c140 jtag anyone? In-Reply-To: <1380899330.47346.YahooMailNeo@web121004.mail.ne1.yahoo.com> References: <1380812233.84280.YahooMailNeo@web121001.mail.ne1.yahoo.com> <1380899330.47346.YahooMailNeo@web121004.mail.ne1.yahoo.com> Message-ID: Hi Craig, I got JTAG working (thanks to #osmocom!). I first recommend you get a C115 or C118 with JTAG exposed, which is much easier than having to remove the shields. However remove the plastic cover which makes soldering GND, TDI, TMS, TDO & TCK easier - be careful not to short them the surrounding shields! You will see there is actually 8+9 pads, you must disregard the pin that is left of CTS (it is not shown on http://bb.osmocom.org/trac/raw-attachment/wiki/MotorolaC123/compal_testpads.png). Finally you need a proper VREF. As for me, I just connected the internal 3.3V (TP4) on my Flyswatter2 to the VREF, it appears to work fine (the Flyswatter1 has a jumper that you can use to bridge VREF and 3.3V). On Fri, Oct 4, 2013 at 5:08 PM, Craig Comstock wrote: > I cracked open the shield on my C139 and didn't see the TPs I expected > from the schematic. I thought maybe the angle of the photo on osmocom hid > the TPs but it really didn't. > > I'll try my C115 instead since that is more clear and accessible. Flashing > hello_world on my C115 seemed to fail in a similar fashion as it does on my > C139 so maybe the same issue exists there. > > I was wrong too... it was TP16 not TP6, so I found TP16 but still haven't > located TP8 on the C139 schematic. > > -Craig > > > ------------------------------ > *From:* Craig Comstock > *To:* "baseband-devel at lists.osmocom.org" > > *Sent:* Thursday, October 3, 2013 9:57 AM > *Subject:* c139/c140 jtag anyone? > > I'm at the point w/ flashing firmware where I feel like I need to use a > debugger w/ JTAG. I figured I could probably use serial line logging > somehow but JTAG seems better and I should learn it anyway. > > Has anyone pried open the shield on a c139/c140 and tried attaching to the > JTAG test points that are just inside the shield next to the test points > which are accessible via the battery compartment? > > From what I can gather from the schematics: > TDI - TP8 > TCK - TP17 > TDO - TP16 > > TMS - TP18 > > Looking at the board from the battery compartment side with the top of the > phone pointing North/Up I see at least TP17 is near the right-hand bank of > test points visible from the battery compartment. From left-to-right there > I see something like: TP12, TP18?, TP16?, TP17 so it looks like I have two > of the TPs I need: 17 and 18. > > I can't seem to find TP6 or TP8 anywhere on the schematic. > > -Craig > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From devinechristophe at gmail.com Tue Apr 1 09:25:19 2014 From: devinechristophe at gmail.com (Christophe Devine) Date: Tue, 1 Apr 2014 11:25:19 +0200 Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb In-Reply-To: <1403310853.AA20927@ivan.Harhan.ORG> References: <1403310853.AA20927@ivan.Harhan.ORG> Message-ID: Hi, I had a similar problem with a tracfone branded c139 (ftmtool error). 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 -cde On Mon, Mar 31, 2014 at 10:53 AM, Michael Spacefalcon < msokolov at ivan.harhan.org> wrote: > Sylvain Munaut <246tnt at gmail.com> wrote: > > > If that doesn't yield anything you might need to > > dump the flash (how ? good question ... no idea what option there is > > without being able to load code. jtag, or chip unsoldering ?), and > > reverse engineer the boot loader to see what changed. > > I have just posted flash images read out of two C139s and one C140, > along with an annotated disassembly of the bootloader and other > reverse eng notes: > > ftp://ftp.ifctf.org/pub/GSM/Compal/ > > Hopefully someone will find it helpful... > > To the OP: in case you haven't already figured it out, you need to use > -m c140xor with C139 and C140 phones. I don't know what phones would > -m c140 (w/o xor) be correct for, if any. Sylvain's direction to use > the -c option as well (and then use *.highram.bin instead of > *.compalram.bin) > is also correct, because the images are bigger than the ~15k max one > can download w/o -c on this phone. > > Also you said your C139 came with fw version "V1.9.24" - are you sure > it isn't V1.0.24 instead? The imprint on those stickers is a pain to > read, too small... If your fw version is actually V1.0.24, then it is > the exact same one I have just dumped and reverse-engineered. > > HTH, > SF > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From devinechristophe at gmail.com Tue Apr 1 12:58:27 2014 From: devinechristophe at gmail.com (Christophe Devine) Date: Tue, 1 Apr 2014 14:58:27 +0200 Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb In-Reply-To: References: <1403310853.AA20927@ivan.Harhan.ORG> Message-ID: Hi, It should be noted that the new bootloader is very limited (no charging, no loading of the regular phone os). I found another tool, called "C139 FULL SOLUTION UNLOCK AND FLASH", that successfully could flash a proper firmware (European_Software in the archive it is version 1.0.03.E): https://drive.google.com/file/d/0ByHQWL5Q6bSwTWdhRFAyU05uLUk/edit?usp=sharing Nonethless this particular (trac)phone is still limited to the US bands. On Tue, Apr 1, 2014 at 11:25 AM, Christophe Devine < devinechristophe at gmail.com> wrote: > Hi, > > I had a similar problem with a tracfone branded c139 (ftmtool error). 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 > > -cde > > > On Mon, Mar 31, 2014 at 10:53 AM, Michael Spacefalcon < > msokolov at ivan.harhan.org> wrote: > >> Sylvain Munaut <246tnt at gmail.com> wrote: >> >> > If that doesn't yield anything you might need to >> > dump the flash (how ? good question ... no idea what option there is >> > without being able to load code. jtag, or chip unsoldering ?), and >> > reverse engineer the boot loader to see what changed. >> >> I have just posted flash images read out of two C139s and one C140, >> along with an annotated disassembly of the bootloader and other >> reverse eng notes: >> >> ftp://ftp.ifctf.org/pub/GSM/Compal/ >> >> Hopefully someone will find it helpful... >> >> To the OP: in case you haven't already figured it out, you need to use >> -m c140xor with C139 and C140 phones. I don't know what phones would >> -m c140 (w/o xor) be correct for, if any. Sylvain's direction to use >> the -c option as well (and then use *.highram.bin instead of >> *.compalram.bin) >> is also correct, because the images are bigger than the ~15k max one >> can download w/o -c on this phone. >> >> Also you said your C139 came with fw version "V1.9.24" - are you sure >> it isn't V1.0.24 instead? The imprint on those stickers is a pain to >> read, too small... If your fw version is actually V1.0.24, then it is >> the exact same one I have just dumped and reverse-engineered. >> >> HTH, >> SF >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msokolov at ivan.Harhan.ORG Wed Apr 2 04:37:34 2014 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Wed, 2 Apr 2014 04:37:34 GMT Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb Message-ID: <1404020437.AA23728@ivan.Harhan.ORG> Christophe Devine 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 From rdekema at gmail.com Mon Apr 7 00:20:25 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Sun, 6 Apr 2014 20:20:25 -0400 Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb In-Reply-To: <1404020437.AA23728@ivan.Harhan.ORG> References: <1404020437.AA23728@ivan.Harhan.ORG> Message-ID: > Given your interest in the 850 MHz band, I gather that you must be > somewhere in North America. Anywhere near Southern California > perchance? North America, yes; southern California, no. I'm in southeast Michigan, 30-some miles from Detroit. > 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? That is a very good question. I am not sure yet. I will email either you or the list again when I know more. > 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. I suspect that would cost more money than I am currently willing/able to spend on this project, but I appreciate the reference and will keep it in mind. > 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? Mine is Cingular branded, but it has software version 1.9.24 instead of the seemingly better-known (and known to work) 1.0.24. > 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. Very interesting, that is good to know and will come in handy if/when I get my hands on a Tracfone that it works with. Cheers, Rusty From rdekema at gmail.com Sun Apr 6 20:09:38 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Sun, 6 Apr 2014 16:09:38 -0400 Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb In-Reply-To: References: Message-ID: On Fri, Mar 21, 2014 at 11:39 PM, Rusty Dekema wrote: > 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. > [...] Many thanks for all your help and suggestions. I have tried everything that was suggested (and more) and have still not been able to load osmocom-bb onto that particular C139. That said, it has been a good learning experience. Although I would still like to eventually get a C139 working (mainly for its 850 MHz support), 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.) I really appreciate all the work that has gone into this software, and I'm amazed at how much it can do. Now, back to the C139. If anyone has any further suggestions, please let me know. Other than that, I'm mainly sending these responses out of courtesy and for the benefit of people who may stumble across the list archive while searching for information on the subject. > To the OP: in case you haven't already figured it out, you need to use > -m c140xor with C139 and C140 phones. I don't know what phones would > -m c140 (w/o xor) be correct for, if any. Sylvain's direction to use > the -c option as well (and then use *.highram.bin instead of > *.compalram.bin) > is also correct, because the images are bigger than the ~15k max one > can download w/o -c on this phone. Thanks for the info; I tried both of these but got the same result. The phone never sends a PROMPT1 for reasons discovered later and described above. > Also you said your C139 came with fw version "V1.9.24" - are you sure > it isn't V1.0.24 instead? The imprint on those stickers is a pain to > read, too small... Yes, it's definitely 1.9.24 both on the sticker and the #02# screen. Additionally, in the #02# screen, there is an item shown that says either "UART: 1" or "UART Flag: 1". Various forum posts by members of the unlocking community suggest that this may be an indication that bootloader/flashing access via the serial port is locked down on a given handset. > I had a similar problem with a tracfone branded c139 (ftmtool error). 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 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," and mine is not a Tracfone. > It should be noted that the new bootloader is very limited (no charging, no > loading of the regular phone os). I found another tool, called "C139 FULL > SOLUTION UNLOCK AND FLASH", that successfully could flash a proper > firmware (European_Software in the archive it is version 1.0.03.E): > https://drive.google.com/file/d/0ByHQWL5Q6bSwTWdhRFAyU05uLUk/edit?usp=sharing > Nonethless this particular (trac)phone is still limited to the US bands. The DLTool/"DM Tool" software in this package does not seem to be able to "see" or communicate with the phone. After following the directions and clicking Start, nothing happens for a few minutes after which a timeout error is shown. Perhaps this is not surprising, since the mot931c tool was not able to "unlock" whatever it was supposed to unlock on this phone. >Has anyone figured out just what this (presumably) closed source >mot931c.exe binary sends to the phone? I have not, but I wouldn't mind trying. I do not have any test equipment for serial communication, but perhaps I could find some software (or use a VM environment) that would let me observe the communication between mot931c.exe and the phone. Then again, since mot931c.exe does not seem to work with the C139 I have, I'm not sure how much that would help. Sincerely, Rusty D From devinechristophe at gmail.com Sun Apr 6 21:54:59 2014 From: devinechristophe at gmail.com (Christophe Devine) Date: Sun, 6 Apr 2014 23:54:59 +0200 Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb In-Reply-To: References: Message-ID: Rusty, I'm unsure, but it's possible mot931c might be sensitive to timing issues. At first I tried with portmon running, and it would fail. I could finally get it working after a couple tries. Note this was using XP on a real host (not a VM). But as the tool was made specifically for tracfone, thus it's likely the payload would not work on other carriers. On Sun, Apr 6, 2014 at 10:09 PM, Rusty Dekema wrote: > On Fri, Mar 21, 2014 at 11:39 PM, Rusty Dekema wrote: > > 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. > > [...] > > Many thanks for all your help and suggestions. I have tried everything > that was suggested (and more) and have still not been able to load > osmocom-bb onto that particular C139. That said, it has been a good > learning experience. > > Although I would still like to eventually get a C139 working (mainly > for its 850 MHz support), 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.) I really appreciate all the work that has gone into this > software, and I'm amazed at how much it can do. > > Now, back to the C139. If anyone has any further suggestions, please > let me know. Other than that, I'm mainly sending these responses out > of courtesy and for the benefit of people who may stumble across the > list archive while searching for information on the subject. > > > To the OP: in case you haven't already figured it out, you need to use > > -m c140xor with C139 and C140 phones. I don't know what phones would > > -m c140 (w/o xor) be correct for, if any. Sylvain's direction to use > > the -c option as well (and then use *.highram.bin instead of > > *.compalram.bin) > > is also correct, because the images are bigger than the ~15k max one > > can download w/o -c on this phone. > > Thanks for the info; I tried both of these but got the same result. > The phone never sends a PROMPT1 for reasons discovered later and > described above. > > > > Also you said your C139 came with fw version "V1.9.24" - are you sure > > it isn't V1.0.24 instead? The imprint on those stickers is a pain to > > read, too small... > > Yes, it's definitely 1.9.24 both on the sticker and the #02# screen. > Additionally, in the #02# screen, there is an item shown that says > either "UART: 1" or "UART Flag: 1". Various forum posts by members of > the unlocking community suggest that this may be an indication that > bootloader/flashing access via the serial port is locked down on a > given handset. > > > > I had a similar problem with a tracfone branded c139 (ftmtool error). 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 > > 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," and mine > is not a Tracfone. > > > > It should be noted that the new bootloader is very limited (no charging, > no > > loading of the regular phone os). I found another tool, called "C139 FULL > > SOLUTION UNLOCK AND FLASH", that successfully could flash a proper > > firmware (European_Software in the archive it is version 1.0.03.E): > > > https://drive.google.com/file/d/0ByHQWL5Q6bSwTWdhRFAyU05uLUk/edit?usp=sharing > > Nonethless this particular (trac)phone is still limited to the US bands. > > The DLTool/"DM Tool" software in this package does not seem to be able > to "see" or communicate with the phone. After following the directions > and clicking Start, nothing happens for a few minutes after which a > timeout error is shown. Perhaps this is not surprising, since the > mot931c tool was not able to "unlock" whatever it was supposed to > unlock on this phone. > > > >Has anyone figured out just what this (presumably) closed source > >mot931c.exe binary sends to the phone? > > I have not, but I wouldn't mind trying. I do not have any test > equipment for serial communication, but perhaps I could find some > software (or use a VM environment) that would let me observe the > communication between mot931c.exe and the phone. Then again, since > mot931c.exe does not seem to work with the C139 I have, I'm not sure > how much that would help. > > > Sincerely, > Rusty D > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdekema at gmail.com Sun Apr 6 22:51:39 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Sun, 6 Apr 2014 18:51:39 -0400 Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb In-Reply-To: References: Message-ID: On Sun, Apr 6, 2014 at 5:54 PM, Christophe Devine wrote: > Rusty, > > I'm unsure, but it's possible mot931c might be sensitive to timing issues. > At first I tried with portmon running, and it would fail. I could finally > get it working after a couple tries. Note this was using XP on a real host > (not a VM). But as the tool was made specifically for tracfone, thus it's > likely the payload would not work on other carriers. That makes sense; I was running it on a win7 non-virtual machine. I'll snag a cheap tracfone one of these days and see if I can do anything with it. I'll try to find the most dinged-up one I can; hopefully it will be old and not completely locked down :). -Rusty From msokolov at ivan.Harhan.ORG Sun Apr 6 21:30:30 2014 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Sun, 6 Apr 2014 21:30:30 GMT Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb Message-ID: <1404062130.AA29989@ivan.Harhan.ORG> Rusty Dekema 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 From rdekema at gmail.com Tue Apr 8 23:09:37 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Tue, 8 Apr 2014 19:09:37 -0400 Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb In-Reply-To: <1404062130.AA29989@ivan.Harhan.ORG> References: <1404062130.AA29989@ivan.Harhan.ORG> Message-ID: On Sun, Apr 6, 2014 at 5:30 PM, Michael Spacefalcon wrote: > Rusty Dekema 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 > From rdekema at gmail.com Tue Apr 8 23:17:41 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Tue, 8 Apr 2014 19:17:41 -0400 Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb In-Reply-To: References: <1404062130.AA29989@ivan.Harhan.ORG> Message-ID: >> 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 From rdekema at gmail.com Wed Apr 9 02:19:20 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Tue, 8 Apr 2014 22:19:20 -0400 Subject: Motorola C139 V1.9.24 Won't Load from osmocom-bb In-Reply-To: References: <1404062130.AA29989@ivan.Harhan.ORG> Message-ID: On Apr 8, 2014, at 7:17 PM, Rusty Dekema wrote: > I have found that the PCS1900 support on this C123 [...] I'm sorry; in the interest of correctness, please replace every mention of C123 in my previous message with C118. -Rusty From e10007a at gmail.com Tue Apr 1 17:54:34 2014 From: e10007a at gmail.com (Ahmad Jan) Date: Tue, 1 Apr 2014 22:54:34 +0500 Subject: An OsmocomBB-compatible phone as transceiver for OpenBTS Message-ID: 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Fri Apr 11 08:55:31 2014 From: akibsayyed at gmail.com (Akib Sayyed) Date: Fri, 11 Apr 2014 14:25:31 +0530 Subject: Mobile app crashing while making call Message-ID: Guys I am trying to make call using mobile app but when i try to call it crashes here is report http://pastebin.com/nsdxLvPg -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlhommet at gmail.com Thu Apr 17 00:34:55 2014 From: nlhommet at gmail.com (Nicolas Lhommet) Date: Wed, 16 Apr 2014 17:34:55 -0700 (PDT) Subject: Mobile app crashing while making call In-Reply-To: References: Message-ID: <1397694895061-4026430.post@n3.nabble.com> hello, I had the same problem, it occurs with a recent commit to master branch of libosmocore : "ladpm: Fix msgb handling and SAPI=3 establishment delay" (Jacob, feel free to ask for any details that may help...) http://cgit.osmocom.org/libosmocore/commit/?id=8dac4159adb7377f016317808e3a6b0c79df7fa1 so you would need to compile a (slightly) older version of libosmocore, or patch a recent version to revert these changes. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Mobile-app-crashing-while-making-call-tp4026413p4026430.html Sent from the baseband-devel mailing list archive at Nabble.com. From akibsayyed at gmail.com Thu Apr 17 04:17:51 2014 From: akibsayyed at gmail.com (Akib Sayyed) Date: Thu, 17 Apr 2014 09:47:51 +0530 Subject: Mobile app crashing while making call In-Reply-To: <1397694895061-4026430.post@n3.nabble.com> References: <1397694895061-4026430.post@n3.nabble.com> Message-ID: Issue is in libosmocore use try to checkout older version of libosmocore On 17 Apr 2014 06:13, "Nicolas Lhommet" wrote: > hello, > I had the same problem, it occurs with a recent commit to master branch of > libosmocore : > "ladpm: Fix msgb handling and SAPI=3 establishment delay" (Jacob, feel free > to ask for any details that may help...) > > http://cgit.osmocom.org/libosmocore/commit/?id=8dac4159adb7377f016317808e3a6b0c79df7fa1 > > so you would need to compile a (slightly) older version of libosmocore, or > patch a recent version to revert these changes. > > > > -- > View this message in context: > http://baseband-devel.722152.n3.nabble.com/Mobile-app-crashing-while-making-call-tp4026413p4026430.html > Sent from the baseband-devel mailing list archive at Nabble.com. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Thu Apr 17 09:07:58 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 17 Apr 2014 11:07:58 +0200 Subject: Mobile app crashing while making call In-Reply-To: References: <1397694895061-4026430.post@n3.nabble.com> Message-ID: <20140417090758.GB9417@xiaoyu.lan> On Thu, Apr 17, 2014 at 09:47:51AM +0530, Akib Sayyed wrote: > Issue is in libosmocore use try to checkout older version of libosmocore Or try to understand the issue and fix the mobile application? From e10007a at gmail.com Fri Apr 11 12:45:29 2014 From: e10007a at gmail.com (Ahmad Jan) Date: Fri, 11 Apr 2014 12:45:29 +0000 Subject: Accessing the firmware of osmocom-bb compatible phone Message-ID: By using osmocom-bb, is this possible to access the firmware of osmocom-bb compatible phone? If yes, then how? -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Fri Apr 11 13:17:54 2014 From: akibsayyed at gmail.com (Akib Sayyed) Date: Fri, 11 Apr 2014 18:47:54 +0530 Subject: Accessing the firmware of osmocom-bb compatible phone In-Reply-To: References: Message-ID: Osmocom is a firmware for osmocom phones On 11 Apr 2014 18:22, "Ahmad Jan" wrote: > By using osmocom-bb, is this possible to access the firmware of osmocom-bb > compatible phone? > If yes, then how? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msokolov at ivan.Harhan.ORG Fri Apr 11 22:12:57 2014 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Fri, 11 Apr 2014 22:12:57 GMT Subject: Accessing the firmware of osmocom-bb compatible phone Message-ID: <1404112212.AA06864@ivan.Harhan.ORG> Ahmad Jan 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 From e10007a at gmail.com Sat Apr 12 15:09:42 2014 From: e10007a at gmail.com (Ahmad Jan) Date: Sat, 12 Apr 2014 20:09:42 +0500 Subject: Accessing the firmware of osmocom-bb compatible phone In-Reply-To: <1404112212.AA06864@ivan.Harhan.ORG> References: <1404112212.AA06864@ivan.Harhan.ORG> Message-ID: Oooh...that's great 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? On Sat, Apr 12, 2014 at 3:12 AM, Michael Spacefalcon < msokolov at ivan.harhan.org> wrote: > Ahmad Jan 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Sat Apr 12 15:42:49 2014 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sat, 12 Apr 2014 21:12:49 +0530 Subject: Accessing the firmware of osmocom-bb compatible phone In-Reply-To: References: <1404112212.AA06864@ivan.Harhan.ORG> Message-ID: NO On Sat, Apr 12, 2014 at 8:39 PM, Ahmad Jan wrote: > Oooh...that's great > 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? > > > On Sat, Apr 12, 2014 at 3:12 AM, Michael Spacefalcon < > msokolov at ivan.harhan.org> wrote: > >> Ahmad Jan 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 >> > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From msokolov at ivan.Harhan.ORG Sat Apr 12 17:33:28 2014 From: msokolov at ivan.Harhan.ORG (Michael Spacefalcon) Date: Sat, 12 Apr 2014 17:33:28 GMT Subject: Accessing the firmware of osmocom-bb compatible phone Message-ID: <1404121733.AA07898@ivan.Harhan.ORG> Ahmad Jan 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 From rdekema at gmail.com Sat Apr 12 18:15:40 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Sat, 12 Apr 2014 14:15:40 -0400 Subject: Accessing the firmware of osmocom-bb compatible phone In-Reply-To: <1404121733.AA07898@ivan.Harhan.ORG> References: <1404121733.AA07898@ivan.Harhan.ORG> Message-ID: > 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: I am very excited to hear about this project. If it is possible to alter the 45 MHz tx/rx separation of the E-GSM-900 band on both a handset and BTS, I believe that in conjunction with a few other modifications, it might be possible to legally run a GSM network in the ITU Region 2 33 cm amateur band. While not necessarily especially practical, that could be a fun little project. Once I get layer23/mobile working, I plan to test this in conjunction with calypso-bts. If it works, it would be cool to be able to do it on an untethered handset. Rusty D From e10007a at gmail.com Mon Apr 14 11:46:27 2014 From: e10007a at gmail.com (Ahmad Jan) Date: Mon, 14 Apr 2014 16:46:27 +0500 Subject: Error: no such instruction: `eor %edx,%r15d,%r15d,ror' Message-ID: 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdekema at gmail.com Mon Apr 14 14:07:13 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Mon, 14 Apr 2014 10:07:13 -0400 Subject: Error: no such instruction: `eor %edx,%r15d,%r15d,ror' In-Reply-To: References: Message-ID: To the best of my knowledge from when I first was trying to build osmocom-bb, the error you are receiving is a result of gcc for Intel x86/x86_64 trying to compile ARM code. There is no 'eor' instruction for x86, which is why you get that error. When you built the toolchain, you built a copy of gcc that compiles to the ARM architecture. On your system, this compiler should be located at /home/arslan/dir/install/bin/arm-elf-gcc. The message about assuming arm-elf-gcc is inside the current path means your PATH environment variable, not your current working directory. So, if you add /home/arslan/dir/install/bin to your path environment variable, the osmocom-bb build scripts will be able to find arm-elf-gcc there, and you should not receive that error. If you are using bash as your shell, you can accomplish this by issuing the command: export PATH=$PATH:/home/arslan/dir/install/bin Cheers, Rusty D On Mon, Apr 14, 2014 at 7:46 AM, Ahmad Jan wrote: > 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? > > From e10007a at gmail.com Mon Apr 14 15:02:07 2014 From: e10007a at gmail.com (Ahmad Jan) Date: Mon, 14 Apr 2014 20:02:07 +0500 Subject: Error: no such instruction: `eor %edx,%r15d,%r15d,ror' In-Reply-To: References: Message-ID: As m using bash, export PATH=$PATH:/home/arslan/dir/install/bin seems to resolved this issue of arm-elf-gcc. M really grateful for your help. After that, when i went on making the source, a new sort of error has been arrived. It seems to be quite a big problem as compare to last one. It look like this: make[1]: Entering directory `/home/arslan/osmocom-bb/src/target/firmware' LD board/compal_e88/hello_world.highram.elf apps/hello_world/main.o: In function `console_rx_cb': /home/arslan/osmocom-bb/src/target/firmware/apps/hello_world/main.c:59: undefined reference to `msgb_free' comm/libcomm.a(sercomm.o): In function `sercomm_sendmsg': /home/arslan/osmocom-bb/src/target/firmware/comm/sercomm.c:138: undefined reference to `msgb_enqueue' comm/libcomm.a(sercomm.o): In function `msgb_alloc_headroom': /home/arslan/osmocom-bb/src/target/firmware/../../shared/libosmocore/include/osmocom/core/msgb.h:388: undefined reference to `msgb_alloc' comm/libcomm.a(sercomm.o): In function `sercomm_drv_pull': /home/arslan/osmocom-bb/src/target/firmware/comm/sercomm.c:174: undefined reference to `msgb_dequeue' /home/arslan/osmocom-bb/src/target/firmware/comm/sercomm.c:201: undefined reference to `msgb_free' comm/libcomm.a(sercomm.o): In function `sercomm_drv_rx_char': /home/arslan/osmocom-bb/src/target/firmware/comm/sercomm.c:259: undefined reference to `msgb_free' comm/libcomm.a(sercomm.o): In function `dispatch_rx_msg': /home/arslan/osmocom-bb/src/target/firmware/comm/sercomm.c:240: undefined reference to `msgb_free' comm/libcomm.a(sercomm_cons.o): In function `msgb_alloc_headroom': /home/arslan/osmocom-bb/src/target/firmware/../../shared/libosmocore/include/osmocom/core/msgb.h:388: undefined reference to `msgb_alloc' make[1]: *** [board/compal_e88/hello_world.highram.elf] Error 1 make[1]: Leaving directory `/home/arslan/osmocom-bb/src/target/firmware' make: *** [firmware] Error 2 Any idea, anyone? On Mon, Apr 14, 2014 at 7:07 PM, Rusty Dekema wrote: > To the best of my knowledge from when I first was trying to build > osmocom-bb, the error you are receiving is a result of gcc for Intel > x86/x86_64 trying to compile ARM code. There is no 'eor' instruction > for x86, which is why you get that error. > > When you built the toolchain, you built a copy of gcc that compiles to > the ARM architecture. On your system, this compiler should be located > at /home/arslan/dir/install/bin/arm-elf-gcc. The message about > assuming arm-elf-gcc is inside the current path means your PATH > environment variable, not your current working directory. So, if you > add /home/arslan/dir/install/bin to your path environment variable, > the osmocom-bb build scripts will be able to find arm-elf-gcc there, > and you should not receive that error. > > If you are using bash as your shell, you can accomplish this by > issuing the command: > > export PATH=$PATH:/home/arslan/dir/install/bin > > Cheers, > Rusty D > > > > On Mon, Apr 14, 2014 at 7:46 AM, Ahmad Jan wrote: > > 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? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdekema at gmail.com Mon Apr 14 22:57:32 2014 From: rdekema at gmail.com (Rusty Dekema) Date: Mon, 14 Apr 2014 18:57:32 -0400 Subject: Error: no such instruction: `eor %edx,%r15d,%r15d,ror' In-Reply-To: References: Message-ID: I am not familiar with that error. I would recommend starting over (except for building the gcc toolchain; that part is probably alright) and making sure to follow the directions on the wiki carefully. Cheers, Rusty D On Mon, Apr 14, 2014 at 11:02 AM, Ahmad Jan wrote: > As m using bash, export PATH=$PATH:/home/arslan/dir/install/bin seems to > resolved this issue of arm-elf-gcc. M really grateful for your help. > > After that, when i went on making the source, a new sort of error has been > arrived. > It seems to be quite a big problem as compare to last one. It look like > this: > > make[1]: Entering directory `/home/arslan/osmocom-bb/src/target/firmware' > LD board/compal_e88/hello_world.highram.elf > apps/hello_world/main.o: In function `console_rx_cb': > /home/arslan/osmocom-bb/src/target/firmware/apps/hello_world/main.c:59: > undefined reference to `msgb_free' > comm/libcomm.a(sercomm.o): In function `sercomm_sendmsg': > /home/arslan/osmocom-bb/src/target/firmware/comm/sercomm.c:138: undefined > reference to `msgb_enqueue' > comm/libcomm.a(sercomm.o): In function `msgb_alloc_headroom': > /home/arslan/osmocom-bb/src/target/firmware/../../shared/libosmocore/include/osmocom/core/msgb.h:388: > undefined reference to `msgb_alloc' > comm/libcomm.a(sercomm.o): In function `sercomm_drv_pull': > /home/arslan/osmocom-bb/src/target/firmware/comm/sercomm.c:174: undefined > reference to `msgb_dequeue' > /home/arslan/osmocom-bb/src/target/firmware/comm/sercomm.c:201: undefined > reference to `msgb_free' > comm/libcomm.a(sercomm.o): In function `sercomm_drv_rx_char': > /home/arslan/osmocom-bb/src/target/firmware/comm/sercomm.c:259: undefined > reference to `msgb_free' > comm/libcomm.a(sercomm.o): In function `dispatch_rx_msg': > /home/arslan/osmocom-bb/src/target/firmware/comm/sercomm.c:240: undefined > reference to `msgb_free' > comm/libcomm.a(sercomm_cons.o): In function `msgb_alloc_headroom': > /home/arslan/osmocom-bb/src/target/firmware/../../shared/libosmocore/include/osmocom/core/msgb.h:388: > undefined reference to `msgb_alloc' > make[1]: *** [board/compal_e88/hello_world.highram.elf] Error 1 > make[1]: Leaving directory `/home/arslan/osmocom-bb/src/target/firmware' > make: *** [firmware] Error 2 > > > > Any idea, anyone? > > > On Mon, Apr 14, 2014 at 7:07 PM, Rusty Dekema wrote: >> >> To the best of my knowledge from when I first was trying to build >> osmocom-bb, the error you are receiving is a result of gcc for Intel >> x86/x86_64 trying to compile ARM code. There is no 'eor' instruction >> for x86, which is why you get that error. >> >> When you built the toolchain, you built a copy of gcc that compiles to >> the ARM architecture. On your system, this compiler should be located >> at /home/arslan/dir/install/bin/arm-elf-gcc. The message about >> assuming arm-elf-gcc is inside the current path means your PATH >> environment variable, not your current working directory. So, if you >> add /home/arslan/dir/install/bin to your path environment variable, >> the osmocom-bb build scripts will be able to find arm-elf-gcc there, >> and you should not receive that error. >> >> If you are using bash as your shell, you can accomplish this by >> issuing the command: >> >> export PATH=$PATH:/home/arslan/dir/install/bin >> >> Cheers, >> Rusty D >> >> >> >> On Mon, Apr 14, 2014 at 7:46 AM, Ahmad Jan wrote: >> > 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? >> > >> > > > From e10007a at gmail.com Tue Apr 15 07:50:07 2014 From: e10007a at gmail.com (Ahmad Jan) Date: Tue, 15 Apr 2014 12:50:07 +0500 Subject: arm-elf-gcc Message-ID: While installing osmocom-bb, i came across the "building the source" section. It says in later part that: " If your GCC binary that produces ARM code is not called *arm-elf-gcc* you will need to invoke the following statement and provide the basename of the toolchain with the ending *-*" cd src make -e CROSS_TOOL_PREFIX=arm-OTHER_NAME- How can i find out that my GCC binary is called as *arm-elf-gcc *or something else? -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Tue Apr 15 07:57:27 2014 From: akibsayyed at gmail.com (Akib Sayyed) Date: Tue, 15 Apr 2014 13:27:27 +0530 Subject: arm-elf-gcc In-Reply-To: References: Message-ID: you will need toolchain to cross compile firmware On Tue, Apr 15, 2014 at 1:20 PM, Ahmad Jan wrote: > While installing osmocom-bb, i came across the "building the source" > section. > > It says in later part that: > " If your GCC binary that produces ARM code is not called *arm-elf-gcc*you will need to invoke the following statement and provide the basename of > the toolchain with the ending *-*" > > cd src > make -e CROSS_TOOL_PREFIX=arm-OTHER_NAME- > > How can i find out that my GCC binary is called as *arm-elf-gcc *or > something else? > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From e10007a at gmail.com Tue Apr 15 08:01:28 2014 From: e10007a at gmail.com (Ahmad Jan) Date: Tue, 15 Apr 2014 13:01:28 +0500 Subject: arm-elf-gcc In-Reply-To: References: Message-ID: Which one? arm-elf-toolchain? On Tue, Apr 15, 2014 at 12:57 PM, Akib Sayyed wrote: > you will need toolchain to cross compile firmware > > > On Tue, Apr 15, 2014 at 1:20 PM, Ahmad Jan wrote: > >> While installing osmocom-bb, i came across the "building the source" >> section. >> >> It says in later part that: >> " If your GCC binary that produces ARM code is not called *arm-elf-gcc*you will need to invoke the following statement and provide the basename of >> the toolchain with the ending *-*" >> >> cd src >> make -e CROSS_TOOL_PREFIX=arm-OTHER_NAME- >> >> How can i find out that my GCC binary is called as *arm-elf-gcc *or >> something else? >> > > > > -- > Akib Sayyed > Matrix-Shell > akibsayyed at gmail.com > akibsayyed at matrixshell.com > Mob:- +91-966-514-2243 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Tue Apr 15 08:02:37 2014 From: akibsayyed at gmail.com (Akib Sayyed) Date: Tue, 15 Apr 2014 13:32:37 +0530 Subject: arm-elf-gcc In-Reply-To: References: Message-ID: http://bb.osmocom.org/trac/wiki/toolchain On Tue, Apr 15, 2014 at 1:31 PM, Ahmad Jan wrote: > Which one? arm-elf-toolchain? > > > On Tue, Apr 15, 2014 at 12:57 PM, Akib Sayyed wrote: > >> you will need toolchain to cross compile firmware >> >> >> On Tue, Apr 15, 2014 at 1:20 PM, Ahmad Jan wrote: >> >>> While installing osmocom-bb, i came across the "building the source" >>> section. >>> >>> It says in later part that: >>> " If your GCC binary that produces ARM code is not called *arm-elf-gcc*you will need to invoke the following statement and provide the basename of >>> the toolchain with the ending *-*" >>> >>> cd src >>> make -e CROSS_TOOL_PREFIX=arm-OTHER_NAME- >>> >>> How can i find out that my GCC binary is called as *arm-elf-gcc *or >>> something else? >>> >> >> >> >> -- >> Akib Sayyed >> Matrix-Shell >> akibsayyed at gmail.com >> akibsayyed at matrixshell.com >> Mob:- +91-966-514-2243 >> >> > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trixbox.t at yandex.ru Mon Apr 21 01:47:03 2014 From: trixbox.t at yandex.ru (trixbox.t) Date: Sun, 20 Apr 2014 18:47:03 -0700 (PDT) Subject: OpenBTS OsmocomBB Asterisk Message-ID: <1398044823291-4026434.post@n3.nabble.com> Hello! I Need Help I install these three programs OpenBTS, OsmocomBB, Asterisk Then run them, Everything works well OpenBTS sent an SMS to my phones I answered and he checked me I registered into OpenBTS a second phone I tried to transfer SMS between phones - all good but when I try to call from one to another I did not get Asterisk writes ================================================================ *CLI> Retransmission timeout reached on transmission 755803415 at 127.0.0.1 for seqno 179 (Critical Response) -- See wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 32001ms with no response ================================================================ Why? What do I do? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp4026434.html Sent from the baseband-devel mailing list archive at Nabble.com. From trixbox.t at yandex.ru Mon Apr 21 15:40:17 2014 From: trixbox.t at yandex.ru (trixbox.t) Date: Mon, 21 Apr 2014 08:40:17 -0700 (PDT) Subject: OpenBTS OsmocomBB Asterisk In-Reply-To: <1398044823291-4026434.post@n3.nabble.com> References: <1398044823291-4026434.post@n3.nabble.com> Message-ID: <1398094817266-4026435.post@n3.nabble.com> I use motorola c118 as hardware for OpenBTS here's what I see in my osmocomBB: ======================================= BAT-ADC: 567 7 0 0 1023 360 336 219 Charger at 60 mV. Battery at 3876 mV. Charging at 0 mA. Battery capacity is 85%. Battery range is 3199..3999 mV. Battery full at 468 LSB .. full at 585 LSB Charging at 239 LSB (204 mA). BCICTL2=0x3ff battery-info.flags=0x00000000 bat_compal_e88_chg_state=0 LOST 1882! LOST 1868! LOST 1877! LOST 1873! ... ... BAT-ADC: 572 8 0 0 1023 386 359 219 Charger at 68 mV. Battery at 3910 mV. Charging at 0 mA. Battery capacity is 89%. Battery range is 3199..3999 mV. Battery full at 468 LSB .. full at 585 LSB Charging at 239 LSB (204 mA). BCICTL2=0x3ff battery-info.flags=0x00000000 bat_compal_e88_chg_state=0 ### NB ### (0799 10ed) ... ... BAT-ADC: 565 8 0 0 1023 359 336 219 Charger at 68 mV. Battery at 3862 mV. Charging at 0 mA. Battery capacity is 83%. Battery range is 3199..3999 mV. Battery full at 468 LSB .. full at 585 LSB Charging at 239 LSB (204 mA). BCICTL2=0x3ff battery-info.flags=0x00000000 bat_compal_e88_chg_state=0 LOST 1892! LOST 1858! TOA AVG is not 16 qbits, correcting (got 13) ... ... BAT-ADC: 563 8 0 0 1023 357 332 212 Charger at 68 mV. Battery at 3849 mV. Charging at 0 mA. Battery capacity is 81%. Battery range is 3199..3999 mV. Battery full at 468 LSB .. full at 585 LSB Charging at 239 LSB (204 mA). BCICTL2=0x3ff battery-info.flags=0x00000000 bat_compal_e88_chg_state=0 ### RACH ### (15f0 0773 - 0004) ### NB ### (15ae 4000) ### NB ### (15a9 4000) ### NB ### (15c8 4000) ### NB ### (15c8 4000) ... ... ### NB ### (0f65 4000) ### NB ### (0f65 4000) ### NB ### (0f5f 4000) ### NB ### (0f52 4000) BAT-ADC: 563 9 0 0 1023 356 332 212 Charger at 77 mV. Battery at 3849 mV. Charging at 0 mA. Battery capacity is 81%. Battery range is 3199..3999 mV. Battery full at 468 LSB .. full at 585 LSB Charging at 239 LSB (204 mA). BCICTL2=0x3ff battery-info.flags=0x00000000 bat_compal_e88_chg_state=0 ### RACH ### (15b3 06fe - 0005) STALE BURST 1767427 STALE BURST 1767428 STALE BURST 1767429 STALE BURST 1767430 ### NB ### (159b 4000) ### NB ### (15a0 4000) ### NB ### (159b 4000) ### NB ### (158c 4000) ### NB ### (1576 4000) ... ... ======================================= what is STALE BURST -? what is ### RACH ### (15b3 06fe - 0005) -? what is ### NB ### (159b 4000) -? what is LOST 1858! -? what isTOA AVG is not 16 qbits, correcting (got 13) -? thank you for your attention! -- View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp4026434p4026435.html Sent from the baseband-devel mailing list archive at Nabble.com. From edachleger at yahoo.com Tue Apr 22 11:42:43 2014 From: edachleger at yahoo.com (Erich Dachleger) Date: Tue, 22 Apr 2014 12:42:43 +0100 (BST) Subject: Vedr: OpenBTS OsmocomBB Asterisk In-Reply-To: <1398094817266-4026435.post@n3.nabble.com> References: <1398044823291-4026434.post@n3.nabble.com> <1398094817266-4026435.post@n3.nabble.com> Message-ID: <1398166963.59876.YahooMailNeo@web171801.mail.ir2.yahoo.com> Have you also installed linux call router as is instructed in the network_from_scratch wiki? I only tried the basic setup(without voice)? last year,i.e registering phones to broadcasted network but also saw stale burst messages sometimes just after launching the transceiver. Den Mandag, 21. april 2014 17.42 skrev trixbox.t : I use motorola c118 as hardware for OpenBTS here's what I see in my osmocomBB: ======================================= BAT-ADC: 567? 7? 0? 0 1023 360 336 219? ? ? ? ? Charger at 60 mV. ? ? ? ? Battery at 3876 mV. ? ? ? ? Charging at 0 mA. ? ? ? ? Battery capacity is 85%. ? ? ? ? Battery range is 3199..3999 mV. ? ? ? ? Battery full at 468 LSB .. full at 585 LSB ? ? ? ? Charging at 239 LSB (204 mA). ? ? ? ? BCICTL2=0x3ff ? ? ? ? battery-info.flags=0x00000000 ? ? ? ? bat_compal_e88_chg_state=0 LOST 1882! LOST 1868! LOST 1877! LOST 1873! ... ... BAT-ADC: 572? 8? 0? 0 1023 386 359 219? ? ? ? ? Charger at 68 mV. ? ? ? ? Battery at 3910 mV. ? ? ? ? Charging at 0 mA. ? ? ? ? Battery capacity is 89%. ? ? ? ? Battery range is 3199..3999 mV. ? ? ? ? Battery full at 468 LSB .. full at 585 LSB ? ? ? ? Charging at 239 LSB (204 mA). ? ? ? ? BCICTL2=0x3ff ? ? ? ? battery-info.flags=0x00000000 ? ? ? ? bat_compal_e88_chg_state=0 ### NB ### (0799 10ed) ... ... BAT-ADC: 565? 8? 0? 0 1023 359 336 219? ? ? ? ? Charger at 68 mV. ? ? ? ? Battery at 3862 mV. ? ? ? ? Charging at 0 mA. ? ? ? ? Battery capacity is 83%. ? ? ? ? Battery range is 3199..3999 mV. ? ? ? ? Battery full at 468 LSB .. full at 585 LSB ? ? ? ? Charging at 239 LSB (204 mA). ? ? ? ? BCICTL2=0x3ff ? ? ? ? battery-info.flags=0x00000000 ? ? ? ? bat_compal_e88_chg_state=0 LOST 1892! LOST 1858! TOA AVG is not 16 qbits, correcting (got 13) ... ... BAT-ADC: 563? 8? 0? 0 1023 357 332 212? ? ? ? ? Charger at 68 mV. ? ? ? ? Battery at 3849 mV. ? ? ? ? Charging at 0 mA. ? ? ? ? Battery capacity is 81%. ? ? ? ? Battery range is 3199..3999 mV. ? ? ? ? Battery full at 468 LSB .. full at 585 LSB ? ? ? ? Charging at 239 LSB (204 mA). ? ? ? ? BCICTL2=0x3ff ? ? ? ? battery-info.flags=0x00000000 ? ? ? ? bat_compal_e88_chg_state=0 ### RACH ### (15f0 0773 - 0004) ### NB ### (15ae 4000) ### NB ### (15a9 4000) ### NB ### (15c8 4000) ### NB ### (15c8 4000) ... ... ### NB ### (0f65 4000) ### NB ### (0f65 4000) ### NB ### (0f5f 4000) ### NB ### (0f52 4000) BAT-ADC: 563? 9? 0? 0 1023 356 332 212? ? ? ? ? Charger at 77 mV. ? ? ? ? Battery at 3849 mV. ? ? ? ? Charging at 0 mA. ? ? ? ? Battery capacity is 81%. ? ? ? ? Battery range is 3199..3999 mV. ? ? ? ? Battery full at 468 LSB .. full at 585 LSB ? ? ? ? Charging at 239 LSB (204 mA). ? ? ? ? BCICTL2=0x3ff ? ? ? ? battery-info.flags=0x00000000 ? ? ? ? bat_compal_e88_chg_state=0 ### RACH ### (15b3 06fe - 0005) STALE BURST 1767427 STALE BURST 1767428 STALE BURST 1767429 STALE BURST 1767430 ### NB ### (159b 4000) ### NB ### (15a0 4000) ### NB ### (159b 4000) ### NB ### (158c 4000) ### NB ### (1576 4000) ... ... ======================================= what is STALE BURST -? what is ### RACH ### (15b3 06fe - 0005) -? what is ### NB ### (159b 4000) -? what is LOST 1858! -? what isTOA AVG is not 16 qbits, correcting (got 13) -? thank you for your attention! -- View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp4026434p4026435.html Sent from the baseband-devel mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trixbox.t at yandex.ru Wed Apr 23 00:29:32 2014 From: trixbox.t at yandex.ru (al red) Date: Wed, 23 Apr 2014 04:29:32 +0400 Subject: Vedr: OpenBTS OsmocomBB Asterisk In-Reply-To: <1398166963.59876.YahooMailNeo@web171801.mail.ir2.yahoo.com> References: <1398044823291-4026434.post@n3.nabble.com> <1398094817266-4026435.post@n3.nabble.com> <1398166963.59876.YahooMailNeo@web171801.mail.ir2.yahoo.com> Message-ID: <845591398212972@web17g.yandex.ru> An HTML attachment was scrubbed... URL: From edachleger at yahoo.com Wed Apr 23 09:59:40 2014 From: edachleger at yahoo.com (Erich Dachleger) Date: Wed, 23 Apr 2014 10:59:40 +0100 (BST) Subject: Vedr: Vedr: OpenBTS OsmocomBB Asterisk In-Reply-To: <845591398212972@web17g.yandex.ru> References: <1398044823291-4026434.post@n3.nabble.com> <1398094817266-4026435.post@n3.nabble.com> <1398166963.59876.YahooMailNeo@web171801.mail.ir2.yahoo.com> <845591398212972@web17g.yandex.ru> Message-ID: <1398247180.22024.YahooMailNeo@web171801.mail.ir2.yahoo.com> I guess you need to install the other packages as well since they are listed in the wiki. As I understand Linux call Router must be present to somehow "interface" the? traffic/voice/channels to asterisk. NB in your logs stands for Normal Bursts Den Onsdag, 23. april 2014 2.32 skrev al red : thank you very much for the help! I do not have installed Linux-Call-Router (LCR) except the Linux-Call-Router (LCR) have yet to install something? for example oRTP, opencore-amr, Sip-Sofia, libosmo-abis, OsmoNITB, OsmoBTS, OsmoTRX, I understood from the "network_from_scratch wiki" that I need to have more than one phone "motorola c118" The "network_from_scratch wiki" says: ======================================================================================== Now you should start with a single phone for one timeslot only. If it works, you can try two phones to serve two timeslots. Since you have only one slot, you will only be able to transmit broadcast, do location updating and send/receive SMS. Here is the "osmo-bts.cfg" for a single timeslot: ... ... slotmask 1 0 0 0 0 0 0 0 and further When using two phones, two timeslots can be served. I suggest to configure second timeslot (TS 1) as TCH/H at openbsc.cnf. This way it is possible to allow two traffic channels on a single timeslot. If you do a call from one phone to another, you will need one channel for each phone. In order to use two phones, you need to change the alot map of osmo-bts.cnf: slotmask 1 1 0 0 0 0 0 0 ============================================================================================== how many phones can I connect -? slotmask 1 1 1 1 1 1 1 1 8 - am I right? what opportunities does it give? ? 22.04.2014, 15:42, "Erich Dachleger" : Have you also installed linux call router as is instructed in the network_from_scratch wiki? > > >I only tried the basic setup(without voice)? last year,i.e registering phones to broadcasted network but also saw stale burst messages sometimes just after launching the transceiver. > >Den Mandag, 21. april 2014 17.42 skrev trixbox.t : > >I use motorola c118 as hardware for OpenBTS > > > > >here's what I see in my osmocomBB: >======================================= >BAT-ADC: 567? 7? 0? 0 1023 360 336 219? >? ? ? ? Charger at 60 mV. >? ? ? ? Battery at 3876 mV. >? ? ? ? Charging at 0 mA. >? ? ? ? Battery capacity is 85%. >? ? ? ? Battery range is 3199..3999 mV. >? ? ? ? Battery full at 468 LSB .. full at 585 LSB >? ? ? ? Charging at 239 LSB (204 mA). >? ? ? ? BCICTL2=0x3ff >? ? ? ? battery-info.flags=0x00000000 >? ? ? ? bat_compal_e88_chg_state=0 >LOST 1882! >LOST 1868! >LOST 1877! >LOST 1873! >... >... >BAT-ADC: 572? 8? 0? 0 1023 386 359 219? >? ? ? ? Charger at 68 mV. >? ? ? ? Battery at 3910 mV. >? ? ? ? Charging at 0 mA. >? ? ? ? Battery capacity is 89%. >? ? ? ? Battery range is 3199..3999 mV. >? ? ? ? Battery full at 468 LSB .. full at 585 LSB >? ? ? ? Charging at 239 LSB (204 mA). >? ? ? ? BCICTL2=0x3ff >? ? ? ? battery-info.flags=0x00000000 >? ? ? ? bat_compal_e88_chg_state=0 >### NB ### (0799 10ed) >... >... >BAT-ADC: 565? 8? 0? 0 1023 359 336 219? >? ? ? ? Charger at 68 mV. >? ? ? ? Battery at 3862 mV. >? ? ? ? Charging at 0 mA. >? ? ? ? Battery capacity is 83%. >? ? ? ? Battery range is 3199..3999 mV. >? ? ? ? Battery full at 468 LSB .. full at 585 LSB >? ? ? ? Charging at 239 LSB (204 mA). >? ? ? ? BCICTL2=0x3ff >? ? ? ? battery-info.flags=0x00000000 >? ? ? ? bat_compal_e88_chg_state=0 >LOST 1892! >LOST 1858! >TOA AVG is not 16 qbits, correcting (got 13) >... >... >BAT-ADC: 563? 8? 0? 0 1023 357 332 212? >? ? ? ? Charger at 68 mV. >? ? ? ? Battery at 3849 mV. >? ? ? ? Charging at 0 mA. >? ? ? ? Battery capacity is 81%. >? ? ? ? Battery range is 3199..3999 mV. >? ? ? ? Battery full at 468 LSB .. full at 585 LSB >? ? ? ? Charging at 239 LSB (204 mA). >? ? ? ? BCICTL2=0x3ff >? ? ? ? battery-info.flags=0x00000000 >? ? ? ? bat_compal_e88_chg_state=0 >### RACH ### (15f0 0773 - 0004) >### NB ### (15ae 4000) >### NB ### (15a9 4000) >### NB ### (15c8 4000) >### NB ### (15c8 4000) >... >... >### NB ### (0f65 4000) >### NB ### (0f65 4000) >### NB ### (0f5f 4000) >### NB ### (0f52 4000) >BAT-ADC: 563? 9? 0? 0 1023 356 332 212? >? ? ? ? Charger at 77 mV. >? ? ? ? Battery at 3849 mV. >? ? ? ? Charging at 0 mA. >? ? ? ? Battery capacity is 81%. >? ? ? ? Battery range is 3199..3999 mV. >? ? ? ? Battery full at 468 LSB .. full at 585 LSB >? ? ? ? Charging at 239 LSB (204 mA). >? ? ? ? BCICTL2=0x3ff >? ? ? ? battery-info.flags=0x00000000 >? ? ? ? bat_compal_e88_chg_state=0 >### RACH ### (15b3 06fe - 0005) >STALE BURST 1767427 >STALE BURST 1767428 >STALE BURST 1767429 >STALE BURST 1767430 >### NB ### (159b 4000) >### NB ### (15a0 4000) >### NB ### (159b 4000) >### NB ### (158c 4000) >### NB ### (1576 4000) >... >... >======================================= > >what is STALE BURST -? > >what is ### RACH ### (15b3 06fe - 0005) -? > >what is ### NB ### (159b 4000) -? > >what is LOST 1858! -? > >what isTOA AVG is not 16 qbits, correcting (got 13) -? > >thank you for your attention! > > > > > >-- >View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp4026434p4026435.html >Sent from the baseband-devel mailing list archive at Nabble.com. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rm.engineer84 at gmail.com Sat Apr 26 06:44:28 2014 From: rm.engineer84 at gmail.com (R M) Date: Sat, 26 Apr 2014 02:44:28 -0400 Subject: Frame Structure and Multiframe questions Message-ID: Hi, I am trying to understand the Multiframe structure in GSM. Here is my question: Lets say that in a particular cell, only two GSM frequencies are available to cater to all the traffic. FB is the frequency of the beacon channel and FT is the frequency of the traffic channel. FBT0 is having the following configuration FCCH + SCH + BCCH + CCCH. Now a phone which is in this cell, gets paged for an incoming SMS. The phone responds to the paging request and gets an immediate assignment. The immediate assignment assigns it a channel with the following configuration: FTT2 and channel multiplexing is SDCCH/8 + SACCH/8. Now how does the phone know the multiframe structure of FTT2 ? In other words how does the phone know how long it has to wait, so that it can transmit in the right time-slot ? The same question applies to the BTS if we are talking about down-link ? Is there a relation between the multiframe structure of FBT0 and FTT2 ? Thanks and Regards, R M -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sat Apr 26 09:26:10 2014 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 26 Apr 2014 11:26:10 +0200 Subject: Frame Structure and Multiframe questions In-Reply-To: References: Message-ID: Hi, > FTT2 and channel multiplexing is SDCCH/8 + SACCH/8. > > Now how does the phone know the multiframe structure of FTT2 ? > > In other words how does the phone know how long it has to wait, so that it > can transmit in the right time-slot ? The multiframe structure is entirely defined by the channel time. For SDCCH/8 channel, it will be a 51 multiframe and GSM 05.02 has the detail of which frame maps to which subchannel. The GSM time (i.e. frame number and frame alignement) is the same for all the ARFCN in a cell. So the phone can just use the current (FN % 51) and see if this is a frame that maps to the subchannel that was assigned to it. It's pretty well documented in GSM 05.01 and GSM 05.02. The GSM05.01 has a quick explanation with a couple of well made graphics and GSM 05.02 has the actual reference tables with all the details. Cheers, Sylvain From mailman-bounces at lists.osmocom.org Mon Apr 28 07:00:07 2014 From: mailman-bounces at lists.osmocom.org (mailman-bounces at lists.osmocom.org) Date: Mon, 28 Apr 2014 09:00:07 +0200 Subject: baseband-devel unsubscribe notification Message-ID: lea_lss_bollnas at telia.com has been removed from baseband-devel.