baseband-devel

baseband-devel@lists.osmocom.org

1981 discussions

by chekov

hi, i'd like to do some more c118 testing. the only tool i further got to work was l1test.bin[1]. the others were downloaded correctly but ended up /blue/ :) is it worth the time to make some tests with older object-code-versions? otherwise i will investigate what happens to compal_dump.bin[1], because this one answers with some "Dropping sample" lines. attachments: [1] l1test.bin.txt [2] compal_dump.bin.txt l1test.bin $ ../osmocom-bb/src/host/osmocon/osmocon -m c123 -p /dev/ttyUSB0 ../osmocom-bb/src/target/firmware/l1test.bin got 1 bytes from modem, data looks like: 04 got 1 bytes from modem, data looks like: 81 got 5 bytes from modem, data looks like: 1b f6 02 00 41 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(../osmocom-bb/src/target/firmware/l1test.bin): file_size=31836, hdr_len=4, dnload_len=31843 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 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 43 Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/31843) handle_write(): 4096 bytes (8192/31843) handle_write(): 4096 bytes (12288/31843) handle_write(): 4096 bytes (16384/31843) handle_write(): 4096 bytes (20480/31843) handle_write(): 4096 bytes (24576/31843) handle_write(): 4096 bytes (28672/31843) handle_write(): 3171 bytes (31843/31843) 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 got 1 bytes from modem, data looks like: 03 got 1 bytes from modem, data looks like: 42 Received DOWNLOAD ACK from phone, your code is running now! Hello World from apps/l1test/main.c program code ====================================================================== Device ID code: 0xb4fb Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Die ID code: <snip> ====================================================================== REG_DPLL=0x2413 CNTL_ARM_CLK=0xf0a1 CNTL_CLK=0xff91 CNTL_RST=0xfff3 CNTL_ARM_DIV=0xfff9 ====================================================================== Assert DSP into Reset Releasing DSP from Reset Setting some dsp_api.ndb values Setting API NDB parameters DSP Download Status: 0x0001 DSP API Version: 0x822e 0x08bf Finishing download phase DSP Download Status: 0x0002 DSP API Version: 0x3606 0x0000 Performing power measurement over GSM900 LOST!ARFCN Top 10 Rx Level ARFCN 26: -57 dBm ARFCN 64: -58 dBm ARFCN 104: -59 dBm ARFCN 80: -64 dBm ARFCN 71: -75 dBm ARFCN 77: -76 dBm ARFCN 123: -77 dBm ARFCN 111: -78 dBm ARFCN 121: -78 dBm ARFCN 114: -88 dBm Starting FCCH Recognition FB0 (379:5): TOA= 5040, Power= -59dBm, Angle= 1044Hz =>FB @ FNR 378 fn_offset=378 qbits=68 FB1 (390:2): TOA= 1251, Power= -60dBm, Angle= 259Hz =>FB @ FNR 388 fn_offset=388 qbits=4912 FB1 (400:2): TOA= 1251, Power= -61dBm, Angle= 68Hz =>FB @ FNR 398 fn_offset=398 qbits=4912 FB1 (410:2): TOA= 1251, Power= -63dBm, Angle= 35Hz =>FB @ FNR 408 fn_offset=408 qbits=4912 FB1 (420:2): TOA= 1243, Power= -65dBm, Angle= -13Hz =>FB @ FNR 418 fn_offset=418 qbits=4880 FB1 (430:2): TOA= 1251, Power= -66dBm, Angle= 5Hz =>FB @ FNR 428 fn_offset=428 qbits=4912 FB1 (441:3): TOA= 2503, Power= -67dBm, Angle= 17Hz =>FB @ FNR 439 fn_offset=439 qbits=4920 FB1 (451:2): TOA= 1299, Power= -69dBm, Angle= 2Hz =>FB @ FNR 450 fn_offset=450 qbits=104 FB1 (471:11): TOA=12567, Power= -69dBm, Angle= 21Hz =>FB @ FNR 470 fn_offset=470 qbits=176 FB1 (492:12): TOA=13675, Power= -68dBm, Angle= -31Hz =>FB @ FNR 490 fn_offset=490 qbits=4608 FB1 (502:2): TOA= 1251, Power= -68dBm, Angle= 14Hz =>FB @ FNR 500 fn_offset=500 qbits=4912 FB1 (512:2): TOA= 1299, Power= -68dBm, Angle= 6Hz =>FB @ FNR 511 fn_offset=511 qbits=104 FB1 (532:11): TOA=12555, Power= -66dBm, Angle= 7Hz =>FB @ FNR 531 fn_offset=531 qbits=128 FB1 (543:2): TOA= 1275, Power= -67dBm, Angle= 26Hz =>FB @ FNR 542 fn_offset=542 qbits=8 FB1 (563:11): TOA=12503, Power= -67dBm, Angle= -13Hz =>FB @ FNR 561 fn_offset=561 qbits=4920 FB1 (573:2): TOA= 1243, Power= -67dBm, Angle= 15Hz =>FB @ FNR 571 fn_offset=571 qbits=4880 FB1 (583:2): TOA= 1251, Power= -67dBm, Angle= 9Hz =>FB @ FNR 581 fn_offset=581 qbits=4912 FB1 (594:3): TOA= 2503, Power= -67dBm, Angle= 3Hz =>FB @ FNR 592 fn_offset=592 qbits=4920 FB1 (604:2): TOA= 1251, Power= -67dBm, Angle= 22Hz =>FB @ FNR 602 fn_offset=602 qbits=4912 FB1 (614:2): TOA= 1251, Power= -67dBm, Angle= 10Hz =>FB @ FNR 612 fn_offset=612 qbits=4912 FB1 (624:2): TOA= 1243, Power= -67dBm, Angle= -1Hz =>FB @ FNR 622 fn_offset=622 qbits=4880 FB1 (634:2): TOA= 1251, Power= -66dBm, Angle= -14Hz =>FB @ FNR 632 fn_offset=632 qbits=4912 FB1 (645:3): TOA= 2499, Power= -66dBm, Angle= 0Hz =>FB @ FNR 643 fn_offset=643 qbits=4904 FB1 (655:2): TOA= 1295, Power= -66dBm, Angle= 17Hz =>FB @ FNR 654 fn_offset=654 qbits=88 FB1 (675:11): TOA=12515, Power= -66dBm, Angle= -23Hz =>FB @ FNR 673 fn_offset=673 qbits=4968 FB1 (685:2): TOA= 1251, Power= -66dBm, Angle= 14Hz =>FB @ FNR 683 fn_offset=683 qbits=4912 FB1 (696:3): TOA= 2503, Power= -66dBm, Angle= 0Hz =>FB @ FNR 694 fn_offset=694 qbits=4920 FB1 (706:2): TOA= 1251, Power= -67dBm, Angle= 13Hz =>FB @ FNR 704 fn_offset=704 qbits=4912 FB1 (716:2): TOA= 1295, Power= -68dBm, Angle= 17Hz =>FB @ FNR 715 fn_offset=715 qbits=88 FB1 (736:11): TOA=12443, Power= -68dBm, Angle= -23Hz =>FB @ FNR 734 fn_offset=734 qbits=4680 FB1 (747:3): TOA= 2527, Power= -68dBm, Angle= 22Hz =>FB @ FNR 746 fn_offset=746 qbits=16 FB1 (767:11): TOA=12503, Power= -69dBm, Angle= -15Hz =>FB @ FNR 765 fn_offset=765 qbits=4920 FB1 (777:2): TOA= 1203, Power= -69dBm, Angle= 19Hz =>FB @ FNR 775 fn_offset=775 qbits=4720 FB1 (787:2): TOA= 1311, Power= -70dBm, Angle= 5Hz =>FB @ FNR 786 fn_offset=786 qbits=152 FB1 (798:2): TOA= 1251, Power= -70dBm, Angle= 17Hz =>FB @ FNR 796 fn_offset=796 qbits=4912 FB1 (808:2): TOA= 1199, Power= -71dBm, Angle= 17Hz =>FB @ FNR 806 fn_offset=806 qbits=4704 FB1 (818:2): TOA= 1251, Power= -71dBm, Angle= -18Hz =>FB @ FNR 816 fn_offset=816 qbits=4912 FB1 (828:2): TOA= 1299, Power= -72dBm, Angle= 2Hz =>FB @ FNR 827 fn_offset=827 qbits=104 FB1 (849:12): TOA=13675, Power= -69dBm, Angle= -13Hz =>FB @ FNR 847 fn_offset=847 qbits=4608 FB1 (859:2): TOA= 1299, Power= -69dBm, Angle= 14Hz =>FB @ FNR 858 fn_offset=858 qbits=104 FB1 (879:11): TOA=12503, Power= -69dBm, Angle= -36Hz =>FB @ FNR 877 fn_offset=877 qbits=4920 FB1 (889:2): TOA= 1243, Power= -68dBm, Angle= 35Hz =>FB @ FNR 887 fn_offset=887 qbits=4880 FB1 (900:3): TOA= 2555, Power= -68dBm, Angle= 24Hz =>FB @ FNR 899 fn_offset=899 qbits=128 FB1 (920:11): TOA=12451, Power= -69dBm, Angle= -28Hz =>FB @ FNR 918 fn_offset=918 qbits=4712 FB1 (930:2): TOA= 1251, Power= -69dBm, Angle= 7Hz =>FB @ FNR 928 fn_offset=928 qbits=4912 FB1 (940:2): TOA= 1195, Power= -69dBm, Angle= 11Hz =>FB @ FNR 938 fn_offset=938 qbits=4688 FB1 (951:3): TOA= 2523, Power= -69dBm, Angle= 6Hz =>FB @ FNR 950 fn_offset=950 qbits=0 FB1 (971:11): TOA=12547, Power= -71dBm, Angle= 3Hz =>FB @ FNR 970 fn_offset=970 qbits=96 FB1 (991:11): TOA=12567, Power= -75dBm, Angle= 18Hz =>FB @ FNR 990 fn_offset=990 qbits=176 FB1 (1032:4): TOA= 3803, Power= -75dBm, Angle= -10Hz =>FB @ FNR 1031 fn_offset=1031 qbits=120 Synchronize_TDMA LOST!SB2 (2711:1684): TOA= 17, Power= -60dBm, Angle= 1738Hz => SB 0x00089797: BSIC=37 fn=2438464(1838/ 2/ 1) qbits=4976 SB2 (2444039:7257): TOA= 22, Power= -58dBm, Angle=-2015Hz => SB 0x012f13ff: BSIC=63 fn=2087603(1574/11/71)=> DSP reports SB in bit that is 1239921045 bits in the future?!? SB1 (2090933:10585): TOA= 9, Power= -59dBm, Angle= 1849Hz => SB 0x00a58606: BSIC=1 fn=1715151(1293/ 9/21)=> DSP reports SB in bit that is 1681302282 bits in the future?!? SB2 (1718584:14016): TOA= 16, Power= -54dBm, Angle= 1703Hz => SB 0x00089797: BSIC=37 fn=2438464(1838/ 2/ 1)=> DSP reports SB in bit that is 2146739789 bits in the future?!? SB1 (2446030:21580): TOA= 2, Power= -58dBm, Angle= 1683Hz => SB 0x00c30b0c: BSIC=3 fn=31528(23/16/61)=> DSP reports SB in bit that is 1237431025 bits in the future?!? SB2 (44003:34053): TOA= 22, Power= -57dBm, Angle= -5Hz => SB 0x0148ca37: BSIC=13 fn=2573420(1940/18/11) qbits=4996 Synchronize_TDMA LOST!SB2 (2573793:34424): TOA= 37, Power= -56dBm, Angle= -836Hz => SB 0x00a3a0ab: BSIC=42 fn=2462494(1857/ 8/61)=> DSP reports SB in bit that is 1077728560 bits in the future?!? SB1 (2471920:43848): TOA= 35, Power= -58dBm, Angle= -552Hz => SB 0x00090ea8: BSIC=42 fn=38118(28/ 2/21)=> DSP reports SB in bit that is 1205068558 bits in the future?!? works, powerbutton works lcd shows l1test.bin $ ../osmocom-bb/src/host/osmocon/osmocon -m c118 -p /dev/ttyUSB0 ../osmocom-bb/src/target/firmware/compal_dump.bin got 2 bytes from modem, data looks like: 04 81 got 5 bytes from modem, data looks like: 1b f6 02 00 41 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(../osmocom-bb/src/target/firmware/compal_dump.bin): file_size=10264, hdr_len=0, dnload_len=10267 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 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 43 Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/10267) handle_write(): 4096 bytes (8192/10267) handle_write(): 2075 bytes (10267/10267) 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 got 1 bytes from modem, data looks like: 03 got 1 bytes from modem, data looks like: 42 Received DOWNLOAD ACK from phone, your code is running now! Dropping sample 'm' Dropping sample 'p' Dropping sample 'a' Dropping sample 'l' Dropping sample ' ' Dropping sample 'd' Dropping sample 'e' Dropping sample 'v' Dropping sample 'i' Dropping sample 'c' Dropping sample 'e' Dropping sample ' ' Dropping sample 'd' Dropping sample 'a' Dropping sample 't' Dropping sample 'a' Dropping sample ' ' Dropping sample 'd' Dropping sample 'u' Dropping sample 'm' Dropping sample 'p' Dropping sample 'e' Dropping sample 'r' Dropping sample ' ' hangs, blue

15 years, 4 months

Re: hello_world.bin on C118

by Dieter Spaar

Hello Chekov, On Mon, 01 Mar 2010 02:04:13 +0100, "chekov" <chekov(a)riseup.net> wrote: > but now i'm stuck, because i get no feedback from the phone, except that > the display lights up blue. I think the problem is related to this: > Received PROMPT2 from phone, starting download > handle_write(): 4096 bytes (4096/16503) > handle_write(): 4096 bytes (8192/16503) > handle_write(): 4096 bytes (12288/16503) > handle_write(): 4096 bytes (16384/16503) > handle_write(): 119 bytes (16503/16503) > handle_write(): finished > handle_write(): 4096 bytes (4096/16503) <<<<----- this should not happen > got 1 bytes from modem, data looks like: 1b This probably means that the downloader does not receive a reply in time and continues to download the code. You can try to fix it with this modification: --- ./src/host/osmocon/osmocon.c Tue Feb 23 18:38:39 2010 +++ /src/host/osmocon/osmocon.c Mon Mar 01 07:59:22 2010 @@ -275,6 +275,7 @@ usleep(1); } else if (dnload.write_ptr >= dnload.data + dnload.data_len) { printf("finished\n"); + dnload.serial_fd.when = BSC_FD_READ; dnload.write_ptr = dnload.data; return 1; } As a consequence of still sending data to the phone, the firmware could crash because there was a bug which is already fixed in the latest GIT version. You can check if you already have the latest version: --- ./src/target/firmware/comm/msgb.c Tue Feb 23 18:38:39 2010 +++ /src/target/firmware/comm/msgb.c Sun Feb 28 11:22:57 2010 @@ -35,7 +35,11 @@ #ifdef NO_TALLOC /* This is a poor mans static allocator for msgb objects */ -#define MSGB_DATA_SIZE 256 +#define MSGB_DATA_SIZE 256+4 #define MSGB_NUM 16 struct supermsg { uint8_t allocated; Maybe the above helps to solve the problem. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years, 4 months

layer2/3 interface

by Harald Welte

Hi! I'm currently working on getting the integration between l1, l2 and l3 running. As it seems to me, using at least the RLL part of RSL as an interface between l2 and l3 seems to make a lot of sense. After all, it contains all information we need, such as timeslot/subslot/sapi/... and supports all the various {data,unit_data,establish}{{request,indication} messages. So my idea is to generate a RSL RLL message in L2 and send ot to L3 and vice versa. I'll commit it to the 'uplink' branch as soon as I have something useful. -- - 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)

15 years, 4 months

hello_world.bin on C118

by chekov

hi, i'm trying to follow this projects developement with my revived Motorola C118. The wiki helped me making the phone downloading the hello_world.bin file. but now i'm stuck, because i get no feedback from the phone, except that the display lights up blue. here is what osmocon prints when i make the phone downloading the hello_world.bin: $ ./host/osmocon/osmocon -m c118 -p /dev/ttyUSB0 target/firmware/hello_world.bin got 2 bytes from modem, data looks like: 04 81 got 5 bytes from modem, data looks like: 1b f6 02 00 41 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/hello_world.bin): file_size=16500, hdr_len=0, dnload_len=16503 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 got 1 bytes from modem, data looks like: 02 got 1 bytes from modem, data looks like: 43 Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/16503) handle_write(): 4096 bytes (8192/16503) handle_write(): 4096 bytes (12288/16503) handle_write(): 4096 bytes (16384/16503) handle_write(): 119 bytes (16503/16503) handle_write(): finished handle_write(): 4096 bytes (4096/16503) 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 got 1 bytes from modem, data looks like: 03 got 1 bytes from modem, data looks like: 42 Received DOWNLOAD ACK from phone, your code is running now! this also works with -m c118xor maybe you can create something like a user mailinglist if this kind of questions produces to much volume.

15 years, 4 months

Re: batter charging interface / iota madc block

by Dieter Spaar

Hello Joachim, On Sun, 28 Feb 2010 03:55:12 +0100, "Joachim Steiger" <roh(a)hyte.de> wrote: > > ps: according the the schem the vibra should be controlled by the auxdac > of iota. i poked it and some enable bit few minutes, but couldnt get it > doing anything. Have you turned the Auxiliary DAC on ? It has its own power control bit and bit 5 (ADACS) in TOGBR1 hat to be set to turn the Auxiliary DAC on. I just did a quick test with a C123, and the following seems to work: twl3025_reg_write(TOGBR1, 1 << 5); // turn ADAC on twl3025_reg_write(AUXDAC, 1000); delay_ms(1500); twl3025_reg_write(AUXDAC, 0); twl3025_reg_write(TOGBR1, 1 << 4); // turn ADAC off Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years, 4 months

batter charging interface / iota madc block

by Joachim Steiger

sorry for not writing anything earlier, but i'm currently moving so i'm a bit short of time. i have been working on the bci and madc block already, so if you are not already done, i'd like to do that. its a bit tricky since one needs to do quite a lot to charge the battery correctly, but in the end we could even charge nimh and i guess small lead batterys also if we want to (with different code). i have done the irq handlers, the charger plug in detection and the async madc stuff is already working. it just needs some cleanup before commit. about the bci stuff: i'm now done reading and understanding the iota datasheets and appnotes (the latter one having invaluable information not in the datasheets). 'just' need to get it written down in code and debug it. ;) summary: if you can live with charging your batteries for another week or 2, just try figuring out the ringer and or vibra for example ps: according the the schem the vibra should be controlled by the auxdac of iota. i poked it and some enable bit few minutes, but couldnt get it doing anything. so there is still a mystery or 2 left. kind regards -- roh

15 years, 4 months

Bootloader

by Ingo Albrecht

Hi everyone Without further introduction and in a similar manner to laforge's last mail I would like to note that I am working on a bootloader that will allow for larger binaries in RAM and flexible flashing. To avoid troublesome interaction between the Calypso bootrom (which we use for interrupt redirection) and CFI support, I have decided to go for an interrupt-less approach. So don't be surprised to see me committing a polling mode to fundamental drivers (keypad, uart) sometime soon. Luckily, the required changes are trivial. I'll push my branch sometime soon, just dropping a line to keep everyone informed. Feel free to drop a line in case you are interested in other flash-based tasks like hammering out linkage details and implementing some kind of filesystem. Greetings prom

15 years, 4 months

C155 display driver

by Harald Welte

Hi! Just to avoid any possible duplicate work: A member of this list already has a working C155 color display driver. So if you were thinking of working on this: Please rather do another TODO item. I'm supposed to be merging that driver during the next couple of days. Cheers, Harald p.s.: I'm back in Berlin now, will be working with zecke of getting layer2 (bi-directional) up and running. -- - 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)

15 years, 4 months

Motorola C200

by Tiago Maluta

Hi, First I'd like to thank all people involved with the project. I don't know about GSM but as Harald said [1] I can contribute with microcontroller development. I have an old functional Motorola C200 phone. I'd like to know if it's possible use it? I've search for some information about C200 baseband processor without success, so I'm asking in the list. [1] http://lists.osmocom.org/pipermail/baseband-devel/2010-February/000000.html --tm

15 years, 4 months

Re: [airprobe-main] Cell phone tracking using ss7 hlr lookups

by Karsten Nohl

Hi Yanis, I'm CCing the OsmoconBB list who could perhaps help setup a MSC-GPS data collector. On Feb 22, 2010, at 8:09 PM, Yanis Pavlidis wrote: > Hi all, > > not exactly related to airprobe itself, but I am sure people on this > list could answer my question. > So, after reading Tobias Engels' presentation on 25c3 ( http://events.ccc.de/congress/2008/Fahrplan/attachments/1262_25c3-locating-… > ), I found out you can perform an HLR lookup and come up with the > current MSC number that "controls" the connection of the subscriber, > for any subscriber. Yes, every telco company and VoIP provider with SS7 access in the world always knows where you are. Scary. > My question is, is this MSC number, visible from the mobile phone > side? If yes, somebody could actually wardrive, to get the MSC > number-to-location mapping? > Can airprobe, or OpenBTS help? Creating the {MSC -> location} mapping database would be a very worthwhile exercise. The data collection would have to happen from phones. Either we create an application for one of the popular phone platforms (Symbian, Android, iPhone). Anybody on the list knows if these phones expose the MSC number to application software? Alternative, the Osmocon project could probably expose the MSC information easily. The project is still in early stages and it will take a few months until a collector software could be running. I wonder if any of the supported Motorola phones have GPS? > Forgive my ignorance on all-things-gsm, I am just beginning exploring! Thanks for bringing up the topic! > Thanks all, > Yanis Cheers, -Karsten

15 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel