baseband-devel May 2017

baseband-devel@lists.osmocom.org

17 participants
32 discussions

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 19 May '17

19 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 19 May '17

19 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 18 May '17

18 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

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

17 May '17

I got around this error by adding a #if (!EMBEDDED) around all of select.c and moving the #include "../config.h" to the top. diff --git a/src/select.c b/src/select.c index 8ed7f1b..e51e50a 100644 --- a/src/select.c +++ b/src/select.c @@ -20,6 +20,8 @@ * MA 02110-1301, USA. */ +#include "../config.h" +#if (!EMBEDDED) #include <fcntl.h> #include <stdio.h> #include <string.h> @@ -30,7 +32,6 @@ #include <osmocom/core/linuxlist.h> #include <osmocom/core/timer.h> -#include "../config.h" #ifdef HAVE_SYS_SELECT_H @@ -235,3 +236,4 @@ struct osmo_fd *osmo_fd_get_by_fd(int fd) /*! @} */ #endif /* _HAVE_SYS_SELECT_H */ +#endif /* !EMBEDDED */ After that the next error in building is related to talloc. make[3]: Entering directory '/home/craig/libosmocore/src' CC select.lo CC utils.lo In file included from ../include/osmocom/core/utils.h:4:0, from utils.c:30: ../include/osmocom/core/talloc.h:4:20: fatal error: talloc.h: No such file or directory #include <talloc.h> I didn't see the laforge/pseudotalloc branch. Did you forget to push it? How is this dealt with currently in osmocom-bb for embedded? Thanks, Craig

1 0

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

17 May '17

Looks like in package libnewlib-dev for stretch (unstable) we have sys/select.h but in jessie (stable) it is not included. https://packages.debian.org/stretch/libnewlib-dev https://packages.debian.org/jessie/libnewlib-dev craig@box:~/libosmocore$ ./configure --prefix=/usr/local/arm-none-eabi --host=arm-none-eabi --enable-embedded --disable-shared CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" craig@box:~/libosmocore$ make make all-recursive make[1]: Entering directory '/home/craig/libosmocore' Making all in include make[2]: Entering directory '/home/craig/libosmocore/include' make all-am make[3]: Entering directory '/home/craig/libosmocore/include' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory '/home/craig/libosmocore/include' make[2]: Leaving directory '/home/craig/libosmocore/include' Making all in src make[2]: Entering directory '/home/craig/libosmocore/src' make all-am make[3]: Entering directory '/home/craig/libosmocore/src' CC select.lo select.c:27:24: fatal error: sys/select.h: No such file or directory #include <sys/select.h> ^ compilation terminated. Makefile:510: recipe for target 'select.lo' failed make[3]: *** [select.lo] Error 1 make[3]: Leaving directory '/home/craig/libosmocore/src' Makefile:373: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/craig/libosmocore/src' Makefile:519: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/craig/libosmocore' Makefile:382: recipe for target 'all' failed make: *** [all] Error 2 -------------------------------------------- On Tue, 5/16/17, Harald Welte <laforge(a)gnumonks.org> wrote: Subject: removing ancient libosmocore fork from osmocom-bb.git To: baseband-devel(a)lists.osmocom.org Date: Tuesday, May 16, 2017, 11:18 AM Dear all, when we initially crated OsmocomBB, we moved the code that it shared with the pre-existing OpenBSC project into libosmocore.git, where libosmocore and libosmogsm are built. As libosmocore was quite a bit in flux (and we didn't have jenkins+gerrit yet), we decided to have a local clone of libosmocore.git as a git-subtree module inside osmocom-bb.git Meanwhile, upstream libosmocore received more and more code, and none of that was ever built with an 'arm-non-eabi' toolchain and --enable-embedded. I've been working quite a bit during the last week on making that embedded build work again. The idea is to be able to configure + build libosmocore.git master using something like ./configure --prefix=/usr/local/arm-none-eabi \ --host=arm-none-eabi \ --enable-embedded \ --disable-shared \ CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" and then install it onto the host pc. I've used /usr/local/arm-none-eabi as the prefix, but it could of course be anywhere. The above already works for me on Debian unstable using libosmocore.git master. I have some patches pending in laforge/sercomm and laforge/pseudotalloc, but those are not mandatory to make the build work The local clone of libosmocore in OsmocomBB src/shared/libosmocore will be removed, and the Makefiles of osmocom-bb instructed to use the system-installed libosmocore from /usr/local/arm-none-eabi (see my 'laforge/remove-libosmocore' branch in). This also already "works" on my Debian unstable system, in as far as there are no unresolved symbols or other compilation/linking issues, and the firmware images are generated. I have not tested any of the resulting binaries yet, and as I'm travelling without compatible hardware (and overloaded), it's unlikely that I'll be able to test it soon. Nevertheless, this is what I would like to move to. If anyone wants to try if he can build the embedded libosmocore and resulting osmocom-bb from laforge/remove-libosmocore branch, please do so and report your progress/success/issues here. Next steps (after validating the above) are: * remove old sercomm.c code from osmocom-bb and use the new code from libosmocore * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from libosmocore.git (plus an embedded 'malloc' like umm_malloc) Further ideas: * create Debian/Ubuntu package of cross-compiled libosmocore for embedded-arm, which we can add to the Osmocom nightly builds apt repository. * have an (optional?) osmocom-bb makefile step to git clone + configure + make install libosmocore Anyone interested in helping out with this, please feel free to join in. 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)

1 0

removing ancient libosmocore fork from osmocom-bb.git
by Harald Welte 17 May '17

17 May '17

Dear all, when we initially crated OsmocomBB, we moved the code that it shared with the pre-existing OpenBSC project into libosmocore.git, where libosmocore and libosmogsm are built. As libosmocore was quite a bit in flux (and we didn't have jenkins+gerrit yet), we decided to have a local clone of libosmocore.git as a git-subtree module inside osmocom-bb.git Meanwhile, upstream libosmocore received more and more code, and none of that was ever built with an 'arm-non-eabi' toolchain and --enable-embedded. I've been working quite a bit during the last week on making that embedded build work again. The idea is to be able to configure + build libosmocore.git master using something like ./configure --prefix=/usr/local/arm-none-eabi \ --host=arm-none-eabi \ --enable-embedded \ --disable-shared \ CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" and then install it onto the host pc. I've used /usr/local/arm-none-eabi as the prefix, but it could of course be anywhere. The above already works for me on Debian unstable using libosmocore.git master. I have some patches pending in laforge/sercomm and laforge/pseudotalloc, but those are not mandatory to make the build work The local clone of libosmocore in OsmocomBB src/shared/libosmocore will be removed, and the Makefiles of osmocom-bb instructed to use the system-installed libosmocore from /usr/local/arm-none-eabi (see my 'laforge/remove-libosmocore' branch in). This also already "works" on my Debian unstable system, in as far as there are no unresolved symbols or other compilation/linking issues, and the firmware images are generated. I have not tested any of the resulting binaries yet, and as I'm travelling without compatible hardware (and overloaded), it's unlikely that I'll be able to test it soon. Nevertheless, this is what I would like to move to. If anyone wants to try if he can build the embedded libosmocore and resulting osmocom-bb from laforge/remove-libosmocore branch, please do so and report your progress/success/issues here. Next steps (after validating the above) are: * remove old sercomm.c code from osmocom-bb and use the new code from libosmocore * remove 'talloc emulation' from osmocom-bb and use pseudotalloc from libosmocore.git (plus an embedded 'malloc' like umm_malloc) Further ideas: * create Debian/Ubuntu package of cross-compiled libosmocore for embedded-arm, which we can add to the Osmocom nightly builds apt repository. * have an (optional?) osmocom-bb makefile step to git clone + configure + make install libosmocore Anyone interested in helping out with this, please feel free to join in. 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 1

Re: CalypsoBTS and modern OsmoBSC
by Vadim Yanitskiy 12 May '17

12 May '17

Hi, > I found that the manual from the main site is outdated. Yeah, still couldn't find some time to update the wiki. > If I understood it correct, I have to setup calypso bts > as bts of type nanoBTS, correct? Why do you think so? No, CalypsoBTS has nothing related toip.access nanoBTS. From the other side, we don't have a dedicated type for OsmoBTS, so you can use 'sysmoBTS'. > I can sync with commercial cell, I can run OsmoBSC and > OsmoBTS but I still cannot find my network from my personal > phone in searching mode. Please watch a great Sylvain's talk, where he explained almost everything you need to know: "Further hacks on the Calypso platform" https://media.ccc.de/v/29c3-5226-en-further_hacks_calypso_h264 In short: BTS should transmit a continuous beacon on C0 to be detected. Normal MS can't do that. CalypsoBTS was hacked to perform the following timeslot layout: Tt_R_ttt, where 'T' means TX on Downlink, 'R' means RX on Uplink, and 't' means channel filling - dummy bursts. Phone cannot RX and TX at the same time, so one phone serves only one TS. With two phones you have the following layout: TT_RRttt, so you have two timeslots served. This is why you will have some detection troubles even with working BSS setup :/ > In logs of osmo-bts I can see: > > <0000> rsl.c:246 Tx RSL RF RESource INDication > <000b> trx_if.c:397 transceiver (phy0.0) rejected TRX command with > response: 'RSP SETTSC -1' > <0000> rsl.c:2353 (bts=0,trx=0,ts=0,ss=0) Rx RSL BCCH_INFO Just delete the 'settsc' line from your config, because CalypsoBTS transceiver only supports 'setbsic'. Have a fun! With best regards, Vadim Yanitskiy.

3 8

Timeslot allocation
by Anton Gorbachev 12 May '17

12 May '17

Dear colleagues, Could you please tell me when I am wrong in my assumptions? My story is about beacon channel. >From different resourses I got the information that we transmit bcch data (fcch,sch,bcch) which is required for MS to find our network. OK? On the pictures it's drawn like we transmit BCCH on C0T0. So DL TS1-7 can be used for i.e. TCH. So if we want just to create bts which can be found by MS and that's all, we may not transmit on TS1-7 at all. OK? When we are talking about CalypsoBTS we say that we must transmit several burst in a row. So here I am a bit confused. So if we want to just transmit bcch messages we can transmit every TS0 and rest on TS1-7. Why not? Why I can see in manuals and videos pictures like Ttt_R_tt? Why do I need these dummy "t" bursts? Why one burst is "t" and another is "T"? Sure I understand that we must receive something for normal BTS operation like RACH and need some time to switch Tx/Rx. But why we just cannot use mask like T_R_T_R_ ...? I understood that we cant use mask TTT_RR because calypso phone was not hacked to receive two bursts in a row. Thanks in advance!

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel May 2017