baseband-devel January 2011

baseband-devel@lists.osmocom.org

71 participants
98 discussions

[PATCH] How to compile osmocom on NetBSD

by Pierre Pronchery

Hi baseband developers, a couple days ago I managed to compile osmocom's binaries and firmware files from a NetBSD host, using a cross-compilation toolchain generated with the standard build script on this system. This was actually quite straightforward, but required some patches and tricks, so I figured it'd be worth posting it here. I will write the procedure in more details on my blog [1], in my case it was enough to do this: $ CPATH="/usr/include" gmake \ CROSS_TOOL_PREFIX="/home/arm/tools/bin/arm--netbsdelf-" The patch itself is certainly more interesting to discuss here. I do not expect it to be fully merged, but I think it may raise interesting points: - src/shared/libosmocore/src/Makefile.am linking with "-ldl" is hardcoded, but breaks the build on systems where it is not required; this is a usual portability issue, already solved about a thousand times, I'll try to come up with a cleaner solution here. - src/shared/libosmocore/src/gsm_utils.c I think this one is quite elegant, allowing to build even without support for backtraces; an additional #warning would help though/ - src/shared/libosmocore/src/msgfile.c here I had to bluntly emulate the functionality of the getline() call, which seems to be specific to glibc; again, it'd certainly be nicer if I added a test for HAVE_GETLINE or something along this line. - src/shared/libosmocore/src/talloc.c again, talloc seems to rely on strnlen() being part of the libc, which is already known to not be the case on MacOS X; considering it also absent of NetBSD fixes the build for me. - src/target/firmware/include/stdint.h this one is definitely more ugly, since I tricked the cross-compiler to believe /usr/include matches its specific needs I ended up with some essential type definitions already; therefore, I am not sure if this workaround would not be more harmful upstream than not. Anyway, the actual patch is attached. A few more things to NetBSD users: - my previous patch about building without GNU make is also necessary; - I haven't tested the resulting binaries on a NetBSD host; - the firmware images seem to be only partly functional at the moment. HTH, -- khorben

14 years, 5 months

Re: Trouble building Osmocom

by Holger Freyther

On 06/08/2010 09:41 PM, Huseyin Turan wrote: > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ls -l arm-elf-gcc > -rwxrwxrwx 1 name1 name1 112344 2006-02-17 23:59 arm-elf-gcc > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ./arm-elf-gcc > bash: ./arm-elf-gcc: cannot execute binary file > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# uname -a > Linux name1-desktop 2.6.28-19-generic #61-Ubuntu SMP Wed May 26 23:35:15 > UTC 2010 i686 GNU/Linux > please try b.) again (you miss the file part) and also please reply to the mailinglist.

14 years, 5 months

Re: Cell_log > gsmmap

by Bogdan Alecu

I just thought of another way of using cell_log without GPS. The resulting KML could be parsed and sent to opencellid project, this way we could get the lat-long coordinates and afterward create another kml and send it to Google. Ex: http://www.opencellid.org/cell/get?mcc=232&mnc=01&cellid=1721&lac=4269

14 years, 5 months

[PATCH] Added command line switches to cell_log to change default gps device and baud rate.

by Dario Lombardo

--- src/host/layer23/src/misc/app_cell_log.c | 17 ++++++++++++++++- 1 files changed, 16 insertions(+), 1 deletions(-) diff --git a/src/host/layer23/src/misc/app_cell_log.c b/src/host/layer23/src/misc/app_cell_log.c index 84f5a83..9c05108 100644 --- a/src/host/layer23/src/misc/app_cell_log.c +++ b/src/host/layer23/src/misc/app_cell_log.c @@ -29,6 +29,7 @@ #include <osmocom/bb/common/l1ctl.h> #include <osmocom/bb/common/l23_app.h> #include <osmocom/bb/common/logging.h> +#include <osmocom/bb/common/gps.h> #include <osmocom/bb/misc/cell_log.h> #include <osmocore/talloc.h> @@ -91,6 +92,8 @@ static int l23_getopt_options(struct option **options) {"logfile", 1, 0, 'l'}, {"rach", 1, 0, 'r'}, {"no-rach", 1, 0, 'n'}, + {"gps", 1, 0, 'g'}, + {"baud", 1, 0, 'b'} }; *options = opts; @@ -103,6 +106,8 @@ static int l23_cfg_print_help() printf(" -l --logfile LOGFILE Logfile for the cell log.\n"); printf(" -r --rach RACH Nr. of RACH bursts to send.\n"); printf(" -n --no-rach Send no rach bursts.\n"); + printf(" -g --gps DEVICE /dev/ttyACM0. GPS device.\n"); + printf(" -b --baud BAUDRATE The baud rate of the GPS device\n"); return 0; } @@ -118,6 +123,16 @@ static int l23_cfg_handle(int c, const char *optarg) case 'n': RACH_MAX = 0; break; + case 'g': + snprintf(gps.device, ARRAY_SIZE(gps.device), "%s", optarg); + /* force string terminator */ + gps.device[ARRAY_SIZE(gps.device - 1)] = '\0'; + LOGP(DGPS, LOGL_INFO, "Using GPS device %s\n", gps.device); + break; + case 'b': + gps.baud = atoi(optarg); + LOGP(DGPS, LOGL_INFO, "Setting GPS baudrate to %u\n", gps.baud); + break; } return 0; @@ -125,7 +140,7 @@ static int l23_cfg_handle(int c, const char *optarg) static struct l23_app_info info = { .copyright = "Copyright (C) 2010 Andreas Eversberg\n", - .getopt_string = "l:r:n", + .getopt_string = "l:r:ng:b:", .cfg_supported = l23_cfg_supported, .cfg_getopt_opt = l23_getopt_options, .cfg_handle_opt = l23_cfg_handle, -- 1.7.3.4 --------------090907080903040108080303--

14 years, 5 months

Re: Cell_log > gsmmap

by Bogdan Alecu

Or even better, use Google API and this way you could also include the Signal strenght and Timing advance for a better position. See http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&… --- On Wed, 1/26/11, Bogdan Alecu <b.alecu(a)yahoo.com> wrote: From: Bogdan Alecu <b.alecu(a)yahoo.com> Subject: Re: Cell_log > gsmmap To: Cc: baseband-devel(a)lists.osmocom.org Date: Wednesday, January 26, 2011, 7:27 AM I just thought of another way of using cell_log without GPS. The resulting KML could be parsed and sent to opencellid project, this way we could get the lat-long coordinates and afterward create another kml and send it to Google. Ex: http://www.opencellid.org/cell/get?mcc=232&mnc=01&cellid=1721&lac=4269

14 years, 5 months

[PATCH] Adjust top-level Makefile for arm-none-eabi toolchain

by Peter Stuge

The gnuarm.com toolchain works fine but is very old. And although it is based on newlib, the os name in the tuple that we used to configure for is arm-elf-linux, which is of course bogus since we are not building Linux applications. Finally, CC= should never be set, instead configure should detect the right compiler using the --host tuple. --- src/Makefile | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/Makefile b/src/Makefile index b3594c1..e66f0ff 100644 --- a/src/Makefile +++ b/src/Makefile @@ -1,10 +1,10 @@ # this is not really used as we don't do 'make install'. You can still specify # it in case you _want_ to manually 'make install' the target libosmocore. -CROSS_INST_PREFIX=/usr/local/stow/osmocom-bb/arm-elf +CROSS_INST_PREFIX ?= /usr/local/stow/osmocom-bb/arm-2010.09 # this is the prefix of your cross-toolchain programs -CROSS_TOOL_PREFIX=arm-elf- +CROSS_TOOL_PREFIX ?= arm-none-eabi- TOPDIR=$(shell pwd) OSMOCORE_CONFIGURE_ENV= LIBOSMOCORE_LIBS=$(TOPDIR)/shared/libosmocore/build-host/src/.libs/libosmocore.a \ @@ -37,9 +37,9 @@ shared/libosmocore/build-target: shared/libosmocore/build-target/Makefile: shared/libosmocore/configure shared/libosmocore/build-target cd shared/libosmocore/build-target && ../configure \ - --host=arm-elf-linux --disable-vty --enable-panic-infloop \ + --host=arm-none-eabi --disable-vty --enable-panic-infloop \ --disable-shared --disable-talloc --disable-tests \ - CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs" + CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs" shared/libosmocore/build-target/src/.libs/libosmocore.a: shared/libosmocore/build-target/Makefile cd shared/libosmocore/build-target && make -- 1.7.2

14 years, 5 months

[PATCH] Adjust top-level Makefile for arm-none-eabi toolchain

by Peter Stuge

The gnuarm.com toolchain works fine but is very old. And although it is based on newlib, the tuple that we used to configure for was arm-elf-linux, which is of course bogus since we aren't building Linux applications. This patch optimizes for the CodeSourcery G++ Lite 2010.09 ARM EABI toolchain, and assumes that it was unpacked next to the old one. Download here: http://www.codesourcery.com/sgpp/lite/arm/portal/release1592 (I haven't gotten the Linux Installer to work, so I recommend the TAR.) And since CC is detected by configure when a valid host tuple is given and that toolchain is sane there's no need for us to hard-code the gnuarm.com compiler name in our Makefile. --- src/Makefile | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/src/Makefile b/src/Makefile index b3594c1..f2d935b 100644 --- a/src/Makefile +++ b/src/Makefile @@ -1,10 +1,13 @@ # this is not really used as we don't do 'make install'. You can still specify # it in case you _want_ to manually 'make install' the target libosmocore. -CROSS_INST_PREFIX=/usr/local/stow/osmocom-bb/arm-elf +CROSS_INST_PREFIX ?= /usr/local/stow/osmocom-bb/arm-2010.09 + +# this is the host tuple of your cross-toolchain +HOST ?= arm-none-eabi- # this is the prefix of your cross-toolchain programs -CROSS_TOOL_PREFIX=arm-elf- +CROSS_TOOL_PREFIX ?= $(CROSS)- TOPDIR=$(shell pwd) OSMOCORE_CONFIGURE_ENV= LIBOSMOCORE_LIBS=$(TOPDIR)/shared/libosmocore/build-host/src/.libs/libosmocore.a \ @@ -37,9 +40,9 @@ shared/libosmocore/build-target: shared/libosmocore/build-target/Makefile: shared/libosmocore/configure shared/libosmocore/build-target cd shared/libosmocore/build-target && ../configure \ - --host=arm-elf-linux --disable-vty --enable-panic-infloop \ + --host=$(HOST) --disable-vty --enable-panic-infloop \ --disable-shared --disable-talloc --disable-tests \ - CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs" + CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs" shared/libosmocore/build-target/src/.libs/libosmocore.a: shared/libosmocore/build-target/Makefile cd shared/libosmocore/build-target && make -- 1.7.2 --dMyqICaxQaaUjrCL--

14 years, 5 months

[PATCH] Adjust top-level Makefile for arm-none-eabi toolchain

by Peter Stuge

The gnuarm.com toolchain works fine but is very old. And although it is based on newlib, the tuple that we used to configure for was arm-elf-linux, which is of course bogus since we aren't building Linux applications. This patch optimizes for the CodeSourcery G++ Lite 2010.09 ARM EABI toolchain, and assumes that it was unpacked next to the old one. Download here: http://www.codesourcery.com/sgpp/lite/arm/portal/release1592 (I haven't gotten the Linux Installer to work, so I recommend the TAR.) And since CC is detected by configure when a valid host tuple is given and that toolchain is sane there's no need for us to hard-code the gnuarm.com compiler name in our Makefile. --- src/Makefile | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/src/Makefile b/src/Makefile index b3594c1..bb34175 100644 --- a/src/Makefile +++ b/src/Makefile @@ -1,10 +1,13 @@ # this is not really used as we don't do 'make install'. You can still specify # it in case you _want_ to manually 'make install' the target libosmocore. -CROSS_INST_PREFIX=/usr/local/stow/osmocom-bb/arm-elf +CROSS_INST_PREFIX ?= /usr/local/stow/osmocom-bb/arm-2010.09 + +# this is the host tuple of your cross-toolchain +HOST ?= arm-none-eabi- # this is the prefix of your cross-toolchain programs -CROSS_TOOL_PREFIX=arm-elf- +CROSS_TOOL_PREFIX ?= $(HOST)- TOPDIR=$(shell pwd) OSMOCORE_CONFIGURE_ENV= LIBOSMOCORE_LIBS=$(TOPDIR)/shared/libosmocore/build-host/src/.libs/libosmocore.a \ @@ -37,9 +40,9 @@ shared/libosmocore/build-target: shared/libosmocore/build-target/Makefile: shared/libosmocore/configure shared/libosmocore/build-target cd shared/libosmocore/build-target && ../configure \ - --host=arm-elf-linux --disable-vty --enable-panic-infloop \ + --host=$(HOST) --disable-vty --enable-panic-infloop \ --disable-shared --disable-talloc --disable-tests \ - CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs" + CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs" shared/libosmocore/build-target/src/.libs/libosmocore.a: shared/libosmocore/build-target/Makefile cd shared/libosmocore/build-target && make -- 1.7.2 --nEsDIrWrg+hrB7l1--

14 years, 5 months

[PATCH] Allow top-level Makefile to use arm-none-eabi toolchain

by Peter Stuge

The gnuarm.com toolchain works fine but is very old. And although it is based on newlib, the tuple that we used to configure for was arm-elf-linux, which is bogus since we aren't building for Linux. This patch optimizes for the CodeSourcery G++ Lite 2010.09 ARM EABI toolchain instead, and for libosmocore installation it assumes that the new toolchain was unpacked next to the old one. Download it here: http://www.codesourcery.com/sgpp/lite/arm/portal/release1592 (The Linux Installer seems not to work reliably so I recommend the TAR.) Since CC is detected by configure when the host tuple points to a sane toolchain we shouldn't hard-code the gnuarm.com compiler. The patch autodetects arm-elf-gcc installed in PATH, and uses arm-elf as prefix if it is found. Otherwise, it defaults to arm-none-eabi. make CROSS_HOST=arm-xyzzy can be used to override on the command line. --- src/Makefile | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/src/Makefile b/src/Makefile index b3594c1..402f28a 100644 --- a/src/Makefile +++ b/src/Makefile @@ -1,10 +1,13 @@ # this is not really used as we don't do 'make install'. You can still specify # it in case you _want_ to manually 'make install' the target libosmocore. -CROSS_INST_PREFIX=/usr/local/stow/osmocom-bb/arm-elf +CROSS_INST_PREFIX ?= /usr/local/stow/osmocom-bb/arm-2010.09 + +# this is the host tuple of your cross-toolchain +CROSS_HOST ?= $(shell which arm-elf-gcc >/dev/null 2>&1 && echo arm-elf || echo arm-none-eabi) # this is the prefix of your cross-toolchain programs -CROSS_TOOL_PREFIX=arm-elf- +CROSS_TOOL_PREFIX=$(CROSS_HOST)- TOPDIR=$(shell pwd) OSMOCORE_CONFIGURE_ENV= LIBOSMOCORE_LIBS=$(TOPDIR)/shared/libosmocore/build-host/src/.libs/libosmocore.a \ @@ -37,9 +40,9 @@ shared/libosmocore/build-target: shared/libosmocore/build-target/Makefile: shared/libosmocore/configure shared/libosmocore/build-target cd shared/libosmocore/build-target && ../configure \ - --host=arm-elf-linux --disable-vty --enable-panic-infloop \ + --host=$(CROSS_HOST) --disable-vty --enable-panic-infloop \ --disable-shared --disable-talloc --disable-tests \ - CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs" + CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs" shared/libosmocore/build-target/src/.libs/libosmocore.a: shared/libosmocore/build-target/Makefile cd shared/libosmocore/build-target && make -- 1.7.2 --ibvzjYYg+QDzMCy1--

14 years, 5 months

C99 [was Fwd: Cell_log > gsmmap]

by Dieter Spaar

Hello Holger, On Tue, 25 Jan 2011 16:51:02 +0100, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote: > > Almost perfect. I can apply and modify myself or you could do two things. We > tend to avoid the '//' comments, they were only added in C99 and used to be a > GCC extension for C. This is a good one ;-) One of the biggest problems when I tried a long time ago to compile any of OpenBSC or OsmocomBB with a different compiler than GCC were designated initializer which are _heavily_ used all over the sources (I don't question their advantage, I only mention it). They are a C99 feature (besides the library function snprintf() in the patch you commented). So I would not care about the '//', this was the smallest problem I had when I did my porting experiment (in fact the compilers I am aware of silently accept it). Just out of interest, do we really want to to avoid C99 ? I know there is this implicit "kernel style" coding rule, does it include C99 ? Please note that I don't want to discuss this, I use GCC from Cygwin and can find workarounds for Linux specific issues on Windows on my own, so I don't care that much. I am just interested in the reasons for using C99 or not. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

14 years, 5 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel January 2011