baseband-devel April 2010

baseband-devel@lists.osmocom.org

25 participants
42 discussions

large collection of gsm related datasheets
by willem 19 Apr '10

19 Apr '10

i found this, searching google/codesearch for 'ftm_cmd' svn co http://hwplatform.googlecode.com/svn/trunk/ about 1.5G of datasheets, sourcecode, and tools for various phones. willem

5 4

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel April 2010