November 2011 - baseband-devel

Engagetted !

by Sébastien Lorquet

http://www.engadget.com/2010/12/29/researchers-eavesdrop-on-encrypted-gsm-c… Congrats!

6 months

5
5
0 0

Please can anyone advise me - FMTOOL Error and no further processing

by Raz Sharif

Dear all, I vae the C115 with a T1 USB to Serial cable with the Prolific chipset. When i run osmocon i get :- an its just sits there with no further processing. ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin read_file(../../target/firmware/board/compal_e88/loader.compalram.bin): file_size=17120, hdr_len=4, dnload_len=17127 read_file(../../target/firmware/board/compal_e88/loader.compalram.bin): file_size=17120, hdr_len=4, dnload_len=17127 got 1 bytes from modem, data looks like: 00 . got 2 bytes from modem, data looks like: 2f 00 /. got 1 bytes from modem, data looks like: 1b . got 3 bytes from modem, data looks like: f6 02 00 ... got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD got 1 bytes from modem, data looks like: 66 f got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6d m got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6c l 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 got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . I think the cable is ok as when i run my fingers on the tip i get random Zeros so it appears to be talking to the cable. Also when i tried to run Mobile i get the :- even though i created the Mobile.cfg file in /etc/osmoco Failed to parse the config file: '/home/raz/.osmocom/bb/mobile.cfg' Please check or create config file using: 'touch /home/raz/.osmocom/bb/mobile.cfg' I have spent some hours researching the lists and trying various things to no avail but I want to continue until I resolve this issues and use this great stack to learn about the GSM network. Please advise. Great full for any help or pointers but this maybe a timing issue that is difficult to debug. Thanks Raz

7 years, 10 months

5
6
0 0

cell re-selection

by Andreas.Eversberg

hi, i did a lot of resarch and testing on cell selection and re-selection process the last two week. the cell selection process, network selection process (manual and automatic) and mobility management process were already implemented in OsmocomBB a long time, but turned out to be buggy and incomplete. i made test drives to check the process and debugged it. the re-selection process is new. it is used to track surrounding cells while listening to the BCCH of the current cell (camping on a cell). special extension to the layer1 firmare is used to measure neighbour cells. if an neighbour cell becomes 'better', the mobile switches to that cell, depening on different criteria. now it is possible to move with OsmocomBB. the re-selection process is not handover! handover is a process where a phone switches between cells while doing a call. handover is one next step to implement. the process is a little more complex, because it requires not only neighbour cell measurements, but also syncing to them without interrupting the traffic channel. most layer 3 stuff of handover is already implemented. if you like to play and test your moving OsmocomBB, you can check out the "jolly/roaming" branch. it contains the extension to layer1, as well as sim reader and fixes from "sylvain/testing" branch. use both "mobile" and "layer1" firmware from this branch. in order to see some process at VTY, you can do: enable monitor network 1 (continously display the strongest cell and neighbour cells) show ms 1 (to see current states) show neighbour-cells 1 (to see a more detailed current list of neighbours) andreas

8 years, 1 month

3
3
0 0

AW: The call has been rejected

by Andreas.Eversberg

hi josephli, > Read stored BA list mnc=01 the mobile application stores the last cells and neighbour cells (band allocation) of each network. this way the scanning is much faster when restarting. because you use the SIM card with MNC == 02 the first time, there is no band allocation stored for that. the mobile will do a full scan in this case. > while the sim card service I am tesing is actually with mnc 00 and 02. i know that MNC == 0 will not work until i commited improvements of cell selection process last sunday. you should retry that, but first try with an MNC > 0. can you provide debug output when trying a call? also can you provide VTY output of "show ms" before you make the call? regards, andreas

11 years

3
2
0 0

status report layer1 and layer23

by Andreas.Eversberg

hi, i just fixed some locking issues the last days. fix will follow. it took a bit longer, because there were some race conditions. it took up to about one hour until it crashed. my way to detect the area where the crash happened, was to turn on buzzer before that area, and turn it off after that area. after many hours of approximation, i finally found out that the major crash happend during _talloc_zero. (first it looks for a free memory chunk, then it allocates it.) since it can be called from all contexts (main, irq, fiq), it need to be locked against any interrupt, otherwise the memory chunk can be assigned multiple times. (the process of _talloc_free is "atomic" and requires no locking.) because it seems pretty stable, i think it is time to merge some branches into the master. (i made a 6 hours call yesterday. and no crash after bugfix ever since.) i will do that together with sylvain, if we find the time this weekend. currently i use the jolly/voice together with the sylvain/traffic branch. i am able to use an isdn phone togehter with linux-call-router and make/receive calls. audio is passed both ways. i think this is a stage where it actually become "usable". (if not moving arround.) one of my major work for the next weeks/months will be the neighbour cell measurement, cell re-selection, and handover. this is essential when moving with the phone. regards, andreas

11 years

2
1
0 0

cp2102 (betemcu, B75937)

by lonelysurfer

...a never ending story: i have a working ftdi-ttl, but the cp2102-adapters (http://www.ebay.de/itm/USB-2-0-to-UART-TTL-6PIN-Module-Serial-Converter-CP2…) with the same cable dont work under ubuntu or windows. if i rub the top of the 2.55mm with my finger random data appears. but the loader doesnt upload the firmware. i used the txd, rxd and gnd pins and checked the connections with a multimeter. i tested -m c123xor, -m c123 and the default firmware. flashing custom baudrates was no problem. rivers are installed correctly (stady ttyusb0 under ubuntu/ com1 under win). is there any hint? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/cp2102-betemcu-B75937-tp3489336p… Sent from the baseband-devel mailing list archive at Nabble.com.

11 years, 8 months

3
4
0 0

Receiving on TS=1 ?

by Sylvain Munaut

Hi, I've hacked something together to quickly test non-combined CCCH. However, I've hit a problem when trying to receive anything on another timeslot than 0. The TX side seems to work fine as the BTS can see my location update request and answers with a reject, but on the MS side, I never see the reject and wireshark only shows invalid incohrent data on the RX. The frames for SDCCH/8 show really nothing valid (looks like random bytes), things like 09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36 ... while the frames for the associated SAACH show at least something gsm-like : 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b but that's not quite a SI5/6 ... To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 * 156.25) when I'm in dedicated channel mode by chaning the 'start' in l1s_tx_win_ctrl / l1s_rx_win_ctrl Is there something else that should be done ? Cheers, Sylvain

11 years, 9 months

2
5
0 0

burst_ind and TCH

by Mad

Hi Sylvain, hi list! I'm experimenting with burst_ind and TCHs right now and ran into some problem I couldn't solve yet. After receiving an Assignment Command for a hopping TCH/F I call l1ctl_tx_dm_est_req_h1() with all necessary parameters and tch_mode GSM48_CMODE_SPEECH_V1 or _EFR. After that I do get burst indications containing the received bits on up- and downlink for the active arfcn on each consecutive frame number. BUT the rx level measurements are most of the time very low and sporadic higher, surely not from that nearby bts and the very close cellphone. It looks like the layer1 doesn't "hit" the right timeslot on the right arfcn at the right time. There are some possible sources of error leading to that, like hopping parameters, channel number and MA list. But I checked these and I took all of them directly from the ASS CMD, the MA as word list in ascending order, like in layer23 IMM ASS handling. The specific AC doesn't have any specialties like Starting Time or "before time" parameters. So my question is if there is some obvious pitfall I'm missing and are there any suggestions how to debug that? Regards, Mad

11 years, 9 months

4
5
0 0

bursts****.dat

by Victor P

Hi, I am trying to use burst_ind branch of osmocom. I have noticed that layer23 creates bursts****.dat files when it indicates uplink. What data are written to these files and what should I use to see its data? Thank you.

11 years, 10 months

5
6
0 0

Use OsmocomBB as OpenBTS / airprobe clock generator

by Harald Welte

Hi! Recently we've had the idea of using OsmocomBB with a simple firmware that synchronizes to an existing GSM networks FCCH and use the resulting 13MHz clock to drive the USRP for airprobe or OpenBTS. Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to multiply it up to the required 52 MHz. However, neither the Openmoko nor the Compal/Motorola phones expose any of the 3 clock output pads :( So the only choice is to use something along the lines of the http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html as a quad clock multiplier and attach it to the CLK13OUT signal of the phone. The chip is available for 9 USD in single quantities at digikey, and possibly cheaper at other sources. Combined with a sub-20EUR phone it might be a very cheap but still accurate frequency source for OpenBTS - at least as long as there are any commercial gsm networks available. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

12 years, 1 month

8
17
0 0

osmocombb and usrp

by Paul Lambert

Hello, I have a ursp1 working fine and I want to use my c123 to conenct to it with osmocombb. Now I face some problems. First of all I have no sim, so I do: sim testcard 1 001 01 The usrp runs a testnetwork (001 01) I don't know how I can associate with the usrp. I tried: network search (lot of output and also my testnet) network show (nothing happens) network select 1 001 01: Network not in list! Any idea what I'm doing wrong? Would be really Cool if i could use opensource only. With best regards, Paul

12 years, 2 months

3
3
0 0

Linux + u-boot port to MT6235

by Marcin Mielczarczyk

Hi All! That's true, I managed to run U-Boot on MT6235, but linux kernel is not fully functional yet (it's fresh stuff as I managed to ran it on Tuesday and then I was off to conference). For MT6235 development I chose Sciphone G2, which is pretty cheap. After some time I managed to download code to SRAM (just 64KB) using MTK's FlashTool. MTK FlashTool communicates over UART directly with MT6235 bootloader and sends its own chunk of code (about 58KB) which is executed in SRAM and communicates with FlashTool. I found on pudn.com some pack to customize code loaded by FlashTool, thanks to which I could download my own code to SRAM (without JTAG). The problem was that it had to be linked with some security libraries which occupied about 56KB and not much memory left for my own code. Then I decided to try find JTAG pins to get all control on MT6235. That took me sometime, but finally I succeeded. The other bigger issue was initializing DRAM controller to be able to download bigger code (linux kernel + uboot) to external RAM. In sciphone there is problem that all interesting chips are under metal shield which is pretty havily soldered. In this case I couldn't read what kind of RAM memory is mounted without destroying the board (I don't have such soldering machine which could unsolder so big metal shield). Thanks to JTAG I could attach to target and then dump DRAM controller registers from processor running MTK's software, but setting these values after processor start and configuration of PLL didn't work. I decided to disassemble bootloader which could show me how DRAM controller is initialized and how code fron NAND is loaded (to be able to flash U-Boot and kernel to NAND so MT6235 will start my code automatically and I will not have to use JTAG). Currently I have knowledge how internal MT6235 bootloader is loading code from memory during startup and I also extracted procedure of DRAM controller initialization. Thanks to that I'm able to run U-Boot from the very begining of processor startup. The problem is that I have just one piece of Sciphone G2 and I don't want to flash it yet to not break existing code in it. Thanks to running device I'm able to attach with JTAG and check how peripherals are configured (i.e. LCD, MMC, etc.). I have backup of flash, but I'm not 100% sure if I will flash it back, phone will startup. That's why I bought second piece of Sciphone G2 and should receive it today or on Tuesday (this Monday is holiday in Poland). In this case I'll flash U-Boot to NAND and try to make it working. Then we could load the rest of code from U-Boot (to RAM or NAND over serial). You can see how my setup looks on attached picture. The good thing about it is that the same bootloader is used in MT622x, so it should be fairly easy to do the same on phones based on that SoCs (but unfortuantely it's just ARM7). If it comes to code, of course I can share it on "git.osmocom.org". Currently it's just basic port of U-Boot and not much for linux kernel, but I'm working on this now so I'll push it when it'll be ready. Currently I'm working on driver for NAND memory for U-Boot, so we could flash linux kernel. When that will be ready I'll push the code. Then I'll switch to linux kernel and when it'll be functional I also push the code. At this stage you will not need to have JTAG and you could load the code over serial in U-Boot. If it comes to GSM I didn't work with it before. I actualy worked 6 months in L2/3 team for LTE (on RRC) but it's different story. That could be really outstanding thing if we could run first phone ever with whole code open (from BB up to APP). BR, Marcin

