baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

MT6235/6140 and MT6516?
by Duane Lew 09 Dec '10

09 Dec '10

Dear Members, I incidentally see your development of linux drivers for MT6235/6140 chipset(the sciphone G2), and wanna share my 50 cents: The year 2009 released AP+BB monolithic chip MT6156 from mediatek is an ARM9 AP + ARM7 BB (the old MT6235 is ARM9 AP, MT6140 is ARM7 BB), considering the timeline of mediatek processors, it should be conjectured that MT6516 is a combination of these two chips. They already have Windows mobile 6.5 drivers mature for MT6516, and they have android drivers (not only driver but the whole system image), which might be an important referenece for developing MT6235 linux drivers. So I believe it's a good idea to ask MTK for its MT6516 linux driver and see what can be ported. Best for all, Duane

2 1

[PATCH] protocol: typofix for gsm_03_41.h
by Hermann Gausterer 08 Dec '10

08 Dec '10

On Tue, Dec 07, 2010 at 08:16:06PM +0200, Alex Badea wrote: > On 12/07/2010 06:36 PM, Hermann Gausterer wrote: > >Small typo in the second Serial Number Octet > > > >Signed-off-by: Hermann Gausterer<libosmocore-2010(a)mrq1.org> > > Good catch, thanks! > > You should send this patch to baseband-devel(a)lists.osmocom.org such > that one of the maintainers can apply it. > > Thanks, > Alex

1 0

Sciphone G2 (MT6235) status
by Marcin.Mielczarczyk＠tieto.com 05 Dec '10

05 Dec '10

Hi list, Last days I was focused on getting self-built code running from NAND memory and finally I got it working. You can find short demo which actually covers all the functionality which is currently working on Sciphone: http://www.youtube.com/watch?v=w_Iwsckm7Ko Here is the list of functionalities which are already working: * NAND memory driver with HW ECC control and MTK's ECC layout (ECC layout is important for loading SPL, creating dumps of firmware and restoring it). NAND driver also supports all the NAND memories found so far on Sciphone G2 (small page and large page). * SD/MMC card support * LCD driver (automatically detects LCD controller, so far identified two different LCD controllers mounted in G2: ILI9331 and ILI9325) * tool for creating bootable image from given binary file (should work on all MT62xx chips). It doesn't need to be SPL (from U-Boot), it can be self-built binary which will be run by IPL on the phone (not bigger than 64kB). * automatic detection of RAM memory in SPL (two configurations checked) - this will be added by Steve to osmocon loader as well * BBT and ENV can be saved in NAND (BBT in NAND is disabled by default, as deletes last two NAND blocks, and most people are running from RAM) I also updated wiki with informations about new features added: http://bb.osmocom.org/trac/wiki/SciphoneDreamG2 Open issues: * LCD controller is using the same data lines as NFI (NAND) controller. Currently it's not possible to use NAND when LCD is enabled. * vibrator in SPL code - vibrator will be turned on in SPL when it'll start reading NAND and turned off when it'll finish, thanks to that user will know that SPL code has started (short code which doesn't change SPL size). * boot process from NAND has been tested only on small page NAND device - I'll create dump of my second phone and try this process on large page NAND device as well I recommend to create full NAND dump before playing with new software. There is already driver for NAND running and you can erase/write NAND easily by mistake. I turned on define CONFIG_ENV_IS_IN_NAND, which will not erase/write NAND at start, but when you execute "saveenv" command it'll do so. Please, make NAND dump first. The problem with NAND dump is that I haven't found built-in functionality in U-Boot that sends dump of RAM memory (where NAND will be read) to PC/SD card. Dump also has to be created in chunks, as there is less RAM memory than NAND. I'm planning to create dump/restore commands which will save/restore dumps using SD card, but I didn't start it yet. Currently the easiest way is to create dump in FlashTool. I checked that restoring of phone using dump created in FlashTool works, so going back to previous firmware is possible. Unfortunatelly code for LCD driver is not yet in git as my coleague didn't manage to finish it today. Hopefully it'll be available during weekend or beginning next week. Now I'm going to switch to Linux kernel side and start writing drivers there... Other good new is that Andrew has reported last week that he successfully run our code on E1000 chinese phone which is also based on MT6235. There was no need to make any changes. Here is how E1000 phone looks like: http://triray.en.made-in-china.com/product/kbYJeomynHhs/China-N97-WiFi-Java… BR, Marcin

3 2

Free Software GSM Talk in Berlin on Dec. 9th
by Ali Gündüz 03 Dec '10

03 Dec '10

Hello all, I'm going to be giving a presentation about free software GSM implementations at the FSFE's Berlin meeting on December 9th, 2010. It will be very elementary and newcomer-friendly. I'm planning to go over OsmocomBB, OpenBTS and OpenBSC, and discuss their security and practical implications. The talk will start at 19:30 in Newthinking Store Tucholskystr. 48, 10117 Berlin. You can find more about it on http://aligunduz.org/blog/free_gsm_talk_next_week.html Considering I'm not an expert on GSM myself, it would be nice to have people more familiar with it in attendance. Ali Gündüz

1 0

Re: bb-osmocom: sim.c
by Dieter Spaar 30 Nov '10

30 Nov '10

Hello Ton, On Sun, 28 Nov 2010 23:09:59 +0100, "Ton Slewe" <ton.slewe(a)gmail.com> wrote: > > I have tracked down the error to sim.c. I tried to push it to the GIT > repository which does not seem to work (credentials?). Maybe somebody > can patch it in their version and then push it. Or otherwise please > point me in the direction to get it fixed in the repository. You have take the version from Sylvain's testing branch (Sylvain, please correct me if the extended SIM driver is no longer there) ? I ask because there is already a fixed version with several improvments which is supposed to work in this branch (at least for those SIM task required to access a real network). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 2

bb-osmocom: sim.c
by Ton Slewe 29 Nov '10

29 Nov '10

I have trying the osmocom apps today (firmware). One of the apps, simtest, did not seem to work well. I have tracked down the error to sim.c. I tried to push it to the GIT repository which does not seem to work (credentials?). Maybe somebody can patch it in their version and then push it. Or otherwise please point me in the direction to get it fixed in the repository. Some of the variables on top of the file are not declared as volatile (they should be because they are modified in an Interrupt Service Routine). I changed all the variables on top of the file into volatile: static volatile int sim_rx_character_count = 0; /* How many bytes have been received by calypso_sim_receive() */ static volatile int sim_tx_character_count = 0; /* How many bytes have been transmitted by calypso_sim_transmit() */ static volatile int sim_tx_character_length = 0; /* How many bytes have to be transmitted by calypso_sim_transmit() */ static volatile uint8_t *rx_buffer = 0; /* RX-Buffer that is issued by calypso_sim_receive() */ static volatile uint8_t *tx_buffer = 0; /* TX-Buffer that is issued by calypso_sim_transmit() */ Now simtest is working as expected. Kind regards, Ton

2 1

[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 29 Nov '10

29 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel