baseband-devel

baseband-devel@lists.osmocom.org

3 participants
2004 discussions

Re: Osmocombb with USRP
by Vadim Yanitskiy 01 Jun '17

01 Jun '17

> your device, current supports both uplink and downlink rx Wrong. What do you mean by 'device'? I can only receive DL bursts for now. As soon as I integrate TDMA scheduler, it will be possible to decode raw bursts to L3 packets and forward them higher layers. > It can be further be connected to any standard L2/L3 > stack for further processing What do you mean by 'standard stack'? Some simple applications like ccch_scan already able to tune SDR to required ARFCN and to start burst detection. > Do you have some cfile What for? You can tune to any of surrounding carriers, and test the implementation against the real networks. Moreover you can use RTL-SDR while we don't have TX capabilities. P.S. Please sign in to the baseband-devel mailing lists and CC to baseband-devel(a)lists.osmocom.org because your messages aren't displayed there. With best regards, Vadim Yanitskiy.

2 2

Re: Osmocombb with USRP
by Vadim Yanitskiy 01 Jun '17

01 Jun '17

Hi, > I want to implement a GSM Mobile stack with USRP as RF Frontend. Well, I am currently working on that. I don't stick on a specific SDR device like mentioned one. > Is it possible to build the DSP part of osmocommbb in a different > TI DSP board other than calypso. In case of SDR, DSP part should be done on computer side, like OsmoTRX does. And some low-level GSM L1 part is already implemented and could be used by MS implementation too. If you would like to cooperate me in this direction, have a look at: https://github.com/axilirator/osmocom-bb Right now I am doing some code refactoring, and further commits will be posted at http://gerrit.osmocom.org/ With best regards, Vadim Yanitskiy.

2 2

Couldn't get connectivity to Motorolla c118 on writing osmocombb
by baymax Robo 01 Jun '17

01 Jun '17

Hi, I am trying to write osmocombb to Motorolla c118 phone by following the given [1] guide.I have successfully compiled firmware binaries but having issues while writing them to phone. I connected motorolla c118 via USB Serial To RS232 TTL to 2.5mm audio jack, using the given guide [2] When I run this command $ dmesg | grep tty I get the following output [ 0.000000] console [tty0] enabled [ 14.946936] usb 3-6: pl2303 converter now attached to ttyUSB0 [ 973.747957] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 [ 1484.595816] usb 3-6: pl2303 converter now attached to ttyUSB0 [ 1845.344494] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0 [ 2643.566407] usb 3-6: pl2303 converter now attached to ttyUSB1 And on running this $ sudo cu -l /dev/ttyUSB1 -s 115200 I get a connected message but no further progress is done. When i press Power button briefly, no activity is shown. I have tried with two phones but no success on any. I have checked the connectivity between headphone jack and USB serial chip via voltmeter, it is fine as well. Also tried by doing Master reset on phone but no use. What can be issue and how can i fix it. ? Kindly ignore any mistakes, i am new to this domain, couldn't find much help on google as well :( [1] https://osmocom.org/projects/baseband/wiki/Software_Getting_Started https://osmocom.org/projects/baseband/wiki/Osmocon [2] http://www.linuxx.eu/2014/09/osmocombb-hardware-and-software-setup.html [2]

2 4

Osmocombb with USRP
by Snehasish Kar 31 May '17

31 May '17

Hi Herald I needed some information from you, I want to implement a GSM Mobile stack with USRP as RF Frontend. Is it possible to build the DSP part of osmocommbb in a different TI DSP board other than calypso. As it is very difficult to find calypso phones now a days. BR Snehasish

1 0

Re: OsmocomBB compile testing / Re: libosmocore embedded build
by Craig Comstock 29 May '17

29 May '17

I was thinking about how to setup an automated real device test for the repo and/or PRs especially. I have devices and cables, just was thinking about how to automate the re-loading of firmware (via an interface to the power button I suppose). Any work ongoing on this front? I'd be happy to contribute as I have a server I'm going to use for nano3g, calypsobts, development. -Craig -------------------------------------------- On Thu, 5/18/17, Harald Welte <laforge(a)gnumonks.org> wrote: Subject: OsmocomBB compile testing / Re: libosmocore embedded build To: "André Boddenberg" <dr.blobb(a)gmail.com> Cc: baseband-devel(a)lists.osmocom.org, "OpenBSC" <openbsc(a)lists.osmocom.org>, "Vadim Yanitskiy" <axilirator(a)gmail.com> Date: Thursday, May 18, 2017, 1:24 PM Hi Andre and others. We currently have a series of patches from Vadim pending in gerrit for OsmocomBB. They cannot move ahead, as we have no compile testing / jenkins job which would give this a +1. To resolve this, we should also start to have a jenkins compile testing job for OsmocomBB. The "host" (PC) part of the code is built against regular libosmocore, just like e.g. openbsc or osmo-bts. That should be possible even so far, and it might make sense to start with that. Basically you need to: * git clone osmocom-bb * cd src/host/layer23 * regular 'autoreconf -fi && ./configure && make' compile-testing the 'embedded' (firmware) part is not possible easily in the current master. However, as a second step, and after the libosmocore embedded build has run (and it is installed to /usr/local/arm-none-eabi), and if you use the laforge/remove-libosmocore branch in OsmocomBB, you should also be able to compile-test the firmware using * git clone osmocom-bb * cd src/target/firmware && make There currently is no "make check" tests for either the host utilities or the firmware, and of course we have no clue if the resulting binaries will do anything useful on an actual pone [yet!], but I still think the two steps above would be very useful to move ahead, and to unify the patch submission/review/verification/approval/merge process in gerrit with what we have established for the network-side projects like OsmoBTS & co. 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)

2 2

OsmocomBB build verification
by Harald Welte 27 May '17

27 May '17

Hi Vadim, see attachment. This was my 'test ballon': We now have automatic jenkins build verification at least for the host part of OsmocomBB. Please re-push your patch series again into jenkins, so they will get build-verified. -- - 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)

2 1

libosmocore embedded build
by Harald Welte 24 May '17

24 May '17

Dear all, when we originally moved a lot of generic code from OpenBSC to libosmo{core,gsm} to re-use it from OsmocomBB, we created an 'embedded' build of libosmocore, which can use [most of] the library code also in deeply embedded, OS-less 'bare metal' microcontroller environments. The ability to build libosmocore this way has been broken for many years, but I've fixed that in recent libosmocore master. Below command works for me [tm]: ./configure --prefix=/usr/local/arm-none-eabi \ --host=arm-none-eabi \ --enable-embedded \ --disable-shared \ CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" What we'd need now is: 1) make sure embedded builds continue to work by building libosmocore for embedded as part of the jenkins setup (using gcc-arm-none-eabi debian package). Any volunteers? 2) start to use this embedded build from simtrace2 firmware, osmocom-bb and the upcoming fimrware for the RFDN[1]. So far, * osmocom-bb uses an old clone of libosmocore, * simtrace2 is using some copy+pasted fork of some libosmocore files * rfdn is using some copy+pasted fork of some libosmocore files The above is no longer required. 3) consider if we can shrink the resource requirements of some libosmocore parts. One issue coming up are the static buffers in osmo_hexdump[] or the like. If your total processor RAM is 8k or 16k, then spending 4k on the buffer for hex-dumping is indeed a bit excessive. Any help is appreciated, particularly on the jenkins side. Regards, Harald [1] (1:8 splitter-combiner with adjustible step attenuators, part of the osmo-gsm-tester setup we're building at sysmocom). Code will be released as soon as the hardware is validated. -- - 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)

3 10

Re: libosmocore embedded build
by Vadim Yanitskiy 18 May '17

18 May '17

Hi, > The arm build does not succeed (yet) [2]. > > Can someone else may have a quick look at log [2] to point me in the > right direction? Afaics build dependencies are available but the > compilation itself fails. As I can see from the console output, build fails because we are trying to test disabled features, which we haven't compiled. Fixed by fixeria ;) https://gerrit.osmocom.org/#/c/2682/1 With best regards, Vadim Yanitskiy.

1 0

Re: libosmocore embedded build
by Craig Comstock 18 May '17

18 May '17

> Can someone else may have a > quick look at log [2] to point me in the > right direction? Afaics build dependencies are > available but the > compilation itself > fails. > [2] https://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/arch… Looks like the tests are failing. My build seems to work but when I run "make check-am" in tests I get a different error related to talloc. This is on a Debian 8 stable box using arm-none-eabi and newlib from debian packages. Maybe the make of timer_test fails and doesn't log somehow? I"m not sure. craig@z500:~/libosmocore/tests$ vi timer/timer_test. timer_test.c timer_test.ok craig@z500:~/libosmocore/tests$ vi timer/timer_test.c craig@z500:~/libosmocore/tests$ make check-am make timer/timer_test sms/sms_test ussd/ussd_test smscb/smscb_test bits/bitrev_test a5/a5_test conv/conv_test auth/milenage_test lapd/lapd_test gsm0808/gsm0808_test gsm0408/gsm0408_test gb/bssgp_fc_test gb/gprs_bssgp_test gb/gprs_ns_test gprs/gprs_test kasumi/kasumi_test gea/gea_test logging/logging_test fr/fr_test codec/codec_test loggingrb/loggingrb_test strrb/strrb_test vty/vty_test comp128/comp128_test utils/utils_test smscb/gsm0341_test stats/stats_test ctrl/ctrl_test bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test tlv/tlv_test gsup/gsup_test oap/oap_test fsm/fsm_test write_queue/wqueue_test socket/socket_test coding/coding_test conv/conv_gsm0503_test abis/abis_test endian/endian_test sercomm/sercomm_test make[1]: Entering directory '/home/craig/libosmocore/tests' CC timer/timer_test.o In file included from timer/timer_test.c:31:0: ../include/osmocom/core/talloc.h:4:20: fatal error: talloc.h: No such file or directory #include <talloc.h> ^ compilation terminated. Makefile:1336: recipe for target 'timer/timer_test.o' failed make[1]: *** [timer/timer_test.o] Error 1 make[1]: Leaving directory '/home/craig/libosmocore/tests' Makefile:1529: recipe for target 'check-am' failed make: *** [check-am] Error 2

1 0

Re: removing ancient libosmocore fork from osmocom-bb.git
by Vadim Yanitskiy 17 May '17

17 May '17

Hi Harald and Craig, > select.c:27:24: fatal error: sys/select.h: No such file or directory > #include <sys/select.h> I have the same issue with: gcc-arm-none-eabi 4.8.2-14ubuntu1+6 binutils-arm-none-eabi 2.24-2ubuntu2+4 libnewlib-arm-none-eabi 2.1.0-3 > * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from > libosmocore.git (plus an embedded 'malloc' like umm_malloc) Why do we need this hack (pseudotalloc)? What if we could cross-compile libtalloc too, and link it against core? > * have an (optional?) osmocom-bb makefile step to git clone + configure > + make install libosmocore Great idea! What about to have libosmocore as a git submodule inside OsmocomBB (like OpenCL headers in hashcat)? Also, I think it would be good to make libosmocore more modular, because it could allow us to create more flexible builds (e.g. to compile only what we need, not a whole library). This makes sense in case of low RAM / ROM embedded systems. What do you think? With best regards, Vadim Yanitskiy.

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel