May 2011 - baseband-devel - lists.osmocom.org

by Alan Carvalho de Assis

FYI ---------- Forwarded message ---------- From: Gregory Nutt <spudarnia(a)yahoo.com> Date: Sun, 15 May 2011 07:52:18 -0700 (PDT) Subject: Re: Fwd: RFC: RTOS for Calypso To: Alan Carvalho de Assis <acassis(a)gmail.com> Hi Alan, I also notice that they are using a TI dual core, ARM7TDMI and C5 DSP. I already have support for a TI chip like that (the C5471) and also for an ARM9 with C5 DSP (DM320). See http://focus.ti.com.cn/cn/lit/ml/sprt239/sprt239.pdf I have a c5 DSP bridge driver somewhere around on my backup disks as well. I never released it into NuttX because there was never any need. Perhaps that could be useful now. Somewhere I also have tools that will convert the TI proprietary object files and logic to manage loading different programs into the DSP. The bridge also supports communication channels to communicate with the DSP. Greg

12 years, 11 months

1
0
0 0

RFC: RTOS for Calypso

by l--putt

Hi! Is AreasOfWork in the wiki still up to date? I intend to work on the UI (Sorry Dieter, GSM testset too expensive at the moment :( ) and want to choose a RTOS. A small collection that I came across: FreeRTOS What is the problem? TNKernel http://www.tnkernel.com/tn_description.html Scheduler, Mutexes, Queues, etc. available strange (at least unfamiliar) API for memory eCos http://ecos.sourceware.org/about.html many target MCUs but are their any other than ARM in BB chipsets? powerful but complex (at least at first glance) NUT/OS http://www.ethernut.de/en/ minimalistic RTOS, easy to port seems to have sound community familiar APIs: malloc, fopen's devices, ... cooperative multithreading: Is that OK? We still have IRQs for realtime... Since we seem to barely need an OS, a full-blown OS like eCos seems excessive. For compatibility with MT6235 user space, malloc and fopen is the right direction. Hence, my favourite is NUT/OS. In fact, I tried porting it to calypso just for fun. With some wrappers, Osmocom's platform files can be used. Only turns on the backlight and occasionally outputs some bytes on the UART at the moment. However, I still call this success. It took me just a day from knowing nothing about NUT/OS and very little about calypso and ARM to do this. Seems promising in terms of portability and documentation to me. Open question: How much overhead can we afford, i.e., how much spare time is there on the CPU? Does "Disable RTC interrupt as it causes lost TDMA frames" (layer1/init.c) indicate issues? (Yes, sorry, haven't read GSM specs yet...) If yes, is it reasonable to independently handle GSM stuff with FIQ and only give IRQ to whatever OS we choose? Regards, Stefan

12 years, 11 months

13
27
0 0

[PATCH,v2] SMS decode

by Gianni Tedesco

This is a folowup to previous patch implementing SMS decoding. I have removed the 7bit decoding functions to use those in libosmocore. This time I have also tried to send CP-ACK in response to the CP-DATA containing the SMS. But this seems to break the entire state machine, not sure what I'm doing wrong here. I just built the packet and used gsm48_rr_downmsg() to send it. Maybe I just need to learn more about the lower layers. A BTS or a GSM tester would be really handy I guess... Gianni diff --git a/src/host/layer23/include/osmocom/bb/mobile/gsm48_sms.h b/src/host/layer23/include/osmocom/bb/mobile/gsm48_sms.h new file mode 100644 index 0000000..99911ad --- /dev/null +++ b/src/host/layer23/include/osmocom/bb/mobile/gsm48_sms.h @@ -0,0 +1,7 @@ +#ifndef _GSM48_SMS_H +#define _GSM48_SMS_H + +int gsm48_rcv_sms(struct osmocom_ms *ms, struct msgb *msg); + +#endif /* _GSM48_SMS_H */ + diff --git a/src/host/layer23/src/mobile/Makefile.am b/src/host/layer23/src/mobile/Makefile.am index fb0423e..60e8d23 100644 --- a/src/host/layer23/src/mobile/Makefile.am +++ b/src/host/layer23/src/mobile/Makefile.am @@ -4,7 +4,7 @@ LDADD = ../common/liblayer23.a $(LIBOSMOCORE_LIBS) $(LIBOSMOVTY_LIBS) $(LIBOSMOG noinst_LIBRARIES = libmobile.a libmobile_a_SOURCES = gsm322.c gsm48_cc.c gsm48_mm.c gsm48_rr.c \ - mnccms.c settings.c subscriber.c support.c \ + gsm48_sms.c mnccms.c settings.c subscriber.c support.c \ transaction.c vty_interface.c bin_PROGRAMS = mobile diff --git a/src/host/layer23/src/mobile/gsm48_mm.c b/src/host/layer23/src/mobile/gsm48_mm.c index bf5bbc2..2155a71 100644 --- a/src/host/layer23/src/mobile/gsm48_mm.c +++ b/src/host/layer23/src/mobile/gsm48_mm.c @@ -36,6 +36,7 @@ #include <osmocom/bb/common/networks.h> #include <osmocom/bb/common/l1ctl.h> #include <osmocom/bb/mobile/gsm48_cc.h> +#include <osmocom/bb/mobile/gsm48_sms.h> #include <osmocom/bb/mobile/app_mobile.h> extern void *l23_ctx; @@ -737,10 +738,10 @@ int gsm48_mmxx_dequeue(struct osmocom_ms *ms) case GSM48_MMSS_CLASS: gsm48_rcv_ss(ms, msg); break; +#endif case GSM48_MMSMS_CLASS: gsm48_rcv_sms(ms, msg); break; -#endif } msgb_free(msg); work = 1; /* work done */ @@ -3788,11 +3789,11 @@ static int gsm48_mm_data_ind(struct osmocom_ms *ms, struct msgb *msg) rr_prim = GSM48_MMSS_DATA_IND; rr_est = GSM48_MMSS_EST_IND; break; +#endif case GSM48_PDISC_SMS: rr_prim = GSM48_MMSMS_DATA_IND; rr_est = GSM48_MMSMS_EST_IND; break; -#endif } if (rr_prim != -1) { uint8_t transaction_id = ((gh->proto_discr & 0xf0) ^ 0x80) >> 4; @@ -3847,9 +3848,10 @@ static int gsm48_mm_data_ind(struct osmocom_ms *ms, struct msgb *msg) case GSM48_PDISC_NC_SS: return gsm48_rcv_ss(ms, msg); +#endif case GSM48_PDISC_SMS: + LOGP(DMM, LOGL_NOTICE, "SMS PDISC = 0x%.2x\n", GSM48_PDISC_SMS); return gsm48_rcv_sms(ms, msg); -#endif default: LOGP(DMM, LOGL_NOTICE, "Protocol type 0x%02x unsupported.\n", diff --git a/src/host/layer23/src/mobile/gsm48_sms.c b/src/host/layer23/src/mobile/gsm48_sms.c new file mode 100644 index 0000000..5337b1e --- /dev/null +++ b/src/host/layer23/src/mobile/gsm48_sms.c @@ -0,0 +1,355 @@ +/* + * (C) 2010 by Andreas Eversberg <jolly(a)eversberg.eu> + * (C) 2011 by Gianni Tedesco <gianni(a)scaramanga.co.uk> + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include <stdint.h> +#include <errno.h> +#include <stdio.h> +#include <string.h> +#include <stdlib.h> +#include <arpa/inet.h> + +#include <osmocom/core/msgb.h> +#include <osmocom/core/utils.h> +#include <osmocom/gsm/gsm48.h> +#include <osmocom/core/talloc.h> + +#include <osmocom/bb/common/logging.h> +#include <osmocom/bb/common/osmocom_data.h> +#include <osmocom/bb/common/networks.h> +#include <osmocom/bb/common/l1ctl.h> +#include <osmocom/bb/mobile/gsm48_sms.h> +#include <osmocom/bb/mobile/app_mobile.h> + +/* GSM 04.11 Table 8.1 */ +#define CP_DATA 1 +#define CP_ACK 4 +#define CP_ERROR 16 + +#define CP_CAUSE_INVALID_MANDATORY_INFO 96 +#define CP_CAUSE_MSG_TYPE_NOT_IMPLEMENTED 97 +#define CP_CAUSE_INFO_ELEMENT_NOT_IMPLEMENTED 97 +#define CP_CAUSE_PROTOCOL_ERROR 111 + +#define RP_DATA 1 +#define RP_ACK 3 +#define RP_ERROR 5 + +#define TP_MTI_MASK 3 +#define SMS_DELIVER 0 +#define SMS_SUBMIT_REPORT 1 +#define SMS_STATUS_REPORT 2 + +#define TP_RP 0x80 +#define TP_UDHI 0x40 +#define TP_SRI 0x20 +#define TP_MMS 0x04 + +static uint8_t hi_nibble(uint8_t byte) +{ + return byte >> 4; +} + +static uint8_t lo_nibble(uint8_t byte) +{ + return byte & 0xf; +} + +static int parse_address(struct msgb *msg, int rp, const char *name) +{ + uint8_t len, type; + + if ( !msg->len ) + return -EPROTO; + + len = msgb_get_u8(msg); + if ( !len ) + return 0; + + type = msgb_get_u8(msg); + + if ( rp ) { + /* for RP address, len is in bytes including type field */ + len = len - 1; + }else{ + /* TP address is in BCD digits, not including type field */ + len = len / 2; + } + + if ( msg->len < len ) + return -EPROTO; + + LOGP(DMM, LOGL_NOTICE, "%s: type=0x%.2x %s\n", + name, type, hexdump(msg->data, len)); + + msgb_pull(msg, len); + return 0; +} + +static int parse_timestamp(struct msgb *msg, const char *name) +{ + if ( msg->len < 7 ) + return -EPROTO; + LOGP(DMM, LOGL_NOTICE, + "%s: 20%1x%1x-%1x%1x-%1x%1x %1x%1x:%1x%1x:%1x%1x\n", + name, + lo_nibble(msg->data[0]), + hi_nibble(msg->data[0]), + lo_nibble(msg->data[1]), + hi_nibble(msg->data[1]), + lo_nibble(msg->data[2]), + hi_nibble(msg->data[2]), + lo_nibble(msg->data[3]), + hi_nibble(msg->data[3]), + lo_nibble(msg->data[4]), + hi_nibble(msg->data[4]), + lo_nibble(msg->data[5]), + hi_nibble(msg->data[5])); + msgb_pull(msg, 7); + return 0; +} + +static int sms_7bit(const uint8_t *in, size_t octets, size_t chars) +{ + char out[chars + 1]; + + if ( (chars * 7 + 6) / 8 > octets ) { + chars = (octets * 8) / 7; + octets = (chars * 7 + 6) / 8; + } + + gsm_7bit_decode(out, in, octets); + LOGP(DMM, LOGL_NOTICE, "SMS-MSG: %s\n", out); + return 0; +} + +static int sms_deliver(struct osmocom_ms *ms, struct msgb *msg, uint8_t b) +{ + uint8_t tp_pid, tp_dcs, tp_udlen; + int rc; + + if ( !(b & TP_MMS) ) + LOGP(DMM, LOGL_NOTICE, "SMS-DELIVER: More messages to send.\n"); + + rc = parse_address(msg, 0, "TP-Originating"); + if ( rc ) + return -EPROTO; + + if ( msg->len < 2 ) + return -EPROTO; + + tp_pid = msgb_get_u8(msg); + tp_dcs = msgb_get_u8(msg); + LOGP(DMM, LOGL_NOTICE, "TP-PID: 0x%.2x\n", tp_pid); + LOGP(DMM, LOGL_NOTICE, "TP-DCS: 0x%.2x\n", tp_dcs); + + rc = parse_timestamp(msg, "TP-Service-Center-Time-Stamp"); + if ( rc ) + return -EPROTO; + + if ( !msg->len ) + return -EPROTO; + tp_udlen = msgb_get_u8(msg); + + /* TODO: user-data-header? */ + + /* check for unknown data coding scheme */ + switch(tp_dcs) { + case 0: + return sms_7bit(msg->data, msg->len, tp_udlen); + default: + return -EPROTO; + } + + return 0; +} + +static int sms_tpdu_decode(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t tp_mti; + + if ( !msg->len ) + return 0; + tp_mti = msgb_get_u8(msg); + + switch(tp_mti & TP_MTI_MASK) { + case SMS_DELIVER: + return sms_deliver(ms, msg, tp_mti); + case SMS_SUBMIT_REPORT: + LOGP(DMM, LOGL_NOTICE, "Received SMS-SUBMIT-REPORT: %s\n", + hexdump(msg->data, msg->len)); + break; + case SMS_STATUS_REPORT: + LOGP(DMM, LOGL_NOTICE, "Received SMS-STATUS-REPORT: %s\n", + hexdump(msg->data, msg->len)); + break; + default: + LOGP(DMM, LOGL_NOTICE, "Reserved MTI: 0x%.2x\n", + tp_mti); + return -EPROTO; + } + + return 0; +} + +static int rp_data_decode(struct osmocom_ms *ms, struct msgb *msg, uint8_t ref) +{ + static const char * const str[2] = {"RP-Origination", "RP-Destination"}; + unsigned int i; + uint8_t tpdu_len; + + LOGP(DMM, LOGL_NOTICE, "Received RP-DATA: ref %d\n", ref); + + for(i = 0; i < 2; i++) { + int rc; + + rc = parse_address(msg, 1, str[i]); + if ( rc ) + return -EPROTO; + } + + if ( !msg->len ) + return -EPROTO; + tpdu_len = msgb_get_u8(msg); + if ( tpdu_len < msg->len ) + return -EPROTO; + if ( tpdu_len < msg->len ) { + LOGP(DMM, LOGL_NOTICE, "RP-DATA: %u trailing bytes: %s\n", + msg->len - tpdu_len, + hexdump(msg->data + tpdu_len, msg->len - tpdu_len)); + msg->len = tpdu_len; + } + + /* TODO: pass in reference, and src/dst addresses */ + return sms_tpdu_decode(ms, msg); +} + +/* TODO: whatever happens here we need to send RP-ACK or RP-ERROR */ +static int rp_decode(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t rp_mt, rp_ref; + + if ( msg->len < 2 ) + return -EPROTO; + + rp_mt = msgb_get_u8(msg); + rp_ref = msgb_get_u8(msg); + + switch(rp_mt) { + case RP_DATA: + return rp_data_decode(ms, msg, rp_ref); + case RP_ACK: + LOGP(DMM, LOGL_NOTICE, "Received RP-ACK: %s\n", + hexdump(msg->data, msg->len)); + return -ENOTSUP; + case RP_ERROR: + LOGP(DMM, LOGL_NOTICE, "Received RP-ERROR: %s\n", + hexdump(msg->data, msg->len)); + return -ENOTSUP; + default: + LOGP(DMM, LOGL_NOTICE, "Bad RP Message-type: 0x%.2x\n", rp_mt); + return -ENOTSUP; + } + + return 0; +} + +static int cp_tx_error(struct osmocom_ms *ms, uint8_t tid, uint8_t cause) +{ + struct gsm48_hdr *gh; + struct msgb *msg; + + msg = gsm48_l3_msgb_alloc(); + if ( NULL == msg ) + return -ENOMEM; + + gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh)); + gh->proto_discr = tid | GSM48_PDISC_SMS; + gh->msg_type = CP_ERROR; + msgb_put_u8(msg, cause); + return gsm48_rr_downmsg(ms, msg); +} + +static int cp_tx_ack(struct osmocom_ms *ms, uint8_t tid) +{ + struct gsm48_hdr *gh; + struct msgb *msg; + + msg = gsm48_l3_msgb_alloc(); + if ( NULL == msg ) + return -ENOMEM; + + gh = (struct gsm48_hdr *) msgb_put(msg, sizeof(*gh)); + gh->proto_discr = tid | GSM48_PDISC_SMS; + gh->msg_type = CP_ACK; + return gsm48_rr_downmsg(ms, msg); +} + +static int cp_data(struct osmocom_ms *ms, uint8_t tid, struct msgb *msg) +{ + uint8_t len; + + if ( !msg->len ) { + return cp_tx_error(ms, tid, CP_CAUSE_PROTOCOL_ERROR); + } + + len = msgb_get_u8(msg); + if ( len != msg->len ) { + LOGP(DMM, LOGL_NOTICE, "CP-DATA: size mismatch " + "%u != %u bytes\n", len, msg->len); + }else{ + LOGP(DMM, LOGL_NOTICE, "CP-DATA: %u bytes\n", len); + } + + rp_decode(ms, msg); + return cp_tx_ack(ms, tid); +} + +int gsm48_rcv_sms(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t cp_type, tid; + int rc; + + LOGP(DMM, LOGL_NOTICE, "Received SMS: %s\n", + hexdump(msg->data, msg->len)); + + tid = msgb_get_u8(msg) & 0xf0; + if (!msg->len) { + rc = cp_tx_error(ms, tid, CP_CAUSE_PROTOCOL_ERROR); + goto out; + } + + cp_type = msgb_get_u8(msg); + + switch(cp_type) { + case CP_DATA: + rc = cp_data(ms, tid, msg); + break; + default: + LOGP(DMM, LOGL_NOTICE, "Unknown SMS type: 0x%.2x\n", cp_type); + rc = cp_tx_error(ms, tid, CP_CAUSE_MSG_TYPE_NOT_IMPLEMENTED); + break; + } + +out: + msgb_free(msg); + return rc; +}

12 years, 11 months

2
1
0 0

Fw: Re: mobile - making a call

by eisencah eisenach

So any ideea where to look for the answer to the UPDATE_BINARY message? Can I have a buffer overflow on UART RX? Is the buffer size selectable somewhere? --- On Wed, 5/4/11, eisencah eisenach <wbg_1000(a)yahoo.com> wrote: From: eisencah eisenach <wbg_1000(a)yahoo.com> Subject: Re: mobile - making a call To: baseband-devel(a)lists.osmocom.org Date: Wednesday, May 4, 2011, 4:58 PM Done some more digging in the logs and it seems the sim state machine has locked earlier (when attaching to the network) while waiting for some response on UPDATE BINARY. Does this sounds familiar to anyone? :) GOOD CASE: [0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) [0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) [0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:151 sending result to callback function (type=0) [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) BAD CASE: [0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) [0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) [0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state location updating initiated --- On Wed, 5/4/11, Harald Welte <laforge(a)gnumonks.org> wrote: From: Harald Welte <laforge(a)gnumonks.org> Subject: Re: mobile - making a call To: "eisencah eisenach" <wbg_1000(a)yahoo.com> Date: Wednesday, May 4, 2011, 11:59 AM On Tue, May 03, 2011 at 03:02:58AM -0700, eisencah eisenach wrote: > So is as if the message for the sim job doesn't get pulled from the > queue, "got new job: SIM_JOB_RUN_GSM_ALGO " never appears. Must say > the computer I use osmocom on is not exactly a rocket :) (is a 500Mhz > celeron with ubuntu 6.10) , and It gets slowed down when running the > hole thing. Can that be the cause? Mihai. The L1CTL protocol goes through a unix domain socket, and you can trace it in either osmocon or in the mobile program itself. It should be relatively easy to detect if the RUN_GSM_ALGO is transmitted by mobile, or if it is lost, where it is lost. -- - 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)

12 years, 11 months

3
3
0 0

[PATCH] src: use namespace prefix osmo_* for crc16 functions

by Pablo Neira Ayuso

Summary of changes: s/crc16_table/osmo_crc16_table/g s/crc16/osmo_crc16/g s/crc16_byte/osmo_crc16_byte/g --- src/host/osmocon/osmoload.c | 8 ++++---- src/target/firmware/apps/loader/main.c | 6 +++--- src/target/firmware/apps/loader_mtk/main.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 5848e56..8a0b21c 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -575,7 +575,7 @@ loader_start_memput(uint8_t length, uint32_t address, void *data) { struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); msgb_put_u8(msg, LOADER_MEM_WRITE); msgb_put_u8(msg, length); - msgb_put_u16(msg, crc16(0, data, length)); + msgb_put_u16(msg, osmo_crc16(0, data, length)); msgb_put_u32(msg, address); memcpy(msgb_put(msg, length), data, length); loader_send_request(msg); @@ -603,7 +603,7 @@ loader_do_memdump(uint16_t crc, void *data, size_t length) { int rc; if(data && length) { - osmoload.memcrc = crc16(0, data, length); + osmoload.memcrc = osmo_crc16(0, data, length); if(osmoload.memcrc != crc) { osmoload.memoff -= osmoload.memreq; printf("\nbad crc %4.4x (not %4.4x) at offset 0x%8.8x", crc, osmoload.memcrc, osmoload.memoff); @@ -665,7 +665,7 @@ loader_do_memload() { uint8_t reqbytes = (rembytes < MEM_MSG_MAX) ? rembytes : MEM_MSG_MAX; - osmoload.memcrc = crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); + osmoload.memcrc = osmo_crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); osmoload.memreq = reqbytes; struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); @@ -705,7 +705,7 @@ loader_do_fprogram() { uint8_t reqbytes = (rembytes < MEM_MSG_MAX) ? rembytes : MEM_MSG_MAX; - osmoload.memcrc = crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); + osmoload.memcrc = osmo_crc16(0, (uint8_t *) osmoload.binbuf + osmoload.memoff, reqbytes); osmoload.memreq = reqbytes; struct msgb *msg = msgb_alloc(MSGB_MAX, "loader"); diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c index a948934..2ff6f9c 100644 --- a/src/target/firmware/apps/loader/main.c +++ b/src/target/firmware/apps/loader/main.c @@ -253,7 +253,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) nbytes = msgb_get_u8(msg); address = msgb_get_u32(msg); - crc = crc16(0, (void *)address, nbytes); + crc = osmo_crc16(0, (void *)address, nbytes); msgb_put_u8(reply, LOADER_MEM_READ); msgb_put_u8(reply, nbytes); @@ -274,7 +274,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { memcpy((void *)address, data, nbytes); @@ -392,7 +392,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { res = flash_program(&the_flash, address, data, nbytes); diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c index 899d765..9bfaa7e 100644 --- a/src/target/firmware/apps/loader_mtk/main.c +++ b/src/target/firmware/apps/loader_mtk/main.c @@ -194,7 +194,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) nbytes = msgb_get_u8(msg); address = msgb_get_u32(msg); - crc = crc16(0, (void *)address, nbytes); + crc = osmo_crc16(0, (void *)address, nbytes); msgb_put_u8(reply, LOADER_MEM_READ); msgb_put_u8(reply, nbytes); @@ -215,7 +215,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { memcpy((void *)address, data, nbytes); @@ -333,7 +333,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) data = msgb_get(msg, nbytes); - mycrc = crc16(0, data, nbytes); + mycrc = osmo_crc16(0, data, nbytes); if (mycrc == crc) { res = flash_program(&the_flash, address, data, nbytes); -- 1.7.2.5 --------------090200050301070809080105--

12 years, 11 months

1
0
0 0

[PATCH] src: use namespace prefix osmo_wqueue*

by Pablo Neira Ayuso

Summary of changes: s/struct write_queue/struct osmo_wqueue/g s/write_queue_init/osmo_wqueue_init/g s/write_queue_clear/osmo_wqueue_clear/g s/write_queue_enqueue/osmo_wqueue_enqueue/g s/write_queue_bfd_cb/osmo_wqueue_bfd_cb/g --- .../include/osmocom/bb/common/osmocom_data.h | 2 +- src/host/layer23/src/common/l1l2_interface.c | 4 ++-- src/host/layer23/src/common/sap_interface.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/common/osmocom_data.h b/src/host/layer23/include/osmocom/bb/common/osmocom_data.h index 9d8a030..9ca4114 100644 --- a/src/host/layer23/include/osmocom/bb/common/osmocom_data.h +++ b/src/host/layer23/include/osmocom/bb/common/osmocom_data.h @@ -50,7 +50,7 @@ struct rx_meas_stat { struct osmocom_ms { struct llist_head entity; char name[32]; - struct write_queue l2_wq, sap_wq; + struct osmo_wqueue l2_wq, sap_wq; uint16_t test_arfcn; uint8_t deleting, shutdown, started; diff --git a/src/host/layer23/src/common/l1l2_interface.c b/src/host/layer23/src/common/l1l2_interface.c index 3272359..2abb660 100644 --- a/src/host/layer23/src/common/l1l2_interface.c +++ b/src/host/layer23/src/common/l1l2_interface.c @@ -126,7 +126,7 @@ int layer2_open(struct osmocom_ms *ms, const char *socket_path) return rc; } - write_queue_init(&ms->l2_wq, 100); + osmo_wqueue_init(&ms->l2_wq, 100); ms->l2_wq.bfd.data = ms; ms->l2_wq.bfd.when = BSC_FD_READ; ms->l2_wq.read_cb = layer2_read; @@ -167,7 +167,7 @@ int osmo_send_l1(struct osmocom_ms *ms, struct msgb *msg) len = (uint16_t *) msgb_push(msg, sizeof(*len)); *len = htons(msg->len - sizeof(*len)); - if (write_queue_enqueue(&ms->l2_wq, msg) != 0) { + if (osmo_wqueue_enqueue(&ms->l2_wq, msg) != 0) { LOGP(DL1C, LOGL_ERROR, "Failed to enqueue msg.\n"); msgb_free(msg); return -1; diff --git a/src/host/layer23/src/common/sap_interface.c b/src/host/layer23/src/common/sap_interface.c index 4d465f0..5d92840 100644 --- a/src/host/layer23/src/common/sap_interface.c +++ b/src/host/layer23/src/common/sap_interface.c @@ -127,7 +127,7 @@ int sap_open(struct osmocom_ms *ms, const char *socket_path) return rc; } - write_queue_init(&ms->sap_wq, 100); + osmo_wqueue_init(&ms->sap_wq, 100); ms->sap_wq.bfd.data = ms; ms->sap_wq.bfd.when = BSC_FD_READ; ms->sap_wq.read_cb = sap_read; @@ -170,7 +170,7 @@ int osmosap_send(struct osmocom_ms *ms, struct msgb *msg) len = (uint16_t *) msgb_push(msg, sizeof(*len)); *len = htons(msg->len - sizeof(*len)); - if (write_queue_enqueue(&ms->sap_wq, msg) != 0) { + if (osmo_wqueue_enqueue(&ms->sap_wq, msg) != 0) { LOGP(DSAP, LOGL_ERROR, "Failed to enqueue msg.\n"); msgb_free(msg); return -1; -- 1.7.2.5 --------------080404070907070702060601--

12 years, 11 months

1
0
0 0

problem with Pirelli DP-L10 and upload the firmware

by Marco Schwan

Hi, I have a problem with the DP-L10. The upload the firmware in the phone is not succesfull. I have made following steps: - change the UART number in the two header files - compile the source - connected the phone with laptop - run the command "./host/osmocon/osmocon -p /dev/ttyUSB0 -m romload ./target/firmware/board/pirelli_dpl10/layer1.highram.bin" - put the accu in the mobile phone the upload the firmware start and the last message from osmocon is: handle_write_block(): 64 bytes (1024/1024) handle_write_block(): Block 51 finished Finished, sent 51 blocks in total Received block ack from phone Sending checksum: 0x55 I have follow message expected: Received block ack from phone Sending checksum: 0xaa Checksum on phone side matches, let's branch to your code Branching to 0x00820000 Received branch ack, your code is running now! I see not the error. Can you please a idea give. Marco

12 years, 11 months

1
0
0 0

arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf section .rodata)

by Jens Hoffmann

Hi, when compiling the firmware I get the following error: make[2]: Entering directory `/home/hoffmaje/proseminar/install/osmocom-bb/src/target/firmware' LD board/mt62xx/loader_mtk.mtkram.elf arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf section .rodata) arm-elf-ld: region LRAM is full (board/mt62xx/loader_mtk.mtkram.elf section .rodata) I used a tool-chain mentioned in a post from 18. January 2011: ftp://ftp.pengutronix.de/pub/oselas/oselas.toolchain-1.99.3.6-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18_i386.tar.bz2 I read the PreliminaryRequirements <http://www.osmocom.org/trac/wiki/PreliminaryRequirements>, the archives and I did a google search; I would be even glad just to understand what this error is about. Thanks for your help, Jens

12 years, 11 months

2
1
0 0

Re: Anybody using a BTS for debugging?

by Dieter Spaar

Hello Gianni, On Fri, 13 May 2011 11:41:35 +0100, "Gianni Tedesco" <gianni(a)scaramanga.co.uk> wrote: > > Any idea of model numbers? The ones I've looked at have been > $1,000 > and only do calls, not SMS for example. The Racal 6103E can do SMS and sometimes is available for less than $US 500 (a few cheap ones were sold in the UK a while ago). Be aware of the 6103G or the "Anite" variant, they cannot be used "standalone". Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

12 years, 11 months

1
0
0 0

L1 corruption?

by suraev＠stud.ntnu.no

Hi. I'm trying to follow the logic described in app_ccch_scan to send RACH bursts to my openbts. First 2-2 goes fine but after that I got constant errors - see below. It looks like after I've sent couple of packets something got corrupted in L1. How can I debug this and understand what causing all the errors? LOG: <0001> app_rach_send.c:227 registering signal handler... <0001> app_rach_send.c:229 resetting L1... <0001> app_rach_send.c:231 L3 init... <0001> app_rach_send.c:190 requesting FBSB from L1... <0001> app_rach_send.c:200 unhandled callback 1 <S_L1CTL_FBSB_RESP> fired... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:73 SI2 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:75 SI3 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:75 SI3 on the wrong TC: 0 <0001> app_rach_send.c:200 unhandled callback 5 <S_L1CTL_CCCH_MODE_CONF> fired... <0001> app_rach_send.c:200 unhandled callback 5 <S_L1CTL_CCCH_MODE_CONF> fired... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:86 SI4 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:86 SI4 on the wrong TC: 0 ... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:86 SI4 on the wrong TC: 0 <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:70 SI1 received. <0001> app_rach_send.c:127 sending RACH #0 on ARFCN 21... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:127 sending RACH #1 on ARFCN 21... <0001> app_rach_send.c:111 obtained BCCH, dumping... <0001> app_rach_send.c:127 sending RACH #2 on ARFCN 21... <0000> rslms.c:136 unknown RSLms msg_discr 0x0c <0000> rslms.c:136 unknown RSLms msg_discr 0x0c <0000> rslms.c:136 unknown RSLms msg_discr 0x0c <000b> l1ctl.c:210 Dropping frame with 80 bit errors <000b> l1ctl.c:210 Dropping frame with 80 bit errors <000b> l1ctl.c:210 Dropping frame with 80 bit errors <000b> l1ctl.c:210 Dropping frame with 59 bit errors <000b> l1ctl.c:210 Dropping frame with 59 bit errors <000b> l1ctl.c:210 Dropping frame with 59 bit errors <000b> l1ctl.c:210 Dropping frame with 58 bit errors <000b> l1ctl.c:210 Dropping frame with 58 bit errors <000b> l1ctl.c:210 Dropping frame with 58 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 62 bit errors <000b> l1ctl.c:210 Dropping frame with 60 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors <000b> l1ctl.c:210 Dropping frame with 61 bit errors

12 years, 11 months

1
0
0 0

Osmocom project vs. sysmocom GmbH

by Harald Welte

Hi all! As some of you already know, Holger and I have recently started a new company called "sysmocom - systems for mobile communications GmbH". The process of establishing the new company has now formally concluded. Before some rumours start to spread, we would like to clarify some points and make sure there is mutual understanding between the Osmocom community and the sysmocom company. sysmocom is intended to provide commercial offerings related to the Osmocom projects. This is not entirely new. Especially on the network side, people like Holger and I have been doing quite a lot of paid development to bring those projects forward. We would not have many of the features we have today, if it wasn't for customers who actually pay us for development of OpenBSC, OsmoBSC, OsmoSGSN and the various side projects more targetted at a real network operator like cellmgr-ng, bsc-nat, gb_proxy - just to name a few. However, this has always only been freelancing development of Software. With sysmocom, we want to go one step further and work on hardware products related to the various Free Software projects. Right now I don't want to talk too much about unfinished products, but we are working towards an inexpensive BTS product, we are funding the prototypes for Osmocom SIMtrace, and we will likely also see stuff like OpenBSC appliances. Given our past involvement and exposure into other projects that share a split Free Software / business set-up, we think we understand very well where potential issues of conflict between the two sides may be. Let me make some more clarification what this is not about: * sysmocom is not about creating proprietary derivates of Osmocom software. We work on Free Software which is publicly available under OSI approved and FSF endorsed licenses. We may offer proprietary hardware and sometimes software - but those are independent projects from existing Osmocom software. * we specifically will not have a public and a non-public version of the same program with differences in features. * sysmocom is not a VC-funded startup. It's a very small company run out of personal funds with no intention to take external funding or grow rapidly. Nobody but Holger and I determine where it goes and what it does. * sysmocom does not hold any copyright on the Free Software projects. The copyrights stay distributed with the major authors such as Holger, Onwaves, Sylvain, Dieter, Andreas and myself. None of the others have any affiliation with sysmocom. I have (personally, unrelated to sysmocom) asked some of the smaller contributors for a copyright transfer to make sure we could do the AGPLv3 transition, or future re-licensing decisions without having to ask dozens and dozens of people. sysmocom does not seek to control the Free Software projects. * we will maintain a strict separation between the community side of things and the business side. Unlike some other popular projects, we will not end up in a situation where the osmocom.org websites will be full of advertisements and hidden links that lure you on the company website. * we will keep a strict separation of naming. Osmocom is for the FOSS projects, sysmocom for the business. The company will use the term "Osmocom" only in descriptive context, not as a product name, brand or for advertisement. If you do have any concerns, please feel free to share them. However, I'd like to avoid cross-posting them throguh different mailing lists. Please follow-up-to openbsc(a)lists.osmocom.org Regards, Harald -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

12 years, 11 months

1
0
0 0

Anybody using a BTS for debugging?

by Gianni Tedesco

Hi, It seems like a BTS is required in order to really debug anything one develops with osmocombb. I'm still looking at implementing SMS. However the only off-the-shelf option seems to be USRP which is about $1,000 right? Is this going to become a very expensive hobby or are there cheaper options here? Is there a way to bypass L1CTL on the phone and feed the data in to, say, openBTS? If not, it would seem useful to hack such a thing up... Gianni

12 years, 11 months

2
2
0 0

Planning for Radio Village at 2011 CCC Camp

by Harald Welte

Hi all! [This message is cross-posted to many lists, please be careful when replying to it! Think twice if your respones really matters to all those projects...] In order to do some better planning for our Camp activities this summer, I would like to request all people who intend to participate in the radio village to add themselves to the wiki: https://events.ccc.de/camp/2011/wiki/index.php/RadioVillage The list of citizens is auto-generated if you use Person template like I have done in my user page at https://events.ccc.de/camp/2011/wiki/index.php/User:LaForge The large main tent is not really intended as a place to sleep, but more like a place where we set up our gear and work on the various projects, similar to what happened at HAR. Thanks in advance! -- - 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)

12 years, 11 months

1
0
0 0

reading bts parameters

by Tom Mayer

hello, I am not quite sure if this is the right place to ask, so sorry in advance for spamming ir i'm in the wrong place. I have build and run osmocom on my C123. I am using it for a university project and we try to read parameters from surrounding BTS. The final goal will be to separate real bts from imsi catchers. So my question is, can I use the osmocom library to gather some data from surrounding BTS? Are there some example programs? Would anyone know a good way to read the SIM data from the connected C123? Thanks in advance! Cheers Tom ---------------------------------------------------------------------------- Short example scenario: A very obvious catcher fault would be not having set the regional code or having set a wrong regional code. So it would theoretically be possible to read the regional code from the own SIM card and the regional code of the transmitting BTS and compare those.

12 years, 11 months

5
5
0 0

[PATCH]: Implement SMS decoding

by Gianni Tedesco

Hi, Attached patch implements SMS decoding. Right now it just logs it all to DMM (when I tried DSMS I didn't get any output?!). What remains is to plumb this through to mobile so that the messages can be displayed over a vty and also to send a response other than GSM48_REJECT_MSG_TYPE_NOT_IMPLEMENTED - but I'm not sure what needs to happen here. Is anyone else working in this area? Gianni commit a244cccb6f7600cb867e4949926cc7d877b58f31 Author: Gianni Tedesco <gianni(a)scaramanga.co.uk> Date: Thu May 12 03:24:19 2011 +0100 Implement SMS decoding diff --git a/src/host/layer23/src/mobile/Makefile.am b/src/host/layer23/src/mobile/Makefile.am index fb0423e..60e8d23 100644 --- a/src/host/layer23/src/mobile/Makefile.am +++ b/src/host/layer23/src/mobile/Makefile.am @@ -4,7 +4,7 @@ LDADD = ../common/liblayer23.a $(LIBOSMOCORE_LIBS) $(LIBOSMOVTY_LIBS) $(LIBOSMOG noinst_LIBRARIES = libmobile.a libmobile_a_SOURCES = gsm322.c gsm48_cc.c gsm48_mm.c gsm48_rr.c \ - mnccms.c settings.c subscriber.c support.c \ + gsm48_sms.c mnccms.c settings.c subscriber.c support.c \ transaction.c vty_interface.c bin_PROGRAMS = mobile diff --git a/src/host/layer23/src/mobile/gsm48_mm.c b/src/host/layer23/src/mobile/gsm48_mm.c index bf5bbc2..84069f3 100644 --- a/src/host/layer23/src/mobile/gsm48_mm.c +++ b/src/host/layer23/src/mobile/gsm48_mm.c @@ -36,6 +36,7 @@ #include <osmocom/bb/common/networks.h> #include <osmocom/bb/common/l1ctl.h> #include <osmocom/bb/mobile/gsm48_cc.h> +#include <osmocom/bb/mobile/gsm48_sms.h> #include <osmocom/bb/mobile/app_mobile.h> extern void *l23_ctx; @@ -737,10 +738,10 @@ int gsm48_mmxx_dequeue(struct osmocom_ms *ms) case GSM48_MMSS_CLASS: gsm48_rcv_ss(ms, msg); break; +#endif case GSM48_MMSMS_CLASS: gsm48_rcv_sms(ms, msg); break; -#endif } msgb_free(msg); work = 1; /* work done */ @@ -3847,9 +3848,10 @@ static int gsm48_mm_data_ind(struct osmocom_ms *ms, struct msgb *msg) case GSM48_PDISC_NC_SS: return gsm48_rcv_ss(ms, msg); - case GSM48_PDISC_SMS: - return gsm48_rcv_sms(ms, msg); #endif + case GSM48_PDISC_SMS: + LOGP(DMM, LOGL_NOTICE, "SMS PDISC = 0x%.2x\n", GSM48_PDISC_SMS); + gsm48_rcv_sms(ms, msg); default: LOGP(DMM, LOGL_NOTICE, "Protocol type 0x%02x unsupported.\n", diff --git a/src/host/layer23/src/mobile/gsm48_sms.c b/src/host/layer23/src/mobile/gsm48_sms.c new file mode 100644 index 0000000..63b1965 --- /dev/null +++ b/src/host/layer23/src/mobile/gsm48_sms.c @@ -0,0 +1,306 @@ +/* + * (C) 2010 by Andreas Eversberg <jolly(a)eversberg.eu> + * (C) 2011 by Gianni Tedesco <gianni(a)scaramanga.co.uk> + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include <stdint.h> +#include <errno.h> +#include <stdio.h> +#include <string.h> +#include <stdlib.h> +#include <arpa/inet.h> + +#include <osmocom/core/msgb.h> +#include <osmocom/core/utils.h> +#include <osmocom/gsm/gsm48.h> +#include <osmocom/core/talloc.h> + +#include <osmocom/bb/common/logging.h> +#include <osmocom/bb/common/osmocom_data.h> +#include <osmocom/bb/common/networks.h> +#include <osmocom/bb/common/l1ctl.h> +#include <osmocom/bb/mobile/gsm48_sms.h> +#include <osmocom/bb/mobile/app_mobile.h> + +#define CP_DATA 1 + +#define RP_DATA 1 +#define RP_ACK 3 +#define RP_ERROR 5 + +#define TP_MTI_MASK 3 +#define SMS_DELIVER 0 +#define SMS_SUBMIT_REPORT 1 +#define SMS_STATUS_REPORT 2 + +#define TP_RP 0x80 +#define TP_UDHI 0x40 +#define TP_SRI 0x20 +#define TP_MMS 0x04 + +static void decode_7bit(const uint8_t *inp, size_t octets, size_t len) +{ + uint8_t out[len + 1]; + unsigned int i; + + for(i = 0; i <= len; i++) { + int ipos = i - (i >> 3); + int offset = (i & 0x7); + + out[i] = (inp[ipos] & (0x7F >> offset)) << offset; + if( 0 == offset ) + continue; + + out[i] |= (inp[ipos - 1] & + (0x7F << (8 - offset)) & 0xFF) >> (8 - offset); + } + + out[len] = '\0'; + LOGP(DMM, LOGL_NOTICE, "SMS: \"%s\"\n", out); +} + +static uint8_t hi_nibble(uint8_t byte) +{ + return byte >> 4; +} + +static uint8_t lo_nibble(uint8_t byte) +{ + return byte & 0xf; +} + +static int parse_address(struct msgb *msg, int rp, const char *name) +{ + uint8_t len, type; + + if ( !msg->len ) + return -EPROTO; + + len = msgb_get_u8(msg); + if ( !len ) + return 0; + + type = msgb_get_u8(msg); + + if ( rp ) { + /* for RP address, len is in bytes including type field */ + len = len - 1; + }else{ + /* TP address is in BCD digits, not including type field */ + len = len / 2; + } + + if ( msg->len < len ) + return -EPROTO; + + LOGP(DMM, LOGL_NOTICE, "%s: type=0x%.2x %s\n", + name, type, hexdump(msg->data, len)); + + msgb_pull(msg, len); + return 0; +} + +static int parse_timestamp(struct msgb *msg, const char *name) +{ + if ( msg->len < 7 ) + return -EPROTO; + LOGP(DMM, LOGL_NOTICE, + "%s: 20%1x%1x-%1x%1x-%1x%1x %1x%1x:%1x%1x:%1x%1x\n", + name, + lo_nibble(msg->data[0]), + hi_nibble(msg->data[0]), + lo_nibble(msg->data[1]), + hi_nibble(msg->data[1]), + lo_nibble(msg->data[2]), + hi_nibble(msg->data[2]), + lo_nibble(msg->data[3]), + hi_nibble(msg->data[3]), + lo_nibble(msg->data[4]), + hi_nibble(msg->data[4]), + lo_nibble(msg->data[5]), + hi_nibble(msg->data[5])); + msgb_pull(msg, 7); + return 0; +} +static int sms_deliver(struct osmocom_ms *ms, struct msgb *msg, uint8_t b) +{ + uint8_t tp_pid, tp_dcs, tp_udlen; + int rc; + + if ( !(b & TP_MMS) ) + LOGP(DMM, LOGL_NOTICE, "SMS-DELIVER: More messages to send.\n"); + + rc = parse_address(msg, 0, "TP-Originating"); + if ( rc ) + return -EPROTO; + + if ( msg->len < 2 ) + return -EPROTO; + + tp_pid = msgb_get_u8(msg); + tp_dcs = msgb_get_u8(msg); + LOGP(DMM, LOGL_NOTICE, "TP-PID: 0x%.2x\n", tp_pid); + LOGP(DMM, LOGL_NOTICE, "TP-DCS: 0x%.2x\n", tp_dcs); + + rc = parse_timestamp(msg, "TP-Service-Center-Time-Stamp"); + if ( rc ) + return -EPROTO; + + if ( !msg->len ) + return -EPROTO; + tp_udlen = msgb_get_u8(msg); + + /* check for unknown data coding scheme */ + if (tp_dcs) + return 0; + + decode_7bit(msg->data, msg->len, tp_udlen); + return 0; +} + +static int sms_tpdu_decode(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t tp_mti; + + if ( !msg->len ) + return 0; + tp_mti = msgb_get_u8(msg); + + switch(tp_mti & TP_MTI_MASK) { + case SMS_DELIVER: + return sms_deliver(ms, msg, tp_mti); + case SMS_SUBMIT_REPORT: + LOGP(DMM, LOGL_NOTICE, "Received SMS-SUBMIT-REPORT: %s\n", + hexdump(msg->data, msg->len)); + break; + case SMS_STATUS_REPORT: + LOGP(DMM, LOGL_NOTICE, "Received SMS-STATUS-REPORT: %s\n", + hexdump(msg->data, msg->len)); + break; + default: + LOGP(DMM, LOGL_NOTICE, "Reserved MTI: 0x%.2x\n", + tp_mti); + return -EPROTO; + } + + return 0; +} + +static int rp_data_decode(struct osmocom_ms *ms, struct msgb *msg, uint8_t ref) +{ + static const char * const str[2] = {"RP-Origination", "RP-Destination"}; + unsigned int i; + uint8_t tpdu_len; + + LOGP(DMM, LOGL_NOTICE, "Received RP-DATA: ref %d\n", ref); + + for(i = 0; i < 2; i++) { + int rc; + + rc = parse_address(msg, 1, str[i]); + if ( rc ) + return -EPROTO; + } + + if ( !msg->len ) + return -EPROTO; + tpdu_len = msgb_get_u8(msg); + if ( tpdu_len < msg->len ) + return -EPROTO; + if ( tpdu_len < msg->len ) { + LOGP(DMM, LOGL_NOTICE, "RP-DATA: %u trailing bytes: %s\n", + msg->len - tpdu_len, + hexdump(msg->data + tpdu_len, msg->len - tpdu_len)); + msg->len = tpdu_len; + } + + /* TODO: pass in reference, and src/dst addresses */ + return sms_tpdu_decode(ms, msg); +} + +static int rp_decode(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t rp_mt, rp_ref; + + if ( msg->len < 2 ) + return -EPROTO; + + rp_mt = msgb_get_u8(msg); + rp_ref = msgb_get_u8(msg); + + switch(rp_mt) { + case RP_DATA: + return rp_data_decode(ms, msg, rp_ref); + case RP_ACK: + LOGP(DMM, LOGL_NOTICE, "Received RP-ACK: %s\n", + hexdump(msg->data, msg->len)); + return -ENOTSUP; + case RP_ERROR: + LOGP(DMM, LOGL_NOTICE, "Received RP-ERROR: %s\n", + hexdump(msg->data, msg->len)); + return -ENOTSUP; + default: + LOGP(DMM, LOGL_NOTICE, "Bad RP Message-type: 0x%.2x\n", rp_mt); + return -ENOTSUP; + } + + return 0; +} + +static int cp_data(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t len; + + if ( !msg->len ) + return -EPROTO; + len = msgb_get_u8(msg); + if ( len != msg->len ) { + LOGP(DMM, LOGL_NOTICE, "CP-DATA: size mismatch " + "%u != %u bytes\n", len, msg->len); + }else{ + LOGP(DMM, LOGL_NOTICE, "CP-DATA: %u bytes\n", len); + } + + return rp_decode(ms, msg); +} + +int gsm48_rcv_sms(struct osmocom_ms *ms, struct msgb *msg) +{ + uint8_t cp_type; + + LOGP(DMM, LOGL_NOTICE, "Received SMS: %s\n", + hexdump(msg->data, msg->len)); + + if ( msg->len < 2) + return -EPROTO; + + msgb_pull(msg, 1); /* protocol discriminator */ + cp_type = msgb_get_u8(msg); + + switch(cp_type) { + case CP_DATA: + return cp_data(ms, msg); + default: + LOGP(DMM, LOGL_NOTICE, "Unknown SMS type: 0x%.2x\n", cp_type); + return 0; + } + + return 0; +}

12 years, 11 months

2
3
0 0

GSM specs doubt

by Gerard

Hi list, while studing burst_ind (I know that burst_ind must be used in a own controlled network) i see that one SDCCH for a specific operator has been shared by more than one MS (different TMSIs), some MS use for SMS other use for calls. Is that an interpratation error (due the fact of using burst_ind in real networks) or that could be possible? i didn't find explanations on sepcs. TIA

12 years, 11 months

2
1
0 0

[ANN] libosmocore stable API/ABI

by Harald Welte

Hi all! I think now that the namespace issues in libosmocore have been resolved, we seriously have to think of maintaining a stable API and ABI. This allows us to have truly independent library and application releases, and the dynamic linker library versioning support should ensure compatibility. So please think twice about any modifying libosmocore. It is safe to add new functions, but we cannot change the prototypes (number of arguments) for existing functions. As soon as new functions are introduced, we should increment the library interface number. For more information, see http://www.gnu.org/software/libtool/manual/libtool.html#Versioning especially the rules in Chapter 7.3: # If the library source code has changed at all since the last update, then increment revision (‘c:r:a’ becomes ‘c:r+1:a’). # If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0. # If any interfaces have been added since the last public release, then increment age. # If any interfaces have been removed or changed since the last public release, then set age to 0. 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)

12 years, 12 months

2
2
0 0

[ADM] osmocom.org via IPv6

by Harald Welte

Hi all, JFYI: For a couple of days, *.osmocom.org is reachable via IPv6. I've had native IPv6 at my co-located servers for more than 10 years, but somehow never configured it for the virtual machines like *.osmocom.org - this is now fixed. If you encounter any difficulties, please let me know. 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)

12 years, 12 months

1
0
0 0

SPMA100B ringtone chip

by l--putt

Hi list! To get closer to a useful phone, I started a project to create a driver for the SPMA100B ringtone chip of the C155. I can replay the commands to play the startup and shutdown sounds and have some idea about the registers. A problem is the MIDI(?) data send to the chip: It's possible to extract the MIDI files from a flash image but the tracks are interleaved by the firmware. Some random single track files don't work either. Anybody an idea? I've found other datasheets (in particular for the W56964 of the DPL10) and they helped a lot in understanding the SPMA100B due to the similarities. Hence, I suggest a common framework for all those chips. However, even salsa (embedded version of ALSA) seems excessive since we have just a single device. I considered a really simple design with just single write-call that blocks until played. Some ioctl solve volume etc. But this doesn't communicate the state (playing, fifo empty, finished, error) well. Any ideas? Does anybody know cc-licensed MIDI ringtones? http://www.ringtonepirates.de/ seems to have only MP3 sounds. Given its name, you also need balls to download there (at least in Germany: "offensichtlich illegale Quelle" :-P ) Regards, Stefan A hack of hello_world example to play ringtones on SPMA100B chip --- src/target/firmware/apps/hello_world/main.c | 330 ++++++++++++++++++++++++++- 1 files changed, 328 insertions(+), 2 deletions(-) diff --git a/src/target/firmware/apps/hello_world/main.c b/src/target/firmware/apps/hello_world/main.c index 5e3ed85..f247795 100644 --- a/src/target/firmware/apps/hello_world/main.c +++ b/src/target/firmware/apps/hello_world/main.c @@ -68,6 +68,310 @@ static void l1a_l23_rx_cb(uint8_t dlci, struct msgb *msg) puts("\n"); } +/* Define GPIO interface */ +#define ARMIO_LATCH_OUT 0xfffe4802 +#define IO_CNTL_REG 0xfffe4804 +#define ASIC_CONF_REG 0xfffef008 + +#define IO_CONF_REG 0xfffef00a +#define CALYPSO_CONF_OFF 4 + +#define CALYPSO_IO4 (1 << 4) +#define CALYPSO_IO7 (1 << 7) +#define CALYPSO_IO8 (1 << 8) +#define CALYPSO_IO12 (1 << 12) + +#define GPIO_ENABLE(pins) { \ + uint16_t reg = readw(IO_CONF_REG); \ + reg |= (pins) >> CALYPSO_CONF_OFF; \ + writew(reg, IO_CONF_REG); } + +#define GPIO_OUTPUT(pins) { \ + uint16_t reg = readw(IO_CNTL_REG); \ + reg &= ~(pins); \ + writew(reg, IO_CNTL_REG); } + +#define GPIO_SET(pins) { \ + uint16_t reg = readw(ARMIO_LATCH_OUT); \ + reg |= (pins); \ + writew(reg, ARMIO_LATCH_OUT); } + +#define GPIO_UNSET(pins) { \ + uint16_t reg = readw(ARMIO_LATCH_OUT); \ + reg &= ~(pins); \ + writew(reg, ARMIO_LATCH_OUT); } + +/* Define W569x constants */ +#define MUSIC_REG 0x01800000 + +#define MUSIC_IRQ CALYPSO_IO4 +#define MUSIC_A0 CALYPSO_IO8 +#define MUSIC_ON CALYPSO_IO12 + +static uint8_t spma100_regread(uint8_t bank) +{ + GPIO_UNSET(MUSIC_A0); + delay_ms(1); + writeb(bank, MUSIC_REG); + GPIO_SET(MUSIC_A0); + + delay_ms(1); + + return readb(MUSIC_REG); +} + +static void spma100_dumpregs(void) +{ + int i; + for(i=0; i<256; i++) { + printf("%02x,", spma100_regread(i)); + } + printf("\n\n"); +} + +static void spma100_deltaregs(void) +{ + int i; + static uint8_t state[256]; + for(i=0; i<256; i++) { + char tmp = spma100_regread(i); + if(tmp ^ state[i]) + printf("%02x: %02x, changed by %02x\n", i, tmp, tmp ^ state[i]); + state[i] = tmp; + } + printf("\n\n"); +} + +static void spma100_regwrite(uint8_t bank, uint8_t data) +{ + GPIO_UNSET(MUSIC_A0); + delay_ms(1); + writeb(bank, MUSIC_REG); + GPIO_SET(MUSIC_A0); + + delay_ms(1); + + writeb(data, MUSIC_REG); + + delay_ms(1); + + //spma100_dumpregs(); + //spma100_deltaregs(); +} + +void music_onoff(int on) +{ + uint16_t reg = readw(0xfffe4802); + + if(on) { + reg |= 0x1000; + } else { + reg &= 0xefff; + } + + writew(reg, 0xfffe4802); +} + +/* HW init */ +void music_init(void) +{ + GPIO_ENABLE(MUSIC_ON); + GPIO_OUTPUT(MUSIC_ON); + + GPIO_ENABLE(MUSIC_IRQ); + + GPIO_ENABLE(MUSIC_A0); + GPIO_OUTPUT(MUSIC_A0); + + writeb(2, 0xfffe4818); + printf("GPIO event mode %x\n", readw(0xfffe4814)); + + music_onoff(1); +} + +int play_midi = -1; +static char midi1[] = {0x72, 0xab, 0x62, 0x00, 0xb0, 0xb3, 0x7f, 0xc0, 0xd2, 0x0b, 0xa7, 0x07, 0xef, 0x3c, 0xce, 0x2f, 0x5e, 0x40, 0x25, 0x3c, 0xb1, 0x07, 0x18, 0x60, 0x30, 0x7b, 0x57, 0x00, 0x91, 0x7f, 0x3f, 0x92, 0x63, 0xf3, 0x0b, 0x18, 0x47, 0xf3, 0xc1, 0x10, 0x54, 0x00, 0xb1, 0x4b, 0x7c, 0x81, 0xe1, 0x00, 0x60, 0x13, 0x50, 0xd6, 0x8a, 0x68, 0x43, 0x90, 0x43, 0x26, 0x74, 0x81, 0xc1, 0x4c, 0x18, 0x00, 0xd9, 0x2a, 0xe0, 0x63, 0x5b, 0xb0, 0x0b, 0x5b, 0x6a, 0x11, 0x37, 0x20, 0x13, 0x00, 0xf6, 0x60, 0x99, 0x70, 0xd6, 0x47, 0x63, 0x5b, 0x7e, 0x31, 0x7b, 0x51, 0x00, 0x90, 0x0c, 0x0a, 0x92, 0x70, 0xfd, 0x0b, 0x19, 0x47, 0xe1, 0xc1, 0x14, 0x54, 0x13, 0xb0, 0x43, 0x68, 0x81, 0xe0, 0x0b, 0x66, 0x13, 0x4c, 0xc2, 0x8a, 0x69, 0x4c, 0x91, 0x43, 0x29, 0x67, 0x92, 0xc0, 0x44, 0x19, 0x00, 0xd8, 0x32, 0xe6, 0x63, 0x48, 0xb1, 0x0b, 0x55, 0x77, 0x10, 0x37, 0x2b, 0x13, 0x13, 0xff, 0x73, 0x9b, 0x70, 0xdf, 0x48, 0x69, 0x40, 0x7a, 0x30, 0x7b, 0x49, 0x00, 0x91, 0x04, 0x12, 0x92, 0x63, 0xfc, 0x0b, 0x1a, 0x4f, 0xed, 0xc2, 0x1a, 0x5c, 0x00, 0xb1, 0x58, 0x64, 0x81, 0xe1, 0x10, 0x6a, 0x13, 0x47, 0xcf, 0x8e, 0x4a, 0x54, 0x90, 0x47, 0x94, 0x3c, 0x00, 0xfc, 0x5f, 0x68, 0x6b, 0x91, 0x47, 0x6b, 0xa7, 0x13, 0x71, 0x5e, 0x1b, 0xb1, 0x97, 0x10, 0x6d, 0x82, 0x3c, 0xef, 0x8a, 0x6b, 0x3c, 0x91, 0x48, 0x2d, 0x73, 0x92, 0xc0, 0x4b, 0x1b, 0x00, 0xd3, 0x2d, 0xef, 0x63, 0x43, 0xb1, 0x0b, 0x5c, 0x63, 0x10, 0x3c, 0x29, 0x13, 0x13, 0xf0, 0x6f, 0x9d, 0x70, 0xd0, 0x47, 0x70, 0x50, 0x66, 0x30, 0x7b, 0x5f, 0x00, 0x91, 0x00, 0x17, 0x92, 0x63, 0xf7, 0x0b, 0x1c, 0x48, 0xf9, 0xc9, 0x01, 0x5b, 0x00, 0xb1, 0x48, 0x76, 0x81, 0xe1, 0x0b, 0x71, 0x13, 0x54, 0xdb, 0x8a, 0x6c, 0x47, 0x90, 0x4c, 0x3b, 0x7e, 0x81, 0xc1, 0x43, 0x1c, 0x00, 0xdd, 0x22, 0xf2, 0x63, 0x5f, 0xb0, 0x0b, 0x5a, 0x70, 0x11, 0x3f, 0x33, 0x13, 0x00, 0xf9, 0x7a, 0x9c, 0x70, 0xd9, 0x4f, 0x74, 0x5f, 0x60, 0x31, 0x7b, 0x51, 0x00, 0x90, 0x07, 0x01, 0x92, 0x70, 0xfe, 0x0b, 0x1d, 0x48, 0xe4, 0xc9, 0x05, 0x5b, 0x13, 0xb0, 0x47, 0x6a, 0x81, 0xe0, 0x00, 0x77, 0x13, 0x4f, 0xc9, 0x8a, 0x6d, 0x4f, 0x91, 0x4c, 0x24, 0x69, 0x92, 0xc0, 0x58, 0x1e, 0x00, 0xdc, 0x34, 0xf9, 0x63, 0x4c, 0xb1, 0x0b, 0x51, 0x7d, 0x10, 0x3f, 0x37, 0x13, 0x13, 0xe3, 0x75, 0x9f, 0x70, 0xc3, 0x53, 0x7a, 0x47, 0x7f, 0x34, 0x5b, 0x4a, 0x00, 0x91, 0xac, 0x55, 0x13, 0x23, 0x80, 0x46, 0x4a, 0x68, 0xf4, 0x4c, 0x7b, 0x13, 0x06, 0xb1, 0x0a, 0x1e, 0x03, 0x92, 0x8c, 0x36, 0x47, 0x61, 0xdb, 0x0b, 0x1f, 0x00, 0xcc, 0x4f, 0x82, 0x10, 0x08, 0xc4, 0x65, 0x6b, 0x69, 0xe5, 0x23, 0x18, 0x77, 0x13, 0x4f, 0x09, 0x3e, 0x43, 0xff, 0x23, 0x07, 0x61, 0x69, 0xd6, 0x63, 0x6b, 0x20, 0x38, 0x73, 0x4c, 0x23, 0x23, 0x82, 0x2b, 0x7d, 0x79, 0xb0, 0x10, 0x1e, 0x4e, 0x69, 0xd5, 0x2b, 0x5d, 0x72, 0xf4, 0x3a, 0x11, 0x5d, 0x4a, 0xff, 0xd0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; +static char midi2[] = {0x00, 0x74, 0x62, 0xc0, 0xd2, 0x07, 0xcf, 0x07, 0xcf, 0x0b, 0x8e, 0x54, 0xe9, 0xd5, 0x09, 0x47, 0x00, 0xc1, 0x06, 0x7a, 0x30, 0x77, 0x09, 0x01, 0xb1, 0x44, 0x6f, 0x81, 0xe1, 0x2c, 0x5f, 0x06, 0x4a, 0xc6, 0x8a, 0x67, 0x4c, 0x91, 0x62, 0x0c, 0x73, 0x87, 0xc1, 0x58, 0x17, 0x00, 0xde, 0x12, 0xde, 0x76, 0x4a, 0xb0, 0x0b, 0x52, 0x72, 0x11, 0x23, 0x36, 0x13, 0x01, 0xf9, 0x7b, 0x96, 0x70, 0xd9, 0x60, 0x5f, 0x49, 0x68, 0x30, 0x7b, 0x58, 0x00, 0x91, 0x13, 0x32, 0x87, 0x76, 0xfd, 0x0b, 0x17, 0x48, 0xfa, 0xdf, 0x2f, 0x4e, 0x05, 0xb0, 0x4c, 0x77, 0x81, 0xe0, 0x08, 0x78, 0x13, 0x4d, 0xd9, 0x8a, 0x67, 0x4c, 0x91, 0x5d, 0x17, 0x60, 0x87, 0xc1, 0x43, 0x17, 0x00, 0xd6, 0x38, 0xde, 0x76, 0x41, 0xb1, 0x0b, 0x54, 0x63, 0x10, 0x2b, 0x1c, 0x06, 0x05, 0xf8, 0x6a, 0x9c, 0x70, 0xd8, 0x4c, 0x77, 0x54, 0x5e, 0x30, 0x7b, 0x50, 0x00, 0x91, 0x19, 0x01, 0x87, 0x76, 0xf2, 0x0b, 0x17, 0x40, 0xcd, 0xd8, 0x2f, 0x46, 0x06, 0xb1, 0x4c, 0x4d, 0x81, 0xe1, 0x1f, 0x5f, 0x06, 0x46, 0xe9, 0x8a, 0x6d, 0x43, 0x90, 0x53, 0x35, 0x44, 0x80, 0xc1, 0x4b, 0x17, 0x00, 0xad, 0x02, 0xde, 0x76, 0x3a, 0xb1, 0x0b, 0xe8, 0x2f, 0x91, 0x1b, 0x0b, 0x74, 0x6d, 0xb1, 0x0b, 0x16, 0xb6, 0x91, 0x94, 0x0a, 0x06, 0xb4, 0xb7, 0x51, 0x13, 0x91, 0xf3, 0x10, 0x23, 0x70, 0x02, 0xb1, 0x69, 0x48, 0x50, 0xf3, 0x54, 0x5f, 0x67, 0x59, 0xe1, 0x6a, 0x17, 0x00, 0xf1, 0x0c, 0x0f, 0x66, 0x06, 0xb1, 0x54, 0x48, 0x50, 0xce, 0x52, 0x5f, 0x58, 0x5b, 0xe0, 0x55, 0x1c, 0x00, 0xcd, 0x13, 0x22, 0x4e, 0x02, 0xb1, 0x57, 0x48, 0x50, 0xcd, 0x51, 0x5f, 0x5d, 0x59, 0xe1, 0x50, 0x17, 0x00, 0xcb, 0x0f, 0x0f, 0x5c, 0x06, 0xb1, 0x52, 0x48, 0x50, 0xc8, 0x4f, 0x5f, 0x5e, 0x5b, 0xe0, 0x53, 0x1c, 0x00, 0xc7, 0x17, 0x20, 0x44, 0x02, 0xb1, 0x5d, 0x48, 0x50, 0xc7, 0x4e, 0x5f, 0x53, 0x59, 0xe1, 0x5e, 0x17, 0x0f, 0xc5, 0x12, 0x0f, 0x52, 0x06, 0xb1, 0x58, 0x48, 0x50, 0xc2, 0x4c, 0x5f, 0x54, 0x5b, 0xe0, 0x59, 0x1b, 0x00, 0xc1, 0x10, 0x3e, 0x42, 0x02, 0xb1, 0x5b, 0x48, 0x50, 0xc1, 0x4b, 0x5f, 0x49, 0x59, 0xe1, 0x44, 0x17, 0x00, 0xdf, 0x15, 0x0f, 0x48, 0x06, 0xb1, 0x46, 0x48, 0x50, 0xdc, 0x49, 0x5f, 0x4a, 0x5b, 0xe0, 0x47, 0x1b, 0x00, 0xdb, 0x13, 0x3d, 0x58, 0x02, 0xb1, 0x41, 0x48, 0x50, 0xdb, 0x48, 0x5f, 0x4f, 0x59, 0xe1, 0x42, 0x17, 0x00, 0xd9, 0x18, 0x0f, 0x4e, 0x06, 0xb1, 0x4c, 0x48, 0x50, 0xd6, 0x46, 0x5f, 0x40, 0x5b, 0xe0, 0x4d, 0x1a, 0x00, 0xd5, 0x17, 0x3b, 0x56, 0x02, 0xb1, 0x4f, 0x48, 0x50, 0xd5, 0x45, 0x5f, 0x45, 0x59, 0xe1, 0x48, 0x17, 0x00, 0xd3, 0x1b, 0x0f, 0x44, 0x06, 0xb1, 0x4a, 0x48, 0x50, 0xd0, 0x43, 0x5f, 0x46, 0x5b, 0xe0, 0x4b, 0x1a, 0x00, 0xaf, 0x18, 0x39, 0x2c, 0x02, 0xb1, 0x35, 0x48, 0x50, 0xaf, 0x42, 0x5f, 0x3b, 0x59, 0xe1, 0x36, 0x17, 0x00, 0xad, 0x1e, 0x0f, 0x3a, 0x06, 0xb1, 0x30, 0x48, 0x50, 0xaa, 0x40, 0x5f, 0x3c, 0x64, 0xe0, 0x31, 0x1a, 0x00, 0xa9, 0x2c, 0x38, 0x2a, 0x02, 0xb1, 0x33, 0x77, 0x50, 0xa9, 0x3f, 0x5f, 0x31, 0x66, 0xe1, 0x3c, 0x17, 0x00, 0xa7, 0x5e, 0x0f, 0x30, 0x06, 0xb1, 0x3e, 0x77, 0x50, 0xa4, 0x3d, 0x5f, 0x32, 0x64, 0xe0, 0x3f, 0x19, 0x00, 0xa3, 0x28, 0x36, 0x20, 0x02, 0xb1, 0x39, 0x77, 0x50, 0xa3, 0x3c, 0x5f, 0x37, 0x66, 0xe1, 0x3a, 0x17, 0x00, 0xa1, 0x5a, 0x1f, 0x29, 0x67, 0xa1}; + +/* SPMA100B driver */ +/* XXX: WARNING! Just guessed! Don't rely on anything! */ + +static void spma100_volume(uint8_t vol1, uint8_t vol2, uint8_t vol3, uint8_t vol4) +{ + /* + * Volume registers + * VDS also OK for VDD=2.8V and SPVDD=3.3V + */ + spma100_regwrite(0xe3, vol1); // MIDI or Master + spma100_regwrite(0xe4, vol2); // PCM??? + spma100_regwrite(0xe5, vol3); // PCM??? + spma100_regwrite(0xe6, vol4); // opposite of 0xe3 +} + +static void spma100_standby(void) +{ + /* Volume: Mute */ + spma100_volume(0, 0, 0, 0); + + spma100_regwrite(0xe2, 0x00); + spma100_regwrite(0xe2, 0x01); + spma100_regwrite(0xe1, 0xff); + spma100_regwrite(0xe2, 0x00); + spma100_regwrite(0xe2, 0x01); + spma100_regwrite(0xf2, 0x04); +} + +static void spma100_start(void) +{ + /* Toggle something. Power? */ + spma100_regwrite(0xe2, 0x00); + spma100_regwrite(0xe2, 0x01); + + spma100_regwrite(0xff, 0x07); + spma100_regwrite(0xe9, 0x00); + spma100_regwrite(0xf2, 0x00); + + /* Volume: Mute */ + spma100_volume(0, 0, 0, 0); + + /* Power-up sequence/disable power-downs. Clicks otherwise */ + spma100_regwrite(0xe1, 0x7e); + spma100_regwrite(0xe1, 0x1e); + spma100_regwrite(0xe1, 0x04); + spma100_regwrite(0xe1, 0x00); + + /* + * PLL settings + * With OKI's table 8, this would be 13*34/10 = 44.2MHz + * -> 0.2% error for 44.1kHz * 1000 cycles/sample + * XXX: why twice!? + */ + spma100_regwrite(0xe7, 0x22); + spma100_regwrite(0xe8, 0x09); + spma100_regwrite(0xf3, 0x22); + spma100_regwrite(0xf4, 0x09); + + /* + * Would be transition from MUTE to 0dB for W56964 + */ + spma100_volume(0, 0, 0, 0); + spma100_volume(0x1f, 0x1f, 0x1f, 0x10); + + spma100_regwrite(0xdb, 0x08); + spma100_regwrite(0xdc, 0x00); + spma100_regwrite(0xde, 0x08); + spma100_regwrite(0xdf, 0x00); +} + +static void spma100_senddata(char *data, int length) +{ + int i; + for(i=0; i<length; i++) + spma100_regwrite(0xc5, data[i]); +} + +static void spma100_play_midi(char *data, int length) +{ + spma100_regwrite(0xe0, 0x02); + spma100_regwrite(0xc8, 0x02); + spma100_regwrite(0xc8, 0x04); + spma100_regwrite(0xd6, 0x00); + spma100_regwrite(0xc4, 0x02); + spma100_regwrite(0xc6, 0xff); + spma100_regwrite(0xd6, 0x01); + spma100_senddata(data, length); + spma100_regwrite(0xd6, 0x00); + spma100_regwrite(0xc8, 0x01); +} + +static void spma100_init(void) +{ + static const char setup_cmd[] = { /* removed because of unknown copyright */ }; + + int i; + /* XOR with flash for copyright issues */ + for(i=0; i<449; i++) + midi1[i] = *(uint8_t *)(0x6f0694 + i) ^ midi1[i]; + for(i=0; i<sizeof(midi2); i++) + midi2[i] = *(uint8_t *)(0x6f0884 + i) ^ midi2[i]; + + music_init(); + +/* Not required to play music! + spma100_regwrite(0xd6, 0x01); + spma100_regwrite(0xc8, 0x06); + spma100_regwrite(0xd6, 0x00); + + // XXX: timestamp advanced! What happened? + spma100_regwrite(0xc8, 0x02); + spma100_regwrite(0xc8, 0x04); + spma100_regwrite(0xd6, 0x00); + spma100_regwrite(0xc0, 0x02); + spma100_regwrite(0xc4, 0x00); + spma100_senddata(setup_cmd, sizeof(setup_cmd)); + + // XXX: timestamp advanced! What happened? + spma100_regwrite(0xc6, 0xff); + spma100_regwrite(0xc8, 0x01); + + spma100_standby(); +*/ +} + +static void spma100_voodoo1(void) +{ + spma100_regwrite(0xda, 0x35); + spma100_regwrite(0xdb, 0x02); + spma100_regwrite(0xdd, 0x59); + spma100_regwrite(0xde, 0x02); +} + +static void spma100_voodoo2(void) +{ + spma100_regwrite(0xd2, 0x00); + spma100_regwrite(0xd3, 0x0f); + spma100_regwrite(0xd4, 0x0f); + spma100_regwrite(0xd8, 0x00); +} + +static void spma100_voodoo3(void) +{ + spma100_regwrite(0xc8, 0x06); + spma100_regwrite(0xd6, 0x00); + spma100_regwrite(0xc8, 0x06); + spma100_regwrite(0xd6, 0x00); + spma100_regwrite(0xd6, 0x00); + spma100_regwrite(0xd9, 0x0f); + spma100_regwrite(0xd9, 0x00); + spma100_regwrite(0xd3, 0x0f); + spma100_regwrite(0xd4, 0x0f); + spma100_regwrite(0xd8, 0x00); +} + +static void spma100_clear_fifo() +{ + int i; + spma100_regwrite(0xd6, 0x01); + for(i=0; i<256; i++) + spma100_regwrite(0xc5, 0); +} + +void spma100(const char *midi, int length) +{ + spma100_start(); + + /* XXX: Volume? */ + //spma100_regwrite(0xe1, 0x00); + + spma100_voodoo1(); + spma100_voodoo2(); + spma100_play_midi(midi, length); + + //spma100_clear_fifo(); + //spma100_voodoo3(); + //spma100_standby(); +} + int main(void) { board_init(); @@ -103,9 +407,30 @@ int main(void) sercomm_register_rx_cb(SC_DLCI_CONSOLE, console_rx_cb); sercomm_register_rx_cb(SC_DLCI_L1A_L23, l1a_l23_rx_cb); - /* beyond this point we only react to interrupts */ - puts("entering interrupt loop\n"); + /* MIDI player */ + int i; + spma100_init(); + puts("Play MIDI on keypress\n"); while (1) { + switch(play_midi) { + case 1: + spma100(midi1, sizeof(midi1)); + break; + case 2: + spma100(midi2, sizeof(midi2)); + break; + case 9: + printf("GPIO status %04x\n", readw(0xfffe4800)); + spma100(midi1, sizeof(midi1)); + for(i=0; i<20; i++) { + spma100_deltaregs(); + printf("GPIO status %04x\n", readw(0xfffe4800)); + delay_ms(50); + } + break; + } + play_midi = -1; + update_timers(); } @@ -132,6 +457,7 @@ void key_handler(enum key_codes code, enum key_states state) case KEY_7: case KEY_8: case KEY_9: + play_midi = code - KEY_0; sprintf(test, "%d", code - KEY_0); display_puts(test); break; -- 1.7.1

12 years, 12 months

1
0
0 0

R: Re: R: Re: lost dump ?!?!?

by screaming-pain＠libero.it

Thanks Sylvain, Harald and Alex, > >Can you please verify this? If you do have a listener on the UDP port >and still get write errors, we need to fix something in 'mobile'. >Otherwise, no need for that... > I was using nc -u -l 4729 > /dev/null I added the -p option and tried again: as you said this solved the problem!!! Thanks again, Loretta

12 years, 12 months

1
0
0 0

simtrace: New mailing list / progress

by Harald Welte

Hi all! Since Kevin and I are trying to re-vitalize the simtrace project, I have decided to create a new simtrace(a)lists.osmocom.org mailing list dedicated to this project. Yesterday at a meeting we have discussed * to use a digitally-controlled analog switch to select sniffing / emulation mode (i.e. to do a software-controlled 'cut' the electrical connection between the SIM card and the phone) * to add a header next to the USB socket so we can attach a battery pack for autonomous operation * to add a SPI NOR flash (for storage of data in autonomous operation) * to not care about 1.8V-only SIM cards and make it a 3.3V-only device We expect to do a bit more schematics review and component placement + routing as well as a prototype PCB in the next couple of weeks. Kevin is in charge of the hardware prototype, while I will look at the firmware side as well as provide funding for the PCB manufacturing and prototype components. 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)

12 years, 12 months

1
0
0 0

R: Re: lost dump ?!?!?

by screaming-pain＠libero.it

Thanks Alex, I actually played a bit with the code and found out that exactly half of the times the write() call in the function gsmtap_fd_cb() (gsmtap_util.c) fails because of EAGAIN or EWOULDBLOCK. I implemented a retransmission in this case and this solve the problem: all the gsmtap are successfully sent and received. Though, I suspect is impacting negatively on the rest of the mobile program. Anyway I do not have a real evidence of this only the fact that after the modification I have never had a successful location update. Do you think this is plausible? am I degrading the overall performances when trying to get all the gsmtap? Can i solve this problem? Thanks Alex and list, Loretta >----Messaggio originale---- >Da: vamposdecampos(a)gmail.com >Data: 6-mag-2011 8.35 >A: "screaming-pain(a)libero.it"<screaming-pain(a)libero.it> >Cc: <baseband-devel(a)lists.osmocom.org> >Ogg: Re: lost dump ?!?!? > >On Thu, May 5, 2011 at 5:28 PM, screaming-pain(a)libero.it ><screaming-pain(a)libero.it> wrote: >> Hi list, >> >> I know I am very slow in understanding osmocom-bb, anyway this is just a quick >> question. >> Is it possible that some of the gsmtap messages are getting lost? >> For example I can see a LOCATION UPDATE and a LOCATION ACCEPT from the >> 'mobile' application log but there aren't the corresponding messages in the >> wireshark capture, >> though this does not always happen, I mean I had captures of location updates >> other times, this is why I am wondering if they are getting lost and what it >> does depend on. >> for what I understood the gsmtap functions utilities are in gsmtap_util.c and >> the one to send the messages on the socket is called by l1ctl.c am I right? >> Can you help me understanding why I cannot see all the messages? >> >> thank you in advance >> Loretta > >Hi, > >I've had this happen to me when I wasn't receiving the gsmtap packets. > >Specifically, I had the gsmtap packets sent over the network (i.e., >non-localhost). There was no UDP listener on the receiving end, such >that ICMP port-unreachable replies were being sent back. It would >appear that this causes the sender's kernel to snub some of the >outgoing packets. I don't know if the same happens on localhost. > >If this is your case, you can try "iptables -I INPUT -p udp -d 4729 -j >DROP", or something like "nc -l -u 4729 > /dev/null". > >Cheers, >Alex > >

12 years, 12 months

3
2
0 0

lost dump ?!?!?

by screaming-pain＠libero.it

Hi list, I know I am very slow in understanding osmocom-bb, anyway this is just a quick question. Is it possible that some of the gsmtap messages are getting lost? For example I can see a LOCATION UPDATE and a LOCATION ACCEPT from the 'mobile' application log but there aren't the corresponding messages in the wireshark capture, though this does not always happen, I mean I had captures of location updates other times, this is why I am wondering if they are getting lost and what it does depend on. for what I understood the gsmtap functions utilities are in gsmtap_util.c and the one to send the messages on the socket is called by l1ctl.c am I right? Can you help me understanding why I cannot see all the messages? thank you in advance Loretta

12 years, 12 months

3
2
0 0

Questions regarding testing branch

by ArMaND VanHell

Some questions about Sylvain testing branch: why is not merged SIMreader into master branch? is planned for mobile aplication to support SMS (sending/receiving)? Thank you, ArMaND VanHell

12 years, 12 months

1
0
0 0

[PATCH 0/5] merge mtk-loader to master

by Wolfram Sang

The first four patches remove some hardcoded calypso-dependencies (as discussed on the list). The final one then adds the mtk-stuff with comments from Sylvain addressed (hopefully). The new mtk-loader was succesfully tested on my Sciphone G2 by loading and executing a bootloader. The compal loaders still compile fine (and no code was changed there). This should get rid of the branches remotes/origin/steve-m/loader_sciphone remotes/origin/steve-m/mtk_hack and should ease merging new platforms in general a bit more. Regards, Wolfram Wolfram Sang (5): comm: msgb: don't set backlight on error lib: move delay.c from calypso to lib cfi_flash: delete unused defines uart.h: move header out of calypso-directory target/boards: add infrastructure for loaders for Mediatek platforms src/Makefile | 8 +- src/target/firmware/Makefile.mtk | 33 ++ src/target/firmware/apps/loader/main.c | 2 +- src/target/firmware/apps/loader_mtk/main.c | 366 ++++++++++++++++++++ src/target/firmware/board/compal_e86/init.c | 2 +- src/target/firmware/board/compal_e88/init.c | 2 +- src/target/firmware/board/compal_e99/init.c | 2 +- src/target/firmware/board/gta0x/init.c | 2 +- src/target/firmware/board/mediatek/macros.S | 76 +++++ src/target/firmware/board/mediatek/ram.lds | 112 +++++++ src/target/firmware/board/mediatek/start.ram.S | 26 ++ src/target/firmware/board/mediatek/uart.c | 426 ++++++++++++++++++++++++ src/target/firmware/board/mt62xx/init.c | 139 ++++++++ src/target/firmware/board/pirelli_dpl10/init.c | 2 +- src/target/firmware/calypso/Makefile | 2 +- src/target/firmware/calypso/delay.c | 16 - src/target/firmware/calypso/uart.c | 2 +- src/target/firmware/comm/msgb.c | 1 - src/target/firmware/comm/sercomm.c | 2 +- src/target/firmware/comm/sercomm_cons.c | 2 +- src/target/firmware/flash/cfi_flash.c | 5 - src/target/firmware/include/calypso/uart.h | 32 -- src/target/firmware/include/mtk/emi.h | 42 +++ src/target/firmware/include/mtk/mt6235.h | 74 ++++ src/target/firmware/include/mtk/system.h | 195 +++++++++++ src/target/firmware/include/uart.h | 32 ++ src/target/firmware/lib/Makefile | 2 +- src/target/firmware/lib/console.c | 2 +- src/target/firmware/lib/delay.c | 16 + 29 files changed, 1556 insertions(+), 67 deletions(-) create mode 100644 src/target/firmware/Makefile.mtk create mode 100644 src/target/firmware/apps/loader_mtk/main.c create mode 100644 src/target/firmware/board/mediatek/macros.S create mode 100644 src/target/firmware/board/mediatek/ram.lds create mode 100644 src/target/firmware/board/mediatek/start.ram.S create mode 100644 src/target/firmware/board/mediatek/uart.c create mode 100644 src/target/firmware/board/mt62xx/init.c delete mode 100644 src/target/firmware/calypso/delay.c delete mode 100644 src/target/firmware/include/calypso/uart.h create mode 100644 src/target/firmware/include/mtk/emi.h create mode 100644 src/target/firmware/include/mtk/mt6235.h create mode 100644 src/target/firmware/include/mtk/system.h create mode 100644 src/target/firmware/include/uart.h create mode 100644 src/target/firmware/lib/delay.c -- 1.7.2.5

12 years, 12 months

2
6
0 0

Anyone based in India on this list? Students?

by Harald Welte

I'm looking for somebody in India who has a deep GSM interest and who is preferrably a student. If you're quick, I have a free giveaway for you. Please simply e-mail me, details will follow. 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)

12 years, 12 months

2
2
0 0

Re: mobile - making a call

by eisencah eisenach

Done some more digging in the logs and it seems the sim state machine has locked earlier (when attaching to the network) while waiting for some response on UPDATE BINARY. Does this sounds familiar to anyone? :) GOOD CASE: [0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) [0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) [0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:151 sending result to callback function (type=0) [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) BAD CASE: [0;m[1;32m<0004> gsm48_mm.c:1557 AUTHENTICATION RESPONSE [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_DATA_REQ' received in state dedicated [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[0;35m<000e> sim.c:209 got new job: SIM_JOB_UPDATE_BINARY (handle=00000005) [0;m[0;35m<000e> sim.c:241 SELECT (file=0x6f20) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4) [0;m[0;35m<000e> sim.c:876 received APDU (len=0 sw1=0x9f sw2=0x0f) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:571 GET RESPONSE (len=15) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xc0) [0;m[0;35m<000e> sim.c:876 received APDU (len=15 sw1=0x90 sw2=0x00) [0;m[0;35m<000e> sim.c:949 command successfull [0;m[0;35m<000e> sim.c:294 UPDATE BINARY (offset=0 len=9) [0;m[0;35m<000e> sim.c:187 sending APDU (class 0xa0, ins 0xd6) [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state location updating initiated --- On Wed, 5/4/11, Harald Welte <laforge(a)gnumonks.org> wrote: From: Harald Welte <laforge(a)gnumonks.org> Subject: Re: mobile - making a call To: "eisencah eisenach" <wbg_1000(a)yahoo.com> Date: Wednesday, May 4, 2011, 11:59 AM On Tue, May 03, 2011 at 03:02:58AM -0700, eisencah eisenach wrote: > So is as if the message for the sim job doesn't get pulled from the > queue, "got new job: SIM_JOB_RUN_GSM_ALGO " never appears. Must say > the computer I use osmocom on is not exactly a rocket :) (is a 500Mhz > celeron with ubuntu 6.10) , and It gets slowed down when running the > hole thing. Can that be the cause? Mihai. The L1CTL protocol goes through a unix domain socket, and you can trace it in either osmocon or in the mobile program itself. It should be relatively easy to detect if the RUN_GSM_ALGO is transmitted by mobile, or if it is lost, where it is lost. -- - 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)

12 years, 12 months

1
0
0 0

mobile - making a call

by eisencah eisenach

Hi. I'm using mobile application (sylvain/testing branch) to initiate calls. My experience is that the call si succesfull in about 20% of cases. Most of the time the connection seems to be lost after receiving the AUTHENTICATION REQUEST message. Has anyone else had this experience, it has to do with the power measurements above? Thanks, Mihai. [0;m[1;33m<0005> gsm48_cc.c:496 Sending MMCC_EST_REQ [0;m[1;32m<0004> gsm48_mm.c:3568 (ms 1) Received 'MMCC_EST_REQ' event in state MM idle [0;m[1;32m<0004> gsm48_mm.c:3571 -> substate normal service [0;m[1;32m<0004> gsm48_mm.c:3573 -> callref 1, transaction_id 255 [0;m[1;32m<0004> gsm48_mm.c:2873 Init MM Connection. [0;m[1;32m<0004> gsm48_mm.c:1332 New MM Connection (proto 0x03 trans_id 255 ref 1) [0;m[1;32m<0004> gsm48_mm.c:1291 (ref 1) new state IDLE -> CONN_PEND [0;m[1;32m<0004> gsm48_mm.c:2650 CM SERVICE REQUEST (cause 9) [0;m[1;32m<0004> gsm48_mm.c:2681 -> Using TMSI [0;m[1;34m<0001> gsm48_rr.c:4904 (ms 1) Message 'RR_EST_REQ' received in state idle [0;m[1;37m<000d> gsm48_rr.c:1181 Establish radio link due to mobility management request [0;m[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_LEAVE_IDLE' for Cell selection in state 'C3 camped normally' [0;m[34m<0003> gsm322.c:2959 Going to camping frequency 47. [0;m[34m<0003> gsm322.c:252 Sync to ARFCN=47 rxlev=-61 (Sysinfo, ccch mode NON-COMB) [0;m[1;34m<0001> gsm48_rr.c:363 new state idle -> connection pending [0;m[1;34m<0001> gsm48_rr.c:1313 CHANNEL REQUEST: e0 (Orig TCH/F) [0;m[1;32m<0004> gsm48_mm.c:887 new state MM IDLE, normal service -> wait for RR connection (MM connection) [0;m[34m<0003> gsm322.c:2434 Channel synched. (ARFCN=47, snr=16, BSIC=33) [0;m[1;34m<0001> gsm322.c:2461 using DSC of 90 [0;m[34m<0003> gsm48_rr.c:4541 Channel provides data. [0;m[1;34m<0001> gsm48_rr.c:1452 RANDOM ACCESS (requests left 5) [0;m[1;34m<0001> gsm48_rr.c:1509 RANDOM ACCESS (Tx-integer 32 combined no S(lots) 0 ra 0xed) [0;m[1;34m<0001> gsm48_rr.c:1547 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) [0;m[1;34m<0001> gsm48_rr.c:1452 RANDOM ACCESS (requests left 4) [0;m[1;34m<0001> gsm48_rr.c:1509 RANDOM ACCESS (Tx-integer 32 combined no S(lots) 217 ra 0xed) [0;m[1;34m<0001> gsm48_rr.c:1547 Use MS-TXPWR-MAX-CCH power value 5 (33 dBm) [0;m[1;34m<0001> gsm48_rr.c:2258 IMMEDIATE ASSIGNMENT: [0;m[1;34m<0001> gsm48_rr.c:2270 (ta 1/553m ra 0xed chan_nr 0x41 MAIO 2 HSN 36 TS 1 SS 0 TSC 1) [0;m[1;34m<0001> gsm48_rr.c:2204 request ed matches (fn=4,24,16) [0;m[1;34m<0001> gsm48_rr.c:2304 resetting scheduler [0;m[1;34m<0001> gsm48_rr.c:2858 decoding mobile allocation [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #0: 31 [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #1: 44 [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #2: 47 [0;m[1;34m<0001> sysinfo.c:396 Serving cell ARFCN #3: 57 [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 0 (bit 31) [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 1 (bit 44) [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 2 (bit 47) [0;m[1;34m<0001> sysinfo.c:410 Hopping ARFCN: 3 (bit 57) [0;m[1;34m<0001> gsm48_rr.c:3019 sending establish message [0;m[1;34m<0001> gsm48_rr.c:235 Using and incrementing V(SD) = 0 (pdisc 5) [0;m[1;34m<0001> gsm48_rr.c:2763 setting indicated TA 1 (actual TA 1) [0;m[1;34m<0001> gsm48_rr.c:2774 using last SACCH timeout 16 [0;m[1;34m<0001> gsm48_rr.c:774 stopping pending timer T_meas [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=5 TA=1 meas-invalid=1 rxlev-full=-110 rxlev-sub=-110 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:2796 establishing channel in dedicated mode [0;m[1;34m<0001> gsm48_rr.c:2800 Channel type 64, subch 0, ts 1, mode 0, cipher 1 [0;m[1;34m<0001> gsm48_rr.c:363 new state connection pending -> dedicated [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_EST_CNF' from RR in state wait for RR connection (MM connection) [0;m[1;32m<0004> gsm48_mm.c:431 starting T3230 (MM connection timeout) with 15.0 seconds [0;m[1;32m<0004> gsm48_mm.c:897 new state wait for RR connection (MM connection) -> wait for outgoing MM connection [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 1 (actual ta 1) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 5 [0;m[1;34m<0001> gsm48_rr.c:1828 New SYSTEM INFORMATION 5 [0;m[1;34m<0001> gsm48_rr.c:1583 Complete set of SI5* for BA(0) [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 1 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 3 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 6 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 13 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 17 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 19 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 20 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 21 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 24 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 26 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 30 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 33 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 36 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 37 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 40 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 41 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 42 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 47 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 49 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 58 [0;m[1;34m<0001> gsm48_rr.c:1593 SI5* report arfcn 59 [0;m[1;32m<0004> gsm48_mm.c:4083 (ms 1) Received 'MM_EVENT_SYSINFO' event in state wait for outgoing MM connection [0;m[34m<0003> gsm322.c:2104 Sysinfo of selected cell is updated. [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:3863 (ms 1) Received 'MT_MM_AUTH_REQ' in MM state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:468 stopping pending (periodic loc. upd. delay) timer T3212 [0;m[1;32m<0004> gsm48_mm.c:1533 AUTHENTICATION REQUEST (seq 1) [0;m[1;32m<0004> subscriber.c:898 Generating KEY at SIM [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 5 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-60 snr=11 ber= 27 LAI=226 01 2b96 ID=e328 TA=0 pwr=5 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=5 TA=0 meas-invalid=0 rxlev-full=-60 rxlev-sub=-60 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 5 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 6 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 17 LAI=226 01 2b96 ID=e328 TA=0 pwr=6 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=6 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 7 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 7 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-59 snr= 0 ber= 0 LAI=226 01 2b96 ID=e328 TA=0 pwr=7 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=7 TA=0 meas-invalid=0 rxlev-full=-59 rxlev-sub=-59 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 8 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 8 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 18 LAI=226 01 2b96 ID=e328 TA=0 pwr=8 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=8 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 8 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 9 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 49 LAI=226 01 2b96 ID=e328 TA=0 pwr=9 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=9 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 9 [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_DATA_IND' from RR in state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:3863 (ms 1) Received 'MT_MM_AUTH_REQ' in MM state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:1533 AUTHENTICATION REQUEST (seq 1) [0;m[1;32m<0004> subscriber.c:898 Generating KEY at SIM [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 9 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 32 LAI=226 01 2b96 ID=e328 TA=0 pwr=9 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=9 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-57 snr= 0 ber= 41 LAI=226 01 2b96 ID=e328 TA=0 pwr=10 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=10 TA=0 meas-invalid=0 rxlev-full=-57 rxlev-sub=-57 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 10 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 74 LAI=226 01 2b96 ID=e328 TA=0 pwr=10 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=10 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:4493 setting new ta and tx_power [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-59 snr= 0 ber= 9 LAI=226 01 2b96 ID=e328 TA=0 pwr=11 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=11 TA=0 meas-invalid=0 rxlev-full=-59 rxlev-sub=-59 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:4488 Indicated ta 0 (actual ta 0) [0;m[1;34m<0001> gsm48_rr.c:4490 Indicated tx_power 11 [0;m[1;34m<0001> gsm48_rr.c:609 MON: f=47 lev=-58 snr= 0 ber= 35 LAI=226 01 2b96 ID=e328 TA=0 pwr=11 TS=1/0 [0;m[1;34m<0001> gsm48_rr.c:2666 MEAS REP: pwr=11 TA=0 meas-invalid=0 rxlev-full=-58 rxlev-sub=-58 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0 no-ncell-n 0 [0;m[1;34m<0001> gsm48_rr.c:3174 channel release request with cause 0x00) [0;m[1;34m<0001> gsm48_rr.c:363 new state dedicated -> release pending [0;m[1;34m<0001> gsm48_rr.c:738 starting T3110 with 1.500 seconds [0;m[1;37m<000d> gsm48_rr.c:4666 Requested channel aborted [0;m[1;34m<0001> gsm48_rr.c:798 stopping pending timer T3110 [0;m[1;34m<0001> gsm48_rr.c:363 new state release pending -> idle [0;m[34m<0003> gsm322.c:3319 (ms 1) Event 'EVENT_RET_IDLE' for Cell selection in state 'C3 camped normally' [0;m[34m<0003> gsm322.c:541 new state 'C3 camped normally' -> 'C5 choose cell' [0;m[34m<0003> gsm322.c:2820 No BA range(s), try sysinfo. [0;m[34m<0003> gsm322.c:2859 free sysinfo arfcn=47 [0;m[34m<0003> gsm322.c:2859 free sysinfo arfcn=66 [0;m[1;32m<0004> gsm48_mm.c:3695 (ms 1) Received 'RR_REL_IND' from RR in state wait for outgoing MM connection [0;m[1;32m<0004> gsm48_mm.c:495 stopping pending (MM connection timeout) timer T3230 [0;m[1;32m<0004> gsm48_mm.c:1367 Release any MM Connection [0;m[1;32m<0004> gsm48_mm.c:1348 Freeing MM Connection [0;m[1;32m<0004> gsm48_mm.c:1291 (ref 1) new state CONN_PEND -> IDLE [0;m[1;33m<0005> gsm48_cc.c:2122 (ms 1) Received 'MMCC_ERR_IND' in CC state MM_CONNECTION_PEND [0;m[1;33m<0005> gsm48_cc.c:189 (ms 1 ti ff) Sending 'MNCC_REL_IND' to MNCC. [0;m[1;37m<0007> mnccms.c:336 Call has been released (cause 16)

13 years

2
3
0 0

AW: mobile - making a call

by Andreas.Eversberg

hi, can you try a different sim / different network? andreas

13 years

1
0
0 0

RMS / FSF / OsmocomBB / Free Software GSM phone

by Harald Welte

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Some months ago, Richard Stallman (rms) has contacted me regarding my work with OsmocomBB. As it is not a big surprise to us, he is really interested in the project. After all, it would be the first mobile phone that he himself would be able to use, given that there is no proprietary software on the baseband anymore. And of course it would enable loads of other freedom-loving users to finally have an alternative to the proprietary telephony world. Here in Morocco, I've had some further discussion on the topic face to face with him, and he is sort of unhappy with the fact that nobody is working on making an actual self-contained phone (no matter how simple or limited in features) that can be used by a regular user as 'just a phone'. I explained to him that our motivation is mostly a different one (research, security, GSM-attached PBX, etc.) and thus there is no intrinsic motivation to work towards a more user-friendly version. Furthermore, we are system level hackers with an interest in communications, not particularly people who like to work on a UI or usability. So we agreed to make a public call for volunteers to wokr on that aspect of the phone. I understand this will likely cause some effort on our side (fencing off poeple who don't have the neccessary skills, integrating such code, finally deciding on a RTOS to use, etc.). However, I more or less see it as my (and our?) duty to realize the potential of our protocol stack and baseband firmware. Next to all our own self-motivated personal interestes, there is a bigger cause that we can help along: Free Software based telephony. So the least we can do is to try to find somebody who can work on that part, and help developer[s] to interact with our code. It's the question of whether we are just hacking away on our personal little pet, or if we try to achieve something bigger. I've already drafted a version of the 'job description' and with some luck the FSF will soon publish it, reaching out beyond our existing small Osmocom community. e will try to draft a similar job description related to MS-side GPRS support (L1, RLC/MAC, ..). That would be yet another area where we would appreciate some contribution, and which eventually be important beyond our existing voice telephony capabilities. 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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFNvs0JXaXGVTD0i/8RArkDAKCONleE9HJ2i1jp7L/XnMY0YweIjACbB8Lz puH7X4lkqY8AqzU0SAlOAxM= =Cmo8 -----END PGP SIGNATURE-----

13 years

5
6
0 0

[PATCH] linuxlist.h: silence a noisy warning

by Wolfram Sang

Fixes a couple of warnings like this: In file included from ../../shared/libosmocore/include/osmocom/core/msgb.h:24:0, from include/comm/sercomm.h:6, from apps/loader/main.c:41: ../../shared/libosmocore/include/osmocom/core/linuxlist.h: In function 'prefetch': ../../shared/libosmocore/include/osmocom/core/linuxlist.h:10:41: warning: unused parameter 'x' Signed-off-by: Wolfram Sang <wolfram(a)the-dreams.de> --- .../libosmocore/include/osmocom/core/linuxlist.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/shared/libosmocore/include/osmocom/core/linuxlist.h b/src/shared/libosmocore/include/osmocom/core/linuxlist.h index fb99c5e..ff2c491 100644 --- a/src/shared/libosmocore/include/osmocom/core/linuxlist.h +++ b/src/shared/libosmocore/include/osmocom/core/linuxlist.h @@ -7,7 +7,7 @@ #define inline __inline__ #endif -static inline void prefetch(const void *x) {;} +static inline void prefetch(__attribute__((unused)) const void *x) {;} /** * container_of - cast a member of a structure out to the containing structure -- 1.7.2.5

13 years

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel May 2011