January 2013 - baseband-devel - lists.osmocom.org

[PATCH libosmocore 0/8] Cell Broadcast (SMSCB) MS support

by Alex Badea

Hi, This a respin of my old series of patches[1], to add decoding of SMSCB messages on the MS side. The series defines a new smscb_entity, which can be fed L1 messages from a CBCH, performs reassembly, and constructs equivalent SMS Broadcast Command (RSL_MT_SMS_BC_CMD) messages for L3. I also have a follow-up patch for bb/cell_log which makes use of this functionality. Please review and consider for merging, thanks. [1] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000834.html Alex Badea (8): gsm: add skeleton smscb module smscb: add unit test for smscb_entity smscb: process Null messages smscb test: support a list of L1 messages to test smscb: add test-case for reassembling a normal message smscb: add test-case for reassembling a Schedule message smscb: implement reassembly smscb: hook into LAPDm include/Makefile.am | 1 + include/osmocom/gsm/lapdm.h | 3 + include/osmocom/gsm/smscb.h | 37 ++++++++ src/gsm/Makefile.am | 1 + src/gsm/lapdm.c | 13 +++ src/gsm/libosmogsm.map | 5 + src/gsm/smscb.c | 209 +++++++++++++++++++++++++++++++++++++++++++ tests/smscb/smscb_test.c | 118 ++++++++++++++++++++++++ tests/smscb/smscb_test.ok | 9 ++ tests/testsuite.at | 2 +- 10 files changed, 397 insertions(+), 1 deletions(-) create mode 100644 include/osmocom/gsm/smscb.h create mode 100644 src/gsm/smscb.c

11 years, 3 months

3
13
0 0

[PATCH libosmocore] doxyfiles: refer paths to @srcdir@

by Alex Badea

When building out-of-srcdir, paths such as "src/gsm" will not find any source files. Since the Doxyfiles are preprocessed, we can prepend @srcdir@ to fix that. Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- Doxyfile.codec.in | 2 +- Doxyfile.core.in | 2 +- Doxyfile.gsm.in | 2 +- Doxyfile.vty.in | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Doxyfile.codec.in b/Doxyfile.codec.in index fcd5122..1b0df5e 100644 --- a/Doxyfile.codec.in +++ b/Doxyfile.codec.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/codec src/codec +INPUT = @srcdir@/include/osmocom/codec @srcdir@/src/codec # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is diff --git a/Doxyfile.core.in b/Doxyfile.core.in index 18eb226..ee58f80 100644 --- a/Doxyfile.core.in +++ b/Doxyfile.core.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/core src +INPUT = @srcdir@/include/osmocom/core @srcdir/@src # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is diff --git a/Doxyfile.gsm.in b/Doxyfile.gsm.in index ab25b22..36a6ae2 100644 --- a/Doxyfile.gsm.in +++ b/Doxyfile.gsm.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/gsm include/osmocom/gsm/protocol src/gsm +INPUT = @srcdir@/include/osmocom/gsm @srcdir@/include/osmocom/gsm/protocol @srcdir@/src/gsm # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is diff --git a/Doxyfile.vty.in b/Doxyfile.vty.in index 57f19ad..527cdb2 100644 --- a/Doxyfile.vty.in +++ b/Doxyfile.vty.in @@ -610,7 +610,7 @@ WARN_LOGFILE = # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = include/osmocom/vty src/vty +INPUT = @srcdir@/include/osmocom/vty @srcdir@/src/vty # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is -- 1.7.0.4

11 years, 3 months

3
2
0 0

[PATCH libosmocore] timer_test: tweak path to config.h

by Alex Badea

When building out-of-srcdir, "../../config.h" fails to reach config.h because the compiler is invoked in $builddir/tests/, not $builddir/tests/timer/. Use "../config.h" instead; this also works for in-srcdir builds. Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- tests/timer/timer_test.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/timer/timer_test.c b/tests/timer/timer_test.c index ba3127d..bb9a177 100644 --- a/tests/timer/timer_test.c +++ b/tests/timer/timer_test.c @@ -33,7 +33,7 @@ #include <osmocom/core/select.h> #include <osmocom/core/linuxlist.h> -#include "../../config.h" +#include "../config.h" static void main_timer_fired(void *data); static void secondary_timer_fired(void *data); -- 1.7.0.4

11 years, 3 months

2
1
0 0

libosmocore: [PATCH] Replace obsolete automake AM_CONFIG_HEADER.

by Christian Vogel

Hi, I just setup a machine running ArchLinux which has a pretty recent automake/autoconf. libosmocore fails to build. Attached (trivial) patch fixes that. Someone with a really old toolchain/automake should check if it breaks setups we consider supported. Chris

11 years, 3 months

2
1
0 0

[PATCH] Replace obsolete automake AM_CONFIG_HEADER.

by Christian Vogel

This fixes the following complaint by autoconf 2.69-1, automake 1.13.1-1. : configure.ac:80: error: 'AM_CONFIG_HEADER': this macro is obsolete. : You should use the 'AC_CONFIG_HEADERS' macro instead. : /usr/share/aclocal-1.13/obsolete-err.m4:12: AM_CONFIG_HEADER is expan : configure.ac:80: the top level Automake 1:1.11.3-1ubuntu2, autoconf 2.68-1ubuntu2 don't even emit a warning without, and work just fine with this patch. Signed-off-by: Christian Vogel <vogelchr(a)vogel.cx> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 24ddd0c..fbc83f3 100644 --- a/configure.ac +++ b/configure.ac @@ -77,7 +77,7 @@ AC_DEFUN([CHECK_TM_INCLUDES_TM_GMTOFF], [ CHECK_TM_INCLUDES_TM_GMTOFF dnl Generate the output -AM_CONFIG_HEADER(config.h) +AC_CONFIG_HEADER(config.h) AC_ARG_ENABLE(talloc, [AS_HELP_STRING( -- 1.8.1 --VS++wcV0S1rZb1Fb--

11 years, 3 months

1
0
0 0

[PATCH] layer23 cell_log: log CBCH cell info

by Alex Badea

If System Information contained CBCH channel description, tune to it and log SMSCB messages with a Geographical Scope of Cell Wide (Immediate) -- these are typically used for "Cell Info Display". The CBCH timeout is set to a generous 8 seconds; this is because we need 4 frames for reassembly, we usually miss the first, and we might hit a burst of Null SMSCB messages. By default this feature is disabled; it can be enabled via a new '-B' or '--cbch' commandline argument. Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- This patch requires the CBCH DM flag patch[1], and the libosmocore patch series[2] for SMSCB reassembly. [1] http://lists.osmocom.org/pipermail/baseband-devel/2013-January/003612.html [2] http://lists.osmocom.org/pipermail/baseband-devel/2013-January/003642.html src/host/layer23/src/misc/app_cell_log.c | 11 +++- src/host/layer23/src/misc/cell_log.c | 114 +++++++++++++++++++++++++++++- 2 files changed, 121 insertions(+), 4 deletions(-) diff --git a/src/host/layer23/src/misc/app_cell_log.c b/src/host/layer23/src/misc/app_cell_log.c index a7f42c3..5ed1d6b 100644 --- a/src/host/layer23/src/misc/app_cell_log.c +++ b/src/host/layer23/src/misc/app_cell_log.c @@ -45,6 +45,7 @@ extern uint16_t (*band_range)[][2]; char *logname = "/var/log/osmocom.log"; int RACH_MAX = 2; +int do_cbch = 0; int _scan_work(struct osmocom_ms *ms) { @@ -103,7 +104,8 @@ static int l23_getopt_options(struct option **options) #endif {"gps", 1, 0, 'g'}, {"baud", 1, 0, 'b'}, - {"arfcns", 1, 0, 'A'} + {"arfcns", 1, 0, 'A'}, + {"cbch", 1, 0, 'B'}, }; *options = opts; @@ -162,6 +164,8 @@ static int l23_cfg_print_help() printf(" -f --gps DEVICE /dev/ttyACM0. GPS serial device.\n"); printf(" -b --baud BAUDRAT The baud rate of the GPS device\n"); printf(" -A --arfcns ARFCNS The list of arfcns to be monitored\n"); + printf(" -B --cbch Scan and log info from the CBCH\n"); + return 0; } @@ -224,6 +228,9 @@ static int l23_cfg_handle(int c, const char *optarg) parse_band_range((char*)optarg); printf("New frequencies range: %s\n", print_band_range(*band_range, buf, sizeof(buf))); break; + case 'B': + do_cbch = 1; + break; } return 0; @@ -234,7 +241,7 @@ cmd_line_error: static struct l23_app_info info = { .copyright = "Copyright (C) 2010 Andreas Eversberg\n", - .getopt_string = "g:p:l:r:nf:b:A:", + .getopt_string = "g:p:l:r:nf:b:A:B", .cfg_supported = l23_cfg_supported, .cfg_getopt_opt = l23_getopt_options, .cfg_handle_opt = l23_cfg_handle, diff --git a/src/host/layer23/src/misc/cell_log.c b/src/host/layer23/src/misc/cell_log.c index 7340dcb..41a34fd 100644 --- a/src/host/layer23/src/misc/cell_log.c +++ b/src/host/layer23/src/misc/cell_log.c @@ -26,6 +26,8 @@ #include <stdlib.h> #include <time.h> #include <errno.h> +#include <ctype.h> +#include <arpa/inet.h> #include <l1ctl_proto.h> @@ -35,6 +37,7 @@ #include <osmocom/core/msgb.h> #include <osmocom/gsm/gsm_utils.h> #include <osmocom/gsm/protocol/gsm_04_08.h> +#include <osmocom/gsm/protocol/gsm_03_41.h> #include <osmocom/gsm/rsl.h> #include <osmocom/bb/common/l1ctl.h> @@ -47,6 +50,7 @@ #define READ_WAIT 2, 0 #define RACH_WAIT 0, 900000 +#define CBCH_WAIT 8, 0 #define MIN_RXLEV_DBM -106 #define MAX_DIST 2000 @@ -55,6 +59,7 @@ enum { SCAN_STATE_SYNC, SCAN_STATE_READ, SCAN_STATE_RACH, + SCAN_STATE_CBCH, }; /* ranges of bands */ @@ -89,6 +94,7 @@ static int rach_count; static FILE *logfp = NULL; extern char *logname; extern int RACH_MAX; +extern int do_cbch; static struct gsm48_sysinfo sysinfo; @@ -115,6 +121,7 @@ struct rach_ref { static void start_sync(void); static void start_rach(void); +static void start_cbch(void); static void start_pm(void); static void log_gps(void) @@ -228,6 +235,11 @@ static void timeout_cb(void *arg) rach_count++; start_rach(); break; + case SCAN_STATE_CBCH: + LOGP(DRR, LOGL_INFO, "Timeout on CBCH\n"); + l1ctl_tx_dm_rel_req(ms); + start_sync(); + break; } } @@ -245,6 +257,35 @@ static void start_timer(int sec, int micro) osmo_timer_schedule(&timer, sec, micro); } +static void start_cbch(void) +{ + struct gsm48_sysinfo *s = &sysinfo; + int res; + + if (!do_cbch) { + res = -1; + } else if (!s->chan_nr) { + LOGP(DRR, LOGL_DEBUG, "No CBCH description in sysinfo\n"); + res = -1; + } else if (s->h) { + res = l1ctl_tx_dm_est_req_h1(ms, + s->maio, s->hsn, s->hopping, s->hopp_len, + s->chan_nr, s->tsc, + GSM48_CMODE_SIGN, 0, L1CTL_DM_F_CBCH); + } else { + res = l1ctl_tx_dm_est_req_h0(ms, s->arfcn, s->chan_nr, s->tsc, + GSM48_CMODE_SIGN, 0, L1CTL_DM_F_CBCH); + } + + if (res < 0) { + start_sync(); + return; + } + + state = SCAN_STATE_CBCH; + start_timer(CBCH_WAIT); +} + static void start_rach(void) { struct gsm48_sysinfo *s = &sysinfo; @@ -254,7 +295,7 @@ static void start_rach(void) if (rach_count == RACH_MAX) { log_sysinfo(); - start_sync(); + start_cbch(); return; } @@ -433,7 +474,7 @@ static int ta_result(uint8_t ta) } log_sysinfo(); - start_sync(); + start_cbch(); return 0; } @@ -737,6 +778,70 @@ int chan_conf(struct osmocom_ms *ms, struct msgb *msg) return 0; } +static int sms_bc_cmd(struct osmocom_ms *ms, struct msgb *msg) +{ + struct abis_rsl_cchan_hdr *ch = msgb_l2(msg); + struct tlv_parsed tv; + struct rsl_ie_cb_cmd_type *cmd_type; + struct gsm341_ms_message *cbmsg; + unsigned int cbmsglen; + char buf[256], *p; + + DEBUGP(DRSL, "RSLms SMS BC CMD chan_nr=0x%02x\n", + ch->chan_nr); + + rsl_tlv_parse(&tv, ch->data, msgb_l2len(msg) - sizeof(*ch)); + if (!TLVP_PRESENT(&tv, RSL_IE_SMSCB_MSG) || + !TLVP_PRESENT(&tv, RSL_IE_CB_CMD_TYPE)) { + LOGP(DRR, LOGL_ERROR, "SMS_BC_CMD missing mandatory IEs\n"); + return -EINVAL; + } + + cmd_type = (struct rsl_ie_cb_cmd_type *) TLVP_VAL(&tv, RSL_IE_CB_CMD_TYPE); + cbmsg = (struct gsm341_ms_message *) TLVP_VAL(&tv, RSL_IE_SMSCB_MSG); + cbmsglen = TLVP_LEN(&tv, RSL_IE_SMSCB_MSG); + if (cbmsglen < sizeof(*cbmsg)) { + LOGP(DRR, LOGL_ERROR, "RSL_IE_SMSCB_MSG too short\n"); + return -EINVAL; + } + + if (cmd_type->command != RSL_CB_CMD_TYPE_NORMAL) + return 0; + + gsm_7bit_decode(buf, cbmsg->data, cbmsglen - sizeof(*cbmsg)); + for (p = buf; *p; p++) + if (!isprint(*p)) + *p = '_'; + + LOGP(DSUM, LOGL_INFO, "Cell info: gs=%d code=%d update=%d id=%d text=\"%s\"\n", + cbmsg->serial.gs, + GSM341_MSG_CODE(cbmsg), + cbmsg->serial.update, + ntohs(cbmsg->msg_id), + buf); + + if (cbmsg->serial.gs != GSM341_GS_CELL_WIDE_IMMED) + return 0; + + LOGFILE("[cbch]\n"); + LOGFILE("arfcn %d\n", sysinfo.arfcn); + LOGFILE("gs %d code %d update %d msg_id %d page %d numpages %d\n", + cbmsg->serial.gs, + GSM341_MSG_CODE(cbmsg), + cbmsg->serial.update, + ntohs(cbmsg->msg_id), + cbmsg->page.current, cbmsg->page.total); + LOGFILE("text \"%s\"\n", buf); + LOGFILE("\n"); + LOGFLUSH(); + + l1ctl_tx_dm_rel_req(ms); + stop_timer(); + + start_sync(); + return 0; +} + static int rcv_cch(struct osmocom_ms *ms, struct msgb *msg) { struct abis_rsl_cchan_hdr *ch = msgb_l2(msg); @@ -751,6 +856,11 @@ static int rcv_cch(struct osmocom_ms *ms, struct msgb *msg) msgb_free(msg); return rc; } + if (state == SCAN_STATE_CBCH && msg_type == RSL_MT_SMS_BC_CMD) { + rc = sms_bc_cmd(ms, msg); + msgb_free(msg); + return rc; + } LOGP(DRSL, LOGL_NOTICE, "RSLms message unhandled\n"); msgb_free(msg); -- 1.7.0.4

11 years, 3 months

1
0
0 0

[PATCH] core/msgb: Change return value of msgb_pull to the start of pulled header

by Sylvain Munaut

From: Sylvain Munaut <tnt(a)246tNt.com> Currently msgb_pull returns a pointer to the new start of msgb, which is pretty counter intuitive and when using msgb_pull is often annoying. For eg, the msgb_pull_u{8,16,32} were previously "fixed" for this quirk in a previous commit. The msgb_pull_l2h in lapdm is also wrong because of this, same for code in osmocom-bb loader. AFAICT, the current users of msgb_pull either don't care about the return value, or expect it to be a pointer to the pulled header and not the new start of msgb (and so are currently buggy). Without this patch, you have things like: struct foo *bar = msgb_pull(msg, sizeof(struct foo)) - sizeof(struct foo) With the patch, you have: struct foo *bar = msgb_pull(msg, sizeof(struct foo)); which is IMHO a much better style. Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> --- include/osmocom/core/msgb.h | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/include/osmocom/core/msgb.h b/include/osmocom/core/msgb.h index a1939ab..4a72f2d 100644 --- a/include/osmocom/core/msgb.h +++ b/include/osmocom/core/msgb.h @@ -287,16 +287,18 @@ static inline unsigned char *msgb_push(struct msgb *msgb, unsigned int len) /*! \brief remove (pull) a header from the front of the message buffer * \param[in] msgb message buffer * \param[in] len number of octets to be pulled - * \returns pointer to new start of msgb + * \returns pointer to header that's been pulled (i.e. previous start of msgb) * * This function moves the \a data pointer of the \ref msgb further back * in the message, thereby shrinking the size of the message by \a len * bytes. */ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) -{ +{ + unsigned char *tmp = msgb->data; msgb->len -= len; - return msgb->data += len; + msgb->data += len; + return tmp; } /*! \brief remove uint8 from front of message @@ -305,7 +307,7 @@ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len) */ static inline uint8_t msgb_pull_u8(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 1) - 1; + uint8_t *space = msgb_pull(msgb, 1); return space[0]; } /*! \brief remove uint16 from front of message @@ -314,7 +316,7 @@ static inline uint8_t msgb_pull_u8(struct msgb *msgb) */ static inline uint16_t msgb_pull_u16(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 2) - 2; + uint8_t *space = msgb_pull(msgb, 2); return space[0] << 8 | space[1]; } /*! \brief remove uint32 from front of message @@ -323,7 +325,7 @@ static inline uint16_t msgb_pull_u16(struct msgb *msgb) */ static inline uint32_t msgb_pull_u32(struct msgb *msgb) { - uint8_t *space = msgb_pull(msgb, 4) - 4; + uint8_t *space = msgb_pull(msgb, 4); return space[0] << 24 | space[1] << 16 | space[2] << 8 | space[3]; } -- 1.7.8.6

11 years, 3 months

1
0
0 0

fix of osmoload, flashing c155 works

by jolly

hi, just fixed the issue from 29c3, where flashing of phones did not work anymore. if no one complains, i will apply it. it is also possible to flash c155 phones. the original compal boot loader will start firmware at 0x20000 instead of 0x2000 (c123), so i modified the linker scripts for compal_e99. i am not sure, if all c155 phones behave the same. to check this, i dumped some pages of the flash memory: run the loader: $ host/osmocon/osmocon -p /dev/ttyUSB0 -m c155 target/firmware/board/compal_e99/loader.compalram.bin start the phone and dump some flash: $ host/osmocon/osmoload memdump 0x000000 0x30000 dump a hexdump of that dump showed me where the actual firmware starts: ... 0000800 4f42 544f 392e 2e30 3530 0000 0000 0000 0000810 3031 3330 0101 0000 ffff ffff ffff ffff 0000820 ffff ffff ffff ffff ffff ffff ffff ffff * 0020000 4f43 4544 392e 2e30 3130 0000 0000 0000 0020010 4c46 5845 392e 2e30 3130 302e 0031 0000 0020020 5352 4b50 392e 2e30 3130 302e 0031 0000 ... i would like to know, if this is true for other c155 phones. regards, andreas

11 years, 3 months

3
6
0 0

No r-gsm cell shown in mobile app

by Karsten Krummeich

Hi, I'm thinking about why the mobile app don't show me the German GSM-R (MCC: 262, MNC: 10) cells they are around me. The rssi app shows me the cells (e. g. ARFCN: 957 and 961). I'm using the sylvain/testing branch and I am searching for more details in the source code and found in settings.c that the r gsm band are enabled and in the freq_list. Can someone tell me another point for searching in source? Thanks in advance. Best regards. kasio

11 years, 3 months

3
4
0 0

[PATCH] Generate Compal E99 binaries for loader and flash locations

by Andreas Eversberg

Loader binaries start at 0x20000 at flash memory. This is where the Compal loader jumps to. Flash binaries start at 0x30000 at flash memory. --- src/target/firmware/Makefile | 12 +- src/target/firmware/board/compal_e99/flash.lds | 134 +++++++++++++++++++++ src/target/firmware/board/compal_e99/loader.lds | 147 +++++++++++++++++++++++ 3 files changed, 288 insertions(+), 5 deletions(-) create mode 100644 src/target/firmware/board/compal_e99/flash.lds create mode 100644 src/target/firmware/board/compal_e99/loader.lds diff --git a/src/target/firmware/Makefile b/src/target/firmware/Makefile index a71eef6..c76bcd0 100644 --- a/src/target/firmware/Makefile +++ b/src/target/firmware/Makefile @@ -66,11 +66,13 @@ compal_e86_ENVIRONMENTS=$(compal_COMMON_ENVIRONMENTS) # Compal E99 compal_e99_OBJS=$(compal_COMMON_OBJS) board/compal_e99/init.o battery/dummy.o $(FB_e99_OBJS) -compal_e99_ENVIRONMENTS=$(compal_COMMON_ENVIRONMENTS) +compal_e99_ENVIRONMENTS=$(compal_COMMON_ENVIRONMENTS) e99loader e99flash e99loader_LDS=board/compal_e99/loader.lds -e99loader_OBJS=board/compal/header.o +e99loader_OBJS=board/compal/start.rom.o board/compal/header.o board/compal/exceptions_redirect.o + e99flash_LDS=board/compal_e99/flash.lds +e99flash_OBJS=board/compal/start.rom.o board/compal/header.o board/compal/exceptions_redirected.o board/compal/handlers.o # Sony Ericsson J100 (made by Compal) @@ -99,10 +101,10 @@ ANY_APP_LIBS+=calypso/libcalypso.a layer1/liblayer1.a lib/libmini.a comm/libcomm -include Makefile.inc # Uncomment this line if you want to enable Tx (Transmit) Support. -#CFLAGS += -DCONFIG_TX_ENABLE +CFLAGS += -DCONFIG_TX_ENABLE # Uncomment this line if you want to write to flash. -#CFLAGS += -DCONFIG_FLASH_WRITE +CFLAGS += -DCONFIG_FLASH_WRITE # Uncomment this line if you want to write to flash, including the bootloader. -#CFLAGS += -DCONFIG_FLASH_WRITE_LOADER +CFLAGS += -DCONFIG_FLASH_WRITE_LOADER diff --git a/src/target/firmware/board/compal_e99/flash.lds b/src/target/firmware/board/compal_e99/flash.lds new file mode 100644 index 0000000..1cf189f --- /dev/null +++ b/src/target/firmware/board/compal_e99/flash.lds @@ -0,0 +1,134 @@ +/* + * Linker script for flashed applications on the Compal E99 + * + * This script creates a binary that can be linked at 0xFFFF, starting + * with the second flash page. This is what a phone application or + * pure layer1 device uses. + * + * XXX: interrupts? + * + */ +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +MEMORY +{ + LOADR (rx) : ORIGIN = 0x00000000, LENGTH = 0x30000 + /* 2 MBytes of external flash memory (minus loader) */ + FLASH (rx) : ORIGIN = 0x00030000, LENGTH = 0x1F0000 + /* 256 kBytes of internal zero-waitstate sram */ + IRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x040000 + /* 256 kBytes of external slow sram */ + ERAM (rw) : ORIGIN = 0x01000000, LENGTH = 0x040000 +} +SECTIONS +{ + /* entrypoint */ + .text.start : { + PROVIDE(_start = .); + KEEP(*(.text.start)) + *(.text.start) + } > FLASH + + /* exception vectors from 0x80001c to 0x800034 */ + .text.exceptions 0x80001c : { + KEEP(*(.text.exceptions)) + * (.text.exceptions) + . = ALIGN(4); + } > IRAM AT> FLASH + PROVIDE(_exceptions = LOADADDR(.text.exceptions)); + + /* code */ + .text : { + /* regular code */ + *(.text*) + /* gcc voodoo */ + *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx) + } > FLASH + PROVIDE(_text_start = ADDR(.text)); + PROVIDE(_text_end = ADDR(.text) + SIZEOF(.text)); + + /* constructor pointers */ + .ctors : { + /* ctor count */ + LONG(SIZEOF(.ctors) / 4 - 2) + /* ctor pointers */ + KEEP(*(SORT(.ctors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_ctor_start = LOADADDR(.ctors)); + PROVIDE(_ctor_end = LOADADDR(.ctors) + SIZEOF(.ctors)); + + /* destructor pointers */ + .dtors : { + /* dtor count */ + LONG(SIZEOF(.dtors) / 4 - 2) + /* dtor pointers */ + KEEP(*(SORT(.dtors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_dtor_start = LOADADDR(.dtors)); + PROVIDE(_dtor_end = LOADADDR(.dtors) + SIZEOF(.dtors)); + + /* read-only data */ + .rodata : { + *(.rodata*) + } > FLASH + PROVIDE(_rodata_start = ADDR(.rodata)); + PROVIDE(_rodata_end = ADDR(.rodata) + SIZEOF(.rodata)); + + /* pic offset tables */ + .got : { + . = ALIGN(4); + *(.got) + *(.got.plt) *(.igot.plt) *(.got) *(.igot) + . = ALIGN(4); + } > FLASH + PROVIDE(_got_start = ADDR(.got)); + PROVIDE(_got_end = ADDR(.got) + SIZEOF(.got)); + + /* reserved ram */ + .compal.reservedram 0x800000 (NOLOAD) : { + . = 0xff; + } > IRAM + + /* initialized data */ + .data : AT (LOADADDR(.got) + SIZEOF(.got)) { + . = ALIGN(4); + *(.data) + . = ALIGN(4); + } > IRAM + PROVIDE(__data_start = LOADADDR(.data)); + PROVIDE(__data_end = LOADADDR(.data) + SIZEOF(.data)); + PROVIDE(_data_start = ADDR(.data)); + PROVIDE(_data_end = ADDR(.data) + SIZEOF(.data)); + + /* ram code */ + .ramtext : AT (LOADADDR(.data) + SIZEOF(.data)) { + . = ALIGN(4); + *(.ramtext) + . = ALIGN(4); + } > IRAM + PROVIDE(__ramtext_start = LOADADDR(.ramtext)); + PROVIDE(__ramtext_end = LOADADDR(.ramtext) + SIZEOF(.ramtext)); + PROVIDE(_ramtext_start = ADDR(.ramtext)); + PROVIDE(_ramtext_end = ADDR(.ramtext) + SIZEOF(.ramtext)); + + /* uninitialized data */ + .bss (NOLOAD) : { + . = ALIGN(4); + *(.bss) + . = ALIGN(4); + } > IRAM + PROVIDE(__bss_start = ADDR(.bss)); + PROVIDE(__bss_end = ADDR(.bss) + SIZEOF(.bss)); + PROVIDE(_bss_start = __bss_start); + PROVIDE(_bss_end = __bss_end); + + /* end of image */ + . = ALIGN(4); + _end = .; + PROVIDE(end = .); +} diff --git a/src/target/firmware/board/compal_e99/loader.lds b/src/target/firmware/board/compal_e99/loader.lds new file mode 100644 index 0000000..bb117a8 --- /dev/null +++ b/src/target/firmware/board/compal_e99/loader.lds @@ -0,0 +1,147 @@ +/* + * Linker script for flashed loader on the Compal E99 + * + * This script creates a binary that can replace a standard firmware + * located at 0x20000. It works in conjunction with the compal ramloader. + * + * The interrupt vectors and start address are at known, fixed offsets. + * + */ +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +MEMORY +{ + /* 2 MBytes of external flash memory */ + FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x200000 + /* 256 kBytes of internal zero-waitstate sram */ + IRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x040000 + /* 256 kBytes of external slow sram */ + ERAM (rw) : ORIGIN = 0x01000000, LENGTH = 0x040000 +} +SECTIONS +{ + /* Provide symbols for the compal loader */ + .compal.loader 0x00000000 (NOLOAD) : { + _compal_loader_start = .; + . = 0x2000; + _compal_loader_end = .; + } > FLASH + + /* Compal-style image header */ + .compal.header 0x00020000 : { + _compal_header_start = .; + KEEP(*(.compal.header)) + *(.compal.header) + . = 0xA0; + _compal_header_end = .; + } > FLASH + + /* Compal-style vector table */ + .compal.vectors 0x000200A0 : { + PROVIDE(_exceptions = .); + KEEP(*(.text.exceptions)) + *(.text.exceptions) + } > FLASH + + /* Compal-style entry point */ + .text.start 0x000200F8 : { + PROVIDE(_start = .); + KEEP(*(.text.start)) + *(.text.start) + } > FLASH + + /* code */ + .text : { + /* regular code */ + *(.text*) + /* gcc voodoo */ + *(.glue_7t) *(.glue_7) *(.vfp11_veneer) *(.v4_bx) + } > FLASH + PROVIDE(_text_start = ADDR(.text)); + PROVIDE(_text_end = ADDR(.text) + SIZEOF(.text)); + + /* constructor pointers */ + .ctors : { + /* ctor count */ + LONG(SIZEOF(.ctors) / 4 - 2) + /* ctor pointers */ + KEEP(*(SORT(.ctors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_ctor_start = LOADADDR(.ctors)); + PROVIDE(_ctor_end = LOADADDR(.ctors) + SIZEOF(.ctors)); + + /* destructor pointers */ + .dtors : { + /* dtor count */ + LONG(SIZEOF(.dtors) / 4 - 2) + /* dtor pointers */ + KEEP(*(SORT(.dtors))) + /* end of list */ + LONG(0) + } > FLASH + PROVIDE(_dtor_start = LOADADDR(.dtors)); + PROVIDE(_dtor_end = LOADADDR(.dtors) + SIZEOF(.dtors)); + + /* read-only data */ + .rodata : { + *(.rodata*) + } > FLASH + PROVIDE(_rodata_start = ADDR(.rodata)); + PROVIDE(_rodata_end = ADDR(.rodata) + SIZEOF(.rodata)); + + /* pic offset tables */ + .got : { + . = ALIGN(4); + *(.got) + *(.got.plt) *(.igot.plt) *(.got) *(.igot) + . = ALIGN(4); + } > FLASH + PROVIDE(_got_start = ADDR(.got)); + PROVIDE(_got_end = ADDR(.got) + SIZEOF(.got)); + + /* reserved ram */ + .compal.reservedram 0x800000 (NOLOAD) : { + . = 0xff; + } > IRAM + + /* initialized data */ + .data : AT (LOADADDR(.got) + SIZEOF(.got)) { + . = ALIGN(4); + *(.data) + . = ALIGN(4); + } > IRAM + PROVIDE(__data_start = LOADADDR(.data)); + PROVIDE(__data_end = LOADADDR(.data) + SIZEOF(.data)); + PROVIDE(_data_start = ADDR(.data)); + PROVIDE(_data_end = ADDR(.data) + SIZEOF(.data)); + + /* ram code */ + .ramtext : AT (LOADADDR(.data) + SIZEOF(.data)) { + . = ALIGN(4); + *(.ramtext) + . = ALIGN(4); + } > IRAM + PROVIDE(__ramtext_start = LOADADDR(.ramtext)); + PROVIDE(__ramtext_end = LOADADDR(.ramtext) + SIZEOF(.ramtext)); + PROVIDE(_ramtext_start = ADDR(.ramtext)); + PROVIDE(_ramtext_end = ADDR(.ramtext) + SIZEOF(.ramtext)); + + /* uninitialized data */ + .bss (NOLOAD) : { + . = ALIGN(4); + *(.bss) + . = ALIGN(4); + } > IRAM + PROVIDE(__bss_start = ADDR(.bss)); + PROVIDE(__bss_end = ADDR(.bss) + SIZEOF(.bss)); + PROVIDE(_bss_start = __bss_start); + PROVIDE(_bss_end = __bss_end); + + /* end of image */ + . = ALIGN(4); + _end = .; + PROVIDE(end = .); +} -- 1.7.3.4 --------------060605070405050509030107--

11 years, 3 months

1
0
0 0

[PATCH] Fix: Correctly handle return value of msgb_pull()

by Andreas Eversberg

Now it is possible to use osmoload again to flash. Flashing was successfully tested with c123 and c155. --- src/host/osmocon/osmoload.c | 2 +- src/target/firmware/apps/loader/main.c | 7 +++++-- src/target/firmware/apps/loader_mtk/main.c | 4 ++-- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/host/osmocon/osmoload.c b/src/host/osmocon/osmoload.c index 9b64935..e83f98a 100644 --- a/src/host/osmocon/osmoload.c +++ b/src/host/osmocon/osmoload.c @@ -307,7 +307,7 @@ loader_handle_reply(struct msgb *msg) { length = msgb_pull_u8(msg); crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, length); + data = msgb_pull(msg, length) - length; break; case LOADER_MEM_WRITE: length = msgb_pull_u8(msg); diff --git a/src/target/firmware/apps/loader/main.c b/src/target/firmware/apps/loader/main.c index 50a39dd..fd07d0f 100644 --- a/src/target/firmware/apps/loader/main.c +++ b/src/target/firmware/apps/loader/main.c @@ -273,7 +273,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -391,7 +391,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) chip = msgb_pull_u8(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -439,6 +439,9 @@ static void key_handler(enum key_codes code, enum key_states state) puts("Resetting due to keypress.\n"); device_reset(); break; + case KEY_MENU: + device_jump((void *)0x10000); + break; default: break; } diff --git a/src/target/firmware/apps/loader_mtk/main.c b/src/target/firmware/apps/loader_mtk/main.c index 7748dc4..3a12d27 100644 --- a/src/target/firmware/apps/loader_mtk/main.c +++ b/src/target/firmware/apps/loader_mtk/main.c @@ -213,7 +213,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) crc = msgb_pull_u16(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); @@ -331,7 +331,7 @@ static void cmd_handler(uint8_t dlci, struct msgb *msg) chip = msgb_pull_u8(msg); address = msgb_pull_u32(msg); - data = msgb_pull(msg, nbytes); + data = msgb_pull(msg, nbytes) - nbytes; mycrc = osmo_crc16(0, data, nbytes); -- 1.7.3.4 --------------060605070405050509030107 Content-Type: text/plain; name="0001-Generate-Compal-E99-binaries-for-loader-and-flash-lo.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-Generate-Compal-E99-binaries-for-loader-and-flash-lo.pa"; filename*1="tch"

11 years, 3 months

1
0
0 0

baseband-devel unsubscribe notification

by mailman-bounces＠lists.osmocom.org

osmocom(a)slewe.com has been removed from baseband-devel.

11 years, 3 months

1
0
0 0

OsmoDevCon 2013 brainstorming

by Harald Welte

Hi all, as the year 2012 has already ended or will soon end depending on your timezone, it might be a good occasion to start thinking of an OsmoDevCon 2013. I personally percevied OsmoDevCon 2012 as a big success, and it was fun to bring everyone together. Generally, I prefer to keep the spirit of an invitation-only developer+contributor-only event of those involved in Osmocom. At the same time, I would consider it a good idea to add a one day user-conference to the schedule, where we try to get interested users up to speed with the various projects, possibly including some workshops and the like. So schedule-wise, I would suggest something like: * one day user conference * two day developer/contributor event * optionally: 1-2 "hacking days". The concept of "hacking days" has proven to be quite useful for the netfilter project in the past (Pablo and I can acknowledge to that fact). I'm not sure how many people would be able to spend even more days of their schedule, but even if it's a much smaller group it would still be useful, IMHO. I'd like you to 1) provide feedback on the ideas about the one-day user event and the hacking days 2) consider whether late march (like 2012) would be a good schedule again 3) what we can improve from the last event In terms of improvements, I so far have noted down: * larger venue needs to be found * complaints about the venue not having sufficient heating Venue-wise, I would again suggest to hold it in Berlin, as it's reasonbly well connected, has lots of low-cost flights to it, accomodation is not too expensive and holger/me/sysmocom can take care of local organization related activities. Hoewver, if somebody has a strong opinion against berlin _and_ is willing to organize it, I'm not completely against another venue. Regards and happy new year, 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)

11 years, 3 months

4
7
0 0

linking sdr trx with osmo-bts/openbsc

by jolly

hi thomas, i saw your work for your master of science. i must say: congratulations! it really brings both openbts and openbsc projects together. it allows to use both sdr and real bts together in one network. as shown at the chaos communication congress (29c3), sylvain presented a compal phone with firmware to turn it into a trx for openbts. with your code, it is possible to use it with openbsc. this is something i aimed at too. i like to know if your work is (only) a proof of concept or something that could be used in a productive environment. i would help to review the changes to osmo-bts and help to get them merged to the current master branch. iirc, there are just some fixes and minor issues to solve. i already had planed a similar approach: but instead of using source from openbts, i wanted to do scheduling and coding/fec inside osmo-bts. code from libosmocore could be used for that. instead of using the device to the femto-dsp as an interface, i wanted to add the trx manager's udp interface to osmo-bts code. this way it would not require an additional process to run a trx with osmo-bts. special things regarding to the trx could be configured with the osmo-bts' config. as some guys at the 29c3 might have noticed, i was a little shocked when i read about your work. i was highly motivated to do a work that i found it was already done, so my motivation dropped to zero. i would like to apologize for my bad mood at the congress. best regards, andreas

11 years, 3 months

2
1
0 0

[PATCH] Custom range in cell_log

by Dario Lombardo

Hi guys Please find attached a patch to cell_log that allows a user to specify a custom frequency range instead of the standard one. In the past I've done the same job changing the code by hand and recompiling, but a command line switch is more feasible. This is useful when one wants to monitor a subset of arfcns (like in GSM900) or even a single one. Any comment appreciated. Dario.

11 years, 3 months

2
3
0 0

[PATCH] l23 sysinfo: defer SI4 CBCH mobile allocation until SI1 is received

by Alex Badea

When parsing SI4, there's a check and a log message saying that CBCH MA is ignored until SI1 is received. Then the MA is decoded anyway -- incorrectly -- such that it remains incorrect even after receiving the next SI1. Fix that with an "else". Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- src/host/layer23/src/common/sysinfo.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/host/layer23/src/common/sysinfo.c b/src/host/layer23/src/common/sysinfo.c index 2816c26..b42bd65 100644 --- a/src/host/layer23/src/common/sysinfo.c +++ b/src/host/layer23/src/common/sysinfo.c @@ -753,6 +753,7 @@ short_read: LOGP(DRR, LOGL_NOTICE, "Ignoring CBCH allocation of " "SYSTEM INFORMATION 4 until SI 1 is " "received.\n"); + } else { gsm48_decode_mobile_alloc(s->freq, data + 2, data[1], s->hopping, &s->hopp_len, 1); } -- 1.7.0.4

11 years, 4 months

2
1
0 0

Potential bug / problematic code in gsm411_rx_rl_data()

by Bhaskar11

In gsm411_sms.c the function gsm411_rx_rl_data receives "struct gsm48_hdr *gh" as input then in very first line typecasts the pointer to "struct gsm411_rp_hdr *rp_data" to access its "data" field. struct gsm411_rp_hdr *rp_data = (struct gsm411_rp_hdr*)&gh->data; But the two header structures have their "data" fields offset by one byte as in: struct gsm411_rp_hdr { > uint8_t len; > uint8_t msg_type; > uint8_t msg_ref; > uint8_t data[0]; > } __attribute__ ((packed)); > > struct gsm48_hdr { > uint8_t proto_discr; > uint8_t msg_type; > uint8_t data[0]; > } __attribute__((packed)); Obviously this displacement has been compensated for elsewhere in the code as the application works. But this seems to be inadvertent. And if it is deliberate, it is risky programming practice and could create problems later on. Request you to correct and update suitably. Thanks. B.

11 years, 4 months

2
1
0 0

Re: 29c3 youtube video

by Luca Bongiorni

I perfectly understand and agree about being reluctant to publish code that could be used for malicious purposes. I was talking more about what Harald suggested: a public/private git repo related with Layers implementation into the MS. Cheers, Luca > Currently there is no commercial activity going on. and tool mostly contain testing tools like Multiple IMSI Detach .Identity impersonation , channel hijacking like one presented in this 29C3. Channel DOS. more issue is if we publish such tools we might get in trouble from Government and also from telecom Operator for creating such tools. for same purpose we didnt published those tools. its more like publishing complete sniffing app for GSM with all codec support. > > currently we shall publish l1 l2 l3 app on target code soon when code cleaning will be completed. but dont get time as code is having multiple changes and uses library from different osmocom git hosted locally. > > > about publishing tools and research papers we shall do it after total research is complete. > > and reason that its taking too much time is am single person who can do technical work and coding rest team is more on core telecom network security. > > thats major issue in completing research . > > > On Wed, Jan 2, 2013 at 10:07 AM, <luca.bongiorni1(a)studenti.unimi.it> wrote: > So, if I may ask, since you are NOT having anykind of commercial activity related with osmocom's tools and is more than one year that you are asking for technical explanations over this ml/irc... Why u didn't publish yet the sources/results of your researches into a public repo as Harald suggested? > > Cheers, > Luca > Sent from my Fuffaphone® > From: Akib Sayyed <akibsayyed(a)gmail.com> > Sender: baseband-devel-bounces(a)lists.osmocom.org > Date: Wed, 02 Jan 2013 08:36:46 +0300 > To: Luca Bongiorni<luca.bongiorni1(a)studenti.unimi.it> > Cc: <baseband-devel(a)lists.osmocom.org>; Harald Welte<laforge(a)gnumonks.org> > Subject: Re: 29c3 youtube video > > Damn typo mistake > On Jan 2, 2013 8:35 AM, "Akib Sayyed" <akibsayyed(a)gmail.com> wrote: > > > > Currently we are not in production stage. > > We are more focused on buying own stack or buying chipset with compatible stack as there is no gprs/edge/3g suppprt in osmocom. > > Our first tool was based on osmocom but we are not in production. > > > > On Jan 2, 2013 12:12 AM, "Luca Bongiorni" <luca.bongiorni1(a)studenti.unimi.it> wrote: > >> > >> Hey all, > >> actually is "interesting" his web site. > >> > >> Since it seems a commercial website*: > >> > >> * " Matrix Shell developed own GSM penetration testing tool.This tool is comprised of hardware unit and a laptop.it can perform various test on network using custom firmware. > >> Using this too tester can identify state in which end user is getting service in terms of security." > >> > >> * "We provide following services. > >> GSM Network Penetration Testing > >> Matrixshell have developed a tool that can be used for testing attack vectors from users point of view. That is attacks that can be carried out by using modified handsets which may cause misusing identity of GSM subscriber , mass cellphone cell phone switch off ,denial of service of subscriber etc. Such vulnerability may cause loss in reputation of provider. > >> We can find out such issues using our own tools. Our tools comprised of UM interface hardware and a laptop communicating with UM interface. This tool can run different tests on network like: Checking encryption type, Authentication bypass, Wrong way of TMSI assignment by network, Identity impersonating." > >> > >> I am wondering how his software tools are dealing with Osmocom's licenses. > >> > >> Cheers, > >> Luca > >> > >> > are you sharing your current progress in a public git repository? If > >> > not, I'd like to strongly encourage you to do so. I can also give you > >> > commit access so you can push to a private branch on git.osmocom.org, if you > >> > prefer that. > >> > > >> > -- > >> > - 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) > >> > > >> > >> > > > > -- > Akib Sayyed > Matrix-Shell > akibsayyed(a)gmail.com > akibsayyed(a)matrixshell.com > Mob:- +91-966-514-2243 >

11 years, 4 months

1
0
0 0

29c3 youtube video

by Vic Delorge

this is the 29c3 talk about GSM DOS and SMS sniffing . awesome work osmocom team. layer 1,2,3 now runs all on the phone :) http://youtu.be/a1iZV2nl28A

11 years, 4 months

6
10
0 0

Filter replacement

by Clemens Gruber

Hi, yesterday I fucked up the second C123 while trying to replace the filters, so I decided to buy one model from Sysmocom (with the filters already replaced), but due to too many orders they do not offer this service anymore. Is somebody on this list able and willing to sell me one C123 with the filter kit already built in (and tested)? I'd really appreciate if someone, who is more experienced in SMD soldering than me, could help me out. If so, please contact me at: clemensgru(a)gmail.com I live in Austria, so delivery from Europe should not be a problem. Thanks. Clemens

11 years, 4 months

2
1
0 0

Possible fix for problem -- "l1ctl.c:114 FBSB RESP: result=255"

by Bhaskar11

When I run ccch_scan on a regular network, every once in a while, at random I find the app stops sniffing with the error: > <000c> l1ctl.c:291 BURST IND: @(1428545 = 1077/01/35) (-105 dBm, SNR 3, > SACCH) > <000c> l1ctl.c:114 FBSB RESP: result=255 At the same time Osmocon gives a message like the following: > => DSP reports FB in bit that is 1031487569 bits in the future?!? > Synchronize_TDMA > LOST 2313! The problems seems therefore to emerge from some corruption of data in reception which causes l1ctl.c to dispatch the S_L1CTL_FBSB_ERR signal.

11 years, 4 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel January 2013