baseband-devel March 2010

baseband-devel@lists.osmocom.org

37 participants
76 discussions

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 28 Mar '10

28 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 28 Mar '10

28 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 22 Mar '10

22 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 22 Mar '10

22 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 22 Mar '10

22 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel March 2010