12 years, 3 months

13
37
0 0

R: GPRS decode tutorial

by Luca Bongiorni

Hi Dario, i suggest you to download the last Sylvain's burst_ind, because is improved of some features and patch it manually with Nohl's patch. Then you will be able to dump the bursts using ccch_scan, instead of layer23. Cheers, Luca > Can someone drive me to the right direction? P.S: http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/1754

12 years, 3 months

3
2
0 0

RFC: Osmocom developer workshop 2012

by Harald Welte

<DISCLAIMER> Please follow-up to openbsc(a)lists.osmocom.org </DISCLAIMER> Hi all, this idea has been around for quite some time, and for 2012 I really want to turn it into reality: I'd like to have a Osmocom developer workshop The idea here is to get all the active contributors of the project together for a couple of days (maybe 2-4 days), in order to exchange ideas, get to know each other better and last but not least work together on ironing out some of the more difficult issues. * City: Regarding the location: I think for me it is only possible to organize it if it is to be held in Berlin. I'mn happy if somebody else wants to host it at some other location, but then that person would also have to take care of local organization. Berlin also has good train and flight connections, which is definitely a plus. * Venue: If it is in Berlin, we might consider talking with c-base or Raumfahrtagentur as possible venues. * Date: Regarding a proposed date, I'm completely open for suggestions. Of course there shouldn't be any overlap with other major FOSS or Sescurity related conferences, and it should also not coincide with major public holidays, as that only makes travel + accomodation more expensive. * Funding: As we don't have that many commercial users of Osmocom projects, getting funding for e.g. travel / accomodation is probably going to be difficult. We can ask the "usual suspects" among those commercial users we know,, but I guess it will only be possible in exceptional cases to provide that kind of funding. Any ideas / comments / feedback is much appreciated. If somebody has a particular suggestion. <DISCLAIMER> Please follow-up to openbsc(a)lists.osmocom.org </DISCLAIMER> Cheers, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

12 years, 4 months

2
2
0 0

MTK and Infineon-based phones

by Martin Hinner

Hi Marcin, On Sun, Nov 27, 2011 at 1:17 AM, Marcin Mielczarczyk <marcin.mielczarczyk(a)gmail.com> wrote: > Note, that on the market there is much more Mediatek phones based on ARM7 > (MT622x) than on ARM9 (MT623x). You are right, it makes sense. My mistake. I was only working with flash dumps so far... I have spent some time analyzing mtk-phone project. There is a lot of files missing, but the situation is not so bad. My feeling is that some of the files were simply deleted from the project... (interrupted upload?) I made a list of all files needed to link binary image (from .lis file). Then I did: find . -name '*.c' Then I ran ar l on al mtk-lib .lib files (these can be quite easily disassembled). And finally diff helped to find what is missing... We're missing only these files (no .obj in .lib or .c is present in the project): -lic.c -drvflash.c -l1c_trace.c -l1d2_trace.c -l1d3_trace.c -l1d_edge_trace.c -l1d_trace.c -l1sc_trace.c -l1trc.c -l4drv.c -sst_decrypt.c -sst_intrctrl.c -sst_secure.c -trcmod.c I think none of these are needed for our stuff. Then we are missing .c files, but have .obj in .lib (only important files) dp_engine.lib: awb_bitstream.c (unknown for what is this) dsp_ram.lib: ddload.c dsp_ram.lib: dsp_ptch_6223.c (we can get this from binary) dsp_ram.lib: idma.c l1.lib: l1csm.c l1.lib: l1dsm.c l1.lib: m*.c (it's a lot of files !!!!!!!!!!!!) In fact this is end of all important routines... Tracing functions: l1.lib: l1i_amr_trace.c l1.lib: l1i_cs_trace.c l1.lib: l1sc_trace.c l1.lib: l1t_amr_trace.c l1.lib: l1c3_trace.c l1.lib: l1c4_trace.c l1.lib: l1c_csd_trace.c l1.lib: l1c_trace.c l1.lib: l1d2_trace.c l1.lib: l1d3_trace.c l1.lib: l1d_edge_trace.c l1.lib: l1d_trace.c l1.lib: rftool_gsm.c (shows how to call various functions) Only for testing: l1.lib: l1tst_afc.c l1.lib: l1tst_agc.c l1.lib: l1tst_cfg.c l1.lib: l1tst_cont.c l1.lib: l1tst_fcb.c l1.lib: l1tst_fhc.c l1.lib: l1tst_nbtx.c l1.lib: l1tst_pm.c l1.lib: l1tst_ul.c I have already tried to disassemble some of them and it all makes sense, most of functions are very simple and some files are not even needed. My feeling is that we have all needed to understand the DSP functionality / L1 part of the ARM code! The biggest problem is that m*.c files depend on hardware (a lot of #ifdefs), so this needs to be analyzed on firmware downloaded from hardware. [ Question: why such cryptic names such as m12170.c ? ] I also have list of functions in those files, if anyone's interested in helping me with locating what is important and what is not... (34 kB). Martin

12 years, 4 months

2
2
0 0

MTK and Infineon-based phones

by Martin Hinner

Hi, I spent a few hours today looking at CCC presentations and osmocom code. Good and interesting work! I have a couple of questions... This is my first experience with GSM phones reverse engineering, so sorry if I am wrong, but it seems to be quite difficult for me to obtain four Calypso-based phones (yes, I know I can order them from webshop for a few euros, but I will need more of them if my experiments are successfull). On the other hand, I have access to very cheap phones using Infineon PMB7880 (C166 + DSP) or MTK (ARM9) chipsets. Currently, I do have some information (datasheet&code) for MTK platform, and I see there is implementation of "secondary bootloader" for these phones, but no layer1 yet. I also have very basic documentation of Infineon SoC, plus I have knowledge of the C166 code and I can very easily play with it (reverse engineer firmware & assemble my own code). Is it feasible to create layer1 implementation for Infineon and/or MTK? Is there anyone willing to help with this? Here are my additional questions related to the above question: - Is there any documentation of mask-rom bootloader for Infineon C166 core? - At this moment I do not understand how does the DSP on the PMB7880 work, if RF part is accessible from both DSP and C166 or just the DSP. - How is it with Infineon DSP code, is it present in flash memory, or is it ROM-only thing? Anyone has the code dump? - Is anyone (who has experience with Calypso layer1) willing to help with implementing the same on Infineon or MTK platform? - If anyone has any resources for these two plaforms, I would be grateful if you can send them to me. I will add that I have spent many many nights disassembling car control units using Infineon/Siemens C166 core (since 2002?), so Infineon platform is very attractive for me (the flash is only 2MB for some phones, it's easy to read code, etc...). Thanks, Martin

12 years, 4 months

6
12
0 0

[PATCH] i2c: fix maximum address an I2C chip can assign

by Alan Carvalho de Assis

I2C bus support up to 128 devices (mask 0x7F), but current calypso driver is masked it to 64 (0x3F). I discover it because Motorola W220 has an I/O expander PCA9537 at address 0x49 which could be reached. Signed-off-by: Alan Carvalho de Assis <acassis(a)gmail.com>

12 years, 4 months

2
1
0 0

RFC Wiki re-org of bb.osmocom.org

by Holger Hans Peter Freyther

Hi, I have recently tried to find some information in our wiki and it was more difficult than I think it should be. I would like to propose and then implement some restructuring. So first of all I think we have good enough content, it is just a matter of structure. Front Page: I would like to have a very simple and structured entry. Mainly pointing to other projects, History, Software and Hardware? Hardware Pages Our hardware pages are mostly the same but actually quite different. I would like to find the following information on each page: - Which firmware/board to use (compal_e88)... - Picture of assembled/disassembled device - Knowledge we have I would like to move all Hardware/MotorolaCXX. The example would be to have hardware/ like this[1] and hardware/MotorolaC118 like this[2]. Software Pages: We have the Getting Started but there appears to be a gap from having a toolchain (or building one) and knowing how the various parts are connected to each other. I have not thought about it too much though. History Pages: I would move some older information in there. E.g. our never started/finished Calypso based design, maybe some parts of the project history. comments? ideas? holger [1] http://wiki.openwrt.org/toh/start#supported.hardware.-.router.type [2] http://wiki.openwrt.org/toh/buffalo/whr-g125

12 years, 4 months

3
2
0 0

uplink sniffing

by Lorik Sefaj

Hi all, Just received my C123 (from http://shop.sysmocom.de/) with filter rework and it works great. I have one problem with the "burst*.dat" files when i do uplink sniffing, basically there are no files produced and when they are produced most of the time they are empty? This doesn't happen when i do downlink sniffing. Is this a stupid question or am I missing something... cheers, L.

12 years, 4 months

4
5
0 0

OsmocomBB Bootstrapping

by Kurtis Heimerl

Hello baseband-devel(a)lists.osmocom.org! I've just started my first OsmocomBB project, using a Motorola V171 and the source code in the main git repository. The short hand version of the story is that we're looking into modifying the GSM MS stack to allow for the BTS to save some power. This is research being done at the University of California, and we're sorta amazed at how wonderful OsmocomBB is for this particular project. Thanks for the work! Progress has generally been good, and I've been able to build and run the "hello world" e99 application. Following that, I've moved onto the mobile app... and run into an issue that I can't seem to resolve by searching your mailing lists. Basically, each individual process runs fine: osmocon installs the compal_e99/layer1.compalram.bin image onto a c155 device mobile connects (though it doesn't see the SIM for some reason...) and the terminal is available and active. I'm not able to do much though, as the MS isn't on yet. Upon turning the MS on, it scans for a while, eventually detecting my own cell tower. Terminal is active during this search. Unfortunately, shortly after detecting and syncing with my tower (ARFCN 51), the terminal freezes. osmocon begins repeating the following error: "Failed to write msg to the socket.." and nothing else moves. Kaput. Terminal does not respond to any messages sent. This is my problem, as I'd like to make a call. PRE-POWERUP mobile: http://pastebin.com/tPm9ux83 POST-POWERUP mobile: http://pastebin.com/fMD1Kth6 osmocon: http://pastebin.com/nc3QGGgD terminal says: kheimerl@darth-maul /tmp $ telnet localhost 4247 Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Welcome to the OsmocomBB control interface OsmocomBB> % (MS 1) % No service. My intuition is that I've missed setting some key variables in the related configuration files (~/.osmocom/osmocom.cfg, ~/.osmocom/bb/mobile.cfg). though I can't find ANY documentation about what's supposed to be in those things. Any and all help would be appreciated.

12 years, 4 months

4
4
0 0

Re: osmocom-bb cygwin

by R M

Hi, Its better you send the mail to the list rather than just to me. In that way you get more help. I have built osmocom using cygwin. But I am unable to get the code downloaded into the phone. I am facing timing issues. I am still looking into the issue though. The instructions to install cygwin are found at: http://cygwin.com/. By default cygwin installs just the basic tools. Once you have installed the basic tools, you have to run the installer again to get the tools required for building osmocom. The tools required are given in the Wiki at this link: http://bb.osmocom.org/trac/wiki/GettingStarted. Once you have done that you need to install gnu arm. In the same wiki you have the links to download the cygwin version of GNU Arm. The ftdi cable I use is at this link:http://www.sparkfun.com/products/8772. Regards, RM On 11/24/11, Juantxi <juantxipazos(a)yahoo.es> wrote: > hello, > osmocom-bb got compile using cygwin? > packages could tell me that you downloaded? > which cable did you use? > > I am interested in doing > thanks >

12 years, 4 months

1
0
0 0

Bug in gprs decode software

by Dario Lombardo

Hi guys Today I'm experiencing a bug in the gprs decode software. In rlcmac.c:190, when li_off and f->len get invalid values, we have a buffer overflow in the mempy(). In my case f->len=15, li_off=135. The really stupid patch to avoid it is below: simply jumps the case. I'm not able to investigate why li_off becames greater than f->len, causing the crash. Maybe a check should added. Have some other seen this crash? diff --git a/rlcmac.c b/rlcmac.c index eea02ce..d76a8d6 100644 --- a/rlcmac.c +++ b/rlcmac.c @@ -187,11 +187,14 @@ void process_blocks(struct gprs_tbf *t, int ul) print_pkt(llc_data, llc_len); fflush(stdout); } - memcpy(llc_data, &f->data[li_off], f->len-li_off); - llc_len = f->len - li_off; - llc_first_bsn = bsn; - llc_last_bsn = bsn; - t->start_bsn = bsn; + + if (f->len > li_off && f->len-li_off > 65536) { + memcpy(llc_data, &f->data[li_off], f->len-li_off); + llc_len = f->len - li_off; + llc_first_bsn = bsn; + llc_last_bsn = bsn; + t->start_bsn = bsn; + } } }

12 years, 4 months

1
1
0 0

[PATCH 0/0] firmware janitor work to reduce compiler warnings

by Alexander Huemer

This patch series reduces the number of warnings emitted during firmware compilation. No functional changes. The patches could NOT be TESTED, so please try them before merging. Kind regards, -Alexander Huemer

12 years, 4 months

5
23
0 0

[PATCH] rf: dereference pointer

by Alexander Huemer

--- src/target/firmware/rf/mt6139.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/target/firmware/rf/mt6139.c b/src/target/firmware/rf/mt6139.c index a9a6d32..d48e652 100644 --- a/src/target/firmware/rf/mt6139.c +++ b/src/target/firmware/rf/mt6139.c @@ -39,13 +39,13 @@ static void mt6139_compute_pll(uint32_t f_vco_100khz, /* To compute Nint, we assume Nfrac is zero */ *nint = (fvco_100khz / (10 * 2 * 26)) - (0 / 130); - if (nint > 127) + if (*nint > 127) printf("VCO Frequency %u kHz is out of spec\n", f_vco_100khz); /* Compute Nfract using the pre-computed Nint */ /* Nfrac = ( (Fvco/2*26) - Nint) * 130 */ /* Nfrac = ( (Fvco*130)/(2*26) - (Nint * 130) */ - *nfrac = (f_vco_100khz*130)/(52*10) - (nint * 130); + *nfrac = (f_vco_100khz*130)/(52*10) - (*nint * 130); } /* Set ARFCN. Takes 2 reg_write, i.e. 8 TPU instructions */ -- 1.7.8.rc1

12 years, 4 months

3
3
0 0

OsmocomBB on Motorola W220

by Alan Carvalho de Assis

Hi all, I want to know if someone here already tried osmocombb on Motorola W220? This cell phone is powered by D751749ZPH, but at least my model (W220 E2) doesn't communicate with "osmocon". The problem is not serial cable because it work correctly with C115. After some search I discovered the uart is disabled by software, some firmware version let users to enable it after entering on engineering mode (*#**372#), unfortunately my firmware doesn't have this option at eng. mode. You can see a picture of my W220 board here: http://acassis.files.wordpress.com/2011/11/sam_1634.jpg If someone has some idea for an alternative option (JTAG?) please tell me. BR, Alan

12 years, 5 months

2
2
0 0

Re: Diff between TWL3014 and TWL3025

by msokolov＠ivan.Harhan.ORG

Sylvain Munaut <246tnt(a)gmail.com> wrote: > Google for TWL3016 SWCS010 and check for yourself Thanks once again! OK, so TWL3016 *is* Syren indeed, and it does have additional features over Iota. But EDGE modulation support isn't one of them. If my reading of the doc is correct, the additional features of Syren over Iota are I2S audio, high voltage charger input and the USB regulator support. Does this agree with your reading? MS

12 years, 5 months

1
0
0 0

Re: Diff between TWL3014 and TWL3025

by msokolov＠ivan.Harhan.ORG

Steve Markgraf <steve(a)steve-m.de> wrote: > Search Google for "TWL3025 SWRS021", last hit. Thanks, got it. (In my case it was the middle of the 3 results rather than the last.) I wonder about all these Chinese websites... It looks like they have a healthier attitude about sharing this kind of stuff than the Westerners do. So far we've known about 52rd.com hosting "contraband" phone handset chip documents, and now we know there's also baisi.net... But I find it strange that only PDF datasheets and PPT presentations have been found so far, and not, for example, any of the source/object-mix packages that must have been given for the firmware side of things by TI et al to the same folks (phone makers?) to whom they've given the chip docs. NDA etc issues ought to be the same... Or maybe I just haven't been looking hard enough... Would anyone here perchance happen to have a link to some place on one of those Chinese sites that has the original FW source (or semi-source, as in bits of source mixed with binary object blobs) for the Leonardo reference board or for some other Calypso-based HW version that's more readily available (as in HW availability) than the famous TSM30 version? (I realize that it would never be acceptable to use any such code in a Western FOSS project like OsmocomBB, but I would still *love* to take a peek at the original code for some phone whose HW is better understood and/or more readily available than the TSM30.) > Both TWL3014 and TWL3025 are Iota, TWL3016 is Syren. Hmm. I agree that TWL3025 must be some equivalent Iota variant, and I think you are right about TWL3016 being Syren: the Rita_intro.pdf document in my collection (see my FTP site) says "It is compatible with Iota (TWL3014) and Syren (TWL3016) ABB chips". However, the Iota_intro.pdf document (same FTP site) shows the Nausica->Iota->Syren evolutionary line and lists Syren as EDGE-capable. But Sylvain says TWL3016 doesn't do EDGE either. Hmm. Are you sure? MS

12 years, 5 months

2
1
0 0

Re: Diff between TWL3014 and TWL3025

by msokolov＠ivan.Harhan.ORG

Steve Markgraf <steve(a)steve-m.de> wrote: > Well, some time ago I diffed the TWL3014 and TWL3025 datasheets, Where did you find the TWL3025 datasheet? Wading through 52rd.com, or is there some other source I'm unaware of? > there is no technical difference at all (only 3014 replaced with 3025, > and some minor formatting changes). > [...] > I suspect that TI renamed > the chip because of some changes in the manufacturing process. Hmm, interesting. > Given that both chips work fine with osmocom (with the same revision of > DSP rom code on the Calypso side of things), What OsmocomBB-supported phones use TWL3014? Sylvain Munaut <246tnt(a)gmail.com> wrote: > > supposedly called Syren rather than Iota and supports EDGE modulation. > No it doesn't. > [...] > > Is it a Iota variant or a Syren variant? > I think they're all called "Iota" that's a generic designation for the ABB. I believe that the codenames refer to specific generations for each function, rather than to functions like DBB/ABB/RF. For example, it seems that Calypso succeeded Hercules in the DBB role, and Rita succeeded Clara in the RF role. I remember seeing somewhere that Iota's successor was/is Syren, whereas its predecessor in the ABB role was Nausica. But if TWL3016 and TWL3025 are both Iotas, which chip is then Syren? Does anyone know? MS

12 years, 5 months

3
2
0 0

Diff between TWL3014 and TWL3025

by msokolov＠ivan.Harhan.ORG

Hello GSM BB hackers, I wonder, would anyone here happen to know what are the main diffs between the TWL3014 and TWL3025 ABB chips? TWL3025 is the chip that appears to be used in most of the phones currently supported by OsmocomBB, but the presumably older TWL3014 is the only one for which we have docs as part of the Calypso and Leonardo documentation set at: ftp://ifctfvax.Harhan.ORG/pub/GSM/Calypso (The above FTP server is mine, but the content originates from the 52rd.com Chinese forum linked to from some of the OsmocomBB wiki pages.) Hence me wondering if anyone here knows what the actual differences are... I also recall seeing somewhere (don't remember where) that Iota strictly means TWL3014, and that its successor (TWL3016?) is supposedly called Syren rather than Iota and supports EDGE modulation. If that is true, where does the TWL3025 fit into that picture then? Is it a Iota variant or a Syren variant? It ought to be newer than TWL3016, right? Does that mean it ought to support EDGE? If so, what stands in the way of EDGE support in phones like GTA02 that use the TWL3025 ABB? Lack of Calypso DSP support? Or an RF front-end that isn't compatible with EDGE modulation? Or is TWL3025 a step backward from TWL3016, without EDGE support? If so, would anyone happen to know what its raison-d'etre is? What does it offer over the TWL3014? Just wondering... MS

12 years, 5 months

3
2
0 0

Compile with DEBUG fail / i2c.c

by Stefan Mandl

Hello all, if you compile with #ifdef DEBUG, 2 litte typo errors came up... Regrads from stefan my patch... --- a/src/target/firmware/calypso/i2c.c +++ b/src/target/firmware/calypso/i2c.c @@ -67,7 +67,7 @@ int i2c_write(uint8_t chip, uint32_t addr, int alen, const uint8_t *buffer, int if (len > 16) return -1; - printd("i2c_write(chip=0x%02u, addr=0x%02u): ", chip, addr) + printd("i2c_write(chip=0x%02u, addr=0x%02u): ", chip, addr); writeb(chip & 0x3f, I2C_REG(DEVICE_REG)); writeb(addr & 0xff, I2C_REG(ADDRESS_REG)); @@ -91,7 +91,7 @@ int i2c_write(uint8_t chip, uint32_t addr, int alen, const uint8_t *buffer, int /* wait until transfer completes */ while (1) { uint8_t reg = readb(I2C_REG(STATUS_ACTIVITY_REG)); - printd("I2C Status: 0x%02x\n", rerg & 0xf); + printd("I2C Status: 0x%02x\n", reg & 0xf); if (!(reg & I2C_STATUS_IDLE)) // 0: idle 1: not idle break;

12 years, 5 months

2
1
0 0

burst_ind not working

by Dario Lombardo

Hi guys I'm not able to use cell_log under the burst_ind branch. I checkout the master, compile and run osmocon/cell_log. Everything works (I can see the cells). I checkout the branch, recompile, and run the same commands as before, but I get from layer1: [...] PM MEAS: ARFCN=71, 0 dBm at baseband, -138 dBm at RF DSP Error Status: 8 PM MEAS: ARFCN=72, 0 dBm at baseband, -138 dBm at RF DSP Error Status: 8 PM MEAS: ARFCN=73, 0 dBm at baseband, -138 dBm at RF [...] for every arfcn. Cell_log doesn't log anything: [...] <000e> cell_log.c:359 Measurement done <000e> cell_log.c:368 Measure from 0 to 124 <000e> cell_log.c:368 Measure from 512 to 885 <000e> cell_log.c:368 Measure from 955 to 1023 [...] I don't think it's a hardware problem, since it works with master. Am I missing something in the branch? Is anyone experiencing the same problem? Bye. Dario.

12 years, 5 months

3
3
0 0

c1xx with filter re-work

by Lorik Sefaj

Hi all, Considering my soldering skills and the fact that I just ruined a c123 trying to replace the filters (which was working perfectly with patched burst_ind and got me a lot of downlink traffic to work with). Anyways without wasting your time my question is: does anybody have a c1xx with filter re-work for sale? I'd like to get some uplink traffic Thanks a lot and keep up the great work, J

12 years, 5 months

3
5
0 0

Sony J120?

by Jay R. Worthington

Hi 'yall, before i break out the soldering iron, has someone already tried the J120? It seem's to be a tad newer version of the J100, but with an (FM-) Radio, the specs lists it as Calypso Chipset... Regards, Jay

12 years, 5 months

1
0
0 0

calypso SIM driver on c139 (also: l1ctl SIM APDU)

by Gianni Tedesco

The SIM and the SIM reader in the phone and the mechanical contact between them are definitely working because the SIM can be accessed from the motorola firmware, from another phone and from a PC smartcard reader with no PIN or anything. However, under simtest firmware no data is received by the phone, even the ATR is zero bytes... Anybody had this problem? Also, is l1CTL SIM APDU command not implemented in the layer1 firmware? How are people making calls without a SIM? :P Gianni ----------------SIMTEST----8<----------------- Initializing driver: SIM: Registering interrupt handler for simcard-interface ====================== CALYPSO SIM REGISTER DUMP ===================== Reg_sim_cmd register (R/W) - FFFE:0000 |-REG_SIM_CMD = 0000 | |-REG_SIM_CMD_CMDCARDRST = 0 ==> SIM card reset sequence disabled. | |-REG_SIM_CMD_CMDIFRST = 0 | |-REG_SIM_CMD_CMDSTOP = 0 | |-REG_SIM_CMD_CMDSTART = 0 | |-REG_SIM_CMD_MODULE_CLK_EN = 0 ==> Clock of the module disabled. |-REG_SIM_STAT = 000b | |-REG_SIM_STAT_STATNOCARD = 1 ==> No card! | |-REG_SIM_STAT_STATTXPAR = 1 ==> Parity ok! | |-REG_SIM_STAT_STATFIFOFULL = 0 | |-REG_SIM_STAT_STATFIFOEMPTY = 1 ==> Fifo empty! |-REG_SIM_CONF1 = 000c | |-REG_SIM_CONF1_CONFCHKPAR = 0 ==> Parity check on reception disabled. | |-REG_SIM_CONF1_CONFCODCONV = 0 ==> Coding convention is direct (normal). | |-REG_SIM_CONF1_CONFTXRX = 1 ==> SIO line direction is in transmit mode. | |-REG_SIM_CONF1_CONFSCLKEN = 1 ==> SIM clock in normal mode. | |-REG_SIM_CONF1_reserved = 0 ==> ETU period is CONFETUPERIOD. | |-REG_SIM_CONF1_CONFSCLKDIV = 0 ==> SIM clock frequency is 13/4 Mhz. | |-REG_SIM_CONF1_CONFSCLKLEV = 0 ==> SIM clock idle level is low. | |-REG_SIM_CONF1_CONFETUPERIOD = 0 ==> ETU period is 372/8*1/Fsclk. | |-REG_SIM_CONF1_CONFBYPASS = 0 ==> Hardware timers and start and stop sequences are normal. | |-REG_SIM_CONF1_CONFSVCCLEV = 0 ==> SVCC Level is low (Only valid when CONFBYPASS = 1). | |-REG_SIM_CONF1_CONFSRSTLEV = 0 ==> SRST Level is low (Only valid when CONFBYPASS = 1). | |-REG_SIM_CONF1_CONFTRIG = 0x0 (FIFO trigger level) | |-REG_SIM_CONF1_CONFSIOLOW = 0 |-REG_SIM_CONF2 = 0940 | |-REG_SIM_CONF2_CONFTFSIM = 0x0 (time delay for filtering of SIM_CD) | |-REG_SIM_CONF2_CONFTDSIM = 0x4 (time delay for contact activation/deactivation) | |-REG_SIM_CONF2_CONFWAITI = 0x9 (CONFWAITI overflow wait time between two received chars) |-REG_SIM_IT = 0000 | |-REG_SIM_IT_SIM_NATR = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_WT = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_OV = 0 ==> On read access to REG_SIM_IT. | |-REG_SIM_IT_SIM_TX = 0 ==> On write access to REG_SIM_DTX or on switching | | from transmit to receive mode (CONFTXRX bit) | |-REG_SIM_IT_SIM_RX = 0 ==> On read access to REG_SIM_DRX. |-REG_SIM_DRX = 0100 | |-REG_SIM_DRX_SIM_DRX = 0x0 (next data byte in FIFO available for reading) | |-REG_SIM_DRX_STATRXPAR = 1 ==> Parity Ok. |-REG_SIM_DTX = 00 (next data byte to be transmitted) |-REG_SIM_MASKIT = 003f | |-REG_SIM_MASKIT_MASK_SIM_NATR = 1 ==> No-answer-to-reset interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_WT = 1 ==> Character wait-time overflow interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_OV = 1 ==> Receive overflow interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_TX = 1 ==> Waiting characters to be transmit interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_RX = 1 ==> Waiting characters to be read interrupt is masked. | |-REG_SIM_MASKIT_MASK_SIM_CD = 1 ==> SIM card insertion/extraction interrupt is masked. |-REG_SIM_IT_CD = fffe0010 |-REG_SIM_IT_CD_IT_CD = 0 ==> SIM card insertion/extraction interrupt is unmasked. Power up simcard: * Power enabled! * Clock enabled! * Reset released! SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! (0 bytes) Reset simcard: * Reset pulled down! * Reset released! SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! (0 bytes) SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 2: No input / Output of known length (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Missing ACK byte -- aborting! SIM-T0: Transceiving APDU-Header: (a0 c0 00 00 0f) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 4: Input / No output (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Incorrect or missing answer -- aborting! e0 73 d7 b9 ae ea bf 7e f7 3b 7f 6f 32 fe 25 (15 bytes) Test Phase 1: Testing bare sim commands... * Testing SELECT: Selecting MF SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-T0: Case 2: No input / Output of known length (See also GSM 11.11 Page 34) SIM-ISR: Interrupt caught: Waiting characters to be read... SIM-ISR: Interrupt caught: Character underflow! SIM-T0: T0 Protocol error: Missing ACK byte -- aborting! ==> Status word: ffff * Testing SELECT: Selecting DF_GSM SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02) SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... SIM-ISR: Interrupt caught: Waiting for character to transmit... At this point it hangs "forever" - well at least half hour.

12 years, 5 months

7
11
0 0

GPRS decode tutorial

by Dario Lombardo

Hello everybody Not sure if someone has pointed it out already, but I'm getting stuck following the gprs decode tutorial [...] - Prepare OsmocomBB's burst_ind branch cd ~/gprs_sniffer/osmocom-bb git checkout origin/sylvain/burst_ind git checkout d1cb8ea9b784c7acbafbb2fdcedbdf4655c2f6f5 At this point I get fatal: reference is not a tree: d1cb8ea9b784c7acbafbb2fdcedbdf4655c2f6f5 Next step fails too... pretty obvious... # patch -p1 < ~/gprs_sniffer/gprs_multi.patch can't find file to patch at input line 5 [...] Can someone drive me to the right direction? Thanks! Dario

12 years, 5 months

4
4
0 0

cp2102 (betemcu, B75937)

by lonelysurfer

...a never ending story: i have a working ftdi-ttl, but the cp2102-adapters (http://www.ebay.de/itm/USB-2-0-to-TTL-UART-6PIN-CP2102-Module-Serial-Conver…) with the same cable dont work under ubuntu or windows. if i rub the top of the 2.55mm with my finger random data appears. but the loader doesnt upload the firmware. i used the txd, rxd and gnd pins and checked the connections with a multimeter. i tested -m c123xor, -m c123 and the default firmware. flashing custom baudrates was no problem. drivers are installed correctly (stady ttyusb0 under ubuntu/ com1 under win). is there any hint? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/cp2102-betemcu-B75937-tp3489323p… Sent from the baseband-devel mailing list archive at Nabble.com.

12 years, 5 months

1
0
0 0

Re: Pirelli never syncs

by Andres Berroa

I'm trying to sync to the 1800 or the 900 bands with the Pirelli, I'm not using 850/1900. I tried ccch_scan with different cells. I attached the logs. On Mon, Nov 7, 2011 at 11:48 AM, Sylvain Munaut <246tnt(a)gmail.com> wrote: > > The only thing it's different from you it's > > I live in the Caribbean, but I have GSM networks on all four bands. > > And what band are you trying to sync to ? And with which hardware ? > > The ARFCN of PCS and DCS are overlapped and so I have no idea how > 'mobile' behaves in that case. > > You can try the ccch_scan binary with the -a option to force going to > a cell and just see if the bcch sync works at all. > (for PCS ARFCN you have to add 32768 to the arfcn number). > > Cheers, > > Sylvain >

12 years, 5 months

1
0
0 0

Pirelli never syncs

by Andres Berroa

Hello everybody, I bought several Pirelli DP-L10. I checked out the master branch of Osmocom, changed the console.h and sercomm.h, and enabled the CONFIG_TX_ENABLE option. The code compiled successfully. I loaded the compiled firmware onto the Pirelli with osmocon, and after it loaded, I ran cell_log and mobile. But the phone never syncs to a cell. I first tried with the "no stick" option. But after this, I tried to find a strong cell (I used a Blackberry 9300 for this, it has a nice engineering screen). I found cells from -76 dbm to -104 dbm. I tried them all with the "stick xxx" option, but still, the phone does not sync to this cells. The last thing I tried was using the binaries a friend provided me. He compiled the code on his computer, he tested those binaries at his home, with his Pirelli, and it worked: he could sync. He sent me those same binaries, but still no luck, the phone cannot sync. I have tried this on 4 different computers, 2 different versions of Ubuntu, on Debian, and on a Mac. It doesn't seem it's an operating system problem, but I wanted to test it anyway. The only thing it's different from you it's I live in the Caribbean, but I have GSM networks on all four bands. Now, if I use my sim on the Pirelli, with the original firmware, it works. I can even make a call, so I think it's not a hardware problem. I tested with Nokia C118 on a 850Mhz network, but same story. I'm posting my mobile.cfg file, and some logs. Thank you for your help.

12 years, 5 months

1
0
0 0

Re: delay in SIM reader interrupt handler

by Dieter Spaar

Hello Andreas, On Tue, 01 Nov 2011 12:28:05 +0100, "jolly" <andreas(a)eversberg.eu> wrote: > > i removed the delay, and it works. i checked the tsm30 source code. it > also sets the IO to input right after writing the last TX byte. (i guess > that the controller will trigger the IO switching at the end of > transmission.) so why do we need that delay? are there any problems? I can't tell you exactly what went wrong (it was months ago that I worked on this part). But most certainly one of my Test SIMs did not work without this delay. So I would suggest to leave a comment at this place in case problems with certain SIMs occur. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

12 years, 5 months

1
0
0 0

delay in SIM reader interrupt handler

by jolly

hi dieter, i like to clean up and merge the sim reader code with master branch. while looking at the code i found a delay_ms(1) in interrupt handler: ------- /* Used by: calypso_sim_transmit() to transmit the data */ if(regVal & REG_SIM_IT_SIM_TX) { #if (SIM_DEBUG == 1) puts(" Waiting for transmit...\n"); #endif if(sim_tx_character_count >= sim_tx_character_length) { txDoneFlag = 1; } else { writew(*tx_buffer,REG_SIM_DTX); tx_buffer++; sim_tx_character_count++; #if 1 /* Dieter: set to 0 to get problems with some cards */ /* its essential to immediately switch to RX after TX is done */ if(sim_tx_character_count >= sim_tx_character_length) { /* TODO: set a proper delay here, 4 is to long if not debugging and no delay is too short */ delay_ms(1); /* Switch I/O direction to input */ writew(readw(REG_SIM_CONF1) & ~REG_SIM_CONF1_CONFTXRX, REG_SIM_CONF1); } #endif } } --------- i removed the delay, and it works. i checked the tsm30 source code. it also sets the IO to input right after writing the last TX byte. (i guess that the controller will trigger the IO switching at the end of transmission.) so why do we need that delay? are there any problems? regards, andreas

12 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel November 2011