baseband-devel March 2011

baseband-devel@lists.osmocom.org

47 participants
68 discussions

by bch2011＠sina.cn

$ git clone git://git.osmocom.org/osmocom-bb.git Cloning into osmocom-bb... remote: Counting objects: 10960, done. remote: Compressing objects: 100% (2599/2599), done. fatal: The remote end hung up unexpectedly8 MiB | 23 KiB/s fatal: early EOF fatal: index-pack failed

14 years, 3 months

git error

by bch2011＠sina.cn

14 years, 3 months

bcch_scan initialization and L1

by weberbe＠ee.ethz.ch

Hi everbody I'm currently working on a project at our university where we are trying to connect bcch_scan with our existing hardware/software. The latter consists of L1 implementation partly in hardware and partly in software. The software part is also used to provide the interface towards bcch_scan. So far, the software interface does not do much it just provides the necessary domain sockets and dumps everything it receives from bcch_scan. Now, my question is whether there is some kind of initialization sequences sent from bcch_scan to the phone. And is there any other info you can provide about the messages sent from bcch_scan to the phone and the other way round? Naturally, I tried to find this out myself by looking though the source but didn't get very far. Oh and by the way, the ultimate goal of this project is that we can use bcch_scan to test our L1 hardware. This would be pretty cool Thanks in advance Benjamin

14 years, 3 months

Mediatek RF development informations

by Marcin.Mielczarczyk＠tieto.com

Hi list, I'd like to give you some informations about findings on Mediatek's RF. Sciphone G2 has MT6140 transceiver which seems to be different than MT6139. MT6140 has much more registers to configure at init time (CW0 - CW12, CW15) while MT6139 has just 5 registers (CW0, CW1, CW2, CW9 and CW11). Common registers for MT6140 and MT6139 has also different fields (i.e. register CW0 has reset bit on different offset on MT6140). These findings where first discovered during sniffing of BSI interface. After some time I also found source code for Mediatek's SoCs family on Google Code pages: http://code.google.com/p/mobile-phone-mtk-project/ You can find there source code with drivers for Mediatek RF part (MT6139, MT6140, Murata antenna switches and Mediatek Power Amplifiers). Source code is located under "l1/l1d" directory. This part is delivered as source code because Mediatek wants to give customers chance to change RF electronic components (customers are able to write thair own drivers). The rest of layer 1 code (code which calls RF drivers and uses DSP) is delivered as library "l1.lib". Thanks to above code I confirmed my concernings about difference between MT6139 and MT6140. I prepared initial version of drivers for BPI, BSI, BFE (Baseband Front End) and MT6140 and placed them in U-Boot. MT6140 driver is based on Harald's MT6139 driver from OsmocomBB. It's initial driver which just configures needed peripherals (BSI, BPI, BFE, TDMA, APC, MT6140, MURA465 and RF3159) and performs TX on given ARFCN channel. U-Boot command for that is following: Rf_tx <arfcn> After execution, using spectrum analyzer you should see transmission on given frequency (so far I just tested on low band). This code doesn't use APC yet, but driver is already written, it just needs to be tested (it means that TX has currently very low power). If it comes to RF part, documentation which is available is sufficient, I already know how to configure hardware and I don't expect bigger problems here, that's why I started investigations on DSP. MT6235 has two DSP processors (master and slave). These procesors are from Analog Devices family ADSP-218x. Most probably it's ADSP-2181 (it's just assumption, I haven't found any statement about it). Thanks to code mentioned above it's possible to identify DSP functions and disassemble them. Above code is compiled for MT6223 (ARM7) SoC and it provides symbols table (file: BIRDCELLTEL23_08B_NEP_162_PCB01_gsm_MT6223_S00.sym). Most of this code is also available on Sciphone G2 (comparing binary files) and I'm able to identify addresses of functions and break in these functions using JTAG. It means that I can debug on real hardware, that's really convenient and easy to understand what's going on. I already disassembled functions for DSP init and patch loading over IDMA port (probably DSP code is executed from ROM) and I'll continue this task. Hopefully we'll be able to start sending real TX data soon. -- Recently I received patches with Linux drivers for Sciphone's USB port from Krzysztof Antonowicz and I wanted to thank for his effort. Right now it's possible to use Sciphone as Mass Storage device and it'll be possible to run Ethernet gadget. Unfortunatelly I can't clone Linux/Uboot repository right now and I didn't deliver patches for RF and USB. As soon as I'll succeed cloning of repository, I'll deliver functionality which I described above. I'll also backport drivers I'm writing now to OsmocomBB. Best regards, Marcin

14 years, 3 months

Re: [PATCH OSMOCOM-BB] src: use new libosmogsm and include/osmocom/[gsm|core] path to headers

by Harald Welte

Hi Pablo, On Tue, Mar 22, 2011 at 05:16:58PM +0100, pablo(a)gnumonks.org wrote: > This patch also renames hexdump in osmocon.c and osmoload.c > to avoid clashing with hexdump defined in libosmocore. This > is a workaround, it's planned to fix the namespace pollution > of the library soon. how did you test this patch? Did you first update the libosmocore copy inside osmocom-bb.git using 'git-subtree', and then apply + test your patch? Did you make sure that new libosmocore will also build using the cross-compiler for the phone firmware (see + use the osmocom-bb/src/Makefile) ? Also, for the future: please note the mailing list for osmocom-bb is 'baseband-deve(a)lists.osmocom.org', not the openbsc list... Thanks, 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)

14 years, 3 months

Linux + u-boot port to MT6235

by Harald Welte

Hi All! At my OpenBSC / OsmocomBB talk here at the Embedded Linux Conference Europe, one of the attendees (Marcin, see Cc) came to me after the talk and told me he had recently done a u-boot and Linux kernel port to the MT6235 (that's the ARM926 based chipsets found in the touchscreen MTK phones). He said he has no understanding of GSM or the existing MTK firmware, but is interested in working together with us to try to make the GSM part work. I think that chipset is very intesting, as we could implement the layer1 inside the Linux kernel (and submit that mainline, yay!) and run our layer2 and layer3 implementations as userspace processes on the Linux system, together with the user interface. The performance of those devices should be somewhere between the Openmoko GTA01 and GTA02, and the GSM stack is certainly not going to eat away a lot of the CPU either. I have asked Marcin to write mail to the OsmocomBB mailing list on where we can find the code. He has so far downloaded the code using JTAG. Combining his code with our ramloader might remove that JTAG dependency... Marcin: if you want to push your u-boot / kernel to git.osmocom.org, or want a separate trac installation for your mtk-linux work, pleaes let me know, I'd be happy to host that. 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)

14 years, 3 months

Compiling issue

by Derek Murphy

I'm running Ubuntu 10.10 and having a couple of issues. I've got both options for the toolchain work, only one is in the path at a time while testing. With one of them it seems to compile fine: I can use ./osmocom with something like hello world and this works. However when I go to look at layer23 the binary has not been compiled and I have this error in the conf.log: configure:3833: checking for gps_waiting in -lgps configure:3858: gcc -o conftest -g -O2 conftest.c -lgps >&5 /usr/bin/ld: cannot find -lgps collect2: ld returned 1 exit status configure:3858: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define PACKAGE "layer23" | #define VERSION "0.0.0" | /* end confdefs.h. */ I'm sure most of these are environment error but wanted to check. In the update-libosmocore.sh I get an error that git-subtree doesn't exist. I found git subtree as a third party install that was not in the documentation but it's command is git subtree versus being git-subtree. Any thoughts would be appreciated.

14 years, 3 months

Re: Vcc c155?

by Henk

Well the datacable for c155 is a T191 so 3.3v. This is not the answer to your question but i hope it helps. ;)

14 years, 3 months

osmocon on gta02

by suraev＠stud.ntnu.no

Hello. I've updated & rebuilt osmocom and now I can't use osmocon on gta02 anymore :( Previously I started it like: ./osmocon -i 13 -m romload -p /dev/ttySAC0 layer1.highram.bin power-cycle modem and it started to load firmware. However with recent version firmware is loaded even without power-cycle! When I use hello_world.highram.bin I got exactly the same output as before. But when I use layer1.highram.bin I have problems running osmoload -l /tmp/loader ping Query timed out. What went wrong and how do I fix it? best regards, Max.

14 years, 3 months

problem with dream g2

by francisco flores

hi im francisco from argentina . i can compiled the code for sciphone dream g2 . i make the serial cable but no work is necesary configuration phone? o the conversor usb to serial? because i conect the cable a usb from mi pc and no work

14 years, 3 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel March 2011