- baseband-devel - lists.osmocom.org

Request for review: GSM phone hardware introduction
by Harald Welte 17 Apr '10

17 Apr '10

Hi! I've written an introductory text on GSM mobile phone architecture, and before officially posting/announcing it, I thought I'd invite the members of this list to do some review and give feedback! -- - 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: Request for review: GSM phone hardware introduction
by Harald Welte 15 Apr '10

15 Apr '10

Hi Jake (and others), On Tue, Apr 13, 2010 at 10:09:52AM -0700, Jacob Appelbaum wrote: > > I've written an introductory text on GSM mobile phone architecture, > > and before officially posting/announcing it, I thought I'd invite > > the members of this list to do some review and give feedback! > > Do you have the latex available? It's hard to edit and send a diff of a > pdf... see attachment. -- - 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)

3 4

Patch: Add CRC16 to libosmocore
by Christian Vogel 13 Apr '10

13 Apr '10

Hi everyone, prom is using the crc16 as implemented in the Linux Kernel for his bootloader work, and I'm planning to add an optional crc16 check for sercomm. To have crc16 easily accessible in baseband, this commit adds it to libosmocore. Chris

1 1

Patch: Add ECHO DLCI to sercomm
by Christian Vogel 13 Apr '10

13 Apr '10

Hi, this patch adds a new DLCI, Numbered 11, which just echoes whatever it recveices on the mobile back to the PC. It is very useful for debugging serial port problems. Chris

1 0

Re: Patch: UART initialisation, serial port errors
by Dieter Spaar 11 Apr '10

11 Apr '10

Hello Christian, I had the suspicion that a UART reset in the code is missing, however I could not verify that because I never had those problems with wrong bytes. Out of curiousity, have you tried if just the following line is enough to fix the problems you noticed ? > + uart_reg_write(uart, MDR1, 0x07); /* turn off UART */ This should cause the UART to be reset and I would expect that setting the XON/XOFF characters is not needed as long XON/XOFF handshake is not turned on. Thanks and best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Patch: UART initialisation, serial port errors
by Christian Vogel 11 Apr '10

11 Apr '10

Hi, I've seen a lot of systematic character swaps on the serial port, especially in the vincinity of 0-bytes. As the XON/XOFF registers are the only thing in the UART that look like they would consider the actual data sent, I've added this initialisation to uart.c This makes the problem go away completely on my C123. To check for it I've added CRCs to the HDLC protocol and checked for bad frames, and also compared them in a (patched) osmocon that just sends random garbate in a special DLCI. The bad frames I observed always looked like this (number in parenthesis define number of omitted bytes, for brevity): <------ good bytes ----------> <-recvd|sent-> <----- identical again ------> d0 e0 00 00..(107)..f7 ce 17 c4 < 0c 00|00 0c > db 70 ba cb..(67)..d8 6d 3a 1f 31 e1 00 00..(47)..38 ca 2f e5 < 0c 00|00 0c > f8 a3 77 5f..(127)..5b 72 ff 4a <-- good -> <--- bad -----> <---- good again -------------> dc e1 00 00 < 0c 00|00 0c > 87 cb 24 83..(178)..2f 69 b3 51 ae e2 00 00..(167)..bd 18 6f a1 < 0c 00|00 0c > 2f 53 d2 b2..(7)..da c7 1b 63 dc e3 00 00..(131)..8e 2c b0 a8 < 0c 00|00 0c > 40 62 56 5f..(43)..f0 3a 47 f7 Formerly I was observing about 10 packets for every 2000 sent (with 192 bytes of payload each). Now, with the added initialisation, I see (as the time of writing this email) 12000 packets with 192 bytes each sent, with 0 bytes missing, corrupted, flipped). Please have a look and tell me if it's helping for you. I'll send the HDLC/CRC patch in another email. Chris

1 0

Re: AW: Developer Meeting in Berlin / 2010-04-10
by Dieter Spaar 11 Apr '10

11 Apr '10

Hello Andreas, On Mon, 5 Apr 2010 17:20:24 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote: > > i would like to participate (and others maybe too). what if we have > somethink like a conference for all the people not in berlin? > > in our company we do it this way: > > - a conference number is dialed by all members. > - a phone with hands free option can be used on one place where multiple > members are. > - netmeeting is used for presentation. this can also be via VNC remote > desktop. A conference call sounds good. If it is done this way, I would participate too. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

5 8

fix: disabling romloader on romload-targets
by Steve Markgraf 10 Apr '10

10 Apr '10

Hi, when I tried to read the secure-romloader of an Alcatel VLE5-series phone, I noticed a small bug in calypso_bootrom(), which prom already tried to fix, but his fix only worked on targets which have nIBOOT tied to high (Compal). I've committed a fix for this to steve-m/pending. Regards, Steve

2 2

libosmocore development flow
by Harald Welte 10 Apr '10

10 Apr '10

Hi! Andreas has asked me about this, and it might be interesting to a wider audience, so I've added the information to the wiki at https://calypso.gnumonks.org/trac/wiki/libosmocore Here's a copy of what I wrote there: == Development Cycle == As we are still developing the GSM protocol stacks on the network side (OpenBSC) and phone side (OsmocomBB), every so often there is a need to add some new code to libosmocore. Even worse, we sometimes need to break the API and ABI of the library. However, by keeping libosmocore in a separate git repository, we run into one problem: Checking out an old version of e.g. OpenBSC or OsmocomBB will result in failed builds, as we don't remember which old version of libosmocore was required. This makes debugging and things like git bisect very hard to impossible. In order to solve this problem, we use [http://github.com/apenwarr/git-subtree git-subtree] to import the full libosmocore.git repository into OsmocomBB. This way, we ensure that there is always a compatible version of libosmocore inside the tree if we check out old OsmocomBB versions from git. === Making changes to libosmocore === '''NEVER COMMIT CHANGES DIRECTLY TO osmocom-bb.git:src/shared/libosmocore''' Instead, use the following process: 1. make your changes to your local copy of libosmocore 1. test them together with OsmocomBB and OpenBSC 1. test if libosmocore still builds for both host and target (ARM) 1. create a ''diff'' of your local libosmocore changes 1. apply that diff to the libosmocore.git repository 1. use the script in osmocom-bb.git/src/shared/update-libosmocore.sh (uses git-subtree) to import your changes from libosmocore.git 1. test + commit your OsmocomBB changes that depend on the newly introduced code to libosmocore It is important that the steps are followed in the order state above to ensure consistency of our repositories 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)

1 0

Fix building of layer23 against in-tree libosmocore
by Harald Welte 09 Apr '10

09 Apr '10

Hi all! As Andreas has pointed out to me in a phone call yesterday and steve-m mentioned on IRC: Building layer23 with the not-installed (make install) libosmocore from osmocom-bb resulted in link failures. I've now addressed those problems and the repo should be building just fine again. 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)

1 0

merging prom/pending code (manifest)
by Harald Welte 08 Apr '10

08 Apr '10

Hi Prom! I've now merged (a rebased version of) your prom/pending, including the manifest part. Only one minor issue that I've noticed: 'make clean' does not remove the board/*/*.manifest.o files. Maybe you can fix that at some point. Also, I think it would be better to only export a 'struct manifest' that then has members for all the various parameters (so far only strings with versions, but there might be more stuff in the future). Thanks, 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)

1 0

Re: questions about layer 1 interface
by Dieter Spaar 08 Apr '10

08 Apr '10

Hello Harald, On Thu, 8 Apr 2010 05:18:15 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > Also, layer1 TX side still has a problem where it transmits the bursts > all off-by-one timeslot, i.e. only 3 out of 4 bursts of a message are > received correctly by the BTS, the other burst is sent at a different > (wrong!) point in time, disturbing some other phone on the same cell. With my fix from a while ago sending works as expected. In the meantime I extended my test code so that I could also verify the correct behaviour against a GSM test set when doing a Location Update. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

questions about layer 1 interface
by Andreas.Eversberg 08 Apr '10

08 Apr '10

hi, currently i am working on radio ressource layer and the sub processes for 1) network selection, 2) cell selection, and 3) location update trigger process. i have problems expecially with the cell selection task. since it requires measurements and detection of carriers (for some time depending on the slot configuration), it must work together with the layer 1 (radio part). here are some examples of messages what i think must exist between layer 1 and cell selection process: (the primitive names are just examples and do not conform to GSM specs.) L1CTL_DM_EST_REQ (which already exists) tune to a channel in dedicated mode (by given channel, frequency and later hopping sequence) L1CTL_IM_EST_REQ tune to a BCCH channel in idle mode (by given frequency) L1CTL_IM_EST_CNF confirm valid carrier signal. L1CTL_IM_INFO_IND info when reading of BCCH was enough for a cell selection (depends on the channel configuration), shall include measurement L1CTL_MEAS_IND periodic info of measurements from the selected channel. (required for cell reselection) take these only as examples, not as required messages. while reading GSM 05.08, this is what i think is required to do cell (re-)selection process or abort radio connection if fails (below minimum level). any help/ideas/suggestions? andreas

2 1

gsm48-andreas / issues.txt
by Harald Welte 07 Apr '10

07 Apr '10

Hi Andreas, some comments to your issues.txt: > How do we send MEASUREMENT RESULTS to RSL? (maybe RSL_MT_MEAS_RES) > what triggers the sending? Or do we just send it from time to time to > layer 1 where it is stored and sent when the time is right? (Then we > might get something like RSL_MT_MEAS_CNF, so we can send the next one, > if we have new measurements available, otherwhise the L1 will use the > old measurement results and resends them without confirming it.) measurement results are sent on the SACCH. The Layer1 has independent transmit queues for the main channel (SDCCH/TCH) and its associated SACCH. So the L23 code needs to send the respective packet to a chan_nr/link_id that indicates transmission over the SACCH. In the GSM TS, there is a primitive by which L1 can indicate that it needs the next L23 message for a given channel, which we don't implement (as we're tunnelling L1CTL through HDLC/serial, the answer would never be back before the next TDMA frame anyway). My suggestion would be: Have a fixed SACCH queue depth of 1 or 2 in L1CTL, and every time we actually dequeue the frame (i.e. send it to the DSP), send an indication of the current queue depth up to L23. We should do this for both the main and the ACCH queue so higher layers can implement some kind of flow control if they want. > I need some RACH primitives like: > - RACH request (tx_ph_rach_req already exists) including value and > offset of RACH slot from now. What exactly do you mean with 'value and offset of RACH slot from now'? As we're operating asynchronously "now" is not defined precisely. I think if you simply tell the L1 that you want to transmit at a specified GSM time (modulo 51), we can schedule it that way. L23 should understand the current CCCH/BCCH layout and determine which lsots are applicable for RACH burst transmission. They can then either say "please transmit at this full gsm time (uint32_t of the frame number)" or "please transmit in next multiframe at fn % 51 == X where X is something specified by L23" > - RACH confirm, the RACK has been sent (with timeslot where is was sent) that should be relatively easy to add, I'll add it during the next days. Meanwhile we can simply assume that it was sent at the timeslot as requested. > Since RACH request must be queued in layer 1 until it the right slot > is reached, I need to tell L1 to cancel it. Whenever I receive a > confirm, I schedule the next one until the maximum number has been > transmitted or until an IMMEDIATE ASSIGNMENT is received on CCCH. I think we can ignore that for now. In the worst case, we send one more RACH request than needed. I know this is dangerous if done by many phones on real networks, but for our current goal of "getting something working in our own gsm test network" this is the kind of shortcut we can take. I know your development style is very different. You seem to be trying to implement something thats fully compliant with the spec. I usually try to take a more incremental/iterative approach. Make something work first, and then iteratively improve/complete it. I hope you can live with the fact that at least for now, L1 doesn't have this support. If you want, we can already define the L1CTL message for it but simply ignore it on L1 until its implemented. > RACH request on RSL: > Does it make sense to put RACH request to the set of RSLms primitives? > (i.e. RSL_MT_CHAN_REQ, not RQD!, RSL_MT_CHAN_CNF, RSL_MT_CHAN_CAN) > What do you say? I think we should mark them explicitly as RSLms_MT_* to make it obvious that it is non-standard RSL. Otherwise, I agree. "CAN" for "CANCEL" is probably causing misunderstanding, lets just write the full word. 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)

1 1

Support for the Calypso romloader in osmocon
by Steve Markgraf 06 Apr '10

06 Apr '10

Hi all, I've added support for the Calypso "non-secure" romloader in my branch steve-m/osmocon. This means we now can execute our code on devices like the Motorola W220, the BenQ A38 (which I've used for development), and the OpenMoko devices (can anyone try to cross-compile osmocon and see if it works?). For more information see in the wiki: http://bb.osmocom.org/trac/wiki/CalypsoRomloader I also added a new model switch for the C140 (-m c140), which automatically adds the "1003" string in the uploaded binary. This is meant for use with proms loader, so now you can upload loader.ramload.bin on the C139/C140 and J100i, and load the application itself with osmoload. Regards, Steve

2 1

Re: Developer Meeting in Berlin / 2010-04-10
by Samuel Omlin 06 Apr '10

06 Apr '10

Hi Harald, That's a bright idea for all the developers behind the project as well as those observers around the project to make a brainstorm with the development and evolution of the project. It's a little pity, however, for those people not going to participate directly in the Developer Meeting at CCC near Berlin. If setting up a "green pathway" connecting to the live meeting on the internet, so the people strongly wanna share their ideas with others will be able to join into the Developer Meeting simultaneously. If there has difficulty in doing such things, maybe recording and uploading the live video of the meeting into the public wiki of the project is another way to share the content and fun of the meeting together with other people all around the world. Thanks. Best Regards, Samuel On Mon, Apr 5, 2010 at 6:00 PM, <baseband-devel-request(a)lists.osmocom.org>wrote: > Send baseband-devel mailing list submissions to > baseband-devel(a)lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/baseband-devel > or, via email, send a message with subject or body 'help' to > baseband-devel-request(a)lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of baseband-devel digest..." > > Today's Topics: > > 1. Developer Meeting in Berlin / 2010-04-10 (Harald Welte) > 2. Re: noisy cable? (Nathan Fain) > > > ---------- Forwarded message ---------- > From: Harald Welte <laforge(a)gnumonks.org> > To: baseband-devel(a)lists.osmocom.org > Date: Mon, 5 Apr 2010 09:24:45 +0800 > Subject: Developer Meeting in Berlin / 2010-04-10 > Hi all! > > Since I'm returning from holidays in two days, I think it's a good idea > (for those who are in/around Berlin) to meet again at CCC Berlin. > > This is mainly for me to get an idea where we are (compared to before my > holidas) and how we proceed. Especially the loader seems to have made > progress, as far as I can tell from casual reading of the commitlog. > > I'm also curious to see what's happening on the battery charger, sim > card reader (and other) parts of the system. > > I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in > joining, feel free to join! > > 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) > > > > > ---------- Forwarded message ---------- > From: Nathan Fain <nat(a)fains.com> > To: baseband-devel(a)lists.osmocom.org > Date: Sun, 04 Apr 2010 22:17:38 -0700 > Subject: Re: noisy cable? > fyi, using the /dev/cu.** variant solved my problem of osmocon being > unable to write CMD1 to the port. At least, it worked with an FTDI > cable I built. I imagine it will solve the issue with the prolific > cable as well (will try later). > > > > On 29/03/2010 03:39, willem wrote: > > i managed to get hello_world working on my c121, connected through a > > pl2303 usb/serial cable to my macbookpro. > > > > but found that the connection is extremely noisy. > > often the movement of me putting down the phone on the table is enough > > to break the upload. > > is that a common problem with these headphone/serial cable plugs? > > > > > > for the serial device i can use /dev/cu.PL2303-0000201A > > or /dev/tty.PL2303-0000201A > > > > but when using the '/dev/tty...' variant, i have to add this to > osmocon.c > > > > diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c > > index f934dd7..b361eb1 100644 > > --- a/src/host/osmocon/osmocon.c > > +++ b/src/host/osmocon/osmocon.c > > @@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev) > > /* hardware flow control off */ > > options.c_cflag &= ~CRTSCTS; > > > > + /* ignore modem status lines */ > > + options.c_cflag |= CLOCAL; > > + > > /* software flow control off */ > > options.c_iflag &= ~(IXON | IXOFF | IXANY); > > > > ============================= > > > > willem > > > > > > > > > > > > > _______________________________________________ > baseband-devel mailing list > baseband-devel(a)lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/baseband-devel > >

2 2

AW: Developer Meeting in Berlin / 2010-04-10
by Andreas.Eversberg 06 Apr '10

06 Apr '10

hi harald, i would like to participate (and others maybe too). what if we have somethink like a conference for all the people not in berlin? in our company we do it this way: - a conference number is dialed by all members. - a phone with hands free option can be used on one place where multiple members are. - netmeeting is used for presentation. this can also be via VNC remote desktop. is it possible for you in berlin to establish a VNC server with multiple access, or at least something like a "screen" command? my PRI test machine in my company can be used as conference server for up to 30 parties. it has a german dial-up number. regrads, andreas -----Ursprüngliche Nachricht----- Von: baseband-devel-bounces(a)lists.osmocom.org [mailto:baseband-devel-bounces@lists.osmocom.org] Im Auftrag von Harald Welte Gesendet: Montag, 5. April 2010 03:25 An: baseband-devel(a)lists.osmocom.org Betreff: Developer Meeting in Berlin / 2010-04-10 Hi all! Since I'm returning from holidays in two days, I think it's a good idea (for those who are in/around Berlin) to meet again at CCC Berlin. This is mainly for me to get an idea where we are (compared to before my holidas) and how we proceed. Especially the loader seems to have made progress, as far as I can tell from casual reading of the commitlog. I'm also curious to see what's happening on the battery charger, sim card reader (and other) parts of the system. I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in joining, feel free to join! 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)

2 1

update on layer 3 process
by Andreas.Eversberg 05 Apr '10

05 Apr '10

hi, the current state of coding can be seen in the src/host/gsm48-andreas/README file of GIT. as noted there, the process of mobility management and call control is completed. this does not mean that it is compiling and working. als debugging has to be completed. the next step would be to follow the compiler errors step by step until all missing and wrong symbols are found and fixed. i will do that later. also the radio ressource is at a point where i like to start integrating it into the layer23 application. today i checked out how the system informations are received and how to send a random access burst. please check out the issues about that at src/host/gsm48-andreas/issues.txt in the GIT. i must note that layer3.c and rslms.c is not needed in my case, since it is part of gsm48_rr.c in order to integrate it, i would like to open a new branch, since there are many other existing files to be expanded. (new structures to header files... see extra.c and extra.h) there must also be a way to get all the changes in the master branch merged to the new branch, so i can react on changes of master branch. i am not that familiar with git, so is there any advice except cherry-picking all the time? or maybe there is a better way of doing that? andreas

1 0

noisy cable?
by willem 05 Apr '10

05 Apr '10

i managed to get hello_world working on my c121, connected through a pl2303 usb/serial cable to my macbookpro. but found that the connection is extremely noisy. often the movement of me putting down the phone on the table is enough to break the upload. is that a common problem with these headphone/serial cable plugs? for the serial device i can use /dev/cu.PL2303-0000201A or /dev/tty.PL2303-0000201A but when using the '/dev/tty...' variant, i have to add this to osmocon.c diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index f934dd7..b361eb1 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev) /* hardware flow control off */ options.c_cflag &= ~CRTSCTS; + /* ignore modem status lines */ + options.c_cflag |= CLOCAL; + /* software flow control off */ options.c_iflag &= ~(IXON | IXOFF | IXANY); ============================= willem

4 3

Developer Meeting in Berlin / 2010-04-10
by Harald Welte 05 Apr '10

05 Apr '10

Hi all! Since I'm returning from holidays in two days, I think it's a good idea (for those who are in/around Berlin) to meet again at CCC Berlin. This is mainly for me to get an idea where we are (compared to before my holidas) and how we proceed. Especially the loader seems to have made progress, as far as I can tell from casual reading of the commitlog. I'm also curious to see what's happening on the battery charger, sim card reader (and other) parts of the system. I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in joining, feel free to join! 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)

1 0

message handling
by Andreas.Eversberg 01 Apr '10

01 Apr '10

hi, today i will finally (begin to) structure the message handling in my current work on layer 3: the message handling functions consist of: - message cration - message sending - message en-queueing - message de-queueing i deal with interfaces (SAP): - between application and call control (MNCC-SAP) - between call controll and mobility management (MMCC-SAP) - between supplementary services protocol and mobility management (MMSS-SAP) - between sms protocol and mobility management (MMSMS-SAP) - between mobility management and radio ressource (RR-SAP) - between radio ressource and layer 2 / layer 1 (let's call it RSLms-SAP) additionally there are interfaces: - between application and mobility management - between application and PLMN search - to the sim card - to the application - ... here is what i think the messages should look like. please correct me if i am wrong or if you have suggestions: MNCC-SAP: <gsm48_mncc structure> MMCC-SAP, MMSS-SAP, MMSMS-SAP: <gsm48_mmxx structure>[<L3 message*>] RR-SAP: <gsm48_rr structure>[<L3 message*>] RSL-SAP: <abis_rsl_rll_hdr structure>[<L3 message*>] * the layer 3 message consists of the gsm48_hdr structure + additional information elements. if a layer 3 message moves from call control down to RSL and even lower, the inter-layer headers are pulled and pushed. additionally there are pointers to the beginning of the headers inside the message: - l1h - l2h - l3h - layer 4 headers - layer 5 header the inter-layer messages (MMxx-SAP and RR-SAP) will have no pointer to the message structures. i think they also should not have them, since they have fixed length and are pushed at the time they are sent, and pulled at the time they are received. any suggestions? andreas

1 0

Yet Another Way of Communication
by Samuel Omlin 31 Mar '10

31 Mar '10

Hi, First off, thank the community--OsmocomBB for launching and then sharing the development of mobile protocol stack first. As we can understand, the current mailing list has been acting as the primary way of communicating between one another on the project basis. For these quick questions as well as immediate discussions, however, most likely there should be yet another way to complement, like irc on the freenode. Or, for the above issue you guys out there have other ways to solve, eh? If so, please take me into the circle as well, just because I have too many questions to ask. :) Thanks. Best Regards, Samuel

2 1

AW: noisy cable?
by Andreas.Eversberg 30 Mar '10

30 Mar '10

> but found that the connection is extremely noisy. > often the movement of me putting down the phone on the table is enough > to break the upload. i had a similar problem with an unconnected input pin which caused a reset of a microcontroller, just by moving some centimeters in a distance of one meter. check if you have left unconnected input pins on your USB converter. what about hardware flow control input? (RTS/CTR) andreas

1 0

fixing socket name
by willem 30 Mar '10

30 Mar '10

the /tmp/osmoncon* sockets created by osmocon are created one character too short. willem fix: diff --git a/src/host/layer23/src/main.c b/src/host/layer23/src/main.c index 8e76e8b..9e37fbf 100644 --- a/src/host/layer23/src/main.c +++ b/src/host/layer23/src/main.c @@ -244,7 +244,7 @@ int main(int argc, char **argv) local.sun_path[sizeof(local.sun_path) - 1] = '\0'; rc = connect(ms->wq.bfd.fd, (struct sockaddr *) &local, - sizeof(local.sun_family) + strlen(local.sun_path)); + sizeof(local.sun_family) + strlen(local.sun_path) + 1); if (rc < 0) { fprintf(stderr, "Failed to connect to '%s'.\n", local.sun_path); exit(1); diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index f934dd7..b361eb1 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -629,7 +632,7 @@ static int register_tool_server(struct tool_server *ts, local.sun_path[sizeof(local.sun_path) - 1] = '\0'; unlink(local.sun_path); rc = bind(bfd->fd, (struct sockaddr *) &local, - sizeof(local.sun_family) + strlen(local.sun_path)); + sizeof(local.sun_family) + strlen(local.sun_path) + 1); if (rc != 0) { fprintf(stderr, "Failed to bind the unix domain socket. '%s'\n", local.sun_path); diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index ecee8b3..fdf417a 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -128,7 +128,7 @@ loader_connect(const char *socket_path) { } rc = connect(conn->fd, (struct sockaddr *) &local, - sizeof(local.sun_family) + strlen(local.sun_path)); + sizeof(local.sun_family) + strlen(local.sun_path) + 1); if (rc < 0) { fprintf(stderr, "Failed to connect to '%s'.\n", local.sun_path); exit(1);

3 4

AW: layer3 work / issues
by Andreas.Eversberg 30 Mar '10

30 Mar '10

hi harald, >> must random value in chan_request change on every resend or only on >> every RR establishment? (currently it changes on every RR >> establishment only.) > >as far as I know, it has to change on every retransmission. Dieter is >probably the person who knows all RACH aspects in detail, maybe he can >comment on this. from the specs it is quite clear that every access burst has different random number when resending. but how does the network know if the burst is from the same phone but retransmitted? in case of poor uplink many bursts may be resent. will the network allocate a channel for every burst received and waits for timeout? (if this is the case, emergency calls could quickly 'evacuate' the cell.) >> OpenBSC: if tx-msg fails during process, the msg must be freed to >> avoid memory leak. > >I don't understand, can you please explain this further? it is something to remind me that there are memory leak problems. in some functions of gsm_04_08.c there are messages allocated at the beginning and sent at the end. sometimes during processing, the function returns due to error conditions, but the message is not freed before return. i will check that later together with my new code. as far as i can see right now, it just happens in gsm48_cc_tx_setup(). regards, andreas

2 1

Re: AW: layer3 work / issues
by Dieter Spaar 29 Mar '10

29 Mar '10

Hello Andreas, On Mon, 29 Mar 2010 13:39:21 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote: > > from the specs it is quite clear that every access burst has different > random number when resending. but how does the network know if the burst > is from the same phone but retransmitted? in case of poor uplink many > bursts may be resent. will the network allocate a channel for every > burst received and waits for timeout? (if this is the case, emergency > calls could quickly 'evacuate' the cell.) It does not even need a poor uplink. I experience this behaviour for example with OpenBSC and the nanoBTS. If the "Immediate Assignment" is not sent fast enough, a retransmitted RACH burst will allocate another channel (the timeout for releasing an unused channel is around 2 to 5 seconds in "real" GSM networks). The maximum number of the retransmitted RACH burst is controlled by a parameter in the SYSTEM INFORMATION messages (there are several parameters which control the RACH transmission behaviour). Of course a "bad phone" can ignore those parameters and a DoS attack with continuous RACH bursts works quite well because the BTS or network does not know from which phone the burst come from. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: noisy cable?
by Dieter Spaar 29 Mar '10

29 Mar '10

Hello Christian, On Mon, 29 Mar 2010 13:27:31 +0200, "Christian Vogel" <vogelchr(a)vogel.cx> wrote: > > I'm using a self-made cable consisting of a known good FT232R > converter @ 3.3V and a cut off headset cable (that also worked > flawlessly without any noise on another mobile phone before). My C123 > also looks pristine. I manage to upload and run hello world > successfully in maybe one out of ten attempts, often have to remove > the battery because the phone just gets stuck. So I have ordered a new > cable from Akku-King as suggested on the Wiki. My experience: I work under Windows with Cygwin so the OS internals how the serial port is handled are (totally) different than Linux. With the non-blocking variant of "osmocon" it was nearly impossible to download the code to the phone in a reliable way. So I had to apply an ugly hack to my version which basically switches the serial connection to "blocking mode" during the download phase. This way it works rather reliable here (regardless of using a "real" RS232 port or an USB to serial converter). So you might experience the same problem instead of a bad cable. You can try the attached patch to "osmocom.c". The patch is not for the latest GIT version, however it should be quite easy to apply it to the current on. Again, its an ugly hack, but it works for me. Best regards, Dieter Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: noisy cable?
by Dieter Spaar 29 Mar '10

29 Mar '10

Hello Willem, On Mon, 29 Mar 2010 12:39:35 +0200, "willem" <itsme(a)xs4all.nl> wrote: > > but found that the connection is extremely noisy. > often the movement of me putting down the phone on the table is enough > to break the upload. > is that a common problem with these headphone/serial cable plugs?

1 0

Re: layer3 work / issues
by Dieter Spaar 28 Mar '10

28 Mar '10

Hello Harald, On Sun, 28 Mar 2010 13:16:36 +0800, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > as far as I know, it has to change on every retransmission. Dieter is > probably the person who knows all RACH aspects in detail, maybe he can > comment on this. According to the specification the random value has to change on every transmission: a random reference which is drawn randomly from a uniform probability distribution for every new transmission. In the TSM30 firmware this is done by having a table with random values and an index into the table which is initialised to a random value when the Immediate Assignment Procedure is started and incremented with every random number taken for a retransmission. The table has 32 values because the random reference is not larger than 5 bits. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

layer3 work / issues
by Harald Welte 28 Mar '10

28 Mar '10

Hi Andreas, some comments regarding your issues.txt: > must random value in chan_request change on every resend or only on > every RR establishment? (currently it changes on every RR > establishment only.) as far as I know, it has to change on every retransmission. Dieter is probably the person who knows all RACH aspects in detail, maybe he can comment on this. > must be expanded: struct osmocom_ms: no problem here, expand it how you see fit. I just generally prefer caller-allocated structures to callee-allocated ones, and I'd like to use static allocation whenever possible. So if there's only one 'struct rrlayer' per ms, then we should simply include 'struct rrlayer' as sub-structure of 'struct osmocom_ms', rather than having two structures and pointers between them. > OpenBSC: if tx-msg fails during process, the msg must be freed to > avoid memory leak. I don't understand, can you please explain this further? > random acces via RSL? I think we simply add some new / non-standard primitives, as it does not have any notion of RACH bursts. It might also be possible to encode it as UNIT DATA REQUEST for channel (chan_nr) RACH (CCCH uplink), but then we still cannot specify details like at which frame number, etc. From what I can see, your RSL_MT_RAND_ACC_REQ approach looks fine to me. As a minor improvement we could call it RSLms_MT_RAND_ACC_REQ to indicate that it is our custom RSLms message and nothing specified in the original RSLms spec. 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)

1 0

Patch: osmocon: excape non-printable, add -c option
by Christian Vogel 27 Mar '10

27 Mar '10

Hi, I started to play around with osmocon, but unfortunately my serial cable (a FTDI232RL module from Sparkfun connected to the 2.5mm plug, this one is set to 3v3 and worked flawlessly for several projects!) seems to be quite unreliable in the host -> handset direction. But to not procrastinate, I did some cleanup in osmocon to escape non-printable output and added new "-c" option to start straight into HDLC-mode without uploading any firmware to the mobile. Are those kinds of mostly cosmetic patches appreciated or considered unnecessary? Chris

1 0

recommended toolchain
by Christian Vogel 27 Mar '10

27 Mar '10

Hi, what's currently the recommended toolchain for bb-osmocom? The wiki says on http://bb.osmocom.org/trac/wiki/AreasOfWork that most people are using gcc 4.0.2 from http://gnuarm.com/ but the binary there is only for x86_64 which I don't use. So, as I've got to build from source, I'm going to download the latest binutils/gcc/newlib(?) for that. Is it a good idea, or are there known problems with gcc binutils 2.20.1/gcc 4.4.3? Greetings, Chris

3 3

We're loosing serial bytes from PC to phone
by Harald Welte 27 Mar '10

27 Mar '10

Hi! It seems we're loosing serial characters on their way from the (Linux) PC to the phone. I think I've seen this at some point in the past, but now I'm seeing it constantly. Let's assume we're trying to send the following sequence of bytes from the PC side to the phone in one of the HLDC connections: > send_to_phone(dlci=5): 0a 00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d > 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 > 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d what we actually get from the sercomm callback on the phone is: > l1a_l23_rx_cb: 0a 00 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 > 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a > 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d as you can see, there is a '00 01' missing between the '00' and the '02'. Interestingly, putting a usleep(10000) after every serial write does not solve the problem, so it is not timing related. We don't get any UART overflows on the calypso, either. If I change the data pattern, then the first bytes are transmitted fine, but as soon as there is one 00 bytes, two characters are missing from the stream. If I strace osmocon, it is clear that we write every character, including the null-bytes, and all of the writes are successfully. I've again looked at (and played with) the termios settings, but could not find any problem (nor solution). It's also not the sercomm layer that is loosing bytes, as I the characters appear already lost when printing them from within the calypso UART driver, as you can see here: getchar_nb(1) = 7e // flag character getchar_nb(1) = 05 // hdlc getchar_nb(1) = 03 // hdlc getchar_nb(1) = 0a // l1ctl_hdr (undefined msg_type 10) getchar_nb(1) = 00 // padding getchar_nb(1) = 02 // here should be 00, 01, 02... getchar_nb(1) = 03 getchar_nb(1) = 04 getchar_nb(1) = 05 [...] Any ideas? It's really strange and I don't really know what else to do. I'm quite sure our binaries contain multiple successive null-bytes and their download is working great... 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)

7 14

C123 Battery Pinout
by Riemer, Bjoern 27 Mar '10

27 Mar '10

Hi *, i have an Motorola C123 without a battery and without a charger. Can someone told me pinout of the battery Connector so that I can connect a nokia battery? Or can I use a 5v power supply and connect it to the charger port and the phone boots without a main battery? Bjoern ----- #- Björn Riemer #- FOKUS - Fraunhofer Institute for Open Communication Systems #- -Sensor Applications and Networks - #- Kaiserin-Augusta-Allee 31 #- 10589 Berlin, Germany #- phone: +49 30 3463-7747 #- fax: +49 30 3463-8000 #- email: bjoern.riemer(a)fokus.fraunhofer.de <mailto:bjoern.riemer@fokus.fraunhofer.de> #- http://www.fokus.fraunhofer.de <http://www.fokus.fraunhofer.de>

7 9

minor fixes
by willem 21 Mar '10

21 Mar '10

attached is a patch with several minor fixes: added missing param in call to gsm48_rx_bcch. added 'extern' in .h files for declarations of rsl_rlm_cause_strs and target_board. added several 'const' for strings. removed useless 'bufptr,' from hexdump. willem

1 0

[PATCH] added missing param in call to gsm48_rx_bcch. added 'extern' to declarations of rsl_rlm_cause_strs and target_board. added several 'const' for strings. removed useless 'bufptr,' from hexdump.
by itsme 21 Mar '10

21 Mar '10

--- src/host/gsm48-andreas/gsm48_rr.c | 2 +- src/host/layer23/include/osmocom/layer3.h | 1 + src/host/layer23/src/rslms.c | 2 +- src/host/osmocon/osmocon.c | 6 +++--- src/host/osmocon/osmoload.c | 2 +- .../libosmocore/include/osmocore/gsm_utils.h | 2 +- src/shared/libosmocore/include/osmocore/rsl.h | 2 +- src/shared/libosmocore/src/gsm_utils.c | 2 +- src/target/firmware/include/board.h | 2 +- 9 files changed, 11 insertions(+), 10 deletions(-) diff --git a/src/host/gsm48-andreas/gsm48_rr.c b/src/host/gsm48-andreas/gsm48_rr.c index c3227bf..f1dfc18 100644 --- a/src/host/gsm48-andreas/gsm48_rr.c +++ b/src/host/gsm48-andreas/gsm48_rr.c @@ -23,7 +23,7 @@ * state transition */ -char *rr_state_names[] = { +const char *rr_state_names[] = { "IDLE", "CONN PEND", "DEDICATED", diff --git a/src/host/layer23/include/osmocom/layer3.h b/src/host/layer23/include/osmocom/layer3.h index 1b4af07..415b909 100644 --- a/src/host/layer23/include/osmocom/layer3.h +++ b/src/host/layer23/include/osmocom/layer3.h @@ -6,5 +6,6 @@ int gsm48_rx_ccch(struct msgb *msg, struct osmocom_ms *ms); int gsm48_rx_dcch(struct msgb *msg, struct osmocom_ms *ms); +int gsm48_rx_bcch(struct msgb *msg, struct osmocom_ms *ms); #endif diff --git a/src/host/layer23/src/rslms.c b/src/host/layer23/src/rslms.c index 509bb71..86079ac 100644 --- a/src/host/layer23/src/rslms.c +++ b/src/host/layer23/src/rslms.c @@ -76,7 +76,7 @@ static int rslms_rx_udata_ind(struct msgb *msg, struct osmocom_ms *ms) if (rllh->chan_nr == RSL_CHAN_PCH_AGCH) rc = gsm48_rx_ccch(msg, ms); else if (rllh->chan_nr == RSL_CHAN_BCCH) { - rc = gsm48_rx_bcch(msg); + rc = gsm48_rx_bcch(msg, ms); if (rach_count < 2) { tx_ph_rach_req(ms); rach_count++; diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index 82ff0e0..f934dd7 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -665,9 +665,9 @@ extern void hdlc_tpudbg_cb(uint8_t dlci, struct msgb *msg); int main(int argc, char **argv) { int opt, flags; - char *serial_dev = "/dev/ttyUSB1"; - char *layer2_un_path = "/tmp/osmocom_l2"; - char *loader_un_path = "/tmp/osmocom_loader"; + const char *serial_dev = "/dev/ttyUSB1"; + const char *layer2_un_path = "/tmp/osmocom_l2"; + const char *loader_un_path = "/tmp/osmocom_loader"; dnload.mode = MODE_C123; diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 2ee0124..ecee8b3 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -39,7 +39,7 @@ static void hexdump(const uint8_t *data, unsigned int len) const uint8_t *bufptr = data; int n; - for (n=0; bufptr, n < len; n++, bufptr++) + for (n=0; n < len; n++, bufptr++) printf("%02x ", *bufptr); printf("\n"); } diff --git a/src/shared/libosmocore/include/osmocore/gsm_utils.h b/src/shared/libosmocore/include/osmocore/gsm_utils.h index 2536045..c87e967 100644 --- a/src/shared/libosmocore/include/osmocore/gsm_utils.h +++ b/src/shared/libosmocore/include/osmocore/gsm_utils.h @@ -46,7 +46,7 @@ enum gsm_band { GSM_BAND_810 = 0x80, }; -char *gsm_band_name(enum gsm_band band); +const char *gsm_band_name(enum gsm_band band); enum gsm_band gsm_band_parse(const char *mhz); int gsm_7bit_decode(char *decoded, const uint8_t *user_data, uint8_t length); diff --git a/src/shared/libosmocore/include/osmocore/rsl.h b/src/shared/libosmocore/include/osmocore/rsl.h index 4c5f75b..c108081 100644 --- a/src/shared/libosmocore/include/osmocore/rsl.h +++ b/src/shared/libosmocore/include/osmocore/rsl.h @@ -16,7 +16,7 @@ uint8_t rsl_enc_chan_nr(uint8_t type, uint8_t subch, uint8_t timeslot); /* decode channel number as per Section 9.3.1 */ int rsl_dec_chan_nr(uint8_t chan_nr, uint8_t *type, uint8_t *subch, uint8_t *timeslot); -const struct value_string rsl_rlm_cause_strs[]; +extern const struct value_string rsl_rlm_cause_strs[]; const char *rsl_err_name(uint8_t err); diff --git a/src/shared/libosmocore/src/gsm_utils.c b/src/shared/libosmocore/src/gsm_utils.c index 97497c8..593dd5c 100644 --- a/src/shared/libosmocore/src/gsm_utils.c +++ b/src/shared/libosmocore/src/gsm_utils.c @@ -193,7 +193,7 @@ uint8_t dbm2rxlev(int dbm) return rxlev; } -char *gsm_band_name(enum gsm_band band) +const char *gsm_band_name(enum gsm_band band) { switch (band) { case GSM_BAND_450: diff --git a/src/target/firmware/include/board.h b/src/target/firmware/include/board.h index f6f073d..3635621 100644 --- a/src/target/firmware/include/board.h +++ b/src/target/firmware/include/board.h @@ -3,6 +3,6 @@ void board_init(void); -const char *target_board; +extern const char *target_board; #endif /* _BOARD_H */ -- 1.7.0 --------------090903020606000903000404--

1 0

which OS?
by Arne Zachlod 21 Mar '10

21 Mar '10

Hello, I'm very new here and I wanted to ask if you already choose an OS? On the website I read that you don't want to use FreeRTOS. Is this information still up to date? Which RTOS u want to use instead? I have found a small summary of potential candidates at wikipedia: http://en.wikipedia.org/wiki/List_of_real-time_operating_systems the best candidate seems to be BeRTOS, but i think it could be a little bit too much (e.g. it has a complete graphics subsystem). Regards Arne

2 1

Bounce action notification
by mailman＠lists.osmocom.org 20 Mar '10

20 Mar '10

This is a Mailman mailing list bounce action notice: List: baseband-devel Member: osmocon(a)ngolde.de Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman(a)lists.osmocom.org.

1 0

Re: C139: get ftmtoolerror from ramloader
by Dieter Spaar 20 Mar '10

20 Mar '10

Hello Erik, On Fri, 19 Mar 2010 09:51:48 +0100, "Erik Ekman" <yarrick(a)kryo.se> wrote: > > Yes. Mine has special US Tracfone firmware which seems to have a > particularly evil unlock scheme. Cutting one of the balls in the BGA > seems the way to do it.. I had a quick look at the bootloader from a dumped Tracfone C139 firmware. Its nearly the same the Osmocom loader supports, however this special bootloader checks a flag in flash memory to decide wether to allow RAM download or not. If it is disabled, only the FTMTOOL check is done and no RAM download at the boot stage is possible. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

compiler todo
by Florian Tobias Schandinat 19 Mar '10

19 Mar '10

Hi all, today my serial cable finally arrived. As in the meantime a driver for the C155 display was added I am searching for new things I might be able to do. The AreasOfWork lists under Build System "we need a clean/known base as a compiler" As a LFS user I'm used to compiling my own software and as I did for the toolchain which currently consists of binutils-2.19.1 gcc-4.3.4 newlib-1.18.0 and as I now have the cable, I can confirm that it works. The instructions in the support section of gnuarm.com work well if you have the needed libs (gmp, mpfr, ...) and not picked a broken version of binutils or others. So my questions are: (1) Is this still a todo or did someone work on it? (2) What needs to be done? Thanks for all your work, this is amazing, Florian Tobias Schandinat

1 0

Re: C139: get ftmtoolerror from ramloader
by Dieter Spaar 19 Mar '10

19 Mar '10

Hello Erik, On Fri, 19 Mar 2010 07:42:06 +0100, "Erik Ekman" <yarrick(a)kryo.se> wrote: > > I did some more research and it seems even the unlocking people are > having the same problems here. So I will just wait for my other phone. I do have one C139 here, it works with the "board/compal_e88/hello_world.bin" firmware and the "-m c123xor" option for "osmocon", however without the display working (its a different display). If I boot the normal phone firmware, I also see some output and have the same "AT" behaviour you reported. But maybe there are different versions of the C139 so that some work and others don't. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

C139: get ftmtoolerror from ramloader
by Erik Ekman 19 Mar '10

19 Mar '10

Hi I just got my cable and am trying to download any code into a C139 (tracfone software, bought from usa on ebay). This is what I get: $ ./osmocon -m c123 -p /dev/ttyS2 compal_dump.bin waiting for data got 7 bytes from modem, data looks like: 66 74 6d 74 6f 6f 6c Received FTMTOOL from phone, ramolader has aborted got 1 bytes from modem, data looks like: 65 got 1 bytes from modem, data looks like: 72 got 1 bytes from modem, data looks like: 72 got 1 bytes from modem, data looks like: 6f got 1 bytes from modem, data looks like: 72 ^C

2 2

layer23 : writing msgb to gsmtap fd: Connection refused
by nicolho 19 Mar '10

19 Mar '10

hi, i get errors "writing msgb to gsmtap fd: Connection refused" with layer23 app (see output below). any idea/explanation ? nico nico@debian:~/phone/osmocom-bb/src/host/layer23/src$ ./layer23 -a 4 -i 127.0.0.1 Layer1 Reset. Sending: '01 00 00 00 00 00 04 00 ' SCH: SNR: 6 TDMA: (0609/08/01) bsic: 14 SCH: SNR: 34 TDMA: (0609/18/11) bsic: 14 SCH: SNR: 5 TDMA: (0609/02/21) bsic: 14 SCH: SNR: 218 TDMA: (0609/12/31) bsic: 14 SCH: SNR: 42 TDMA: (0609/22/41) bsic: 14 SCH: SNR: 252 TDMA: (0609/07/01) bsic: 14 SCH: SNR: 148 TDMA: (0609/21/41) bsic: 14 SCH: SNR: 138 TDMA: (0609/06/01) bsic: 14 SCH: SNR: 229 TDMA: (0609/16/11) bsic: 14 SCH: SNR: 203 TDMA: (0609/00/21) bsic: 14 SCH: SNR: 178 TDMA: (0609/10/31) bsic: 14 SCH: SNR: 210 TDMA: (0609/20/41) bsic: 14 BCCH (0609/06/02) 55 06 19 00 00 00 00 00 00 00 00 00 01 ff ff fe 00 00 08 79 00 00 2b l2_ph_data_ind() fmt=Bbis UI RSLms UNIT DATA IND chan_nr=0x80 link_id=0x00 SI1 RACH Req. Sending: '04 00 00 00 00 00 00 00 00 00 ' PCH/AGCH (0609/10/06) 2d 06 22 00 90 17 82 65 6c 10 f4 68 2b 2b 2b 2b 2b 2b 2b 2 b 2b 2b 2b l2_ph_data_ind() fmt=Bbis UI RSLms UNIT DATA IND chan_nr=0x90 link_id=0x00 writing msgb to gsmtap fd: Connection refused PCH/AGCH (0609/16/12) 25 06 21 00 05 f4 9c 04 25 d1 2b 2b 2b 2b 2b 2b 2b 2b 2b 2 b 2b 2b 2b l2_ph_data_ind() fmt=Bbis UI RSLms UNIT DATA IND chan_nr=0x90 link_id=0x00 PCH/AGCH (0609/20/16) 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2 b 2b 2b 2b l2_ph_data_ind() fmt=Bbis UI RSLms UNIT DATA IND chan_nr=0x90 link_id=0x00 writing msgb to gsmtap fd: Connection refused BCCH (0609/05/02) 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 ca c1 c5 0f 79 00 00 l2_ph_data_ind() fmt=Bbis UI RSLms UNIT DATA IND chan_nr=0x80 link_id=0x00 SI2 RACH Req. Sending: '04 00 00 00 00 00 01 00 00 00 ' PCH/AGCH (0609/09/06) 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2 b 2b 2b 2b l2_ph_data_ind() fmt=Bbis UI RSLms UNIT DATA IND chan_nr=0x90 link_id=0x00 writing msgb to gsmtap fd: Connection refused PCH/AGCH (0609/15/12) 15 06 21 00 01 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2 b 2b 2b 2b l2_ph_data_ind() fmt=Bbis UI RSLms UNIT DATA IND chan_nr=0x90 link_id=0x00 ...

3 2

Re: AW: SIM card cuttingg
by Dieter Spaar 19 Mar '10

19 Mar '10

Hello Andreas, On Thu, 18 Mar 2010 10:41:32 +0100, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote: > > i prefer the CNC machine solution. it looks pretty easy to me. in my > example white = fully cut out. black = no cut, light gray = more > deep , dark gray = less deep. Looks good, do you have access to a CNC machine and what costs would you expect for a prototype ? Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Calypso DSP reverse engineering front ...
by Sylvain Munaut 19 Mar '10

19 Mar '10

Hi, 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. 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. Or dealing with raw speech data ... sending other type of burts like SCH / FCCH, or receiving other type of bursts like RACH, ... The DSP ROM dumper has been present for a while but there was no way to really use the output efficiently. For that, I've written a parser that takes the console log output and converts it into a COFF file that you can load in your favorite disassembler. I've been working with IDA 5.6 mostly and I made several enhancement to it to support the calypso better (the tms320c54 module is part of the SDK and can be modded and recompiled) : - Add support for memory mappings so that the same memory zone can 'appear' at several place in the address space (to handle data & code overlay) - Fix the section handling when loading a file: . to set XPC properly, . to not override section name . to support more than 2 sections - Fix a bug in cross reference detection when dealing with section having selectors != 0 - Add stub support for the type system. This allows loading of a .h header file with the NDB structure definition - Add definition for the IO ports so that they are symbolically displayed 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 :) 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) Cheers, Sylvain

3 4

Two more small patches
by Erik Ekman 19 Mar '10

19 Mar '10

Hi Found a spelling error while testing my C139, and also fixed the warning discussed in my earlier patch. /Erik

2 1

Regarding the cable from Dealextreme
by Dieter Spaar 18 Mar '10

18 Mar '10

Hello, Just a note about the RS-232 cable from Dealextreme: http://www.dealextreme.com/details.dx/sku.14664 This is a direct connection cable, this means that there is no level-converter between the phone and the RS-232 port from the PC. Despending on the RS-232 port of the PC, I would expect that this can/will damage the phone. I have one of those cables here and can confirm that there is no level-converter in between. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 3

Re: SIM: File structure.
by Dieter Spaar 18 Mar '10

18 Mar '10

Hello Sebastien, On Thu, 18 Mar 2010 12:17:18 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote: > > The SIM obviously relies on a filesystem. Some files are defined as > mandatory in TS11.11, so I will include them, but their size is not always > fixed. I'm opening this thread to define this kind of information. Maybe useful: https://sites.google.com/site/savolabs/Home/tools Its about a tool (SIMbrush) to extract all EFs from a SIM. Besides the source code there is also a PDF file with the results from scanning a standard SIM, it contains the file size for the EFs of the scanned SIM. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

SIM: File structure.
by Sébastien Lorquet 18 Mar '10

18 Mar '10

Hi all, I'm making progress on the SIM/Filesystem applet. Data access commands are working, I'm now working on writing commands that send replies formatted as defined in TS 11.11 instead of FCI responses. I need input from you: I'm only a "smart card" guy, I can do "whatever is needed", but I need to define *what* is needed with you. I know especially nothing about GSM itself except that the MS talks with the SIM to manage cryptography, store SMS and phonebooks entries, etc. The SIM obviously relies on a filesystem. Some files are defined as mandatory in TS11.11, so I will include them, but their size is not always fixed. I'm opening this thread to define this kind of information. -what should be the N value for files whose size is defined by "3*N, N>=4"? -what optional files will be needed when the layer 2-3 will be ready to talk with the SIM? I let you read the TS11.11 spec to make your choice. Thanks, Sebastien

1 0

AW: SIM card cuttingg
by Andreas.Eversberg 18 Mar '10

18 Mar '10

hi, i prefer the CNC machine solution. it looks pretty easy to me. in my example white = fully cut out. black = no cut, light gray = more deep , dark gray = less deep. two thick metal peaces are cut from a metal band. the left one has partly cut out path for the frame to cut from the card. the right one has partly cut out area to carry the card. the frame is lower than the border, so the card will be positioned before it is cut out. hole in the left plate (white dots) will help to remove the plastic inside the frame path. andreas

1 0

Re: Regarding the cable from Dealextreme
by Dieter Spaar 18 Mar '10

18 Mar '10

Hello Chris, On Thu, 18 Mar 2010 08:34:18 +0100, "Christian Vogel" <vogelchr(a)vogel.cx> wrote: > > Maxim alone has about a dozen variations of the MAX232 (max3232 for 3v3, e.g). > > It's much easier to directly go from USB to TTL/3v3 serial ports, the > basic breakout boards from Sparkfun (e.g. > http://www.watterott.com/de/FTDI-Basic-Breakout-33V) seem to be fine > and sell for ?12. Haven't used them on a C123-phone, though. Thanks for the info. I am a bit old-fashioned when it comes to serial communication, I prefer to use "real" RS-232 because its much more predictable with regards to timing. For the USB serial adpaters it depends on the used interface chip. Of course for "standard" serial communication where the timing is not critical an USB serial adapter is just fine. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: Regarding the cable from Dealextreme
by Dieter Spaar 18 Mar '10

18 Mar '10

Hello Sebastien, On Thu, 18 Mar 2010 08:07:23 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote: > > You can now be sure: the 3.3v part is the MAX 3232. > Other parts exists that need smaller capacitors (100nF) instead of 1-10uF > required by the "grand father" MAX232 :) Thanks for the update. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: Regarding the cable from Dealextreme
by Dieter Spaar 18 Mar '10

18 Mar '10

Hello Lubomir, On Thu, 18 Mar 2010 01:00:44 +0100, "Lubomir Schmidt" <gentoo.lubomir(a)googlemail.com> wrote: > > How can i change the cable to get it working? What is a > level-converter and where can i get such? The level of the RS-232 interface is specified to be -3V..-15V for a logic one and +3V..+15V for a logic zero, typically -12V and +12V is used. The phone uses 0V and 3.2V. So you need a level-converter between the RS-232 port of a PC and the phone. The simple solution is to use a ready-made data cable with a built-in level-converter, they cost around 9.00 EUR on ebay Germany including shipping, either as USB or RS-232 variant. If you really want to build your own level-converter, you can for example use the MAX232 IC. The MAX232 is for TTL level (0V and 5V), I think there is a variant for 3.2V available, however I am not 100% sure. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 2

jtag voltage
by Nathan Fain 18 Mar '10

18 Mar '10

I'm starting to look at the JTAG of the c155. does anyone know the VCC level the IC's are running at. JTAG lines will likely be the same. thanks

4 3

Re: Sim
by Dieter Spaar 17 Mar '10

17 Mar '10

Hello Sebastien, On Tue, 16 Mar 2010 10:04:07 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote: > > I know that smart card EEPROMS are rated for 100k writes, but I would not > rely on that. In fact, this depends on how often is the EF.Kc file written, > which was my original question. Every 30 seconds or every day? Every day is > of course OK. It is only written if an AUTHENTICATION REQUEST from the network is performed. This usually happens when the phone is turned on and does a location update. The network can also perform an AUTHENTICATION REQUEST when doing a call or similar things, however usually this is not done every time and the previous Kc stored on the SIM is reused as Sylvain explained it. For OpenBSC and OpenBTS the default is that there is no AUTHENTICATION REQUEST at all, so no Kc is written (I am not 100% sure if this is true for OpenBTS, but I guess so). > Additionally, how often are these other files written (LOCI, BCCH) ? They are written when a location update is done or the cell changes. However it depends on the phone if the data is really written to the SIM every time, sometimes the phone caches those data and writes them to the SIM only when the phone is turned off. For OpenBSC and OpenBTS writing should not happen that often because there is usually only one cell with fixed parameters. And I guess you will probably not actually write to the EEPROM if the same data is already stored (or a least the Card OS should do it this way). > SmartCardFocus has a ID0 cutting service, that can turn any card into a SIM > sized module: > http://www.smartcardfocus.com/shop/ilp/id~82/p/index.shtml > This is the best option I know so far. Thanks, I did not know that. It would be interesting to know what tool they use and if it is available for a reasonable price. > However for devel purposes, as layer 2-3 will be developed on a PC, most > people will need/use a PCSC reader and a normal sized card. Any javacard > will do, even dual interface cards such as JCOP31 or Cosmo or older > Cyberflex. my applet will have no specific requirement on javacard support, > JC 2.1.x or 2.2.x will do. Yes, sure. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

7 11

C123 crashing (?)
by Patrick McHardy 16 Mar '10

16 Mar '10

I'm trying to run the layer1 firmware and the layer23 program with an C123, however as soon as the firmware reports a layer 1 reset and a L1CTL_NEW_CCCH_REQ message is sent to the phone, it appears to crash and sends a new PROMPT1, causing an endless cycle of firmware uploads and following crashes. Bisection failed due to compiler errors, using trial-and-error I found that the last instructions successfully executed are in l1a_l23_rx_cb(), case L1CTL_NEW_CCCH_REQ, just before the tpu_end_scenario() call. tpu_end_scenario() is what appears to be triggering the crash, more specifically its the tpu_enable() call in tpu_end_scenario(). Any hints how to debug this further? For reference, this is the output of osmocon: $ ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/layer1.bin Received PROMPT1 from phone, responding with CMD read_file(../../target/firmware/board/compal_e88/layer1.bin): file_size=35848, hdr_len=4, dnload_len=35855 ... handle_write(): finished Received DOWNLOAD ACK from phone, your code is running now! Hello World from apps/layer1/main.c program code ====================================================================== Device ID code: 0xb4fb Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Dropping sample '~' === THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!! 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: 0x0000 0x0000 Finishing download phase DSP Download Status: 0x0002 hdlc_send_to_phone(dlci=5): 01 00 00 00 00 00 14 00 Received PROMPT1 from phone, responding with CMD read_file(../../target/firmware/board/compal_e88/layer1.bin): file_size=35848, hdr_len=4, dnload_len=35855 ... Received PROMPT2 from phone, starting download and so on.

4 8

Re: Sim
by Dieter Spaar 16 Mar '10

16 Mar '10

Hello Sebastien, On Tue, 16 Mar 2010 00:09:46 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote: > > Sylvain, if I evolve your algorithm, then I think we don't need to store > anything in EEPROM. Just keep that in RAM and force a renegociation at MS > boot. What do you think of that? Just a question: Why do you want to avoid writing Kc to the EEPROM ? The cards I know have a quite huge number of EPPROM write cycles, e.g. for a certain MULTOS card the number is specified to be 500.000. I don't know the number for the card you use, but I expect it to be at least 100.000. For our purpose this should be really good enough, I would expect more writes to EF LOCI and EF BCCH than to EF KC. A question to the list: does anyone know where to get a tool to cut out a SIM from a standard smart card ? I don't prefer doing this with a knife or similar, this might only be OK for one or two pieces and the result also does not look too good. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 2

Sim
by Sébastien Lorquet 16 Mar '10

16 Mar '10

(sorry dexter , this was intended for the list - someone has to fix the reply-to address of this group) Hi all, Tonight I worked on the sim implementation with javacard. I will update this thread with my progress. A few minutes ago, I completed the most important parts selection and creation code, that allows me to create any directory structure on the card. There is no security yet, only the highway to what is necessary. Side roads will be added later. My implementation has a Master File (MF) and the possibility to create directories (Dedicated Files, DF) like in any unix file system. File identifiers are 2 bytes long (Long identifier or LID). The MF is the tree root, with LID 0x3F00, and DFs can be nested to "any" level. I have a command to select directories, then create directories inside. this is the equivalence of : cd / (select MF) cd .. (select parent DF) cd <dir> (select a file with its LID, be it the parent, a brother or a child) mkdir <dir> (create DF) Everything related to this is described in ISO7816-4 (creation in ISO7816-9). You'll be happy (or not) to find BER-TLV encoded data here, too. I'm now focusing on having a ISO7816-4 compliant card applet whose code is separated from the filesystem implementation. This way, I'll be able to quickly switch from the ISO7816-4 commands to the TS 11.11 apdu commands. This is only a matter of what information is returned from the SELECT FILE apdu, and what selection modes are supported. In the coming day I'll focus on data file (EF) implementation, along with the READ and UPDATE commands. Select commands allowing content browsing are planned too (select first/next child) The current code is not in the global git yet, I prefer keeping it in my personal SVN until the first release. However if anyone is interested in looking at the code, I can provide access to it. Let me say this is quite specific code that will not be usable by everyone. You need skills in javacard, globalplatform and smart cards in general. Regards Sebastien PS: Guess the format of the current "Card FAT" :-) idx ty sf lid fch nxt par 0000: 01 00 3F00 0001 FFFF FFFF 0001: 01 00 2000 0002 0003 0000 0002: 01 00 3000 FFFF 0004 0001 0003: 01 00 4000 FFFF FFFF 0000 0004: 01 00 5000 FFFF FFFF 0001 OK, that was easy, just a list of entries forming a tree with "next" "child" and "parent" links. data files have a corresponding data block at the same index in another list. I can nest just everything I want, and create any number of files (well, atm 256, that is configurable, and the max file size is 32kB, that is fixed by the max array size in javacard - signed short ) until the card is full. tree corresponding to the list (index:file id): 0000:3F00 +--- 0001:2000 | +--- 0002:3000 | +--- 0004:5000 +--- 0003:4000

5 8

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

TS M30 files processing
by Hopsing K 10 Mar '10

10 Mar '10

I was preparsing the TS M30g smStack a bit and came out with something like this: http://netplugin.sourceforge.net/ ++append+next++ htmltag/CC/cc_act.c.pinfo.main.php (please concat the two url parts). I wondered weather I could support this project a bit by processing some more of the TS M30 files. However somebody has to tell me which ones are the relevant files to take into account. (Another limitation is the sourceforge mysql db limit...) Description on how to navigate: - Press on macros to expand - Press on expanded macro names for "definition"/place+view - "[<]" shrink macro expansion Also some hint: Isnt there a software only way to run the stack: Put even Layer1 on the PC ? Then connect directly to BTC software? Kind off skip the messy embedded thing altogether for development. -- Gruesse HopsingK

2 2

wiki-access/todo-list
by Wolfram Sang 09 Mar '10

09 Mar '10

Hello, I couldn't find any possibility to register for a trac-account. I assume it is intentional that only the maintainers may change content (I could see reasons for that)? If so, is there a chance to keep the todo-list updated? I know by now that there is already work ongoing for the C155-display driver. I just became unsure which other topics may already been worked on. Kind regards, Wolfram PS: One for the news section maybe? http://www.pro-linux.de/NB3/news/1/15336/1,osmocombb-will-mobilfunk-mit-fre…

3 5

timer_list implementation
by Harald Welte 09 Mar '10

09 Mar '10

hi! we now have a 'struct timer_list' API, its use is similar to that of the linux kernel (and openbsc). The caller (e.g. your driver/app) allocates a 'struct timer_list', sets the 'cb' function pointer to a callback function, and then schedules the timer with 'schedule_timer(&my_struct_tm, 600) for expiration in e.g. 600ms from now. Once the timer expires, it will call the callback. There's also an 'unsigned long' argument that you can pass along. Calling the timer expiration routines happens by calling update_timers() from the while (1) loop in the main program. This will of course change once we have a scheduler and tasks. 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)

5 10

AW: status layer 3
by Andreas.Eversberg 09 Mar '10

09 Mar '10

> L3 sends RSL RLL ESTABLISH REQUEST with LOC UPD REQ as L3_INFO > L2 converts this in SABM with LOC UPD REQ as payload > L1 sends the packet to the GSM network > L1 receives response from the GSM network > L2 generates RSL RLL ESTABLISH CONFIRM to L3 hi, just to see if i understand it right, here is my view of how it should work: (for reference, see Fig. A.4 in GSM 04.07 in the appendix A.) mobility management layer requires to send an location update, so it does the following things happen: - a msgb is created with payload, large enough for LOC UPD REQ, and a headroom to encapsulate it into other messages... - LOC UPD REQ is assembled by mobility management layer - the msbg is "pushed" to add radio ressource header in front of it - the radio ressource primitive RR EST REQ is written to radio ressource header - the msgb is now transferred using a function call to radio ressource layer - the radio ressource routes the message according to the state and the primitive to the appropiate handler of this message. (state machine) - there the msgb is "pulled" to remove that header - the handler of "RR EST REQ message in IDLE mode" stores the msbg until an IMM ASS is received, and starts channel request procedure... ... - when handling the IMM ASS, the radio ressource layer takes the stored msgb and pushes the RSL RLL header in front of it - the RSL RLL header gets informations about channel to establish, and the RSL EST REQ primitive is set - the msgb is sent down from radio ressource layer to layer 2, in this case the RSLms layer, using a function call. (RSL EST REQ represents the DL-ESTABLISH REQUEST primitive) while the message is walking from radio ressource layer down to layer 1, the primitives for inter-layer communication are added by the sending layer and removed by the receiving layer. is this procedure correct? (of course, more things are done at radio ressource and mobility management layers in the procedure above, but i just wanted to explain what happens to the msgb. regards, andreas

2 1

AW: status layer 3
by Andreas.Eversberg 08 Mar '10

08 Mar '10

hi, my last mail was written yesterday and somehow sent today. meanwhile i decided to work with GIT for the following reasons: - working with others parallel on L3 - faster solving of issues. solving before finishing the code. - backup (even loss of one weekend's work would be a great loss of motivation) i will try the GIT tonight... anyway here is my first issue: the messages between layer 3 (radio ressource) and layer 2 have primitives starting with DL_*. e.g. DL_RANDOM_ACCESS_REQ is used to send a CHANNEL REQUEST on the RACH. and DL_ESTABLISH_REQ is used to establish a layer 2 link on SDCCH or TCH. both messages carry layer 3 messages, like CHANNEL REQUEST or LOCATION UPDATE REQUEST. using msgb between layer 2 and 3 is not enough, because i need to exchange additional informations with layer 2. these are the primitives themselves, and in case of DL_ESTABLISH_REQ the channel information for frequency, channel type, slot, ect. my current solution is to use a structure with primitive type and all additional informations and a pointer to the attached layer 3 message, if there is actually one message. (not yet immplemented, but already implemented at mncc interface in openbsc.) to prevent function call loops, i use a queue in the upward direction, so the structure with the message is copied into a msbg and added to the queue. (remember that this message may carry another layer 3 message) is there a better (simpler) way? regards, andreas

2 1

AW: status layer 3
by Andreas.Eversberg 08 Mar '10

08 Mar '10

hi harald, as i am still working on RR MM and CC layer, it seems to be more complicated as i thought. remember all the messages in 04.08? but most problem is that i must first understand it all. i get more and more knowledge about it while reading it. i started implementing some parts, but most parts i do not understand yet. as i know from earlier project, it requires exact knowledge of every bit to do it right. when i am finished, i will tell you as soon as possible, but i think it takes some more weeks. anyway, there will be many issues then. as i can see, there the layer 2 and layer 1 will also be not that easy too. e.g. layer 2 must process channel descriptions to connect to the right channel and the right configurations and mode. also when i am finished, i will need to solve some coding issues, like message flow, queueing (to prevent message loops), and structures for subscriber data, telephone settings and system informations. as soon i am finished, i will make a list of remaining unsolved issues. and finally gsm 03.22 (selecting and changing cells) must also wants to be implemented. if you like to be aware of what i am doing, just watch my code base. it is live, so every time i do a write, it will be available at: http://home.eversberg.eu/alpha3/ regards, andreas

2 1

OsmocomBB update summary
by Harald Welte 07 Mar '10

07 Mar '10

Hi! Today, there have been quite a number of possibly intrusive changes in the repository. A quick summary: * prom's new makefile voodoo has been merged for the 'firmware' directory, this means we now have proper dependency tracking in our builds, as well as support for multiple board builds * the compiled elf/map/bin/... files are now in board/compal_{e88,e99}, rather than in the main directory. * the firmware now uses the real libosmocore (and its linuxlist, msgb,...) code. No more code duplication, and one step closer to easy migration of the layer23 code into the firmware at some later day. * lots of minor changes here and there have been introduced to reduce number of compiler warnings. * l1ctl messages (L1 <-> L2/L3) communication has changed a little bit, it now includes only the frame number and not a full 'struct gsm_time'. This is important for anyone who has his own ocde to talk to the L1! I hope this was the last time we've had such an amount of changes, especially to the build system. 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)

1 0

C155 display driver
by Harald Welte 07 Mar '10

07 Mar '10

Hi Steve, I have now partially merged your C155 display driver. Partial, since I only merged those parts that didn't break the build for C123. So what needs to be done soon: * support multipe 'boards' in our Makefile magic, producing NR_BOARDS * NR_APPS images as a result. * merge those parts that are identical between board_e88 and board_e99 and create something like a calypso_init() function, keeping only board specific bits in the board_init() * introduce some "lcd_puts()" macro that is defined to either of the two display drivers, depending on the board that we're building for. If anyone is posting patches (or a git branch) for that, I'd be happy to merge them. Later on, I want a LCD abstraction layer that hides the details from the apps. The app should not have to care about color/monochrome, or the fact that the X/Y coordinates seem to be inverted between the displays. I personally have no interest in doing that, as GSM related work has much higher priority to me. I hope somebody in the community will take care of the task. Thanks in advance! 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)

1 0

Re: status layer 3
by Harald Welte 05 Mar '10

05 Mar '10

Hi Andreas, I'm going to pick up your questions as found in your preliminary http://home.eversberg.eu/alpha3/ code. I took the liberty of posting to the ML, as other people will definitely be interested in this, too. 1) why is layer2 a socket client? because we want to develop layer2 + layer3 + everything above on the PC first, while keeping the L1 on the phone. This makes debugging much easier. Later we will simply move the code to the phone and run it in one or multiple tasks of the operating system, replacing sercomm + unix socket with message queues. 2) where is layer3 to go? I think we can directly put it into the layer2 program, but try to keep a clean seperation between l2 and l3, using the REQUEST/RESPONSE/INDICATION primitives. 3) where should the app (layer4) go? library or console? it should live on top of the l23 stack, preferrably as its own program. There is a lot of sense for having the application (UI) as its own process/thread, and the stack in its process/thread. 4) Is the TLV parser buffer-overflow safe? TLV parser (libosmocore) is not buffer-overflow safe, patches are appreciated. 5) classmark1 lsb/msb twisted: I have no idea :) 6) lchan/ms mapping. I don't have a clear idea on this either. I'm not so sure if the 'lchan' concept makes much sense in a phone at all. A phone typically only uses one dedicated channel at any given point - with corner cases in the event of a handover, where we 'switch back' to the old channel if establishing the new channel fails. 7) ms instantiation for multiple devices I think this is not really an important issue at the moment. If there are multiple phones, there should be multiple instances (processes) of the layer23 stack. A normal application would also exist 1:1 for each stack instance. If you think of some PBX application, than I also think it is easier to have one instance (process or thread) of the stack for each phone. After all, the primary target for us is to make layer2+3 work in a phone, and there it will definitely be one instance for one phone. One additional comment: Please make sure that the common/shared code between OpenBSC and your Layer3 does get moved into libosmocore. I'm thinking particularly abotu code for parsing and generating the various IE's. We don't want to keep multiple implementations around... Thanks again for all your help, 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)

2 2

OsmocomBB developer meeting 2010-03-06 8pm CCCB
by Harald Welte 04 Mar '10

04 Mar '10

Hi! There will be an informal meeting of OsmocomBB hackers at the Berlin CCC (http://berlin.ccc.de/) on Saturday, 2010-03-06 at 8pm local time. Prom and myself will be there, most likely also dexter and tec. If you're local, feel free to join. There's no formal agenda, we just like to meet one more time before I'll disappear to Taiwan for quite some time. 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)

1 0

GSMTAP / layer23 / wireshark updates
by Harald Welte 04 Mar '10

04 Mar '10

Hi! I've improved the layer23 gsmtap support to add support for * uplink frames, sent by layer23 to L1 * properly support dedicated channels with LAPDm * allow the user to specify the GSMTAP destination IP address In order to use the new features, you need to 1) use the new gsmtap.patch for wireshark 2) use the '-i dstip' option of layer23, as the default is now to NOT generate GSMTAP UDP Packets I'm attaching a screen-shot showing the wireshark decode of the LOC UPD REQ generated by layer23. As you can see from the packet list, the BTS responds with the UA packet containing the same LOC UPD REQ as part of the contention resolution in LAPDm, just as expected. 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)

2 3

BTS
by Maxim 04 Mar '10

04 Mar '10

Hi, There is at least a theoretic way to turn Motorola C123 into a small BTS? Thanks

2 1

RFC: updated Wireshark patch
by Jason 04 Mar '10

04 Mar '10

All, I found some low-hanging fruit. :-) Attached is an updated patch against the latest wireshark trunk svn. It incorporates all of the requested changes in the bug comments [1]. Hopefully I'll be able to pitch in more once my C123 arrives... hth, Jason. [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4508

2 2

Re: hello_world.bin on C118
by Dieter Spaar 03 Mar '10

03 Mar '10

Hello Chekov, On Mon, 01 Mar 2010 15:32:53 +0100, "chekov" <chekov(a)riseup.net> wrote: > > still, this info differs from the wiki: > the last section is missing and the second last section is printed twice What you receive as output is OK, the current version of "hello_world" prints the same clock configuration twice and doesn't start the DSP. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 3

Status update / layer23
by Harald Welte 03 Mar '10

03 Mar '10

Hi! I'm pleased to report that the current master branch in osmocom-bb.git has initial support for bi-directional communication, and handles messages all the way up from L1 to L3 and back. The architecture is as follows: L1 events (such as received 23byte mac blocks) are encapsulated in L1CTL messages, which are sent over HDLC/rs232 to the PC. 'osmocon' then demultiplexes the L1CTL from the console messages and sends it via unix domain socket to the layer23 program. Inside layer23, L1CTL is decapsulated and passed into the LAPDm code, from where the data is encapsulated in RSLms (RSL for mobil station, my invention) and handed off to L3. Messages from L3 take the opposite way L3->RSLms->LAPDm->L1CTL->HDLC->L1 So far, we still only support IMMEDIATE ASSIGNments to SDCCH/4 on a combined CCCH. But if you are on a BTS with that channel configuration, layer23 will now happily send a LOCATION UPDATE REQUEST to the BTS :) Dieter has indicated he will be looking into supporting TCH/F as well as frequency hopping during the next week(s). I myself desperately need to get some real work done at this point, so don't expect any major developments for some time. 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)

1 0

Strange Problem / Cheap Cables
by Lubomir Schmidt 03 Mar '10

03 Mar '10

Hello. First of all: You can get here extremely cheap the defenetly correct cable(i buy it with hope it could be the right one and had luck. Now everybothy can get a cheap one): http://www.dealextreme.com/details.dx/sku.14664 You could add/change that in the wiki. How it is connected: GND: next to the cable and COM-Port-Pin nr 5 Rx: in the middle and COM-Port-Pin nr 2 Tx: at the smal end and COM-Port-Pin nr 3 And now my problem: I use ARM binary from here: http://embdev.net/articles/ARM_GCC_toolchain_for_Linux_and_Mac_OS_X Everything compiled fine so far. I doesnt use any converter. Just use a real com Port from a older Notebook. I run: ./osmocon -m c123 -p /dev/ttyS0 ../where_the_firmware_is/hello_world.bin And get the result you see in the attachment. Phone: It is an C118 with Firmware 1.0.75 and it is locked to Vodafone DE. I tried today nearly 5 hours all tools for windows i could find to unlock the phone. There was no tool that worked(some also worked with pressing on-button shortly in off-modus). Maybe the problem is in the computer i used (also older one with real com-port.notebook is linux-only). Maybe the phone. Did i understand right, that when i get the output like here: http://bb.osmocom.org/trac/wiki/osmocon I also could get somehow the unlock key? Can you tell me then how? The Unlock Code is always 8 Numbers. After 5 hours i also know that it could be in A:0x7FC300 or A:0x7FC600 Thanks so far

2 2

Re: Strange Problem / Cheap Cables
by nicolho 03 Mar '10

03 Mar '10

hi everyone, could the strange problem be related to the cheap cable...? still waiting for usb data cable from akku-king (supply issue... related to osmocomBB project ?), i'm also experiencing unstable serial communications with this cable : http://www.multi-unlock.com/images/mot-t191.jpg some related questions : does someone here use this cable ? : http://gsmserver.com/newshop/images/large/COM_cable_for_Motorola_T191.jpg can we use direct connection to PC serial port (UART or usb serial adapter) safely ? i mean without any ttl level conversion (like max-232) ? which exact FTDI usb to serial chipset (ie FT232R) is most recommended, with : - good linux driver support - support for a possible future use of higher non-standard baud rates ? is there any serial port configuration trick or driver tweak to get better serial communications with osmocon ? thanks nico

2 1

uplink branch merged / CONFIG_TX_ENABLE
by Harald Welte 02 Mar '10

02 Mar '10

Hi! I have decided to merge the uplink branch as master didn't even build and wasn't receiving any attention from my side. In order to avoid any accidents, the default builds of the master branch will not include any Tx functionality. If you want to enable it, you have to use "CONFIG_TX_ENABLE" while compiling (by enabling it in Makefile.inc). 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)

1 0

l1test hangs
by Hessel 02 Mar '10

02 Mar '10

Hi all, This weekend I had my first try with a C123, and everything seemed to work great from the start. But suddenly when uploading l1test.bin to the phone, it seems to hang after the first three ARFCN's found, like so: 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 Dropping sample '~' ============= 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: 0x975b 0xadac Finishing download phase DSP Download Status: 0x0002 DSP API Version: 0x3606 0x0000 Performing power measurement over GSM900 LOST!ARFCN Top 10 Rx Level ARFCN 7: -102 dBm ARFCN 10: -103 dBm ARFCN 14: -103 dBm When I press any button of the phone it continues by showing the remaining ARFCNs, but nothing else: ARFCN 43: -103 dBm ARFCN 85: -103 dBm ARFCN 87: -103 dBm ARFCN 105: -103 dBm ARFCN 115: -103 dBm ARFCN 123: -103 dBm ARFCN 96: -104 dBm Starting FCCH Recognition key=12 pressed key=12 released I also noticed the dBm values, all channels are barely above the noise floor, right? Does anybody have tips on how to get running again? Thanks, Hessel

2 2

Re: Getting Started..
by Dieter Spaar 02 Mar '10

02 Mar '10

Hello Thomas, On Mon, 01 Mar 2010 23:45:43 +0100, "Thomas Kindler" <mail+gsm(a)t-kindler.de> wrote: > What do I do wrong? There is probably something wrong with your cable or configuration. I have marked the lines below in your log, the marked bytes are the "download command" sent by osmocon. Those bytes are never echoed back by the bootloader and you should not see them. So you should first check why you see those bytes. > 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=16676, > hdr_len=4, dnload_len=16683 > got 1 bytes from modem, data looks like: 1b <<- should not be there > got 1 bytes from modem, data looks like: f6 <<- should not be there > got 1 bytes from modem, data looks like: 02 <<- should not be there > got 1 bytes from modem, data looks like: 00 <<- should not be there > got 1 bytes from modem, data looks like: 52 <<- should not be there > got 1 bytes from modem, data looks like: 01 <<- should not be there > got 1 bytes from modem, data looks like: 53 <<- should not be there > got 1 bytes from modem, data looks like: 66 > got 1 bytes from modem, data looks like: 74 > got 1 bytes from modem, data looks like: 6d > ... Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

The 'uplink' branch / Status update
by Harald Welte 02 Mar '10

02 Mar '10

Hi! After quite a bit of hacking on libosmocore as well as the various parts of Osmocom-BB, I've now committed the latest state to the 'uplink' branch of osmocom-bb.git. I have decided to introduce RSL/RLL as the interface between Layer2(LAPDm) and Layer3(04.08), as it is a clean protocol that we already understand from the OpenBSC side. You can see in src/host/layer2/src/osmocom_rslms.c how we receive e.g. the 04.08 PAGING REQUEST and 04.08 IMMEDIATE ASSIGNMENT on the PCH/AGCH inside RSL UNIT DATA INDICATION messages. Please note the layer2/src/lapdm.c implementation is extremely incomplete, particularly when it comes to ABM (asynchronous balanced mode) and I-frames. It's full of FIXME's that I'll be working on as soon as possible. However, the infrastructure now seems to be coming together and we basically have everything in place for bi-directional transmission of data for SAPI0 and SAPI3 for both DCCH and ACCH (limited to SDCCH/4 on combined CCCH on C0T0) 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)

1 0

Getting Started..
by Thomas Kindler 01 Mar '10

01 Mar '10

Hi! I'm just getting started with GSM and Osmocom and received my C123 from eBay last week. I got everything to compile under Ubuntu 9.10, using the arm-elf toolchain from http://embdev.net/articles/ARM_GCC_toolchain_for_Linux_and_Mac_OS_X Will that be usable at all? As I'm still waiting for my official cable to arrive, I built one myself using an old CP2102 USB-Serial development board.. unfortunately, osmocon fails to upload programs: $ ./osmocon -p /dev/ttyUSB0 -m c123../../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=16676, hdr_len=4, dnload_len=16683 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: 52 got 1 bytes from modem, data looks like: 01 got 1 bytes from modem, data looks like: 53 got 1 bytes from modem, data looks like: 66 got 1 bytes from modem, data looks like: 74 got 1 bytes from modem, data looks like: 6d got 1 bytes from modem, data looks like: 74 got 1 bytes from modem, data looks like: 6f got 1 bytes from modem, data looks like: 6f got 1 bytes from modem, data looks like: 6c Received FTMTOOL from phone, ramolader has aborted got 1 bytes from modem, data looks like: 65 got 1 bytes from modem, data looks like: 72 got 1 bytes from modem, data looks like: 72 got 1 bytes from modem, data looks like: 6f got 1 bytes from modem, data looks like: 72 What do I do wrong? best regards, -- Thomas Kindler <mail+gsm(a)t-kindler.de>

1 0

Hi all
by Erik Ekman 01 Mar '10

01 Mar '10

I have ordered a C139+cable and I am waiting for it to arrive. I guess the helloworld and other binaries will run on it but the peripherals that differ from the C123 will not work. Is that correct? At work we used ARM7TDMI, now an ARM9, and we looked at FreeRTOS before going for a custom non-RTOS event-based os. We use the gnu toolchain and OpenOCD. So far, I have only used GSM/GPRS from the AT-command level, but it looks interesting to see more. While waiting for the hardware I did some trivial patches for osmocon that are attached. Hope that form (as well as the content :) is acceptable. /Erik

2 1

more c118 testing
by chekov 01 Mar '10

01 Mar '10

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

2 1

Re: hello_world.bin on C118
by Dieter Spaar 01 Mar '10

01 Mar '10

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

2 1

layer2/3 interface
by Harald Welte 01 Mar '10

01 Mar '10

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)

1 0

hello_world.bin on C118
by chekov 01 Mar '10

01 Mar '10

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.

1 0

Re: batter charging interface / iota madc block
by Dieter Spaar 28 Feb '10

28 Feb '10

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

1 0

batter charging interface / iota madc block
by Joachim Steiger 28 Feb '10

28 Feb '10

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

1 0

Bootloader
by Ingo Albrecht 27 Feb '10

27 Feb '10

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

1 0

C155 display driver
by Harald Welte 27 Feb '10

27 Feb '10

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)

1 0

Motorola C200
by Tiago Maluta 27 Feb '10

27 Feb '10

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

2 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel