baseband-devel

baseband-devel@lists.osmocom.org

1 participants
2024 discussions

GSM overview
by Andreas.Eversberg 14 Mar '10

14 Mar '10

hi, i just found some valuable information this weekend at www.informatik.hu-berlin.de/~goeller/isdn/ an introduction into gsm tracing in german http://www.informatik.hu-berlin.de/~goeller/isdn/DieGSMDmKanaele.pdf and the same in english http://www.informatik.hu-berlin.de/~goeller/isdn/GSMDmChannels.pdf it gives a rough history of GSM development, GSM network structure, framing, encryption, coding, and services - in just 100 pages. for me it is usefull to verify my parsing of SYSTEM INFORMATION messages. it describes traces of the most importaint messages. andreas

1 0

Re: sercomm/osmocon cant send CMD after PROMPT1
by Dieter Spaar 14 Mar '10

14 Mar '10

Hello Nathan, On Sun, 14 Mar 2010 17:54:29 +0000, "Nathan Fain" <nat(a)fains.com> wrote: > > because i was on the python route I went ahead and wrote code all the way > through uploading. I was expecting I would get a NACK but instead I get > neither a NACK nor ACK but the following response after uploading hello > world. Just curious if anyone has ever seen this before: What you see looks like the strings inside the binary you send to the phone. So your download code either echoes back what you send or there is a problem with the cable (e.g. shortcut between RX and TX). The phone usually does not echo back what it receives, at least I never saw that. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

sercomm/osmocon cant send CMD after PROMPT1
by Nathan Fain 14 Mar '10

14 Mar '10

I'm running into a problem with sercomm. oscmocon is unable to write() the CMD after PROMPT1 is received. I've attached a quick python client that checks from PROMPT1 and then sends CMD to confirm that it responds and its not something with the local system (OSX). Relevant code with some added debugging: static int handle_read(void) { if (!memcmp(buffer, phone_prompt1, sizeof(phone_prompt1))) { printf("Received PROMPT1 from phone, responding with CMD\n"); dnload.print_hdlc = 0; dnload.state = WAITING_PROMPT2; rc = write(dnload.serial_fd.fd, dnload_cmd, sizeof(dnload_cmd)); /* not in src, added for debugging: */ if (rc <= 0) { printf("error writing CMD to serial\n"); exit(1); } ... $ ./osmocon -m c155 -p /dev/tty.usbserial \ ../../target/firmware/board/compal_e99/hello_world.bin got 1 bytes from modem, data looks like: 1b got 6 bytes from modem, data looks like: f6 02 00 41 01 40 Received PROMPT1 from phone, responding with CMD could not write CMD to serial Output from python script: (if you try this, be sure to set your serial port and change the python2.5 call on line 1) $ ./compalserialtest.py 115200 got byte(s) from phone: 1b got byte(s) from phone: f6 got byte(s) from phone: 02 got byte(s) from phone: 00 got byte(s) from phone: 41 got byte(s) from phone: 01 recieved PROMPT1 from phone. Writing CMD got byte(s) from phone: 1b got byte(s) from phone: f6 got byte(s) from phone: 02 got byte(s) from phone: 00 got byte(s) from phone: 41 got byte(s) from phone: 02 got byte(s) from phone: 43 -- cyphunk://cypherpoet.com nathan://squimp.com fain://deadhacker.com

2 2

Re: C123 crashing (?)
by Lubomir Schmidt 14 Mar '10

14 Mar '10

> On Fri, Mar 12, 2010 at 12:06:07PM +0100, Patrick McHardy wrote: > > 1) does hello_world.bin work for you at all? > No. Nothing works for me here

1 0

gsm_04_08.h
by Andreas.Eversberg 14 Mar '10

14 Mar '10

hi, here is one issue that stopped me today: sometimes l3 message headers includes protocol header: see struct gsm48_imm_ass and sometimes it is just the information element part: see struct gsm48_loc_upd_req since i work with layer 3 messages, i need a uniform way to define these headers. i will add new headers for messages i implement to gsm_04_08.h. therefore i need a decision. i prefer that the headers (like gsm48_imm_ass or gsm48_loc_upd_req) consists of the information elements parts only. i must put gsm48_hdr in front of it whenever i create a l3 message. when parsing that message, i must skip the information element part in the decoding function. when creating the message, i always add the l3 header (with it's content) and the information elements. creation would look like this struct msgb *msg = gsm48_msgb_alloc(); struct gsm48_hdr *gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh)); struct gsm48_imm_ass *ia = (struct gsm48_imm_ass *) msgb_put(msg, sizeof(*ia)); gh->protocol = .... gh->msg_type = .... parsing would look like this: struct gsm48_hdr *gh = msgb_l3(msg); struct gsm48_imm_ass *ia = gh->data; unsigned int payload_len = msgb_l3len(msg) - sizeof(*gh) - sizeof(ia); tlv_parse(&tp, &rsl_att_tlvdef, ia->data, payload_len, 0, 0); note: payload_len is where the TLV part of the information elements start. any suggestions? andreas

2 1

build issues on OSX
by Nathan Fain 14 Mar '10

14 Mar '10

first build, grabbed repository today. ran into some issues running make from src. ERROR 1 (snippits): cd host/layer23 && autoreconf -i cd host/layer23 && LIBOSMOCORE_LIBS=/osmocom-bb/src/shared/libosmocore/build-host/src/.libs/libosmocore.a LIBOSMOCORE_CFLAGS=-I/osmocom-bb/src/shared/libosmocore/include ./configure ./configure: line 3361: syntax error near unexpected token `LIBOSMOCORE,' ./configure: line 3461: `PKG_CHECK_MODULES(LIBOSMOCORE, libosmocore)' SOLUTION: i do have pkg-config installed, as well as aclocal 1.10. Commenting out line 3461 continues. Perhaps the errors that happen thereafter are a result of this. ERROR 2: cd host/osmocon && autoreconf -i cd host/osmocon && LIBOSMOCORE_LIBS=/osmocom-bb/src/shared/libosmocore/build-host/src/.libs/libosmocore.a LIBOSMOCORE_CFLAGS=-I/osmocom-bb/src/shared/libosmocore/include ./configure ./configure: line 3364: syntax error near unexpected token `LIBOSMOCORE,' ./configure: line 3364: `PKG_CHECK_MODULES(LIBOSMOCORE, libosmocore)' SOLUTION: same ERROR 3: arm-elf-ld -nostartfiles -nostdlib -nodefaultlibs --gc-sections -T board/common/compal_ramload.lds -Bstatic -Map board/compal_e88/hello_world.map -o board/compal_e88/hello_world.elf --start-group apps/hello_world/main.o board/common/compal_ramload_start.o abb/twl3025.o rf/trf6151.o display/font_r8x8.o display/font_r8x8_horiz.o display/st7558.o display/ssd1783.o display/display.o flash/cfi_flash.o calypso/libcalypso.a layer1/liblayer1.a lib/libmini.a comm/libcomm.a ../../shared/libosmocore/build-target/src/.libs/libosmocore.a board/common/rffe_compal_dualband.o board/compal_e88/init.o board/compal_e88/board.o --end-group calypso/libcalypso.a: could not read symbols: Archive has no index; run ranlib to add one make[1]: *** [board/compal_e88/hello_world.elf] Error 1 make: *** [firmware] Error 2 $ cd target/firmware/calypso/ $ ranlib libcalypso.a ranlib: warning for library: libcalypso.a the table of contents is empty (no object file members in the library define global symbols) Any clues? thanks -- cyphunk://cypherpoet.com nathan://squimp.com fain://deadhacker.com

5 8

Motorola C140 dissection
by Uwe Hermann 13 Mar '10

13 Mar '10

Hi, I've noticed there is no detailed info on the C140 in the wiki as the shielding is soldered on this model. I opened that one on my C140 today by force (ripping it apart, more or less), dunno yet if the phone survived but at least I got some nice photos of it now :-) I put the relevant info and photos up at my wiki: http://randomprojects.org/wiki/Motorola_C140 I don't think I have access to the bb.osmocom.org wiki, but feel free to merge any of the info or photos you like, all my C140 photos are in the public domain. Most of the hardware is very similar to the C123 as far as I can see. The display may be a small problem as it's a Toppoly TD014THEA3 for which I haven't yet found a datasheet. It probably has an integrated controller, or at least I didn't find an external controller on the PCB. I'll try to figure out some of the connections of the test pads on the PCB in the next few days, will report back when I know more. Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

1 0

C155 status
by Uwe Hermann 12 Mar '10

12 Mar '10

Hi, I've played a bit with osmocom on a C155 here, but there seems to be an issue with the UART/puts/printf code somewhere. I'm using latest git as of today. $ src/host/osmocon > ./osmocon -m c155 -p /dev/ttyUSB0 ../../target/firmware/board/compal_e99/hello_world.bin got 2 bytes from modem, data looks like: 00 00 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/board/compal_e99/hello_world.bin): file_size=18560, hdr_len=4, dnload_len=18567 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/18567) handle_write(): 4096 bytes (8192/18567) handle_write(): 4096 bytes (12288/18567) handle_write(): 4096 bytes (16384/18567) handle_write(): 2183 bytes (18567/18567) 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/hello_world/main.c program code At this point there seems to be a hang. However, it looks like the LCD is being partially initialized (?), at least the backlight is enabled and there's a white screen (no "Hello world" on it though). I assume this is because the display driver for C155 is not yet fully merged? Also, the wiki says "The LCD controller inside the display is a Ultrachip UC1682", is this really correct? The code has "ssd1783" as display driver name. Anyway, after removing a newline and some print functions I see some more output (see attached patch for what I changed), which is why I expect a problem in puts/printf, the UART, or the \n handling etc: $ src/host/osmocon > ./osmocon -m c155 -p /dev/ttyUSB0 ../../target/firmware/board/compal_e99/hello_world.bin got 7 bytes from modem, data looks like: 1b f6 02 00 41 01 40 Received PROMPT1 from phone, responding with CMD read_file(../../target/firmware/board/compal_e99/hello_world.bin): file_size=18404, hdr_len=4, dnload_len=18411 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/18411) handle_write(): 4096 bytes (8192/18411) handle_write(): 4096 bytes (12288/18411) handle_write(): 4096 bytes (16384/18411) handle_write(): 2027 bytes (18411/18411) 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! Device ID code: 0xb4fbDevice Version code: 0x0000 Here it hangs after the newline in the "Device Version code" line. Any ideas what the problem could be? Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

4 4

Re: Calypso DSP reverse engineering front ...
by Dieter Spaar 11 Mar '10

11 Mar '10

Hello Sylvain, On Thu, 11 Mar 2010 01:18:06 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote: > > I've been slowly working on the DSP code for some time now and I > tought I'd post a status here in case other people are interested. Great that you work on the DSP part. I am working with the DSP code for a while, mainly to look up things for my Layer1 experiments if the meaning of API RAM fields are not clear from the header files only. I also use the latest IDA Pro version (I am a Hex-Rays customer too), however without much dealing with the Data ROM till now, the Code ROM was good enough so far. > The ultimate point of this is to add support for things the DSP isn't > supposed to do. Like receiving the raw demodulated data without the > deciphering / fire code / whatever. I already found the location in the internal DSP RAM where the raw bits of a frame from four normal bursts are stored. They are stored as "soft" bits (16-bit value) and are already deinterleaved. It should not be too hard to patch the appropriate functions and move the raw bits to some unused location in the API RAM so that they can be accessed from the ARM. So getting the raw bits of one timeslot is probably rather easy, however getting the raw bits of all timeslots is a different thing. I did not look at this in more detail because there are currently other more important things to do in Layer1. > Here's a sample results of what it looks like now (without much manual > fixups, just loading the files and declaring a couple addresses as > being structures) : > http://www.246tnt.com/files/calypso_dsp_ida_sample.png > It becomes clear what function does what :) Yes, I have seen this code ;-). > I'll try to push a maximum in my dsp branch tomorrow. I can't put the > IDA processor module modification because even just the patch contains > some hex-rays code, so I guess I'll have to ask them permission on a > case by case basis to distribute it. (just ask me privately and we'll > work it out) Great. I am interested in your modification to IDA Pro (feel free to ask Hex-Rays of course, they should know me). As a side note: IDA Pro is an extraordinary tool and the support from Hex-Rays is great. So if one use IDA Pro regulary, Hex-Rays really deserves it that a licensed copy of IDA Pro is used and not a pirated one. I am not related to Hex-Rays, just a happy customer for a long time. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

building firmware
by chekov 11 Mar '10

11 Mar '10

hi, after a break of one week, the firmware doesn't seem to be built. when typing make clean followed by make or make firmware in ./src/ here is the tail of the output: make -C target/firmware CROSS_COMPILE=arm-elf- make[1]: Betrete Verzeichnis '<snip>/src/target/firmware' make[1]: Für das Ziel »default« ist nichts zu tun. make[1]: Verlasse Verzeichnis '<snip>/src/target/firmware' what am i doing wrong?

3 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel