baseband-devel November 2010

baseband-devel@lists.osmocom.org

35 participants
30 discussions

[PATCH 0/3] layer23 SMSCB support
by Alex Badea 29 Nov '10

29 Nov '10

Hi, This patch series adds layer23 support for receiving SMSCB messages. Patches 1/3 and 2/3 add common layer2 code for reassembling blocks and sending them up to L3. Patch 3/3 is an addition to cell_log for logging cell-info-display-type SMSCB messages, if available. This series requires patches[1][2][3] to libosmocore protocol headers. Cheers, Alex [1] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000827.html [2] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000830.html [3] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000831.html Alex Badea (3): layer23: introduce SMSCB framework layer23 smscb: reassemble blocks and pass them up to L3 layer23 cell_log: log CBCH cell info src/host/layer23/include/osmocom/bb/common/lapdm.h | 2 + src/host/layer23/include/osmocom/bb/common/smscb.h | 28 +++ src/host/layer23/src/common/Makefile.am | 2 +- src/host/layer23/src/common/lapdm.c | 7 + src/host/layer23/src/common/smscb.c | 211 ++++++++++++++++++++ src/host/layer23/src/misc/cell_log.c | 107 ++++++++++- 6 files changed, 354 insertions(+), 3 deletions(-) create mode 100644 src/host/layer23/include/osmocom/bb/common/smscb.h create mode 100644 src/host/layer23/src/common/smscb.c

2 8

[PATCH libosmocore] protocol: introduce gsm_03_41.h
by Alex Badea 28 Nov '10

28 Nov '10

This currently contains definitions for the BTS->MS SMSCB message. Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- include/osmocore/protocol/gsm_03_41.h | 34 +++++++++++++++++++++++++++++++++ 1 files changed, 34 insertions(+), 0 deletions(-) create mode 100644 include/osmocore/protocol/gsm_03_41.h diff --git a/include/osmocore/protocol/gsm_03_41.h b/include/osmocore/protocol/gsm_03_41.h new file mode 100644 index 0000000..250d667 --- /dev/null +++ b/include/osmocore/protocol/gsm_03_41.h @@ -0,0 +1,34 @@ +#ifndef PROTO_GSM_03_41_H +#define PROTO_GSM_03_41_H + +#include <stdint.h> + +/* GSM TS 03.41 definitions */ + +/* Chapter 9.3.2 */ +struct gsm341_ms_message { + struct { + uint8_t code_hi:6; + uint8_t gs:2; + uint8_t update:2; + uint8_t code_lo:6; + } serial; + uint16_t msg_id; + struct { + uint8_t language:4; + uint8_t group:4; + } dcs; + struct { + uint8_t total:4; + uint8_t current:4; + } page; + uint8_t data[0]; +} __attribute__((packed)); + +/* Section 9.3.2.1 - Geographical Scope */ +#define GSM341_GS_CELL_WIDE_IMMED 0 +#define GSM341_GS_PLMN_WIDE 1 +#define GSM341_GS_LA_WIDE 2 +#define GSM341_GS_CELL_WIDE 3 + +#endif /* PROTO_GSM_03_41_H */ -- 1.7.0.4

2 1

[RFC][PATCH] layer1: clear dedicated mode on FULL reset
by Alex Badea 28 Nov '10

28 Nov '10

This is particularly useful if a layer23 app exists uncleanly; the next app would not be able to synchronize at all. Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- More to the point, I'd get stuck on the CBCH ;) I'm not sure if this would negatively impact other FULL reset use-cases, hence the RFC. Thanks, Alex src/target/firmware/layer1/l23_api.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c index 19838f1..82b86d7 100644 --- a/src/target/firmware/layer1/l23_api.c +++ b/src/target/firmware/layer1/l23_api.c @@ -381,6 +381,7 @@ static void l1ctl_rx_reset_req(struct msgb *msg) switch (reset_req->type) { case L1CTL_RES_T_FULL: printf("L1CTL_RESET_REQ: FULL!\n"); + l1s.dedicated.type = GSM_DCHAN_NONE; l1s_reset(); l1s_reset_hw(); audio_set_enabled(0); -- 1.7.0.4

2 1

[PATCH libosmocore] gsm_08_58: add struct and constants for RSL_IE_CB_CMD_TYPE
by Alex Badea 28 Nov '10

28 Nov '10

Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- include/osmocore/protocol/gsm_08_58.h | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-) diff --git a/include/osmocore/protocol/gsm_08_58.h b/include/osmocore/protocol/gsm_08_58.h index 5fe332e..74a4083 100644 --- a/include/osmocore/protocol/gsm_08_58.h +++ b/include/osmocore/protocol/gsm_08_58.h @@ -441,6 +441,27 @@ struct rsl_ie_chan_ident { #define RSL_CHANNEED_TCH_F 0x02 #define RSL_CHANNEED_TCH_ForH 0x03 +/* Chapter 9.3.45 */ +struct rsl_ie_cb_cmd_type { + uint8_t last_block:2; + uint8_t spare:1; + uint8_t def_bcast:1; + uint8_t command:4; +} __attribute__ ((packed)); +/* ->command */ +#define RSL_CB_CMD_TYPE_NORMAL 0x00 +#define RSL_CB_CMD_TYPE_SCHEDULE 0x08 +#define RSL_CB_CMD_TYPE_DEFAULT 0x0e +#define RSL_CB_CMD_TYPE_NULL 0x0f +/* ->def_bcast */ +#define RSL_CB_CMD_DEFBCAST_NORMAL 0 +#define RSL_CB_CMD_DEFBCAST_NULL 1 +/* ->last_block */ +#define RSL_CB_CMD_LASTBLOCK_4 0 +#define RSL_CB_CMD_LASTBLOCK_1 1 +#define RSL_CB_CMD_LASTBLOCK_2 2 +#define RSL_CB_CMD_LASTBLOCK_3 3 + /* Chapter 3.3.2.3 Brocast control channel */ /* CCCH-CONF, NC is not combined */ #define RSL_BCCH_CCCH_CONF_1_NC 0x00 -- 1.7.0.4

1 0

Linux + u-boot port to MT6235 (E1000 phone)
by Andrew 28 Nov '10

28 Nov '10

Hello, everyone. I've just stumbled on the post in maillists following a news tip on one of the linux forums. I myself have two MTK-based devices - E1000 (MTK6335) and Nokla TV E71 (MTK6225) and have done some research some time ago. However, from what I heard there was no MMU there (even on 35), so I didn't study the possibility to start linux there. To make the story short, I'm now trying to run all the good stuff on my phone and cannot get past the loader. While now I cannot get past the osmocon part and upload ramloader: When I hook up my phone I get ---cut--- ~~~ Welcome to MTK Bootloader V005 (since 2005) ~~~ **===================================================** Main=0x3, Tmp=0x0, Fota=0x0, Bak=0x0 Number of image segments = 4 ..[0] Image size = 352Bytes, start addr. =0x428 ..[1] Image size = 4516152Bytes, start addr. =0x0 ..[2] Image size = 12494144Bytes, start addr. =0x452938 ..[3] Image size = 10340676Bytes, start addr. =-0xe000000 Start loading image... ....................................................................NFB image index: 1... Bye bye bootloader, jump to=0x0 ---cut--- And this comes out at 115200 baud. Trying osmocon: osmocon looks like it sends the beacon - but nothing happens - the phone just turns on. (I do hold the power button, but that just doesn't help) I altered the sources and changed initial baudrate to 115200, but nothing still. I have not yet figured out jtag pins out there, and I guess I will hook my old atmega-based jtag scanner only if there would be not other way to make serial method work. I think I can be of some help, since I have the hardware and some experience in kernel hacking. But I guess I cannot be of any use in the gsm part since I just don't know that stuff. That's it, And thanks for starting the porting process.

1 0

[PATCH libosmocore] gsm_04_12: fix 04.13 typos
by Alex Badea 28 Nov '10

28 Nov '10

There are two occurrences of "413" in the 04.12 header file. These are probably typos; correct them to "412". Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com> --- include/osmocore/protocol/gsm_04_12.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/osmocore/protocol/gsm_04_12.h b/include/osmocore/protocol/gsm_04_12.h index bd9e088..9b1538a 100644 --- a/include/osmocore/protocol/gsm_04_12.h +++ b/include/osmocore/protocol/gsm_04_12.h @@ -10,7 +10,7 @@ #define GSM412_SEQ_TRD_BLOCK 0x2 #define GSM412_SEQ_FTH_BLOCK 0x3 #define GSM412_SEQ_FST_SCHED_BLOCK 0x8 -#define GSM413_SEQ_NULL_MSG 0xf +#define GSM412_SEQ_NULL_MSG 0xf struct gsm412_block_type { uint8_t seq_nr : 4, @@ -19,7 +19,7 @@ struct gsm412_block_type { spare : 1; } __attribute__((packed)); -struct gsm413_sched_msg { +struct gsm412_sched_msg { uint8_t beg_slot_nr : 6, type : 2; uint8_t end_slot_nr : 6, -- 1.7.0.4

1 0

Fresh people's build problem
by chenyu xu 26 Nov '10

26 Nov '10

Hello guys: In order to participate in OSMOCOM-BB project, I have buy the old moto C118 and made the T191 cable by myself. But when I run "make" in ****/src/osmocom-bb/src directory, the error info is below: alexander@Foundation:~/src/osmocom-bb/src$ make cd shared/libosmocore/build-target && ../configure \ --host=arm-elf-linux --disable-vty --enable-panic-infloop \ --disable-shared --disable-talloc --disable-tests \ CC="arm-elf-gcc" CFLAGS="-Os -ffunction-sections -I../../../../target/firmware/include" configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for arm-elf-linux-strip... no checking for strip... strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make sets $(MAKE)... (cached) yes checking for arm-elf-linux-gcc... arm-elf-gcc checking whether the C compiler works... no configure: error: in `/home/alexander/src/osmocom-bb/src/shared/libosmocore/build-target': configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [shared/libosmocore/build-target/Makefile] Error 77 After my investigating on this issue, I think I must build my own arm-elf-linux-gcc, am I right? I want to know how the experienced person handle this scenario? Please answer my questions! Thanks! alexander Xu

2 1

[PATCH 0/2] Small CBCH fixes, and playground
by Alex Badea 23 Nov '10

23 Nov '10

Hi all, I've been looking at receiving CBCH traffic (where I live, 226-01 broadcasts a geographical area name with each cell). Patches 1/1 and 1/2 are small fixes for the layer23 system information parser, for storing the required CBCH channel description and mobile allocation info. I'll also reply with WIP patches for a small CBCH sniffing l23 app, and for decoding CBCH in Wireshark. The latter is a quick hack job, as it only decodes the first block, and it's bodged onto the LAPDm dissector. Also a question: what would be the best place to integrate CBCH handling into osmocom-bb? I'm guessing host/layer23/src/common/lapdm.c would handle block reassembly, then send CBS frames up the stack. Would any existing messages fit the bill (RSL_MT_UNIT_DATA_IND?) or should we add a new one? Cheers, Alex Alex Badea (2): layer23 sysinfo: store chan_nr when decoding CBCH Channel Description layer23 sysinfo: fix parsing of CBCH Mobile Allocation src/host/layer23/src/common/sysinfo.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)

5 8

simtrac hw
by ml＠mail.tsaitgaist.info 22 Nov '10

22 Nov '10

Hi, Because I'm also deceived by the rebelSIM, I was programming a sim sniffer using an atmega, by detecting the clock freq. manualy. Until Harald announced his SIMtrac. His solution is way easier, and more reliable. This is why I've now done a hw design for it. I don't know if it's the right mailing list, but it seemed to be the best. I'm not a electronic expert, I just follow datasheets and examples. I used the openPCD schema to do this one. There is : - the AT91SAM7SXXX - 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual size, as on the rebelSIM - 1 SC port (IN) to connect the SIM for the phone (I would use the ones from rebelSIM) - 1 SC port (OUT) to be able to use the signal using external HW - the sam-ba port to be able to flash it here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe please tell me if there is something wrong, or needs some improvement. I will design the PCB shortly. thanks, tsaitgaist

8 23

AW: Announcing Osmocom SIMtrace
by Andreas.Eversberg 19 Nov '10

19 Nov '10

> As none of my projects is complete without wireshark integration, > SIMtrace abuses the GSMTAP format to feed messages into wireshark. A > simplistic wireshark dissector for the GSM TS 11.11 APDUs is included, > and it is expected to become much more complete in the fuutre (USIM support, > parsing of file contents, etc.) hi laforge, cool project! i think it can be usefull to debugging the sim client/reader of osmocom-bb. as DATA_IND/DATA_REQ is already tapped at layer23/src/common/l1ctl.c, it would be cool if SIM_IND/SIM_REQ will be tapped for wireshark too. regards, andreas

4 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel November 2010