- baseband-devel - lists.osmocom.org

[ADM] Please try to avoid merges in the git tree

by Harald Welte

Hi all, this is just a general request to everyone with git commit access on the OpenBSC / Osmocom repositories. I would appreciate to restrict the use of 'git merge' to the absolute minimum neccessarry, as it makes the commitlog and timeline much harder to understand. If you're working on some private branch on a particular feature, please rebase that private branch on current master before pushing the changes. Thanks! -- - 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)

13 years, 6 months

2
1
0 0

[PATCH] connect's addrlen should be sizeof(local), not the contained path's length. Permits layer23 to work on OS X.

by David Wilson

--- src/host/layer23/src/common/l1l2_interface.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/host/layer23/src/common/l1l2_interface.c b/src/host/layer23/src/common/l1l2_interface.c index e72b86e..08ef7be 100644 --- a/src/host/layer23/src/common/l1l2_interface.c +++ b/src/host/layer23/src/common/l1l2_interface.c @@ -118,9 +118,10 @@ int layer2_open(struct osmocom_ms *ms, const char *socket_path) local.sun_path[sizeof(local.sun_path) - 1] = '\0'; rc = connect(ms->l2_wq.bfd.fd, (struct sockaddr *) &local, - sizeof(local.sun_family) + strlen(local.sun_path)); + sizeof(local)); if (rc < 0) { - fprintf(stderr, "Failed to connect to '%s'.\n", local.sun_path); + fprintf(stderr, "Failed to connect to '%s': %s\n", local.sun_path, + strerror(errno)); close(ms->l2_wq.bfd.fd); return rc; } -- 1.7.3.2 -- Computers are useless. They can only give you answers. -- Pablo Picasso

13 years, 6 months

5
6
0 0

MT6235/6140 and MT6516?

by Duane Lew

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

13 years, 6 months

2
1
0 0

[PATCH] protocol: typofix for gsm_03_41.h

by Hermann Gausterer

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

13 years, 6 months

1
0
0 0

Sciphone G2 (MT6235) status

by Marcin.Mielczarczyk＠tieto.com

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

13 years, 6 months

3
2
0 0

Free Software GSM Talk in Berlin on Dec. 9th

by Ali Gündüz

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

13 years, 6 months

1
0
0 0

Re: bb-osmocom: sim.c

by Dieter Spaar

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

13 years, 6 months

3
2
0 0

bb-osmocom: sim.c

by Ton Slewe

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

13 years, 6 months

2
1
0 0

[PATCH 0/3] layer23 SMSCB support

by Alex Badea

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

13 years, 6 months

2
8
0 0

[PATCH libosmocore] protocol: introduce gsm_03_41.h

by Alex Badea

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

13 years, 6 months

2
1
0 0

[RFC][PATCH] layer1: clear dedicated mode on FULL reset

by Alex Badea

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

13 years, 7 months

2
1
0 0

[PATCH libosmocore] gsm_08_58: add struct and constants for RSL_IE_CB_CMD_TYPE

by Alex Badea

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

13 years, 7 months

1
0
0 0

Linux + u-boot port to MT6235 (E1000 phone)

by Andrew

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.

13 years, 7 months

1
0
0 0

[PATCH libosmocore] gsm_04_12: fix 04.13 typos

by Alex Badea

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

13 years, 7 months

1
0
0 0

Fresh people's build problem

by chenyu xu

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

13 years, 7 months

2
1
0 0

[PATCH 0/2] Small CBCH fixes, and playground

by Alex Badea

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(-)

13 years, 7 months

5
8
0 0

simtrac hw

by ml＠mail.tsaitgaist.info

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

13 years, 7 months

8
23
0 0

AW: Announcing Osmocom SIMtrace

by Andreas.Eversberg

> 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

13 years, 7 months

4
4
0 0

Announcing Osmocom SIMtrace

by Harald Welte

Hi all! After what has become much more time than originally anticipated, I'm happy to announce the first developer version of Osmocom SIMtrace: http://bb.osmocom.org/trac/wiki/SIMtrace (project page) git://git.osmocom.org/simtrace.git (host software + wireshark) git://git.gnumonks.org/openpcd.git (firmware) You can use it to passively sniff the smart card interface between SIM and phone. It consists of some firmware for an AT91SAM7S USB-attached microcontroller, together with a host PC program that receives the APDUs from USB. 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.) What can you use it for? * Determine what is really going on between phone and sim * Debugging of SIM Application Toolkit (SAT) programs Why is it better than existing hardware like Season or the RebelSIM Scanner? * We do proper auto-bauding and support PPS, i.e. you can automatically see all communication on any SIM card interface * We support all clock rates / dividers as per the ISO 7816-3 spec Future plans: * In addition to passive tracing, implement SIM-card side interface in the hardware and have SIM/USIM simulator as host PC software. * Build custom board for it, with 1.8V SIM support 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)

13 years, 7 months

3
2
0 0

Re: Linux + u-boot port to MT6235

by Marcin Mielczarczyk

Hi, Finally I have running Linux on Sciphone G2. Code for U-Boot and Linux kernel can be found here: http://git.osmocom.org/gitweb?p=uboot-mt623x.git;a=summary http://git.osmocom.org/gitweb?p=linux-mt623x.git;a=summary To run U-Boot in RAM you can use osmocon loader for MTK. When U-Boot will start than you can load Linux kernel using serial port (U-Boot commands: loadb or loady). Default load address is set to 0x800000, so Linux kernel will be loaded there. To start executing Linux kernel type in following command: bootm 0x800000 After this command Linux kernel will be relocated, uncompressed and executed. After short time you should have working console in Linux. For testing purposes I prepared binaries which you can load and check that Linux works on your phone: http://downloads.qi-hardware.com/people/marcin/g2_uboot.bin http://downloads.qi-hardware.com/people/marcin/g2_uImage.bin uImage binary has already ramfs image built in, so you don't need any additional filesystem. These binaries were also tested by Steve Markgraf and keytwo, so it should work on most G2s. Today I was also able to load files from MMC card in U-Boot, so hopefully this functionality will be available very soon. Next step will be running UBoot and Linux from NAND, to make development more convenient. Recently we discovered that Sciphone G2 phones are sold with different memory configurations. So far we identified 3 types of memories: HY27XS08121M - 512Mb (64MB) NAND + 32MB RAM (http://hynix.com/datasheet/pdf/flash/HY27US(08_16)12(1_2)B%20Series(Rev0.5)…) HY27XA081G1M - 1Gb (128MB) NAND + 32MB RAM (http://hynix.com/datasheet/eng/nand/details/small_11_HY27US081G1M.jsp?menu1…) TC58NVG0S3AFT - 1Gb (128MB) NAND + 64MB RAM (http://www.datasheetcatalog.com/datasheets_pdf/T/C/5/8/TC58NVG0S3AFT.shtml) This has to be detected in osmocon loader and U-Boot. I write about it so, you'll be aware of it. When U-Boot starts it detects your memory configuration and shows you how much NAND and RAM you have. If it comes to status of work in progress, following drivers are under development: - NAND controller (U-Boot/Linux) - SD/MMC controller (U-Boot/Linux) - GPIO (Linux) - LCD (U-Boot/Linux) I saw that MT6140 (RF) is connected over I2C bus, so probably this driver will be next on the list. BR, Marcin

13 years, 7 months

1
0
0 0

Its posible that OsmocomBB work as a USRP?

by Hernani

Ok, first of all congratulation for this project... Ok, I understood that it wouldn´t work as USRP. But would it allow you to tune (or listen - sory don´t know the tecnical term in english) an especific ARFCN and time slot ? Hernani > Hi Harald > > Thanks for clarifying this confusion. I bought a motorola C123 on ebay > with RS232 data cable. When I arrive I'll try this fantastic software. > Thank you very much for your work, this world needs more people like > you > > On Sat, 6 Nov 2010 08:32:31 +0100, Harald Welte <laforge at gnumonks.org <https://lists.osmocom.org/mailman/listinfo/baseband-devel>> > wrote: >>* Hi Oscar, *>>* *>*> On Sat, Nov 06, 2010 at 03:02:37AM +0100, Oscar Soriano Riera wrote: *>>* *>>*> Its posible use *>>*> OsmocomBB on C123 for do task as a USRP ? or similar scanner ? *>>* *>*> No, I think you have some conceptual misunderstanding about radio *>*> technology in general. *>>* *>*> In your subject you ask if OsmocomBB can work as USRP: *>*> This is wrong, as OsmocomBB is a protocol stack and radio driver, and *>*> the USRP *>*> is hardware. How can some software work as hardware? *>>* *>*> In the body of your mail you ask if the C123 can act as USRP: *>*> No. The USRP is a wide-band software defined radio, and the *>*> Calypso/Iota/Rita *>*> design implements a more traditional narrow-band zero-if transceiver *>*> with a DSP *>*> in the baseband. *>>* *>*> Nevertheless, you can use both hardware design to receive and *>*> transmit GSM *>*> signals. But this is very far from what you ask by "one device *>*> working like *>*> the other" *

13 years, 7 months

2
1
0 0

[PATCH 0/4] Fixes for gta0x targets

by Alex Badea

Hi all, I've been trying to join the party with my OpenMoko GTA02, and I found that a few tweaks were required. Patch 1/4 was required to get the romloader to start, otherwise osmocon would only receive an occasional '\x00' character instead of the ident_cmd. It works perfectly with the beacon interval reduced to 13 mS, but I've made it configurable just in case other targets don't like it. Patches 2/4 and 3/4 are bugfixes for the calypso uart code. The LCR register ended up being clobbered, and this rendered the uart on my board silent. Finally, I'm using the GTA02 AP as the "host", communicating via the internal ttySAC0 UART. Patch 4/4 allowed me to cross-compile osmocon & friends on my x86 box with the AP ARM as the target. Now I can run, ./osmocon -m romload -p /dev/ttySAC0 -i 13 -d tr firmware/layer1.highram.bin while toggling power via, echo 0 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on echo 1 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on and get: OSMOCOM Layer 1 (revision osmocon_v0.0.0-696-ge801cee-modified) ====================================================================== Device ID code: 0xb496 Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Die ID code: e4942219e4949b52 ====================================================================== REG_DPLL=0x2413 CNTL_ARM_CLK=0xf0a1 CNTL_CLK=0xff91 CNTL_RST=0xfff3 CNTL_ARM_DIV=0xfff9 ====================================================================== Cheers, Alex Alex Badea (4): osmocon: make beacon interval configurable via cmdline target uart: fix preservation of LCR target uart: remove REG_OFFS() macro side-effect toplevel Makefile: accept arguments for host ./configure calls src/Makefile | 8 ++++---- src/host/osmocon/osmocon.c | 26 ++++++++++++++++---------- src/target/firmware/calypso/uart.c | 10 +++++----- 3 files changed, 25 insertions(+), 19 deletions(-)

13 years, 7 months

2
5
0 0

Sciphone Dream G2 WLan MT5921

by Heiko Stübner

Hi, Harald Welte wrote: > bluetooth or FM radio. The GSM RF transceiver is probably possible to > reverse engineer from the test mode + 3wire protocol sniffing, but wifi e.g. is > defnitely too complex to do a 100% reverse engineered driver for... while looking through the component listing on Wolgang's wiki page I recognized the MediaTek MT5921 WLan-chipset. This should be the same (or at least similar) chip built into the german Thalia/Bol/Buch.de Oyo ebook-reader (also released in France). The module is called mt5921sta_spi.ko and claims to be released under the GPL but until now no source release happened for any GPL component. The module is also contained in the firmware of the Booq Avant released in Spain (http://www.booqreaders.com/en/product_Avant) and possibly many more ebook-readers as these models seem to share their basic design. Heiko

13 years, 7 months

2
2
0 0

GSMTAP

by Marten Christophe

Hello All, I have a question regarding GSMTAP , If it is used for sending messages to wireshark only or it has some other significant, like communication between L2 and L3 or communication with layer1, as the uint8_t and uint16_t were widely used in source code Kind regards,

13 years, 7 months

2
1
0 0

application ./mobil

by Dev Purohit

Hello List, Ii'm facing problem when i'l trying to run ./mobil application i'm getting below error. if i need some USB or serial SIM reader, or should insert the sim in my MS itself thanks in advance for help. ========= Failed to connect to '/tmp/osmocom_sap'. <<<<<<<<< Failed during sap_open(), no SIM reader <000e> sim.c:1206 init SIM client <0005> gsm48_cc.c:61 init Call Control <0001> gsm48_rr.c:4944 init Radio Ressource process <0004> gsm48_mm.c:1220 init Mobility Management process <0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM. <0002> gsm322.c:3471 init PLMN process <0003> gsm322.c:3472 init Cell Selection process <0003> gsm322.c:3526 No stored BA list Failed to parse the config file: '/etc/osmocom/osmocom.cfg' Please check or create config file using: 'touch /etc/osmocom/osmocom.cfg' <<<<<<<< What Is the solution for this how i can do this ========== Regards, Dev

13 years, 7 months

2
4
0 0

Its posible that OsmocomBB work as a USRP?

by Oscar Soriano Riera

Hi everyone from Spain I have one question: Its posible use OsmocomBB on C123 for do task as a USRP ? or similar scanner ? Thanks for your BIG work ¡¡¡¡ congratulations

13 years, 7 months

2
2
0 0

problem starting out...please help

by Scott Weisman

Hi All, I now have a V171 phone and cable so I thought I might get started with this. I checked out the code and started make. Osmocon built with no problem, but I got this error next: 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... /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 `/mnt/site/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 Checking config.log I can see it chokes here: /usr/bin/arm-elf-ld: this linker was not configured to use sysroots collect2: ld returned 1 exit status I am running Arch Linux and have the packages cross-arm-elf-binutils and cross-arm-elf-gcc-base installed. Does anyone have any suggestions to fix this? Thanks!

13 years, 7 months

3
3
0 0

Re: osmocom on windows

by eisencah eisenach

:D Yup the timers too. That's why I would like to keep that piece of code as it is and move only the serial port handling elsewhere (a different thread I) --- On Thu, 10/21/10, Holger Hans Peter Freyther <holger(a)freyther.de> wrote: From: Holger Hans Peter Freyther <holger(a)freyther.de> Subject: Re: osmocom on windows To: baseband-devel(a)lists.osmocom.org Date: Thursday, October 21, 2010, 8:09 PM On 10/21/2010 07:00 PM, eisencah eisenach wrote: > Here's another one. Regarding the select mechanism (the one in select.c). > Other then the serial port and sockets is anything else registered there? > Cause I would like to keep sockets for communication after all (but the select > function will not work on windows for serial ports handles). So I would use a > different mechanism only for serial port scheduling. > Cheers, > Mihai. well.. we handle the timers with it too.

13 years, 7 months

2
2
0 0

850Mhz support

by Hugo Fortier

Hi everyone, I am fairly new to OsmocomBB. Been in North America I acquired a C118(850Mhz/1900Mhz version of the C123) and a C156(850Mhz / 1900mhz version of the C155) but from what I understand at this point is that only 900Mhz and 1800Mhz are supported. I am trying to figure out what modification I need to do in order to implement North American support for OsmocomBB, do I need to modify the firmware or do I only need to modify the host application? Any pointer would be greatly appreciated. I tried to modify the host application but I didn't had any success so far... Also I am trying to acquire a C123 and I find it quite difficult to find in North America, anyone know where I could acquire it from? I have look online but I could only find it on https://www.samstores.com/ and it seem a bit pricey and I have no idea if this store is trust worthy. I am also interested to acquire a BTS for OpenBSC(I currently have OpenBTS running on my USRP) so if you have any pointer on how I could acquire one, let me know. Thanks, Hugo

13 years, 7 months

2
2
0 0

TCH/F

by Marten Christophe

Hello All, Can Any one expert in programming add new command line in full stack GSM application like , ./mobile. to tune or enter for particular. ARFCN , Time slot, hopping sequence. my understanding here is , once i will logged to any cell , it will automatically find FCCH, and SCH and my MS will synchronize, to a cell and read bcch. only thing left over to finish my work is to tune to right ARFN and TS with appropriate HS i want signaling to be involved without it it wont receive TCH. see, to be frank my not expert in C language and even lots of try i couldn't make API for it . so any one can help me . Kind Regards,

13 years, 7 months

2
3
0 0

L1 TCH code status

by Sylvain Munaut

Hi, Just a quick update for those that don't follow the git or IRC: A few days ago, I merged most of was in my sylvain/testing branch into master. It's now in a state where you can place a call on a BS11 or nanobts. It took a while for me to go from the raw prototype from Dieter to a state I was happy with. (especially because I wanted to understand the purpose of every line I was rewriting since my main goal is to learn :) There were also some extensions (mode switching / bugs fixes / partial HR support / ...). There are still somethings that are only in my testing/ because they're hacks (or even missing): - SIM support: The code is clearly [WIP]. I may get to cleaning it myself at some point, but that's not a priority for me ... - TS change fixup: There is a bug when going from a high TS to a low TS that's tricky to fix. I'm still thinking about the best way to handle this. There is a hack to work around it in my testing branch. This case can't happen on nanoBTS or BS-11 but it may happen on a real network. - TOA loop: I want to check if I can re-use the common code from our AFC/AGC loop rather than adding some other regulation stuff. - Enabling HR: Well ... it doesn't work yet, so no point in putting it in master :) All theses will be added when I have the time to do it. Cheers, Sylvain Munaut

13 years, 7 months

2
1
0 0

osmocom and map

by Andreas.Eversberg

hi, recently i committed a conversion tool to convert logged cell information ("SYSTEM INFORMATION" messages) from "cell_log" application into a geographical KML map layer. the quick and dirty name "gsmmap" is about confusing. MAP is actually a short term for "mobile application part", which has absolutely nothing todo with a geographical map. does anyone have a name for it? (my best idea so far: "bcch2kml") regards, andreas

13 years, 8 months

1
0
0 0

libosmocom VERSION doesn't get set properly

by jakob borg

hi, when building libosmocom in osmocom-bb/src/shared (using the git-subtree script to keep everything up to date), the Makefile in src/shared/libosmocore/build-host doesn't have the version information set properly, instead i get: PACKAGE_VERSION = UNKNOWN VERSION = UNKNOWN this is causing problems compiling stuff that require libosmocom at a specific version, like some of the airprobe tools. i'm running mac os x 10.6.4, using autoconf 2.68, automake 1.11.1, binutils 2.20.1, gcc 4.5.1. when building the master git branch of libosmocom outside of osmocom-bb (bootstrapping using the bootstrap script from airprobe/gsm-receiver), the version gets set properly. thanks jakob -- jakob borg jakborg(a)fastmail.fm -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html

13 years, 8 months

3
3
0 0

command line options for layer23 apps

by Andreas.Eversberg

hi, i like to change the handling of command line options in layer23 applications, because different layer23 applications require different individual options, and common options also. (e.g. the "mobile" application does not required "--arfcn" option, but "--vty-port". others do not require "--vty-port", but might require a "--gps-device". all apps together require "--socket" and "--gsmtap-ip".) therefore i like to leave all common options in common/main.c. additional options i like to put in the individual app_*.c files. each options i like to check at the individual app file. if it doesn't exist there, the main.c checks if the option is a common option: ... c = l23_app_handle_options(); if (c == -1) c = getopt_long(argc, argv, "hs:S:a:i:v:d:", long_options, &option_index); if (c == -1) break; ... an individual help for each application: l23_app_print_help(); any suggestions or complains? best regards, andreas

13 years, 8 months

3
4
0 0

AW: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state

by Andreas.Eversberg

>> you are right. in case of an RR "response" (or an I frame) with the F >> bit set to "1", there is no clearing of the "timer recovery state". in >> other cases (RNR, REJ) it is handled. > Where did you see that an I-Frame with the F bit set should clear the > condition ? you are right. i searched through the document. the I-Frame is handled during "timer recovery state", but this state is not cleared then. anyway: i am missing the description for "Receiving RR frames". A general description for RR, RNR, REJ is given in 5.5.3, but it does not describe what todo on a valid RR response with F bit set to "1". this is why i missed it.

13 years, 8 months

1
0
0 0

AW: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state

by Andreas.Eversberg

> The timer recovery condition is only cleared if the data link layer > entity receives a valid supervisory frame response > with the F bit set to "1". If the N(R) of this received supervisory > frame is within the range from its current state variable > V(A) to its current send state variable V(S) inclusive, it shall set > its send state variable V(S) to the value of the received > N(R). Timer T200 shall be reset if the received supervisory frame > response is an RR or REJ response with F bit set to > "1". The data link layer entity shall then resume with I frame > transmission or retransmission, as appropriate. > Timer T200 shall be set if the received supervisory response is an RNR > response, and the data link layer shall proceed > with the enquiry process in accordance with subclause 5.5.5. hi sylvain, you are right. in case of an RR "response" (or an I frame) with the F bit set to "1", there is no clearing of the "timer recovery state". in other cases (RNR, REJ) it is handled. i would like to test this with a prepared frame drop tonight. if this works, i will commit it. regards, andreas

13 years, 8 months

2
1
0 0

Switching to TCH

by Sylvain Munaut

> but when i doing so , it is chasing up to SDCCH , and after this it is > started to dropping frames .. and not getting tune to any TCH/F Have you even _read_ the code of layer23 ... it _will_ not do what you want directly. It's a starting point, but you're gonna have to learn to write things by yourself. > though there is no encryption being used. A5/0, i have seen , no ciphering. > in traces. Well it's a perfectly normal behavior that after some time you only see lost frames. I suggest you re-read the code and the specs until you understand _why_ it's normal. > kindly confirm with layer1.compalram.bin , if i will be able to listen > TCH/F assign to some other MS , Not out of the box, as I said, you will need to do some programming. Given the question you ask, you obviously don't understand GSM or the code enough yet to do it. Cheers, Sylvain PS: Please don't hijack a thread that has nothing to do with what you're writing about by just clicking the reply button and not even bothering to change the subject ... seems like you need to read the emails RFC as well ...

13 years, 8 months

2
1
0 0

LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state

by Sylvain Munaut

Hi, In GSM 05.06 Section 5.5.7 at the end it says : --- The timer recovery condition is only cleared if the data link layer entity receives a valid supervisory frame response with the F bit set to "1". If the N(R) of this received supervisory frame is within the range from its current state variable V(A) to its current send state variable V(S) inclusive, it shall set its send state variable V(S) to the value of the received N(R). Timer T200 shall be reset if the received supervisory frame response is an RR or REJ response with F bit set to "1". The data link layer entity shall then resume with I frame transmission or retransmission, as appropriate. Timer T200 shall be set if the received supervisory response is an RNR response, and the data link layer shall proceed with the enquiry process in accordance with subclause 5.5.5. --- And I don't see where this is supposed to be handled in the code. I tried this quick fix: diff --git a/src/host/layer23/src/common/lapdm.c b/src/host/layer23/src/common/lapdm.c index b1c0d40..8bd42a7 100644 --- a/src/host/layer23/src/common/lapdm.c +++ b/src/host/layer23/src/common/lapdm.c @@ -1081,8 +1081,12 @@ static int lapdm_rx_s(struct msgb *msg, struct lapdm_msg_ctx *mctx) /* 5.4.2.2: Inidcate error on supervisory reponse F=1 */ if (LAPDm_ADDR_CR(mctx->addr) == CR_BS2MS_RESP && LAPDm_CTRL_PF_BIT(mctx->ctrl)) { - LOGP(DLAPDM, LOGL_NOTICE, "S frame response with F=1 error\n"); - rsl_rll_error(RLL_CAUSE_UNSOL_SPRV_RESP, mctx); + if (dl->state != LAPDm_STATE_TIMER_RECOV) { + LOGP(DLAPDM, LOGL_NOTICE, "S frame response with F=1 error\n"); + rsl_rll_error(RLL_CAUSE_UNSOL_SPRV_RESP, mctx); + } else { + dl->state = LAPDm_STATE_MF_EST; + } } switch (dl->state) { which seems to fix the issue I encountered but my understanding of how lapdm.c works is very limited and I doubt that it's all that's needed to properly handle this case. Cheers, Sylvain Munaut

13 years, 8 months

2
1
0 0

cross-compiling osmocom on mac os x

by jakob borg

hi, i'm struggling to get a working cross-compile toolchain for osmocom-bb on os x, i've been playing with a script called summon-arm-toolchain (http://github.com/esden/summon-arm-toolchain) for a while now without success, my toolchain seems to build fine, but when trying to compile for my target, i get: checking for arm-elf-linux-gcc... arm-elf-gcc checking whether the C compiler works... no config.log says: configure:3106: checking whether the C compiler works configure:3128: arm-elf-gcc -Os -ffunction-sections -I../../../../target/firmware/include conftest.c >&5 /usr/local/arm-elf/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/libc.a(lib_a-exit.o): In function `exit': /usr/local/src/summon-arm-toolchain/build/arm-elf/newlib/libc/stdlib/../../../../../newlib-1.18.0/newlib/libc/stdlib/exit.c:65: undefined reference to `_exit' collect2: ld returned 1 exit status i'm running mac os x 10.6.4, using autoconf 2.68, automake 1.11.1, binutils 2.20.1, gcc 4.5.1. any idea what i might be doing wrong? has anybody successfully cross-compiled the arm part of osmocom-bb on osx? thanks jakob -- jakob borg jakborg(a)fastmail.fm -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow

13 years, 8 months

2
1
0 0

DSP TCH task : time to get/put FAACH

by Sylvain Munaut

Hi Dieter, Hi everyone, (cc'd the list, for the record and if other people are interested in the inner workings :) I'm pretty satisfied with the current state of the TCH primitive (as it is in my testing branch now). But there is still two things I'm stumbling upon: * When to put / read data for FACCH. Getting downlink FACCH blocks looks quite logic: just check the B_BLUD bit on the TCH response of the last burst of the block. So with rx_time being the time at which the burst was received (i.e., one frame before the response is executed) - For TCH/F: (rx_time.fn % 13) % 4 == 3 - For TCH/H: (rx_time.t2 - subchannel) in {6,15,23} But for when to load the next FACCH block, it seems weird. From what I understand of what you did and what the TSM30 does, you need to load the data on the TCH cmd corresponding to the bursts _before_ the first burst. So with tx_time being the time at which the burst will transmitted (i.e., one frame after the command is executed = l1s.next_time) - For TCH/F (tx_time.fn % 13) % 4 == 3 - For TCH/H (tx_time.t2 - subchannel) in {6,15,23} (2 TDMA before the first burst because on TCH/H, we're executed one once every two frame) Why the need to load it one burst in advance ? (while on the RX side, which seems more complex to do, data is available directly after the last burst is received). * TCH/H support: AFAIK, I did everything that should be required for it to work: - set fn_report properly for TCH/H - set chan_type to TCH_H in dsp_load_tch_parameters - Use a different condition for when to put/read FACCH bursts (according to 05.02) - Schedule the TCH task appropriately ... But still can't get it to work (testing with the racal). SACCH seems to work fine (I see the SI messages), but I don't see a single FACCH message (and eventually the racal says T3107 expired, assignement to TCH failed). Do you see anything else that would be required ? Cheers, Sylvain

13 years, 8 months

1
1
0 0

TCH.. OsmocomBB

by Marten Christophe

Hello Deiter ,Sylvian As u advised I completed reading GSM standard, and dig down source code AFAIK , i have recognized the files and parameters where i need to change values to tune for particular TCH, and also understood that how important signaling is to be involved . I just want to know one thing that is , during the channel request MS send burst on RACH with RA ref number, where this RAF or RA reference number stored on MS side , because when Immediate assignment send from the network it must be match before tuning to particular SDCCH, i want to apply a trick here i will copy the RA reference from the immediate assignment message and will replace with original one stored in MS, hence MS will think this channel is for me and tune to the SDCCH accordingly, further it will keep on listening all process like authentication, location updating , again the TCH channel information is send SDCCH without encryption as only authentication procedure needs Kc Ki and SRES, SDCCH is not encrypted and all MS hosting on that SDCCH can decode TCH parameter like FN , TS, ARFCN hopping sequence. but again i need to clarify how L1ctl.c and L23_api.c fetch the decoded data, from immediate assinment masseg. as it is written printf..........%u . From where this will scan or fetch. if i will be able to know, where MS kept stored the input values advised in signaling messages by BTS on PCH, or AGCH. so i can manipulate them and land on CCCH, and then SDCCH then TCH. kindly tell me if it is feasible , or there is more i need to think. Kind Regards,

13 years, 8 months

2
1
0 0

Re: osmocom on windows

by Dieter Spaar

Hello Peter, On Thu, 7 Oct 2010 11:54:28 +0200, "Peter Stuge" <peter(a)stuge.se> wrote: > > Does e.g. the CodeSourcery toolchain really need Cygwin? That would > suck. I don't know CodeSourcery, I use GNU ARM directly from www.gnuarm.com. According to the CodeSourcery FAQ, they do not require Cygwin. Are there any benefit using CodeSourcery ? I had issues in the past with the firmware using a different GNU ARM version, so I switched back to 4.0.2 which seems to be the same other use on Linux and so far it works OK. You don't seem to like Cygwin, my experience with it is not that bad, OpenBSC (not with GPRS yet due to the need for the TUN device), OsmocomBB, GNUradio and Airprobe run with minor adjustments (just to name GSM related stuff I use under Cygwin). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 8 months

4
4
0 0

AW: wrong decoding of bit vectors

by Andreas.Eversberg

> if (bv->data[bytenum] & (1 << bitnum) == bitval) > return H; i must correct: if ((bv->data[bytenum] & (1 << bitnum)) == bitval) return H;

13 years, 8 months

2
1
0 0

wrong decoding of bit vectors

by Andreas.Eversberg

/* check if the bit is L or H for a given position inside a bitvec */ enum bit_value bitvec_get_bit_pos_high(const struct bitvec *bv, unsigned int bitnr) { unsigned int bytenum = bytenum_from_bitnum(bitnr); unsigned int bitnum = 7 - (bitnr % 8); uint8_t bitval; if (bytenum >= bv->data_len) return -EINVAL; bitval = bitval2mask(H, bitnum); if (bv->data[bytenum] & bitval) return H; return L; } hi, this is part of bitvec.c of libosmocore. it returns if a given bit in the vector is "high" or "low". the bitval that represents "high" depends on the bit position. bitval2mask returns that. so we must check if the bit in the vector equals the returned bitval. i suggest to fix it that way: if (bv->data[bytenum] & (1 << bitnum) == bitval) return H; any complains? without it we cannot check the system information's rest octets. they are essential for any multiband mobile. regards, andreas

13 years, 8 months

1
0
0 0

Inquiry on osmocom

by Akilesh Sethu

Hey, I am working on Android Mobile Operating System. Is it possible for me to port osmocom GSM stack to any of the Android compatible mobiles. Regards, Akilesh Sethu

13 years, 8 months

2
1
0 0

Re: osmocom on windows

by Dieter Spaar

Hello Peter, On Thu, 7 Oct 2010 13:24:50 +0200, "Peter Stuge" <peter(a)stuge.se> wrote: > > In practise it can be negligeable, just another DLL, but it isn't > Windowsy, and for someone who wants Windowsy, Cygwin isn't a really > good answer. (But it can save plenty of time instead!) Exactly, saving time is the point. A software developer, regardless of coming from Windows or Linux should have no problem to understand OpenBSC/OsmocomBB/Airprobe from the OS or C language perspective (I don't talk about GSM specific things, this is something else). I want to use those project and develop for them and not waste my time with things like adopting C language specific issues. > OpenVPN has one, it's signed too. I know, but you have to use the TUN device differently than on Linux, so some adjustments are necessary (besides not knowing if Windows will do proper NAT with the IP traffic from the phone). So I run OpenBSC in a VM if I need GPRS support instead spending time on issues I don't care if I want to use this software or develop for it. > Cool, that's proof that Cygwin is pretty good stuff. It doesn't say > almost anything about how these projects run on Windows though. They work for me, I want to use them and I want to develop for them and so far I could do all I want. Of course this is something else if you for example want to run OpenBSC in a production environment with lots of BTSs. A native Windows port is surely possible, but for me I don't see any benefits besides wasting time. Of course if someone want to sponsor a native port, why not, than at least the time for this effort is paid ;-) > That isn't neccessarily a bad thing at all, evolving the project > internally or the featureset or whatever can be much more important > than adapting the project to work "on" more operating systems. I don't have the impression that more people would work on those GSM related projects if they would directly run on Windows. I think the main obstacle is that you need to know quite a lot of GSM to make use of them. And if you are able to learn and understand the GSM related stuff, using Windows and/or Linux should be no problem at all for you ;-) Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 8 months

4
4
0 0

Removing the C123 RX filter

by Sylvain Munaut

Hi, As a prelude to various experimentations, I had to remove the RX filter on some C123. As this can be useful to others, I've done a little summary of how I do it. It's not for the faint of heart tough :) http://www.246tnt.com/gsm/rx_filter.html Comments welcome of course. Cheers, Sylvain Munaut

13 years, 8 months

4
3
0 0

AW: Newbie: C123 + layer1.compalram.bin + layer23

by Andreas.Eversberg

> But I'm not sure it really works: the firmware seems to freeze (not > responding to the power button anymore) and the last output of 'mobile' > is: > > <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) hi nicolas, be sure to use the branch of sylvain: sylvain/testing (i think you did) the process freezes after many sync requests due to a memory leak that has not been fixed. without the fix, the full network search process should run several times without freeze. but in your case it looks like freezing every first sync request. can you watch the display of your c123? see if it gets a little darker at the point it freezes (when trying to sync). regards, andreas

13 years, 8 months

2
1
0 0

PATCH: Framebuffer for C123 and C155

by Christian Vogel

{Resent, it didn't appear on the list after 20 minutes.} Hi, I had some spare time the last days and put together a first attempt at a framebuffer for the OSMOCOM mobiles. It currently supports the C123 and the C155, the only two phones I own. > On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte > >1) we need a way to select between individual fonts ... > > Something like display_select_font(FONT_5x8) to be called > > before a display_puts() sounds like a reasonable API for this. the current API looks like this: fb_clear(); fb_setfg(FB_COLOR_GREEN); fb_setbg(FB_COLOR_WHITE); fb_setfont(FB_FONT_HELVB14); fb_gotoxy(2,20); fb_putstr("Hello World!",framebuffer->width-4); fb_setfg(FB_COLOR_RED); fb_setbg(FB_COLOR_BLUE); fb_gotoxy(2,25); fb_boxto(framebuffer->width-3,38); fb_setfg(FB_COLOR_WHITE); fb_setfont(FB_FONT_5X8); fb_gotoxy(8,33); fb_putstr("osmocom-bb",framebuffer->width-4); fb_flush(); Which results in an output such as: http://vogel.cx/git/20101011_hello_world_c123.jpg http://vogel.cx/git/20101011_hello_world_c155.jpg > - If we want to support arbitrary sized fonts, we either should buffer > the display in RAM (might be wasteful on high res color displays?) ... This patch keeps a image of the LCD in a RAM and only copies "dirty" parts upon changes. > >2) Removing all the special characters might not be the best idea to do. > > If at all, it should be a compile time option whether or not to drop > > the special characters. > > Also, the check for replacing a character with '?' needs to be > > a font-specific and not a global decision. This patch currently encodes only #32..#127 to conserve space, but it supports leaving out arbitrary characters. When the data is actually put into ROM we can spare additional space on more glyphs and/or fonts. I currently don't have commit access to the git-repo, so I couldn't upload my vogelchr/framebuffer branch. Please have a look at the patch you can download from http://vogel.cx/git/20101011_framebuffer.diff It removes the old display code completely and replaces it with the framebuffer, but currently only "hello world" makes use of it by creating the image in the photographs linked above. It should apply cleanly to today's master (11.Oct.2010) as it doesn't touch anything where currently work is being done. Please send me your comments on that patch. Greetings from the Dillberg, Chris

13 years, 8 months

1
1
0 0

PATCH: Framebuffer for C123 and C155

by Christian Vogel

Hi, I had some spare time the last days and put together a first attempt at a framebuffer for the OSMOCOM mobiles. It currently supports the C123 and the C155, the only two phones I own. > On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte > >1) we need a way to select between individual fonts ... > > Something like display_select_font(FONT_5x8) to be called > > before a display_puts() sounds like a reasonable API for this. the current API looks like this: fb_clear(); fb_setfg(FB_COLOR_GREEN); fb_setbg(FB_COLOR_WHITE); fb_setfont(FB_FONT_HELVB14); fb_gotoxy(2,20); fb_putstr("Hello World!",framebuffer->width-4); fb_setfg(FB_COLOR_RED); fb_setbg(FB_COLOR_BLUE); fb_gotoxy(2,25); fb_boxto(framebuffer->width-3,38); fb_setfg(FB_COLOR_WHITE); fb_setfont(FB_FONT_5X8); fb_gotoxy(8,33); fb_putstr("osmocom-bb",framebuffer->width-4); fb_flush(); Which results in an output such as: http://vogel.cx/git/20101011_hello_world_c123.jpg http://vogel.cx/git/20101011_hello_world_c155.jpg > - If we want to support arbitrary sized fonts, we either should buffer > the display in RAM (might be wasteful on high res color displays?) ... This patch keeps a image of the LCD in a RAM and only copies "dirty" parts upon changes. > >2) Removing all the special characters might not be the best idea to do. > > If at all, it should be a compile time option whether or not to drop > > the special characters. > > Also, the check for replacing a character with '?' needs to be > > a font-specific and not a global decision. This patch currently encodes only #32..#127 to conserve space, but it supports leaving out arbitrary characters. When the data is actually put into ROM we can spare additional space on more glyphs and/or fonts. I currently don't have commit access to the git-repo, so I couldn't upload my vogelchr/framebuffer branch. Please have a look at the patch you can download from http://vogel.cx/git/20101011_framebuffer.diff It removes the old display code completely and replaces it with the framebuffer, but currently only "hello world" makes use of it by creating the image in the photographs linked above. It should apply cleanly to today's master (11.Oct.2010) as it doesn't touch anything where currently work is being done. Please send me your comments on that patch. Greetings from the Dillberg, Chris

13 years, 8 months

1
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel