baseband-devel

baseband-devel@lists.osmocom.org

2023 discussions

Pirelli DP-L10 support, steve-m/testing branch
by Steve Markgraf 20 Jan '11

20 Jan '11

Hi all, last weekend I have grinded down a DP-L10 pcb and traced the TSPACT wiring of this board. I've added support for this phone, along with a few other changes in my branch steve-m/testing. Changes include: * Add support for Pirelli DP-L10 * Add TX support for the gta0x devices * separate board images for the Compal E86 (Motorola C139/C140) (display/keypad backlight now works by default) If anyone wants to test those changes (especially the freerunner TX support, since I have no freerunner), please feel free to do so. I tested the other changes and didn't find any regressions, so if no one else does, we can merge it to master soon. One thing I noticed during testing: The C139/C140 seem to have a different SYSTEM_INHERENT_GAIN, I compared the RX levels of several C118/C123/C155 with several C139/C140, and the reported rx level was always at around 18-20dBm worse than with the C123. Regards, Steve

1 1

radio is not started
by Muhammad Rasyid Sahputra 20 Jan '11

20 Jan '11

Hi, I tried to follow instruction on SIM Reader wiki, but seems I got different result. OsmocomBB> enable OsmocomBB# sim reader 1 OsmocomBB# show subscriber Mobile Subscriber of MS '1': IMSI: Status: U2_NOT_UPDATED IMSI detached LAI: invalid Access barred cells: no Access classes: OsmocomBB# show support Supported features of MS '1': Phase 2 mobile station R-GSM : yes E-GSM : yes P-GSM : yes GSM900 Class: 4 DCS 1800 : yes DCS Class : 1 CECS : no VGCS : no VBS : no SMS : yes SS_IND : yes PS_CAP : no CMSP : no SoLSA : no LCSVA : no LOC_SERV : no A5/1 : yes A5/2 : yes A5/3 : no A5/4 : no A5/5 : no A5/6 : no A5/7 : no A5/1 : yes Channels : SDCCH + TCH/F + TCH/H Full-Rate V1: yes Full-Rate V2: yes Full-Rate V3: no Half-Rate V1: yes Half-Rate V3: no Min RXLEV : -106 OsmocomBB# show ms MS '1' is down, radio is not started IMEI: 000000000000000 IMEISV: 0000000000000000 IMEI generation: fixed automatic network selection state: A0 null cell selection state: C0 null radio ressource layer state: idle mobility management layer state: MM idle, PLMN search from the layer23 part, $ ./mobile -i 127.0.0.1 -d Copyright (C) 2008-2010 ... Contributions by ... License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. mobile: option requires an argument -- d VTY available on port 4247. No Mobile Station defined, creating: MS '1' <000e> sim.c:1206 init SIM client <0005> gsm48_cc.c:61 init Call Control <0001> gsm48_rr.c:4944 init Radio Ressource process <0004> gsm48_mm.c:1220 init Mobility Management process <0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM. <0002> gsm322.c:3471 init PLMN process <0003> gsm322.c:3472 init Cell Selection process <0003> gsm322.c:3526 No stored BA list Mobile '1' initialized, please start phone now! <0004> subscriber.c:556 Requesting SIM file 0x2fe2 <000e> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004) <000e> sim.c:697 go MF <000e> sim.c:241 SELECT (file=0x3f00) <000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) can't perform location update, and from the error, is that mean the application failed to read the simcard correctly? and what's the meaning of "Mobile '1' initialized, please start phone now!", is it starting the phone by push the power button? if so, since the firmware is loaded I can't make the phone start like using original firmware. If i push the button, it will show message like Found flash of 2097152 bytes at 0x0 with 2 regions Region 0 of 31 pages with 65536 bytes each. Region 1 of 8 pages with 8192 bytes each. key=20 pressed Powering off due to keypress. I am using motorola c118 anw. any clue about this error? Thanks. Best Regards, Rasyid

1 0

USB fetmocell: What's about the sofware?
by Fabio Pietrosanti (naif) 19 Jan '11

19 Jan '11

Hi all, i noticed that article http://www.eetimes.com/electronics-news/4212228/Picochip-shares-femtocell-r… speaking about 3G basestation on USB dongle. That's really cool, i don't know about the hardware, but for sure when those device will be out the hacking perspective would be really interesting for projects like OpenBSC and OsmocomBB . -naif

1 0

sim reader code / master branch / ...
by Harald Welte 19 Jan '11

19 Jan '11

Hi all! In order to avoid the most common problems, I propose exporting something like a feature bitmask on the L1CTL, i.e. * L1CTL user code (layer23) can send a L1CTL_GET_FEAT_REQ request * laye1 in the phone sends a L1CTL_GET_FEAT_RESP with all the bits set to 1 for the features it supports * L1CTL user code (layer23) can then check if all the features it needs are supported by the L1. IF not, it can simply abort or print a warning to the user. We can simply extend the size of the bitmask over time if we need more bits. Obvious bits I would consider are: - is this firmware compiled with TX support? - does this firmware contain a SIM reader driver? - does this firmware support BURST_IND? Maybe we could also include a static header containing a compile timestamp or the git date/revision that the firmware was built, as well as a name of the board. Now I know, nice idea, who will implement it? I currently have othe priorities, but if somebody lurking on this list is looking for a relatively simple way to contribute back to the project (without knowing anything about GSM!) this might be something useful you could do. Thanks in advance, 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)

4 5

Re: wiki: SIMReader Was: Sim on C115 & C118
by Dobrica Pavlinusic 19 Jan '11

19 Jan '11

On Mon, Jan 17, 2011 at 11:46:50AM -0800, Bogdan Alecu wrote: > Hello, > > Sorry for writing you directly to your email. Thank you very much for the wiki. I was wondering if you have some knowledge about the "sim test" mode. I tried it by filling in the IMSI and MCC MNC. After I start the layer2 in a few seconds layer1 crashes. What I am trying to achieve is to send a IMSI detach to the network for the specified IMSI. Maybe you could give me a hand with this. This is often second question after getting SIM working, so I want to share what I know. However, I'm not an expert, and most of this is gathered from presentations and speaking with people who know more than I do, so I wanted to bounce this against mailing list for additional comments. As far as I understand it, to connect to provider network, you need provider's ki which is shared secret between network and sim card. There are some practical attacks on older sim cards which are used by multi-network sim cards. It seems there is limited number of brute-force interations that cards support before disabling themself and that changed somehow in recent cards. Best SIM explanation I found so far is on 27C3 wiki about GSM network: http://events.ccc.de/congress/2010/wiki/GSM#Why_do_I_need_to_buy_your_SIM_c… > --- On Mon, 1/17/11, Dobrica Pavlinusic <dpavlin(a)rot13.org> wrote: > > > From: Dobrica Pavlinusic <dpavlin(a)rot13.org> > Subject: wiki: SIMReader Was: Sim on C115 & C118 > To: "Bogdan Alecu" <b.alecu(a)yahoo.com> > Cc: dario.lombardo(a)libero.it, baseband-devel(a)lists.osmocom.org > Date: Monday, January 17, 2011, 7:05 PM > > > On Mon, Jan 17, 2011 at 10:24:51AM -0800, Bogdan Alecu wrote: > > I was going to ask the same question because I have same problem with sim reader mode. However I haven't used Sylvain test. I will and come back with an update. > > There seems to be sufficiant interest for using SIM reader, so I created > page on wiki which might serve as good pointer: > > http://bb.osmocom.org/trac/wiki/SIMReader > > -- > Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org > Unix addict. Internet consultant. http://www.rot13.org/~dpavlin > > > > -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

4 6

Why my C118 can't send DOWNLOAD ACK?
by xuchenyu 18 Jan '11

18 Jan '11

~/src/osmocom-bb/src/host/osmocon$ ./osmocon -p /dev/ttyUSB0 -m c123 ../../target/firmware/board/compal_e88/layer1.compalram.bin got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 2f / got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 1b . got 2 bytes from modem, data looks like: f6 02 .. got 1 bytes from modem, data looks like: 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 read_file(../../target/firmware/board/compal_e88/layer1.compalram.bin): file_size=50932, hdr_len=4, dnload_len=50939 got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 43 C Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/50939) handle_write(): 4096 bytes (8192/50939) handle_write(): 4096 bytes (12288/50939) handle_write(): 4096 bytes (16384/50939) handle_write(): 4096 bytes (20480/50939) handle_write(): 4096 bytes (24576/50939) handle_write(): 4096 bytes (28672/50939) handle_write(): 4096 bytes (32768/50939) handle_write(): 4096 bytes (36864/50939) handle_write(): 4096 bytes (40960/50939) handle_write(): 4096 bytes (45056/50939) handle_write(): 4096 bytes (49152/50939) handle_write(): 1787 bytes (50939/50939) handle_write(): finished It stopped here for very long time, I have tried with XOR and without XOR for many times! Please help me to verify this issue! thanks very much! -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Why-my-C118-can-t-send-DOWNLOAD-… Sent from the baseband-devel mailing list archive at Nabble.com.

2 1

Toolchain tests, problems and a few workarounds...
by Wolfram Sang 18 Jan '11

18 Jan '11

Hi, at 27c3, I tested some toolchains with osmocom-bb and found a few build-problems, even with the recommended gnuarm-3.4.3. I want to document them here, so other people can find hints about it. *** GNUARM 3.4.3 TOOLCHAIN master branch ============= ../../src/rate_ctr.c:24:22: inttypes.h: No such file or directory Holger suggested to manually remove this line. It is fixed upstream in libosmocore and osmocom-bb needs to be synced to it. Please do :) remotes/origin/steve-m/loader_sciphone ====================================== 1) First problem is: In file included from ../../include/osmocore/msgb.h:23, from ../../src/msgb.c:27: /home/wsa/Dev/osmocom-bb/src/target/firmware/include/stdint.h:13:25: stdint.h: No such file or directory Cherry-picking e0a605819c39187a494e43cf591f2e79a9d9903f (stdint.h: Next attempt at making this work with various compilers) helps. 2) It then runs into the problem of the master branch. 3) After this is fixed, I get ../../../src/codec/gsm610.c:24:20: stdint.h: No such file or directory ../../../src/codec/gsm610.c:33: error: parse error before "gsm610_bitorder" which needs 733c894c18c127ce5c023e39609b7d2b9e748e7e (build: Use absolute path in the CFLAGS for libosmocore target build) as a fix. 4) This then, leads to: arm-elf-ld: address 0x400054d4 of board/mt62xx/loader.mtkram.elf section .text is not within region LRAM which is sadly also present when you just cherry-pick the main patch d04761d19c432201f7c0f10c72f788fb695d466a ([WIP] Modify loader for use as first stage bootloader on MT62xx devices) on top of current master + its build fix. So, does it seem sensible to simply rebase this branch to master which would eliminate the first three problems? Or at least cherry-pick the above fixes? Also, the workarounds for gcc3 do not look very sustainable (see custom stdint.h). Is it a mid-term option to remove that stuff if a reliable pre-built gcc4 is available? (I am working on that, see below). BTW the linker error was not further worked on yet. I got a prebuilt binary now. It is possibly helpful to put it on the G2-wikipage, so people wanting to work on the Linux-support only are spared from the above hassle. *** CUSTOM 4.3.2 TOOLCHAIN every branch ============ The configure-stage of libosmocom already fails for the target with error 77. The config.log says in detail: configure:3231: checking whether the C compiler works configure:3253: arm-elf-gcc -Os -ffunction-sections -I/home/wsa/Dev/osmocom-bb/src/target/firmware/include conftest.c >&5 /home/opt/OSELAS.Toolchain-1.99.3/arm-elf/gcc-4.3.2-newlib-1.16.0-binutils-2.18/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libc.a(lib_a-exit.o): In function `exit': /home/mkl/himalia-pengutronix/toolchain/releases/OSELAS.Toolchain-1.99.3.6/platform-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18/build-target/newlib-1.16.0/newlib/libc/stdlib/exit.c:65: undefined reference to `_exit' /home/opt/OSELAS.Toolchain-1.99.3/arm-elf/gcc-4.3.2-newlib-1.16.0-binutils-2.18/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r': /home/mkl/himalia-pengutronix/toolchain/releases/OSELAS.Toolchain-1.99.3.6/platform-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18/build-target/newlib-1.16.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk' 27c3 was too interesting ;) so I haven't fixed this yet. The Mac-toolchains also throw this and I also have seen it on the list before, so I hope I can work on it the next days. So much for now. It would be nice if someone with write-access to the repo could comment on my questions and/or fix the low-hanging fruits. I will hopefully be able to send some updates soon, too (famous last words). It was great to meet you all in person! All the best, Wolfram

1 1

Re: R: Re: C115 loader.compalram.bin
by Tomas Kopsa 18 Jan '11

18 Jan '11

Hi Lia, I have tested another cable (USB <-> 2,5 jack, speacial for Compal phones) - it is the same chip (Prolific) and I am able to load firmware too. Although it is the same chip, there is a difference that this one makes the osmocon printing those messages instantly when phone is not connected: got 1 bytes from modem, data looks like: f5 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: f5 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: f5 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: fd . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: f5 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: fd . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ea . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ea . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ea . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ea . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: fd . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ea If I connect phone, printing stops. Here is what happened when I tried to load firmware without xor (-m c123) and pressed the button: (This happened every attempt without xor flag) Received PROMPT2 from phone, starting download handle_write(): 1087 bytes (1087/50947) got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 45 E got 1 bytes from modem, data looks like: 53 S got 1 bytes from modem, data looks like: 16 . Received DOWNLOAD NACK from phone, something went wrong :( 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 . If you have USB adapter (I guess you have), you dont need to check model, check 'lsusb' [root@amilo osmocon]# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub *Bus 002 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port* If you have Prolific, which is very common, I encourage you to use xor flag. You can also try to switch on your phone to check if original firmware boots. I experienced during my early tests, that phone crashed (probably SRAM) and it was unable to boot even original fw. In case phone is crashed, reconnect battery and it will fix itself. Here is the ACK after hello world load: handle_write(): 768 bytes (17919/19787) handle_write(): 768 bytes (18687/19787) handle_write(): 768 bytes (19455/19787) handle_write(): 332 bytes (19787/19787) handle_write(): finished got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 03 . got 1 bytes from modem, data looks like: 42 B Received DOWNLOAD ACK from phone, your code is running now! OSMOCOM Hello World (revision osmocon_v0.0.0-754-gb5abcb6-modified) ====================================================================== Device ID code: 0xb4fb Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Die ID code: efce3b1ce1001255 ====================================================================== REG_DPLL=0x2413 CNTL_ARM_CLK=0xf0a1 CNTL_CLK=0xff91 CNTL_RST=0xfff3 CNTL_ARM_DIV=0xfff9 ============================================== Looking forward your response, Tomas > Hi Tomas, > > thanks for your feedback. > > Actually, I've tried both flags (woth/without xor extension), but hte > result is the same. > > So, in your opinioni, the problem could depend on the cable? > > I don't have the cable model now, but I can send you this information > Tuesday. > > Thanks again. > > cheers. > > lia > > ----Messaggio originale---- > Da: deacon(a)volny.cz > Data: 16-gen-2011 4.26 > A: <list_mailing(a)libero.it> > ubut Ogg: Re: C115 loader.compalram.bin > > Hello, > I have C115 too and I use '-m c123xor' switch, the phone mostly > boots on 1st button push (I never reacher full load with '-m c123'). > > ./osmocon -p /dev/ttyUSB0 -m c123xor > ../../target/firmware/board/compal_e88/hello_world.compalram.bin > ./osmocon -p /dev/ttyUSB0 -m c123xor > ../../target/firmware/board/compal_e88/loader.compalram.bin > ./osmocon -p /dev/ttyUSB0 -m c123xor > ../../target/firmware/board/compal_e88/layer1.compalram.bin > > I have FTDI USB<->RS232 + Calypso serial. When load fails (with > xor), I have a feeling that it helps reconnection cable to the phone. > (I have also Calypso USB cable which I haven't tested yet, will > report later.) > > - Tomas > > >>> Hello. >>> I'm trying to load the loader.compalram.bin. >>> The behaviour is very strange because sometimes the download is complete and >>> successfull, sometimes; in particular, in this case, the download is complete, >>> but any ACK is sent back from the mobile phone (see below). >>> ./osmocon -p /dev/ttyUSB0 -m c123 ../.. >>> /target/firmware/board/compal_e99/loader.compalram.bin >>> got 2 bytes from modem, data looks like: 2e c8 .. >>> got 5 bytes from modem, data looks like: 1b f6 02 00 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 >>> read_file(../../target/firmware/board/compal_e99/loader.compalram.bin): >>> file_size=21752, hdr_len=4, dnload_len=21759 >>> got 1 bytes from modem, data looks like: 1b . >>> got 1 bytes from modem, data looks like: f6 . >>> got 1 bytes from modem, data looks like: 02 . >>> got 1 bytes from modem, data looks like: 00 . >>> got 1 bytes from modem, data looks like: 41 A >>> got 1 bytes from modem, data looks like: 02 . >>> got 1 bytes from modem, data looks like: 43 C >>> Received PROMPT2 from phone, starting download >>> handle_write(): 4096 bytes (4096/21759) >>> handle_write(): 4096 bytes (8192/21759) >>> handle_write(): 4096 bytes (12288/21759) >>> handle_write(): 4096 bytes (16384/21759) >>> handle_write(): 4096 bytes (20480/21759) >>> handle_write(): 1279 bytes (21759/21759) >>> handle_write(): finished >>> >>> >>> The target phone is C115. I tried compal_exx and the result is the same :-( >>> >>> Please, can someone help me to understand the reasons? >>> Thanks in advance. >>> >>> >>> >>> >> > > >

6 6

[PATCH] Makefile: be more robust against toolchains without syscalls
by Michael Grzeschik 18 Jan '11

18 Jan '11

Several toolchains are missing syscalls provided by the libc used. For example, if the newlib was build with the configure flag "--disable-newlib-supplied-syscalls". To prevent the configure check for things like "_exit" in osmocom the CFLAGS+="-nostartfiles -nodefaultlibs" helps a lot. Signed-off-by: Michael Grzeschik <mgr(a)xviews.de> Acked-by: Wolfram Sang <wolfram(a)the-dreams.de> --- src/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/Makefile b/src/Makefile index a0dea5d..b3594c1 100644 --- a/src/Makefile +++ b/src/Makefile @@ -39,7 +39,7 @@ shared/libosmocore/build-target/Makefile: shared/libosmocore/configure shared/li cd shared/libosmocore/build-target && ../configure \ --host=arm-elf-linux --disable-vty --enable-panic-infloop \ --disable-shared --disable-talloc --disable-tests \ - CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include" + CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs" shared/libosmocore/build-target/src/.libs/libosmocore.a: shared/libosmocore/build-target/Makefile cd shared/libosmocore/build-target && make -- 1.7.2.3

3 2

AW: you know phone maybe can made USRP
by Andreas.Eversberg 18 Jan '11

18 Jan '11

sylvain, looks like you are talking to a spam bot. (harald already did earlier :)

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel