From laforge at gnumonks.org Sat Jun 26 10:04:59 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jun 2010 12:04:59 +0200 Subject: Request for help with PA power measurements In-Reply-To: <4BE82D5D.1080708@steve-m.de> References: <20100505114119.GJ6543@prithivi.gnumonks.org> <20100505164413.GE19231@prithivi.gnumonks.org> <4BE82D5D.1080708@steve-m.de> Message-ID: <20100626100459.GZ3890@prithivi.gnumonks.org> Hi Steve, On Mon, May 10, 2010 at 05:59:25PM +0200, Steve Markgraf wrote: > >Similar to the VCTCXO measurements, we also need to do RF-PA output > >power measurements. The Racal 6103 can measure the power level of > >bursts we transmit. > > Attached to this mail you'll find my measurements in GSM900, ARFCN 33. Thanks again. After doing AGC, I'm right now finally working on the uplink power control code and will incorporate your table in one or the other form. > I've done some short tests for DCS1800 and higher ARFCNs in GSM900 > as well, so far the offsets to my measurements seem to be linear, so > we can most likely use a correction value and don't need to store > everything twice. This sounds great. > I'll investigate in this later... Did you ever get around doing this? I'd be more than interested in some of those values. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From fyproject14 at gmail.com Sun Jun 6 05:47:43 2010 From: fyproject14 at gmail.com (Zaki Ud Din) Date: Sun, 6 Jun 2010 10:47:43 +0500 Subject: Building Osmocom Message-ID: Hello, I am a little new to ubuntu and am trying to build osmocom-bb but i am facing some problems in doing so. I found your emial address in the .c files present in the Osmocom-bb folder. I have downloaded the GNU toolchain for ARM which is the first step in building Osmocom. But I am not able to understand the second step in which I have to set a path to include the arm-elf-* executables of the toolchain. Would you please help me on this? Awaiting your response, Zaki. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at hvitehus.no Sun Jun 6 07:37:38 2010 From: frank at hvitehus.no (Frank A. Stevenson) Date: Sun, 06 Jun 2010 09:37:38 +0200 Subject: Building Osmocom In-Reply-To: References: Message-ID: <1275809858.13671.7.camel@quant> On Sun, 2010-06-06 at 10:47 +0500, Zaki Ud Din wrote: > Hello, > > I am a little new to ubuntu and am trying to build osmocom-bb but i am > facing some problems in doing so. I found your emial address in the .c > files present in the Osmocom-bb folder. I have downloaded the GNU > toolchain for ARM which is the first step in building Osmocom. But I > am not able to understand the second step in which I have to set a > path to include the arm-elf-* executables of the toolchain. Would you > please help me on this? > > Awaiting your response, > > Zaki. I used an existing gnuarm toolchain that I had compiled long time ago, but I think this step may be unnecessary for for most users. When I tried repeating this step on another PC - Ubuntu threw up a a series of dependency errors between G++ and binutils, and I just didn't bother with recompiling the gnuarm chain again. I could probably have copied it from one machine to the other, but the simplest route was simply copying the layer1 bin file across. I have put my build here: http://traxme.net/a5/layer1.ramload.bin Then all you have to do is make osmocon make layer23 And you have the executables you need to get started. F From tiago.maluta at gmail.com Sun Jun 6 11:58:03 2010 From: tiago.maluta at gmail.com (Tiago Maluta) Date: Sun, 6 Jun 2010 11:58:03 +0000 Subject: Building Osmocom In-Reply-To: References: Message-ID: On Sun, Jun 6, 2010 at 5:47 AM, Zaki Ud Din wrote: > Hello, > > I am a little new to ubuntu and am trying to build osmocom-bb but i am > facing some problems in doing so. I found your emial address in the .c files > present in the Osmocom-bb folder. I have downloaded the GNU toolchain for > ARM which is the first step in building Osmocom. But I am not able to > understand the second step in which I have to set a path to include the > arm-elf-* executables of the toolchain. Would you please help me on this? > You must update the PATH environment variable with the toolchain info. Suppose your arm-elf-* toolchain are in /opt/arm/toolchain/bin $ export PATH=/opt/arm/toolchain/bin:$PATH This will be valid only to the current shell instance. To use by every instance you could, for example, put the command in your ~/.bashrc file. So, when you start new sessions arm-elf-* is accessible. --tm From jal2 at gmx.de Sun Jun 6 13:28:01 2010 From: jal2 at gmx.de (Joerg Albert) Date: Sun, 06 Jun 2010 15:28:01 +0200 Subject: Building Osmocom In-Reply-To: References: Message-ID: <4C0BA261.2030209@gmx.de> On 06/06/2010 07:47 AM, Zaki Ud Din wrote: > I am a little new to ubuntu and am trying to build osmocom-bb but i am > facing some problems in doing so. I found your emial address in the .c > files present in the Osmocom-bb folder. I have downloaded the GNU > toolchain for ARM which is the first step in building Osmocom. But I am > not able to understand the second step in which I have to set a path to > include the arm-elf-* executables of the toolchain. Would you please > help me on this? Try in a terminal window (Applications/Accessory/Terminal): export PATH=path_to_the_arm_elf_bin:$PATH with path_to_the_arm_elf_bin is the path to the arm-elf-* executables downloaded previously, e.g. export PATH=/mnt/tools/gcc-arm/selfmade/bin:$PATH Call "make" afterwards in this terminal window. The set PATH is restricted to the terminal window. HTH, Joerg From fyproject14 at gmail.com Sun Jun 6 20:21:01 2010 From: fyproject14 at gmail.com (Zaki Ud Din) Date: Mon, 7 Jun 2010 01:21:01 +0500 Subject: Trouble building Osmocom Message-ID: Hello, I have been trying to build osmocom but have been getting errors in doing so. Firstly, I downloaded the following file,"* binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]*" under GCC-4.0 toolchain from www.gnuarm.com and extracted this to my home folder. Secondly, I gave the following path "export PATH=/gnuarm-4.0.2/arm-elf/ bin:$PATH" in terminal window. Afterwards when I entered "make" under "/osmosom-bb/src", I got the following errors zaki at zaki-desktop:~/osmocom-bb/src$ make cd shared/libosmocore/build-host && make make[1]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make all-recursive make[2]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' Making all in include make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' Making all in osmocore make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' Making all in protocol make[5]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' make[5]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' make[5]: Nothing to be done for `all-am'. make[5]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' Making all in src make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' Making all in tests make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' Making all in timer make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' Making all in sms make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make[2]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make[1]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' cd shared/libosmocore/build-target && ../configure \ --host=arm-elf-linux --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 a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for arm-elf-linux-strip... no checking for strip... strip checking whether make sets $(MAKE)... (cached) yes checking for arm-elf-linux-gcc... arm-elf-gcc checking for C compiler default output file name... configure: error: in `/home/zaki/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 I shall be grateful to you if you could help me on this. Awaiting your Response, Zaki. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fyproject14 at gmail.com Mon Jun 7 15:04:56 2010 From: fyproject14 at gmail.com (Zaki Ud Din) Date: Mon, 7 Jun 2010 20:04:56 +0500 Subject: Trouble building Osmocom In-Reply-To: References: Message-ID: Hello, I have built 'osmocon' and 'layer23' by using 'make osmocon' and 'make layer23' respectively in the terminal window. I get the same errors that I have written in my previous mail when i enter 'make firmware'. That means that my toolchain is running fine, it has something to do with the firmware. Please help me on this. Awaiting your response, Zaki. On Mon, Jun 7, 2010 at 1:21 AM, Zaki Ud Din wrote: > Hello, > > I have been trying to build osmocom but have been getting errors in doing > so. > > Firstly, I downloaded the following file,"* binutils-2.16.1, > gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]*" under > GCC-4.0 toolchain from www.gnuarm.com and extracted this to my home > folder. > > Secondly, I gave the following path "export PATH=/gnuarm-4.0.2/arm-elf/ > bin:$PATH" in terminal window. Afterwards when I entered "make" under > "/osmosom-bb/src", I got the following errors > > zaki at zaki-desktop:~/osmocom-bb/src$ make > cd shared/libosmocore/build-host && make > make[1]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make all-recursive > make[2]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > Making all in include > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > Making all in osmocore > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > Making all in protocol > make[5]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' > make[5]: Nothing to be done for `all'. > make[5]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' > make[5]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[5]: Nothing to be done for `all-am'. > make[5]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > Making all in src > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' > Making all in tests > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > Making all in timer > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' > Making all in sms > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[2]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[1]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > cd shared/libosmocore/build-target && ../configure \ > --host=arm-elf-linux --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 a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... no > checking for mawk... mawk > checking whether make sets $(MAKE)... yes > checking for arm-elf-linux-strip... no > checking for strip... strip > checking whether make sets $(MAKE)... (cached) yes > > checking for arm-elf-linux-gcc... arm-elf-gcc > checking for C compiler default output file name... > configure: error: in > `/home/zaki/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 > > I shall be grateful to you if you could help me on this. > > Awaiting your Response, > > Zaki. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Mon Jun 7 15:49:16 2010 From: zecke at selfish.org (Holger Freyther) Date: Mon, 07 Jun 2010 23:49:16 +0800 Subject: Trouble building Osmocom In-Reply-To: References: Message-ID: <4C0D14FC.9090800@selfish.org> On 06/07/2010 11:04 PM, Zaki Ud Din wrote: > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-target': > configure: error: C compiler cannot create executables > See `config.log' for more details. Hi Zaki, you can look at the config.log file (created by autoconf), it should have a line with "C compiler cannot"... and it should show the C program that it tried to compile and the failure message of the compiler... What does it say? From wolfram at the-dreams.de Mon Jun 7 16:12:18 2010 From: wolfram at the-dreams.de (Wolfram Sang) Date: Mon, 07 Jun 2010 18:12:18 +0200 Subject: Trouble building Osmocom In-Reply-To: <4C0D14FC.9090800@selfish.org> References: <4C0D14FC.9090800@selfish.org> Message-ID: <4C0D1A62.7000104@the-dreams.de> Holger Freyther wrote: > On 06/07/2010 11:04 PM, Zaki Ud Din wrote: > >> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-target': >> configure: error: C compiler cannot create executables >> See `config.log' for more details. > you can look at the config.log file (created by autoconf), it should > have a line with "C compiler cannot"... and it should show the C program > that it tried to compile and the failure message of the compiler... What > does it say? Isn't this probably the same as [1] and following? Regards, Wolfram [1] http://lists.osmocom.org/pipermail/baseband-devel/2010-March/000139.html From zecke at selfish.org Mon Jun 7 16:49:18 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 08 Jun 2010 00:49:18 +0800 Subject: Trouble building Osmocom In-Reply-To: <4C0D1A62.7000104@the-dreams.de> References: <4C0D14FC.9090800@selfish.org> <4C0D1A62.7000104@the-dreams.de> Message-ID: <4C0D230E.4050200@selfish.org> On 06/08/2010 12:12 AM, Wolfram Sang wrote: > Holger Freyther wrote: > > Isn't this probably the same as [1] and following? Sounds likely and memory is slowly paged back in... I assume we never finished that patch. :} love z. From fyproject14 at gmail.com Tue Jun 8 10:26:15 2010 From: fyproject14 at gmail.com (Zaki Ud Din) Date: Tue, 8 Jun 2010 15:26:15 +0500 Subject: Trouble building Osmocom In-Reply-To: References: Message-ID: Hello, Thank you very much for your reply. No my config.log file seems to be different. I am pasting a portion of config.log file below and am also attaching the complete file with this email. configure:2074: checking for a BSD-compatible install configure:2142: result: /usr/bin/install -c configure:2153: checking whether build environment is sane configure:2196: result: yes configure:2221: checking for a thread-safe mkdir -p configure:2260: result: /bin/mkdir -p configure:2273: checking for gawk configure:2303: result: no configure:2273: checking for mawk configure:2289: found /usr/bin/mawk configure:2300: result: mawk configure:2311: checking whether make sets $(MAKE) configure:2333: result: yes configure:2413: checking for arm-elf-linux-strip configure:2443: result: no configure:2453: checking for strip configure:2469: found /usr/bin/strip configure:2480: result: strip configure:2520: checking whether make sets $(MAKE) configure:2542: result: yes configure:2559: checking for arm-elf-linux-gcc configure:2586: result: arm-elf-gcc configure:2858: checking for C compiler version configure:2866: arm-elf-gcc --version >&5 ../configure: line 2868: arm-elf-gcc: command not found configure:2870: $? = 127 configure:2877: arm-elf-gcc -v >&5 ../configure: line 2879: arm-elf-gcc: command not found configure:2881: $? = 127 configure:2888: arm-elf-gcc -V >&5 ../configure: line 2890: arm-elf-gcc: command not found configure:2892: $? = 127 configure:2915: checking for C compiler default output file name configure:2937: arm-elf-gcc -Os -ffunction-sections -I../../../../target/firmware/include conftest.c >&5 ../configure: line 2939: arm-elf-gcc: command not found configure:2941: $? = 127 configure:2979: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "libosmocore" | #define PACKAGE_TARNAME "libosmocore" | #define PACKAGE_VERSION "UNKNOWN" | #define PACKAGE_STRING "libosmocore UNKNOWN" | #define PACKAGE_BUGREPORT "openbsc-devel at lists.openbsc.org" | #define PACKAGE "libosmocore" | #define VERSION "UNKNOWN" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2985: error: in `/home/zaki/osmocom-bb/src/shared/libosmocore/build-target': configure:2988: error: C compiler cannot create executables See `config.log' for more details. Awaiting your response, Zaki. On Mon, Jun 7, 2010 at 1:21 AM, Zaki Ud Din wrote: > Hello, > > I have been trying to build osmocom but have been getting errors in doing > so. > > Firstly, I downloaded the following file,"* binutils-2.16.1, > gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]*" under > GCC-4.0 toolchain from www.gnuarm.com and extracted this to my home > folder. > > > Secondly, I gave the following path "export PATH=/gnuarm-4.0.2/arm-elf/ > bin:$PATH" in terminal window. Afterwards when I entered "make" under > "/osmosom-bb/src", I got the following errors > > zaki at zaki-desktop:~/osmocom-bb/src$ make > cd shared/libosmocore/build-host && make > make[1]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make all-recursive > make[2]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > Making all in include > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > Making all in osmocore > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > Making all in protocol > make[5]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' > make[5]: Nothing to be done for `all'. > make[5]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' > make[5]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[5]: Nothing to be done for `all-am'. > make[5]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > Making all in src > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' > Making all in tests > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > Making all in timer > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' > Making all in sms > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[2]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[1]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > cd shared/libosmocore/build-target && ../configure \ > --host=arm-elf-linux --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 a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... no > checking for mawk... mawk > checking whether make sets $(MAKE)... yes > checking for arm-elf-linux-strip... no > checking for strip... strip > checking whether make sets $(MAKE)... (cached) yes > > checking for arm-elf-linux-gcc... arm-elf-gcc > checking for C compiler default output file name... > configure: error: in > `/home/zaki/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 > > I shall be grateful to you if you could help me on this. > > Awaiting your Response, > > Zaki. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: text/x-log Size: 7064 bytes Desc: not available URL: From 246tnt at gmail.com Tue Jun 8 10:43:19 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 8 Jun 2010 12:43:19 +0200 Subject: Trouble building Osmocom In-Reply-To: References: Message-ID: This seems pretty clear : > ../configure: line 2939: arm-elf-gcc: command not found Make sure you have a good ARM toolchain installed ... (look it up on google, plenty of doc on how to install one). ? ?Sylvain From ken at codelabs.ch Tue Jun 8 10:44:56 2010 From: ken at codelabs.ch (Adrian-Ken Rueegsegger) Date: Tue, 08 Jun 2010 12:44:56 +0200 Subject: Trouble building Osmocom In-Reply-To: References: Message-ID: <4C0E1F28.2080702@codelabs.ch> Hi, Zaki Ud Din schrieb: > Hello, > > Thank you very much for your reply. No my config.log file seems to be > different. I am pasting a portion of config.log file below and am also > attaching the complete file with this email. [snip] > configure:2866: arm-elf-gcc --version >&5 > ../configure: line 2868: arm-elf-gcc: command not found > configure:2870: $? = 127 > configure:2877: arm-elf-gcc -v >&5 > ../configure: line 2879: arm-elf-gcc: command not found > configure:2881: $? = 127 > configure:2888: arm-elf-gcc -V >&5 > ../configure: line 2890: arm-elf-gcc: command not found > configure:2892: $? = 127 > configure:2915: checking for C compiler default output file name > configure:2937: arm-elf-gcc -Os -ffunction-sections > -I../../../../target/firmware/include conftest.c >&5 > ../configure: line 2939: arm-elf-gcc: command not found It does not find the toolchain/cross-compiler. Where did you install/unpack the toolchain? Please check that it is really in "/gnuarm-4.0.2/arm-elf/bin". Otherwise you have to export the proper path. -Adrian From zecke at selfish.org Tue Jun 8 11:02:43 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 08 Jun 2010 19:02:43 +0800 Subject: Trouble building Osmocom In-Reply-To: References: Message-ID: <4C0E2353.7070401@selfish.org> On 06/08/2010 06:26 PM, Zaki Ud Din wrote: > configure:2915: checking for C compiler default output file name > configure:2937: arm-elf-gcc -Os -ffunction-sections > -I../../../../target/firmware/include conftest.c >&5 > ../configure: line 2939: arm-elf-gcc: command not found What is the name of your cross compiler? Is it arm-elf-gcc or is it named differently? Is it in your PATH? good luck z. From bjoern.riemer at fokus.fraunhofer.de Tue Jun 8 11:07:30 2010 From: bjoern.riemer at fokus.fraunhofer.de (Riemer, Bjoern) Date: Tue, 8 Jun 2010 13:07:30 +0200 Subject: AW: Trouble building Osmocom In-Reply-To: References: Message-ID: <79C0EA6E7AD7CE4A85EDAF482B5456B2024055A6@EXCHSRV.fokus.fraunhofer.de> Hi You say that you unpacked the gcc compiler to your home directory and then set you path to PATH=/gnuarm-4.0.2/arm-elf/bin:$PATH .. Unless your home directory is set to / the path to the gcc compiler is wrong. bjoern Von: baseband-devel-bounces at lists.osmocom.org [mailto:baseband-devel-bounces at lists.osmocom.org] Im Auftrag von Zaki Ud Din Gesendet: Sonntag, 6. Juni 2010 22:21 An: baseband-devel at lists.osmocom.org Betreff: Trouble building Osmocom Hello, I have been trying to build osmocom but have been getting errors in doing so. Firstly, I downloaded the following file," binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]" under GCC-4.0 toolchain from www.gnuarm.com and extracted this to my home folder. Secondly, I gave the following path "export PATH=/gnuarm-4.0.2/arm-elf/ bin:$PATH" in terminal window. Afterwards when I entered "make" under "/osmosom-bb/src", I got the following errors zaki at zaki-desktop:~/osmocom-bb/src$ make cd shared/libosmocore/build-host && make make[1]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make all-recursive make[2]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' Making all in include make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' Making all in osmocore make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocor e' Making all in protocol make[5]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocor e/protocol' make[5]: Nothing to be done for `all'. make[5]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocor e/protocol' make[5]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocor e' make[5]: Nothing to be done for `all-am'. make[5]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocor e' make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocor e' make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' Making all in src make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' Making all in tests make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' Making all in timer make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' Making all in sms make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' make[4]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' make[4]: Nothing to be done for `all-am'. make[4]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' make[3]: Entering directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make[3]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make[2]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' make[1]: Leaving directory `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' cd shared/libosmocore/build-target && ../configure \ --host=arm-elf-linux --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 a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for arm-elf-linux-strip... no checking for strip... strip checking whether make sets $(MAKE)... (cached) yes checking for arm-elf-linux-gcc... arm-elf-gcc checking for C compiler default output file name... configure: error: in `/home/zaki/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 I shall be grateful to you if you could help me on this. Awaiting your Response, Zaki. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Mon Jun 7 07:49:58 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Mon, 7 Jun 2010 09:49:58 +0200 Subject: state of layer23 Message-ID: hi, if you pull the git, you will notice that i submitted the lapdm code i was working on. location update with app_mobile works now. (at least for the combined BCCH+CCCH+SDCCH4) the best way to test the location update is to setup a mobile test card to manual network selection, and to set the registered PLMN to the tester's network. see VTY interface for more. what happens: - the previously store ba-list of frequencies is used to search for the registered PLMN. since there is only one frequency on a tester, the power measurement is done on this frequency only. - the power measurement result is positive, so a sync request is made to that channel. - the sync is indicated by layer 1. - the BCCH data is received. the cell is "suitable and allowable". - a sync request is done again, because this cell is the one to "camp on". - a sync request is done again, because the mobility management process makes a location update and requests a channel from the radio ressource. - the sync is confirmed by layer 1. - after syncing to the channel the layer 2 is activated by the BTS. - the location updating request is sent and messages are exchanged until the location update is complete. - the layer 2 is de-activated by the BTS. - the release of layer 2 is currently not processed by RR, so the timout aborts the radio link. (but this is fixed soon) but there are problem: 1. the layer 1 sometimes crashes when sending frames. i guess there is no queue inside... i currently don't care about any confirm of a frame, so i send all frames i need to send. i would like to get a confirm when a frame is sent, so i can send the next frame without making layer 1 overflow. this confirm would also be handy for RACH requests when they are sent. since there are only few message during a location update or a call, i think this is not much overhead. when requesting sync/rach again, all pending frames (RACH request / transmit data) shall be removed inside layer 1. 2. when sending two sync requests to layer 1 without a delay, the layer 1 crashes. i expect to do a sync request at any time. also when sending a sync request before i got a response, i do not know to which the response belongs to which request. (delayed on the serial line) a confirm of every sync request would be handy, so i can wait for this confirm until i make another sync request to a different channel. this confirm just tells me that the layer 1 has received the sync request and is able to receive another sync request. also when syncing to a different channel, i skip any sync result or received frames until i get the confirm, so i can skip any data from the last channel i was synced to. andreas From micheal1414 at gmail.com Mon Jun 7 11:11:17 2010 From: micheal1414 at gmail.com (Micheal Johnson) Date: Mon, 7 Jun 2010 16:11:17 +0500 Subject: General Info Message-ID: Hello, Can this project be used to transmit gsm packets from the mobile phone? Regards, Micheal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fyproject14 at gmail.com Tue Jun 8 11:59:23 2010 From: fyproject14 at gmail.com (Zaki Ud Din) Date: Tue, 8 Jun 2010 16:59:23 +0500 Subject: Trouble building Osmocom Message-ID: Hello, Thank you very much for your reply. I am using ,"* binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]*" under GCC-4.0 toolchain from www.gnuarm.com. I then extracted to the folder named "Zaki". I did export the path using the following line "export PATH=$PATH:/home/zaki/gnuarm- 4.0.2/arm-elf/bin/ " and afterwards I typed "make firmware" and then got the errors I told you. Awaiting your response, Zaki. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zecke at selfish.org Tue Jun 8 12:05:45 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 08 Jun 2010 20:05:45 +0800 Subject: Trouble building Osmocom In-Reply-To: References: Message-ID: <4C0E3219.7040103@selfish.org> On 06/08/2010 07:59 PM, Zaki Ud Din wrote: > Hello, > I did export the path using the following line "export > PATH=$PATH:/home/zaki/gnuarm- > 4.0.2/arm-elf/bin/ " and afterwards I typed "make firmware" and then got > the errors I told you. > > Awaiting your response, Well, it claims to not find arm-elf-gcc. Have you considered checking that this application exists? e.g. does which arm-elf-gcc lead to anything? From zecke at selfish.org Tue Jun 8 13:12:05 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 08 Jun 2010 21:12:05 +0800 Subject: Trouble building Osmocom In-Reply-To: References: <4C0E3219.7040103@selfish.org> Message-ID: <4C0E41A5.8030304@selfish.org> On 06/08/2010 09:01 PM, Huseyin Turan wrote: > checking for gcc... gcc > checking for C compiler default output file name... > configure: error: in > `/home/name1/osmocom/osmocom-bb/src/shared/libosmocore/build-host': > configure: error: C compiler cannot create executables > See `config.log' for more details. Looking at the log file is always a good idea. It might have an eye opening effect.... > > That is; in gnuarm-4.0.2/arm-elf/bin there are executables like > gcc,g++,etc. which can be executed. > in gnuarm-4.0.2/bin there are executables like > arm-elf-gcc,arm-elf-g++,etc. which can not be executed. > > Which path is true? You want to use your normal gcc and such, so putting gnuarm-4.0.2/arm-elf/bin in your path is not that clever. What is the issue with arm-elf-gcc? What happens when you try to execute it? From zecke at selfish.org Tue Jun 8 13:31:59 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 08 Jun 2010 21:31:59 +0800 Subject: Trouble building Osmocom In-Reply-To: References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> Message-ID: <4C0E464F.1050601@selfish.org> On 06/08/2010 09:24 PM, Huseyin Turan wrote: > name1 at name1-desktop:~/osmocom/gnuarm-4.0.2/bin$ ./arm-elf-gcc > bash: ./arm-elf-gcc: cannot execute binary file Why is that the case? The basic checks are a.) did the +x bit go missing on that file? b.) file ./arm-elf-gcc tells you what architecture is that? uname -a tells you what architecture are you running on? c.) when the above fails, we will talk about it... From zecke at selfish.org Tue Jun 8 13:46:59 2010 From: zecke at selfish.org (Holger Freyther) Date: Tue, 08 Jun 2010 21:46:59 +0800 Subject: Trouble building Osmocom In-Reply-To: References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> <4C0E464F.1050601@selfish.org> Message-ID: <4C0E49D3.9060400@selfish.org> On 06/08/2010 09:41 PM, Huseyin Turan wrote: > root at 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 at name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ./arm-elf-gcc > bash: ./arm-elf-gcc: cannot execute binary file > root at 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. From huseyinturan at gmail.com Tue Jun 8 13:51:06 2010 From: huseyinturan at gmail.com (Huseyin Turan) Date: Tue, 8 Jun 2010 16:51:06 +0300 Subject: Trouble building Osmocom In-Reply-To: <4C0E49D3.9060400@selfish.org> References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> <4C0E464F.1050601@selfish.org> <4C0E49D3.9060400@selfish.org> Message-ID: Sorry; file ./arm-elf-gcc ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue Jun 8 13:57:22 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 8 Jun 2010 15:57:22 +0200 Subject: Trouble building Osmocom In-Reply-To: <4C0E49D3.9060400@selfish.org> References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> <4C0E464F.1050601@selfish.org> <4C0E49D3.9060400@selfish.org> Message-ID: Looking at gnuarm.com, it looks like you have a x86_64 toolchain and try to run it on i686. Honestly I don't want to be mean but if you can't see what's wrong with that, osmocom-bb might not be for you quite just yet. From bouchtaoui at gmail.com Tue Jun 8 14:26:08 2010 From: bouchtaoui at gmail.com (Nordin) Date: Tue, 08 Jun 2010 16:26:08 +0200 Subject: Trouble building Osmocom In-Reply-To: References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> <4C0E464F.1050601@selfish.org> <4C0E49D3.9060400@selfish.org> Message-ID: <4C0E5300.1020604@gmail.com> On 8-6-2010 15:57, Sylvain Munaut wrote: > Honestly I don't want to be mean but if you can't see what's wrong > with that, osmocom-bb might not be for you quite just yet. > Maybe he's good in programming embedded stuff, this has purely to do with Linux specific builds and nothing to do with coding/decoding gsm stuff. By the way, he can always learn... From 246tnt at gmail.com Tue Jun 8 15:07:42 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 8 Jun 2010 17:07:42 +0200 Subject: Trouble building Osmocom In-Reply-To: <4C0E5300.1020604@gmail.com> References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> <4C0E464F.1050601@selfish.org> <4C0E49D3.9060400@selfish.org> <4C0E5300.1020604@gmail.com> Message-ID: > Maybe he's good in programming embedded stuff, this has purely to do with > Linux specific builds and nothing to do with coding/decoding gsm stuff. I never meant otherwise in my previous message. But basic knowledge / problem solving of the build system is a requirement IMHO, especially in this project (that includes both host and target code with even some shared code between the two). I also looked up his history on the various mailing lists before posting this and this is not the first build problem with GSM related projects so I would expect him to learn from previous experience. Also, when I see a message with : ---- zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux ---- And he still asks what's wrong ? An embedded programmer that doesn't know he can't just run binaries from one architecture onto another architecture ... > By the way, he can always learn... I know, that's why there is a "quite just yet" at the end. That's exactly what I implied: that he learns that first and then come back. Cheers, Sylvain From bouchtaoui at gmail.com Tue Jun 8 15:24:35 2010 From: bouchtaoui at gmail.com (Nordin) Date: Tue, 08 Jun 2010 17:24:35 +0200 Subject: Trouble building Osmocom In-Reply-To: References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> <4C0E464F.1050601@selfish.org> <4C0E49D3.9060400@selfish.org> <4C0E5300.1020604@gmail.com> Message-ID: <4C0E60B3.9040109@gmail.com> Silvain, Yes I agree with you, but I just want to note that we have to encourage beginners to keep trying and learning. Especially when one comes from the Windows world like me, where everything builds magically in Visual Studio (debugging is a joy in there ;-) Never programmed in Linux, never used git, gdb, vim, etc... and now, I begin to rock a little bit, thnx to OpenBSC and you guys ;-) On 8-6-2010 17:07, Sylvain Munaut wrote: >> Maybe he's good in programming embedded stuff, this has purely to do with >> Linux specific builds and nothing to do with coding/decoding gsm stuff. >> > I never meant otherwise in my previous message. But basic knowledge / > problem solving of the build system is a requirement IMHO, especially > in this project (that includes both host and target code with even > some shared code between the two). > > I also looked up his history on the various mailing lists before > posting this and this is not the first build problem with GSM related > projects so I would expect him to learn from previous experience. > > > Also, when I see a message with : > > ---- > zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc > ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped > zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a > Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 > 01:57:59 UTC 2009 i686 GNU/Linux > ---- > > And he still asks what's wrong ? An embedded programmer that doesn't > know he can't just run binaries from one architecture onto another > architecture ... > > > > >> By the way, he can always learn... >> > I know, that's why there is a "quite just yet" at the end. That's > exactly what I implied: that he learns that first and then come back. > > > Cheers, > > Sylvain > > From holger at freyther.de Wed Jun 9 04:31:46 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 09 Jun 2010 12:31:46 +0800 Subject: Trouble building Osmocom In-Reply-To: <4C0E60B3.9040109@gmail.com> References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> <4C0E464F.1050601@selfish.org> <4C0E49D3.9060400@selfish.org> <4C0E5300.1020604@gmail.com> <4C0E60B3.9040109@gmail.com> Message-ID: <4C0F1932.7040903@freyther.de> On 06/08/2010 11:24 PM, Nordin wrote: > Silvain, > > Yes I agree with you, but I just want to note that we have to encourage > beginners to keep trying and learning. > Especially when one comes from the Windows world like me, where > everything builds magically in Visual Studio (debugging is a joy in > there ;-) > Never programmed in Linux, never used git, gdb, vim, etc... and now, I > begin to rock a little bit, thnx to OpenBSC and you guys ;-) Hi Nordin, I wouldn't have the skills I have now if it wouldn't be due to others help. And of course I know file and uname and it is new to others. The biggest problem I have is judging is someone is just lazy, or if there is someone who is slow to start but eager to learn. how would you figure that out? z. PS: Would you be willing to help me to go through the documentation and provide some more getting started information? At least two have downloaded a wrong toolchain, I am pretty sure this will happen again. From bouchtaoui at gmail.com Wed Jun 9 09:36:41 2010 From: bouchtaoui at gmail.com (Nordin) Date: Wed, 09 Jun 2010 11:36:41 +0200 Subject: Trouble building Osmocom In-Reply-To: <4C0F1932.7040903@freyther.de> References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> <4C0E464F.1050601@selfish.org> <4C0E49D3.9060400@selfish.org> <4C0E5300.1020604@gmail.com> <4C0E60B3.9040109@gmail.com> <4C0F1932.7040903@freyther.de> Message-ID: <4C0F60A9.6010902@gmail.com> On 9-6-2010 6:31, Holger Hans Peter Freyther wrote: > Hi Nordin, > > I wouldn't have the skills I have now if it wouldn't be due to others > help. And of course I know file and uname and it is new to others. The > biggest problem I have is judging is someone is just lazy, or if there > is someone who is slow to start but eager to learn. > > how would you figure that out? > I totally understand Holger and agree with you if we just imagine the amount of work you have to do for the projects comparing to someone new just asking even the simplest basic things, but that's something there always be. So to answer your question, just ignore the posted "stupid" questions, or tell him/her to read again the how-to's, or provide links how to build a project etc... And you guys are even kind to take some effort to answer to such simple questions, there are others who smash him with RTFMs :) But let's just forget about it as it's off-topic. > z. > > PS: Would you be willing to help me to go through the documentation and > provide some more getting started information? At least two have > downloaded a wrong toolchain, I am pretty sure this will happen again. > > I'd really like to help you with this project, but as I stated before in OpenBSC as a father of 3 kids and a husband of a very attention-demanding wife I really have very little time, so I'm just following you guys on this list, but I'm not an active member. I'm now focussing on UMTS support for OpenBSC which I really want to help coding this time, as I didn't help to code for 2G in OpenBSC. Greetings, Nordin. From huseyinturan at gmail.com Tue Jun 8 15:16:50 2010 From: huseyinturan at gmail.com (Huseyin Turan) Date: Tue, 8 Jun 2010 18:16:50 +0300 Subject: Trouble building Osmocom In-Reply-To: <4C0E5300.1020604@gmail.com> References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> <4C0E464F.1050601@selfish.org> <4C0E49D3.9060400@selfish.org> <4C0E5300.1020604@gmail.com> Message-ID: Thank you very much. I have succeded to compile. I will try to deploy on C118. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouchtaoui at gmail.com Tue Jun 8 15:27:53 2010 From: bouchtaoui at gmail.com (Nordin) Date: Tue, 08 Jun 2010 17:27:53 +0200 Subject: Trouble building Osmocom In-Reply-To: References: <4C0E3219.7040103@selfish.org> <4C0E41A5.8030304@selfish.org> <4C0E464F.1050601@selfish.org> <4C0E49D3.9060400@selfish.org> <4C0E5300.1020604@gmail.com> Message-ID: <4C0E6179.6070808@gmail.com> Congratulations! :) On 8-6-2010 17:16, Huseyin Turan wrote: > Thank you very much. > > I have succeded to compile. I will try to deploy on C118. > > From fyproject14 at gmail.com Tue Jun 8 14:00:20 2010 From: fyproject14 at gmail.com (Zaki Ud Din) Date: Tue, 8 Jun 2010 19:00:20 +0500 Subject: Trouble building Osmocom Message-ID: Hello, Thank you for your reply. I am really sorry I did not get your point in the mail where you asked me to perform the different checks. Though I have written those commands and have pasted their output below. zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux Awaiting your response, Zaki. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fyproject14 at gmail.com Wed Jun 9 14:21:05 2010 From: fyproject14 at gmail.com (Zaki Ud Din) Date: Wed, 9 Jun 2010 19:21:05 +0500 Subject: Trouble building Osmocom Message-ID: Hello, Thank you for your reply. I have downloaded the toolchain that I should have done at the first place. I am not getting those errors any more but I am stuck at some new ones. I am pasting them below ................. calypso/libcalypso.a(uart.o):(.ARM.exidx.text.uart_irq_handler_sercomm+0x0): undefined reference to `__aeabi_unwind_cpp_pr1' calypso/libcalypso.a(uart.o):(.ARM.exidx.text.uart_init+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' lib/libmini.a(console.o):(.ARM.exidx.text.cons_rb_pull+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' lib/libmini.a(console.o):(.ARM.exidx.text.__cons_rb_append+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' lib/libmini.a(console.o):(.ARM.exidx.text.cons_rb_append+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' lib/libmini.a(console.o):(.ARM.exidx.text.cons_puts+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' lib/libmini.a(console.o):(.ARM.exidx.text.cons_rb_flush+0x0): more undefined references to `__aeabi_unwind_cpp_pr0' follow make[1]: *** [board/compal_e88/hello_world.ramload.elf] Error 1 make[1]: Leaving directory `/home/zaki/osmocom-bb/src/target/firmware' make: *** [firmware] Error 2 Another thing that I had to ask was that basically my work is at the layer1 and all the c files present in that folder of firmware have got built, the error that is coming above is in some other folder. Would I be able to load the layer1 files through osmocon without completing the installation of the rest of the firmware. Awaiting your response, Zaki. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fyproject14 at gmail.com Tue Jun 8 13:47:35 2010 From: fyproject14 at gmail.com (Zaki Ud Din) Date: Tue, 8 Jun 2010 18:47:35 +0500 Subject: baseband-devel Digest, Vol 5, Issue 5 In-Reply-To: References: Message-ID: Hello, Thank you very much for your reply. When i give the path to arm-elf-gcc "export PATH=$PATH:/home/zaki/gnuarm-4.0.2/bin/" , and run "make firmware", I get errors. I have pasted some of the errors that i get in config.log below and have also attached that file. configure:2559: checking for arm-elf-linux-gcc configure:2586: result: arm-elf-gcc configure:2858: checking for C compiler version configure:2866: arm-elf-gcc --version >&5 ../configure: line 2868: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot execute binary file configure:2870: $? = 126 configure:2877: arm-elf-gcc -v >&5 ../configure: line 2879: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot execute binary file configure:2881: $? = 126 configure:2888: arm-elf-gcc -V >&5 ../configure: line 2890: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot execute binary file configure:2892: $? = 126 configure:2915: checking for C compiler default output file name configure:2937: arm-elf-gcc -Os -ffunction-sections -I../../../../target/firmware/include conftest.c >&5 ../configure: line 2939: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot execute binary file configure:2941: $? = 126 configure:2979: result: configure: failed program was: Awaiting your response, Zaki. On Tue, Jun 8, 2010 at 6:12 PM, wrote: > Send baseband-devel mailing list submissions to > baseband-devel at lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/baseband-devel > or, via email, send a message with subject or body 'help' to > baseband-devel-request at lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner at lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of baseband-devel digest..." > > Today's Topics: > > 1. Re: Trouble building Osmocom (Adrian-Ken Rueegsegger) > 2. Re: Trouble building Osmocom (Sylvain Munaut) > 3. AW: Trouble building Osmocom (Riemer, Bjoern) > 4. Re: Trouble building Osmocom (Holger Freyther) > 5. Trouble building Osmocom (Zaki Ud Din) > 6. Re: Trouble building Osmocom (Holger Freyther) > > > ---------- Forwarded message ---------- > From: Adrian-Ken Rueegsegger > To: Zaki Ud Din > Date: Tue, 08 Jun 2010 12:44:56 +0200 > Subject: Re: Trouble building Osmocom > Hi, > > Zaki Ud Din schrieb: > > Hello, > > > > Thank you very much for your reply. No my config.log file seems to be > > different. I am pasting a portion of config.log file below and am also > > attaching the complete file with this email. > > [snip] > > > configure:2866: arm-elf-gcc --version >&5 > > ../configure: line 2868: arm-elf-gcc: command not found > > configure:2870: $? = 127 > > configure:2877: arm-elf-gcc -v >&5 > > ../configure: line 2879: arm-elf-gcc: command not found > > configure:2881: $? = 127 > > configure:2888: arm-elf-gcc -V >&5 > > ../configure: line 2890: arm-elf-gcc: command not found > > configure:2892: $? = 127 > > configure:2915: checking for C compiler default output file name > > configure:2937: arm-elf-gcc -Os -ffunction-sections > > -I../../../../target/firmware/include conftest.c >&5 > > ../configure: line 2939: arm-elf-gcc: command not found > > It does not find the toolchain/cross-compiler. Where did you > install/unpack the toolchain? Please check that it is really in > "/gnuarm-4.0.2/arm-elf/bin". Otherwise you have to export the proper path. > > -Adrian > > > > > ---------- Forwarded message ---------- > From: Sylvain Munaut <246tnt at gmail.com> > To: baseband-devel at lists.osmocom.org > Date: Tue, 8 Jun 2010 12:43:19 +0200 > Subject: Re: Trouble building Osmocom > This seems pretty clear : > > > ../configure: line 2939: arm-elf-gcc: command not found > > Make sure you have a good ARM toolchain installed ... (look it up on > google, plenty of doc on how to install one). > > Sylvain > > > > > ---------- Forwarded message ---------- > From: "Riemer, Bjoern" > To: "Zaki Ud Din" , < > baseband-devel at lists.osmocom.org> > Date: Tue, 8 Jun 2010 13:07:30 +0200 > Subject: AW: Trouble building Osmocom > > Hi > > > > You say that you unpacked the gcc compiler to your home directory and then > set you path to PATH=/gnuarm-4.0.2/arm-elf/bin:$PATH .. > > Unless your home directory is set to / the path to the gcc compiler is > wrong. > > > > bjoern > > > > *Von:* baseband-devel-bounces at lists.osmocom.org [mailto: > baseband-devel-bounces at lists.osmocom.org] *Im Auftrag von *Zaki Ud Din > *Gesendet:* Sonntag, 6. Juni 2010 22:21 > *An:* baseband-devel at lists.osmocom.org > *Betreff:* Trouble building Osmocom > > > > Hello, > > I have been trying to build osmocom but have been getting errors in doing > so. > > Firstly, I downloaded the following file,"* binutils-2.16.1, > gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]*" under > GCC-4.0 toolchain from www.gnuarm.com and extracted this to my home > folder. > > Secondly, I gave the following path "export PATH=/gnuarm-4.0.2/arm-elf/ > > bin:$PATH" in terminal window. Afterwards when I entered "make" under > "/osmosom-bb/src", I got the following errors > > > zaki at zaki-desktop:~/osmocom-bb/src$ make > > cd shared/libosmocore/build-host && make > make[1]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make all-recursive > make[2]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > Making all in include > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > Making all in osmocore > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > Making all in protocol > make[5]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' > make[5]: Nothing to be done for `all'. > make[5]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol' > make[5]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[5]: Nothing to be done for `all-am'. > make[5]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore' > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include' > Making all in src > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src' > Making all in tests > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > Making all in timer > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer' > Making all in sms > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' > make[4]: Nothing to be done for `all'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms' > make[4]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[4]: Nothing to be done for `all-am'. > make[4]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests' > make[3]: Entering directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[3]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[2]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > make[1]: Leaving directory > `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host' > cd shared/libosmocore/build-target && ../configure \ > --host=arm-elf-linux --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 a thread-safe mkdir -p... /bin/mkdir -p > > checking for gawk... no > checking for mawk... mawk > checking whether make sets $(MAKE)... yes > checking for arm-elf-linux-strip... no > checking for strip... strip > checking whether make sets $(MAKE)... (cached) yes > > > checking for arm-elf-linux-gcc... arm-elf-gcc > checking for C compiler default output file name... > configure: error: in > `/home/zaki/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 > > I shall be grateful to you if you could help me on this. > > Awaiting your Response, > > Zaki. > > > ---------- Forwarded message ---------- > From: Holger Freyther > To: > Date: Tue, 08 Jun 2010 20:05:45 +0800 > Subject: Re: Trouble building Osmocom > On 06/08/2010 07:59 PM, Zaki Ud Din wrote: > > Hello, > > > I did export the path using the following line "export > > PATH=$PATH:/home/zaki/gnuarm- > > 4.0.2/arm-elf/bin/ " and afterwards I typed "make firmware" and then got > > the errors I told you. > > > > Awaiting your response, > > Well, > it claims to not find arm-elf-gcc. Have you considered checking that > this application exists? e.g. does which arm-elf-gcc lead to anything? > > > > > > > > ---------- Forwarded message ---------- > From: Zaki Ud Din > To: baseband-devel at lists.osmocom.org, Holger Freyther > Date: Tue, 8 Jun 2010 16:59:23 +0500 > Subject: Trouble building Osmocom > Hello, > > Thank you very much for your reply. > > I am using ,"* binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0, > insight-6.4, TAR BZ2 [65.5MB]*" under GCC-4.0 toolchain from > www.gnuarm.com. I then extracted to the folder named "Zaki". > > I did export the path using the following line "export > PATH=$PATH:/home/zaki/gnuarm- > 4.0.2/arm-elf/bin/ " and afterwards I typed "make firmware" and then got > the errors I told you. > > Awaiting your response, > > Zaki. > > ---------- Forwarded message ---------- > From: Holger Freyther > To: baseband-devel at lists.osmocom.org > Date: Tue, 08 Jun 2010 21:12:05 +0800 > Subject: Re: Trouble building Osmocom > On 06/08/2010 09:01 PM, Huseyin Turan wrote: > > > checking for gcc... gcc > > checking for C compiler default output file name... > > configure: error: in > > `/home/name1/osmocom/osmocom-bb/src/shared/libosmocore/build-host': > > configure: error: C compiler cannot create executables > > See `config.log' for more details. > > Looking at the log file is always a good idea. It might have an eye > opening effect.... > > > > > > That is; in gnuarm-4.0.2/arm-elf/bin there are executables like > > gcc,g++,etc. which can be executed. > > in gnuarm-4.0.2/bin there are executables like > > arm-elf-gcc,arm-elf-g++,etc. which can not be executed. > > > > Which path is true? > > You want to use your normal gcc and such, so putting > gnuarm-4.0.2/arm-elf/bin in your path is not that clever. What is the > issue with arm-elf-gcc? What happens when you try to execute it? > > > > > _______________________________________________ > baseband-devel mailing list > baseband-devel at lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/baseband-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: text/x-log Size: 7204 bytes Desc: not available URL: From saravanadel at gmail.com Tue Jun 8 14:54:35 2010 From: saravanadel at gmail.com (saravanan T) Date: Tue, 8 Jun 2010 20:24:35 +0530 Subject: Getting Started with openmoko Message-ID: Hi, I would like to get started with osmocon for openmoko devices. I have checked out the project and setup the gnuarm but it doesnt seem to compile. I am running ubuntu karmic. Please do help me with the steps of getting it running on this device. -------------Error-------------- configure error could not find install.sh, or sh-tool make [shared/libosmocore/build-host/Makefile] -------------Error-------------- Regards Saravanan.L -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Wed Jun 9 12:17:52 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 09 Jun 2010 20:17:52 +0800 Subject: Getting Started with openmoko In-Reply-To: References: Message-ID: <4C0F8670.2080101@freyther.de> On 06/08/2010 10:54 PM, saravanan T wrote: > Please do help me with the steps of getting it running on this device. > > -------------Error-------------- > configure error could not find install.sh, or sh-tool > make [shared/libosmocore/build-host/Makefile] > -------------Error-------------- You will need to provide us more output... it seems that you lack automake or libtool... Please provide more output (as attachment). From osmocom at lakedaemon.net Wed Jun 9 13:41:45 2010 From: osmocom at lakedaemon.net (Jason) Date: Wed, 09 Jun 2010 09:41:45 -0400 Subject: Getting Started with openmoko In-Reply-To: References: Message-ID: <4C0F9A19.2050602@lakedaemon.net> saravanan T wrote: > I am running ubuntu karmic. > > -------------Error-------------- > configure error could not find install.sh, or sh-tool > make [shared/libosmocore/build-host/Makefile] > -------------Error-------------- > sudo apt-get install build-essential hth, Jason. From fyproject14 at gmail.com Wed Jun 9 05:38:24 2010 From: fyproject14 at gmail.com (Zaki Ud Din) Date: Wed, 9 Jun 2010 10:38:24 +0500 Subject: baseband-devel Digest, Vol 5, Issue 7 In-Reply-To: References: Message-ID: Hello, I never thought I would become such a popular figure on your mailing lists, be it for the wrong reasons. I am sorry to have emailed you that question, but honestly I am new to Ubuntu. I have done quite a lot of programming on Windows, but this seems to be quite a different world, and that is why I email you even my seemingly childish questions for you to you, as I am sure you wont have any trouble solving them although it does takes some seconds of yours. Regards, Zaki. On Wed, Jun 9, 2010 at 9:47 AM, wrote: > Send baseband-devel mailing list submissions to > baseband-devel at lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/baseband-devel > or, via email, send a message with subject or body 'help' to > baseband-devel-request at lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner at lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of baseband-devel digest..." > > Today's Topics: > > 1. Re: Trouble building Osmocom (Sylvain Munaut) > 2. Re: Trouble building Osmocom (Zaki Ud Din) > 3. Re: Trouble building Osmocom (Huseyin Turan) > 4. Re: Trouble building Osmocom (Nordin) > 5. Re: Trouble building Osmocom (Huseyin Turan) > 6. Re: Trouble building Osmocom (Nordin) > 7. Re: Trouble building Osmocom (Nordin) > 8. Re: Trouble building Osmocom (Sylvain Munaut) > 9. Re: Trouble building Osmocom (Holger Hans Peter Freyther) > > > ---------- Forwarded message ---------- > From: Sylvain Munaut <246tnt at gmail.com> > To: > Date: Tue, 8 Jun 2010 15:57:22 +0200 > Subject: Re: Trouble building Osmocom > Looking at gnuarm.com, it looks like you have a x86_64 toolchain and > try to run it on i686. > Honestly I don't want to be mean but if you can't see what's wrong > with that, osmocom-bb might not be for you quite just yet. > > > > > ---------- Forwarded message ---------- > From: Zaki Ud Din > To: baseband-devel at lists.osmocom.org > Date: Tue, 8 Jun 2010 19:00:20 +0500 > Subject: Re: Trouble building Osmocom > Hello, > > Thank you for your reply. I am really sorry I did not get your point in the > mail where you asked me to perform the different checks. Though I have > written those commands and have pasted their output below. > > > zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc > ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped > zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a > Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC > 2009 i686 GNU/Linux > > Awaiting your response, > > Zaki. > > > ---------- Forwarded message ---------- > From: Huseyin Turan > To: baseband-devel at lists.osmocom.org > Date: Tue, 8 Jun 2010 16:51:06 +0300 > Subject: Re: Trouble building Osmocom > Sorry; > > file ./arm-elf-gcc > ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped > > > > ---------- Forwarded message ---------- > From: Nordin > To: baseband-devel at lists.osmocom.org > Date: Tue, 08 Jun 2010 16:26:08 +0200 > Subject: Re: Trouble building Osmocom > On 8-6-2010 15:57, Sylvain Munaut wrote: > >> Honestly I don't want to be mean but if you can't see what's wrong >> with that, osmocom-bb might not be for you quite just yet. >> >> > > Maybe he's good in programming embedded stuff, this has purely to do with > Linux specific builds and nothing to do with coding/decoding gsm stuff. > By the way, he can always learn... > > > > > > ---------- Forwarded message ---------- > From: Huseyin Turan > To: baseband-devel at lists.osmocom.org > Date: Tue, 8 Jun 2010 18:16:50 +0300 > Subject: Re: Trouble building Osmocom > Thank you very much. > > I have succeded to compile. I will try to deploy on C118. > > > ---------- Forwarded message ---------- > From: Nordin > To: Sylvain Munaut <246tnt at gmail.com> > Date: Tue, 08 Jun 2010 17:24:35 +0200 > Subject: Re: Trouble building Osmocom > Silvain, > > Yes I agree with you, but I just want to note that we have to encourage > beginners to keep trying and learning. > Especially when one comes from the Windows world like me, where everything > builds magically in Visual Studio (debugging is a joy in there ;-) > Never programmed in Linux, never used git, gdb, vim, etc... and now, I > begin to rock a little bit, thnx to OpenBSC and you guys ;-) > > > > On 8-6-2010 17:07, Sylvain Munaut wrote: > >> Maybe he's good in programming embedded stuff, this has purely to do with >>> Linux specific builds and nothing to do with coding/decoding gsm stuff. >>> >>> >> I never meant otherwise in my previous message. But basic knowledge / >> problem solving of the build system is a requirement IMHO, especially >> in this project (that includes both host and target code with even >> some shared code between the two). >> >> I also looked up his history on the various mailing lists before >> posting this and this is not the first build problem with GSM related >> projects so I would expect him to learn from previous experience. >> >> >> Also, when I see a message with : >> >> ---- >> zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc >> ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), >> dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped >> zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a >> Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 >> 01:57:59 UTC 2009 i686 GNU/Linux >> ---- >> >> And he still asks what's wrong ? An embedded programmer that doesn't >> know he can't just run binaries from one architecture onto another >> architecture ... >> >> >> >> >> >>> By the way, he can always learn... >>> >>> >> I know, that's why there is a "quite just yet" at the end. That's >> exactly what I implied: that he learns that first and then come back. >> >> >> Cheers, >> >> Sylvain >> >> >> > > > > > > ---------- Forwarded message ---------- > From: Nordin > To: baseband-devel at lists.osmocom.org > Date: Tue, 08 Jun 2010 17:27:53 +0200 > Subject: Re: Trouble building Osmocom > Congratulations! :) > > > > On 8-6-2010 17:16, Huseyin Turan wrote: > >> Thank you very much. >> >> I have succeded to compile. I will try to deploy on C118. >> >> >> > > > > > > ---------- Forwarded message ---------- > From: Sylvain Munaut <246tnt at gmail.com> > To: Nordin > Date: Tue, 8 Jun 2010 17:07:42 +0200 > Subject: Re: Trouble building Osmocom > > Maybe he's good in programming embedded stuff, this has purely to do with > > Linux specific builds and nothing to do with coding/decoding gsm stuff. > > I never meant otherwise in my previous message. But basic knowledge / > problem solving of the build system is a requirement IMHO, especially > in this project (that includes both host and target code with even > some shared code between the two). > > I also looked up his history on the various mailing lists before > posting this and this is not the first build problem with GSM related > projects so I would expect him to learn from previous experience. > > > Also, when I see a message with : > > ---- > zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc > ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped > zaki at zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a > Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 > 01:57:59 UTC 2009 i686 GNU/Linux > ---- > > And he still asks what's wrong ? An embedded programmer that doesn't > know he can't just run binaries from one architecture onto another > architecture ... > > > > > By the way, he can always learn... > > I know, that's why there is a "quite just yet" at the end. That's > exactly what I implied: that he learns that first and then come back. > > > Cheers, > > Sylvain > > > > > ---------- Forwarded message ---------- > From: Holger Hans Peter Freyther > To: baseband-devel at lists.osmocom.org > Date: Wed, 09 Jun 2010 12:31:46 +0800 > Subject: Re: Trouble building Osmocom > On 06/08/2010 11:24 PM, Nordin wrote: > > Silvain, > > > > Yes I agree with you, but I just want to note that we have to encourage > > beginners to keep trying and learning. > > Especially when one comes from the Windows world like me, where > > everything builds magically in Visual Studio (debugging is a joy in > > there ;-) > > Never programmed in Linux, never used git, gdb, vim, etc... and now, I > > begin to rock a little bit, thnx to OpenBSC and you guys ;-) > > Hi Nordin, > > I wouldn't have the skills I have now if it wouldn't be due to others > help. And of course I know file and uname and it is new to others. The > biggest problem I have is judging is someone is just lazy, or if there > is someone who is slow to start but eager to learn. > > how would you figure that out? > > z. > > PS: Would you be willing to help me to go through the documentation and > provide some more getting started information? At least two have > downloaded a wrong toolchain, I am pretty sure this will happen again. > > > > _______________________________________________ > baseband-devel mailing list > baseband-devel at lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/baseband-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Wed Jun 9 05:56:15 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Wed, 09 Jun 2010 13:56:15 +0800 Subject: baseband-devel Digest, Vol 5, Issue 7 In-Reply-To: References: Message-ID: <4C0F2CFF.4060907@freyther.de> On 06/09/2010 01:38 PM, Zaki Ud Din wrote: > Hello, > > I never thought I would become such a popular figure on your mailing > lists, be it for the wrong reasons. I am sorry to have emailed you that > question, but honestly I am new to Ubuntu. I have done quite a lot of > programming on Windows, but this seems to be quite a different world, > and that is why I email you even my seemingly childish questions for you > to you, as I am sure you wont have any trouble solving them although it > does takes some seconds of yours. Hi Zaki, the main problem I am facing is you are not reading. I asked you to not send me private emails many times, you keep insisting to send me them, I asked you to not top-post, you keep top-posting. This is disrespectful toward the people you want help from. We are interested in helping, even beginners, but we do have some basic rules, I agree they are not written down but they do exist. This GSM community is using two means of communication, one is the mailinglist, the other the IRC channel. The community is providing the "service" as best effort, you have certainly no right to insist that someone is helping you. For the mailinglist we assume you to not top-post, but use reply and to quote properly. If you have subscribed to the digest by accident you can change that in the mailman, if you want to keep the digest then please use a service like gmane.org to reply to emails. We are using english for communication and we assume basic problem solving skills. E.g. if a tool emits a line like "Error please see foo.log for details", we kind of assume you to look at that log file, or at least attach it to the email, we also kind of assume you to follow the thread you started. In your specific case. You have downloaded a ia32 bit version of Ubuntu, you have decided to download an amd64 bit version of the toolchain. The 'uname' command tells you something about your kernel, the architecture it is running on (i686) and other bits. The 'file' command is reading the header of the file you point it to. I asked you to determine the type of arm-elf-gcc. In that case 'file' found the ELF magic number in the header, and found out that it was compiled for AMD64. This is the same "mistake" that Huseyin made, he wrote an email about it. Instead of reading that email, you spend your time sending a private email to Syvliant, and then to me, telling that the mailinglist didn't help you. So please stick to the mailinglist, people help, please read the threads you started, and feel free to ask specific questions. happy hacking z. From drasko.draskovic at gmail.com Wed Jun 9 08:51:52 2010 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Wed, 9 Jun 2010 10:51:52 +0200 Subject: Fwd: SIM card driver In-Reply-To: <20100609100855.53f9d9fb@narfi.yggdrasil.draxit.de> References: <201006082252.11369.openmoko@mazikeen.demon.co.uk> <20100609100855.53f9d9fb@narfi.yggdrasil.draxit.de> Message-ID: Hi all, can anybody point be to the SIM card driver sources ? I looked at src/target/firmware/calypso but did not find it... Is there some other sources that you know for SCI (Smart Card Interface) that I can look at ? Best regards, Drasko ---------- Forwarded message ---------- From: Wolfgang Draxinger Date: Wed, Jun 9, 2010 at 10:08 AM Subject: Re: SIM card driver To: hardware at lists.openmoko.org, Al Johnson On Wed, 9 Jun 2010 00:04:07 +0200 Drasko DRASKOVIC wrote: > Very uncool :(. > > I need to write a driver for ARM PrimeCell Smart Card Interface PL131 > in order to init/read/write SIM card for 4G mobile device. Does > anybody knows where I can get hold of some implementation of (any) SIM > interface driver ? > > Thanks and BR, > Drasko SIMs, like any other SmartCard communicate over an interface very similar to I2C, with the notable difference, that the terminal always is the "bus" master. Building your very own SmartCard terminal is very easy. Or you just use one of the ready to use ones (from Towitoko, Reiner SCT, etc.). Also have a look in the Open Baseband project http://bb.osmocom.org/trac/ Which b nature also must deal with SIM cards. Wolfgang _______________________________________________ hardware mailing list hardware at lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware From zero-kelvin at gmx.de Wed Jun 9 10:25:13 2010 From: zero-kelvin at gmx.de (dexter) Date: Wed, 09 Jun 2010 12:25:13 +0200 Subject: Fwd: SIM card driver In-Reply-To: References: <201006082252.11369.openmoko@mazikeen.demon.co.uk> <20100609100855.53f9d9fb@narfi.yggdrasil.draxit.de> Message-ID: <4C0F6C09.70605@gmx.de> Hi Drasko > Hi all, > can anybody point be to the SIM card driver sources ? > > I looked at src/target/firmware/calypso but did not find it... > > I did not commit my work yet because its not finished. The driver works basicly, but is unfinished yet. Sorry folks. I am very busy but i did not forget about the driver. How urgent do you need a well working driver? Maybe i can sacrifice my weekend for this... Then you should be able to communicate with the SIM on APDU level. > Is there some other sources that you know for SCI (Smart Card > Interface) that I can look at ? > For the calypso iota you might want to have a look at the TSM-30 Sources. Are you familliar with GSM 11.11 and the T=0 protocol? regards Philipp From drasko.draskovic at gmail.com Fri Jun 11 09:52:41 2010 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Fri, 11 Jun 2010 11:52:41 +0200 Subject: Fwd: SIM card driver In-Reply-To: <4C0F6C09.70605@gmx.de> References: <201006082252.11369.openmoko@mazikeen.demon.co.uk> <20100609100855.53f9d9fb@narfi.yggdrasil.draxit.de> <4C0F6C09.70605@gmx.de> Message-ID: On Wed, Jun 9, 2010 at 12:25 PM, dexter wrote: > Hi Drasko >> >> Hi all, >> can anybody point be to the SIM card driver sources ? >> >> I looked at src/target/firmware/calypso but did not find it... >> >> > > I did not commit my work yet because its not finished. The driver works > basicly, but is unfinished yet. Sorry folks. I am very busy but i did not > forget about the driver. How urgent do you need a well working driver? Maybe > i can sacrifice my weekend for this... Then you should be able to > communicate with the SIM on APDU level. Hi Dexter, I do not this driver urgently. I just wanted to see the implementation because I have to write one SIM Controller driver myself. Maybe you can send me the sources as they are at this moment, even if they do not compile. Also, you can send me/point me to the manual containing adequate programmers model, so I can work also on your driver, while I have to work on mine anyway. I guess one time I figure out how it works, things should be pretty similar... >> Is there some other sources that you know for SCI (Smart Card >> Interface) that I can look at ? >> > > For the calypso iota you might want to have a look at the TSM-30 Sources. Where exactly can I find these ? Are they in the osmocom tree ? Can you please send me link to the TSM-30 sources ? > > Are you familliar with GSM 11.11 and the T=0 protocol? Yes. Best regards, Drasko From fyproject14 at gmail.com Wed Jun 16 18:21:26 2010 From: fyproject14 at gmail.com (Zaki Ud Din) Date: Wed, 16 Jun 2010 23:21:26 +0500 Subject: Thank you Message-ID: Hello, I am just writing this email to thank everyone who helped me with all the trouble I had while Osmocom. Though I didn't succeed in my objective but it was just a part of my project that I started quite late and was always fighting against time to complete it. Thank you :), Zaki. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bouchtaoui at gmail.com Thu Jun 17 07:33:04 2010 From: bouchtaoui at gmail.com (Nordin) Date: Thu, 17 Jun 2010 09:33:04 +0200 Subject: Thank you In-Reply-To: References: Message-ID: <4C19CFB0.8020309@gmail.com> You're welcome. I hope you learned from it :) On 16-6-2010 20:21, Zaki Ud Din wrote: > Hello, > > I am just writing this email to thank everyone who helped me with all the > trouble I had while Osmocom. Though I didn't succeed in my objective but it > was just a part of my project that I started quite late and was always > fighting against time to complete it. > > Thank you :), > Zaki. > > From jluebbe at debian.org Wed Jun 16 20:11:48 2010 From: jluebbe at debian.org (Jan Luebbe) Date: Wed, 16 Jun 2010 22:11:48 +0200 Subject: [PATCH] l1ctl.c: add missing ntohs for band_arfcn Message-ID: <1276719108-16383-1-git-send-email-jluebbe@debian.org> This fixes mangled ARFCN numbers in gsmtap. --- src/host/layer23/src/l1ctl.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/host/layer23/src/l1ctl.c b/src/host/layer23/src/l1ctl.c index 051b3d8..5e683d3 100644 --- a/src/host/layer23/src/l1ctl.c +++ b/src/host/layer23/src/l1ctl.c @@ -165,7 +165,7 @@ static int rx_ph_data_ind(struct osmocom_ms *ms, struct msgb *msg) /* send CCCH data via GSMTAP */ gsmtap_chan_type = chantype_rsl2gsmtap(chan_type, dl->link_id); - gsmtap_sendmsg(dl->band_arfcn, chan_ts, gsmtap_chan_type, chan_ss, + gsmtap_sendmsg(ntohs(dl->band_arfcn), chan_ts, gsmtap_chan_type, chan_ss, tm.fn, dl->rx_level-110, dl->snr, ccch->data, sizeof(ccch->data)); -- 1.7.1 From laforge at gnumonks.org Thu Jun 17 08:03:54 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 17 Jun 2010 10:03:54 +0200 Subject: [PATCH] l1ctl.c: add missing ntohs for band_arfcn In-Reply-To: <1276719108-16383-1-git-send-email-jluebbe@debian.org> References: <1276719108-16383-1-git-send-email-jluebbe@debian.org> Message-ID: <20100617080353.GH22244@prithivi.gnumonks.org> thanks, applied. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From marco.rust at fokus.fraunhofer.de Mon Jun 21 21:48:13 2010 From: marco.rust at fokus.fraunhofer.de (Rust, Marco) Date: Mon, 21 Jun 2010 23:48:13 +0200 Subject: l1test without hdlc (sercomm) Message-ID: <70524A4436C03E43A293958B505008B602C2D7D2@EXCHSRV.fokus.fraunhofer.de> Hello, I want to use the power measurements from the l1test in the phone. Therefore I modified the program so only the PM is done and additional some averaging and so on. Finally the information should be sent to an microcontroller over UART. There is the problem: I don't know how to use this HDLC sercomm stuff because I don't have time to understand AND implement it for my thesis in the ?c-part. I need a quick dirty hack to deactivate this HDLC. I don't find it in code and tried some hours. I tried "uart_putchar_wait()" and hterm shows me that the bytes are sent with a lot other stuff. What is the easiest way working for me? Thanks a lot. Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Tue Jun 22 00:09:45 2010 From: steve at steve-m.de (Steve Markgraf) Date: Tue, 22 Jun 2010 02:09:45 +0200 Subject: l1test without hdlc (sercomm) In-Reply-To: <70524A4436C03E43A293958B505008B602C2D7D2@EXCHSRV.fokus.fraunhofer.de> References: <70524A4436C03E43A293958B505008B602C2D7D2@EXCHSRV.fokus.fraunhofer.de> Message-ID: <4C1FFF49.8040203@steve-m.de> Hi, At 21.06.2010 23:48 Rust, Marco, wrote: > Finally the information should be sent to an microcontroller over UART. > What is the easiest way working for me? In this case I would suggest swapping the console and the HDLC UART, by changing CONS_UART_NR 0 to 1 in /include/console.h and SERCOMM_UART_NR 1 to 0 in /include/comm/sercomm.h and using the cons_puts() function. Excerpt from console.h: /* This is the direct (IRQ driven) UART console, bypassing the HDLC layer. You should not need to call those functions unless you've decided to not use the HLDC layer or have a device with two UARTs */ Regards, Steve From marco.rust at fokus.fraunhofer.de Tue Jun 22 17:48:33 2010 From: marco.rust at fokus.fraunhofer.de (Rust, Marco) Date: Tue, 22 Jun 2010 19:48:33 +0200 Subject: AW: l1test without hdlc (sercomm) In-Reply-To: <4C1FFF49.8040203@steve-m.de> References: <70524A4436C03E43A293958B505008B602C2D7D2@EXCHSRV.fokus.fraunhofer.de> <4C1FFF49.8040203@steve-m.de> Message-ID: <70524A4436C03E43A293958B505008B602C2D8BB@EXCHSRV.fokus.fraunhofer.de> Great. Easy, but working. Thanks Marco -----Urspr?ngliche Nachricht----- Von: Steve Markgraf [mailto:steve at steve-m.de] Gesendet: Dienstag, 22. Juni 2010 02:10 An: Rust, Marco Cc: baseband-devel at lists.osmocom.org Betreff: Re: l1test without hdlc (sercomm) Hi, At 21.06.2010 23:48 Rust, Marco, wrote: > Finally the information should be sent to an microcontroller over UART. > What is the easiest way working for me? In this case I would suggest swapping the console and the HDLC UART, by changing CONS_UART_NR 0 to 1 in /include/console.h and SERCOMM_UART_NR 1 to 0 in /include/comm/sercomm.h and using the cons_puts() function. Excerpt from console.h: /* This is the direct (IRQ driven) UART console, bypassing the HDLC layer. You should not need to call those functions unless you've decided to not use the HLDC layer or have a device with two UARTs */ Regards, Steve From 246tnt at gmail.com Wed Jun 23 08:29:36 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Jun 2010 10:29:36 +0200 Subject: Some L1 status updates Message-ID: Hi, The good news, is that hopping and ts[0:4] work just fine and were surprisingly easy to implement. The bugs I thought I had were in fact not related to these and just prior bugs that were never noticed before. (see my sylvain/testing branch). Only L1 is changed, so you'll need to tweak l23 (either the mobile app or layer23 for quick tests) if you want to try them out somehow. Current limitations: - SDCCH8 subchannel 4,5,6,7 won't work. For those, we need to TX and RX in the same frame ... which just isn't possible with the way the primitives work right now. (each assume to have the full frame for themselve). - TS >= 4 may not work When using TS>=4 we should also change the interrupt alignment so that the DSP still has time to do it's job. Switching 'forward' is easy, but when switching 'back', we need to be conscious that we need to skip 1 frame at the very least ... IMHO to solve both those issue, we need a better scheduler/primitives that possibly have some knowledge of the 'span' (in terms of qbit) of each operation. Because if we do a TX on TS=5 for instance, there is no way we can do a RX on TS=0 on the next frame, the tpu window overlap. - No ciphering. That should be trivial to add. Just setup the fn and the kc and set the flag ... the 'l1s.next_time' contains the godd time of the frame TX/RX frame during the primitive execution, so that's the FN to use. Once that's done, the few bits missing from mobile app could be added (and from a quick look, not much is missing ... just the l1ctl_* calls because they don't exists yet) and a full location update with auth and ciphering could be done. The need for a SIM interface grows quickly :) Some 'gotchas' you might encounter that are not fixed yet: - The L1 completion handler crashes. In target/firmware/layer1/prim_tx_nb.c , l1s.completion[L1_COMPL_TX_NB] is set in l1s_tx_test() but that's never called. So you need to comment out l1s_compl_sched(L1_COMPL_TX_NB) in the 'resp' handler temporarly until a proper fix. - Wireshark SDCCH8 subchannel decoding in IMMEDIATE ASSIGNEMENT is just plain wrong. (source code uses % 0x38 instead of & 0x38), need to send a patch for this - layer23 doesn't currently filter much the IMM.ASS it receives so you may end up on a channel that's not yours ... beware. Sylvain From Andreas.Eversberg at versatel.de Wed Jun 23 11:21:42 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 23 Jun 2010 13:21:42 +0200 Subject: AW: Some L1 status updates Message-ID: > - layer23 doesn't currently filter much the IMM.ASS it receives so > you may end up on a channel that's not yours ... beware. hi sylvain, what do you mean with "much"? i filter the channel with the channel request number (includes random number) in the IMM.ASS message. maybe in the future we can filter the time slot where it was sent (RACH confirm) and compare it also. but this requires RACH confirm with GSM time where it was sent. andreas @harald: is there any time stamp in the RACH confirm? what format would it be? .... from the IMM.ASS parsing: /* 3.3.1.1.2: ignore assignment while idle */ if (rr->state != GSM48_RR_ST_CONN_PEND || !rr->wait_assign) { LOGP(DRR, LOGL_INFO, "Not for us, no request.\n"); return 0; } /* request ref */ if (gsm48_match_ra(ms, &ia->req_ref)) { /* channel description */ memcpy(&rr->cd_now, &cd, sizeof(rr->cd_now)); /* timing advance */ rr->cd_now.ta = ia->timing_advance; /* mobile allocation */ memcpy(&rr->cd_now.mob_alloc_lv, &ia->mob_alloc_len, ia->mob_alloc_len + 1); rr->wait_assign = 0; return gsm48_rr_dl_est(ms); } LOGP(DRR, LOGL_INFO, "Request, but not for us.\n"); From 246tnt at gmail.com Wed Jun 23 11:39:09 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 23 Jun 2010 13:39:09 +0200 Subject: Some L1 status updates In-Reply-To: References: Message-ID: Hi Andreas, >> ?- layer23 doesn't currently filter much the IMM.ASS it receives so >> you may end up on a channel that's not yours ... beware. > > what do you mean with "much"? i filter the channel with the channel > request number (includes random number) in the IMM.ASS message. maybe in > the future we can filter the time slot where it was sent (RACH confirm) > and compare it also. but this requires RACH confirm with GSM time where > it was sent. I was refering to "layer23" the quick & dirty test app if you want to play with the layer1. The mobile app does everything properly. For the RACH_CONF, from the code, I see that it already contains the frame number at which the RACH was sent. (in the l1ctl_info_dl header of the CONF message, the frame_nr field is set) Sylvain From laforge at gnumonks.org Thu Jun 24 07:45:02 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 24 Jun 2010 09:45:02 +0200 Subject: Some L1 status updates In-Reply-To: References: Message-ID: <20100624074502.GD3890@prithivi.gnumonks.org> On Wed, Jun 23, 2010 at 01:39:09PM +0200, Sylvain Munaut wrote: > For the RACH_CONF, from the code, I see that it already contains the > frame number at which the RACH was sent. > (in the l1ctl_info_dl header of the CONF message, the frame_nr field is set) yes, this is how I intended it to be used. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Wed Jun 23 12:10:29 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 23 Jun 2010 14:10:29 +0200 Subject: AW: Some L1 status updates Message-ID: > I was refering to "layer23" the quick & dirty test app if you want to > play with the layer1. oops. sorry, but anyway i need to improve the IMM.ASS. check against timestamp. i will test all the new features soon and also check the time stamps if they match. From laforge at gnumonks.org Wed Jun 23 17:30:31 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 23 Jun 2010 19:30:31 +0200 Subject: Some L1 status updates In-Reply-To: References: Message-ID: <20100623173031.GD3301@prithivi.gnumonks.org> Hi Sylvain, On Wed, Jun 23, 2010 at 10:29:36AM +0200, Sylvain Munaut wrote: > The good news, is that hopping and ts[0:4] work just fine and were > surprisingly easy to implement. Thanks a lot for your work and the good news! > The bugs I thought I had were in fact not related to these and just prior > bugs that were never noticed before. (see my sylvain/testing branch). ok, I will look at it, probably at some point tomorrow. > Current limitations: > > - SDCCH8 subchannel 4,5,6,7 won't work. > > For those, we need to TX and RX in the same frame ... which just > isn't possible with the way the primitives work right now. (each > assume to have the full frame for themselve). yes, this is one of the shortcuts Dieter and me were willing to take to get layer1 going in the beginning. > - TS >= 4 may not work > > When using TS>=4 we should also change the interrupt alignment so > that the DSP still has time to do it's job. Switching 'forward' is > easy, but when switching 'back', we need to be conscious that we need > to skip 1 frame at the very least ... > > IMHO to solve both those issue, we need a better scheduler/primitives > that possibly have some knowledge of the 'span' (in terms of qbit) of > each operation. Because if we do a TX on TS=5 for instance, there is > no way we can do a RX on TS=0 on the next frame, the tpu window > overlap. agreed. but I haven't looked at the problem hard/long enough to come up with details for a solution. > - No ciphering. > > That should be trivial to add. Just setup the fn and the kc and set > the flag ... the 'l1s.next_time' contains the godd time of the frame > TX/RX frame during the primitive execution, so that's the FN to use. indeed, it probably is very easy to do right now. And you are the best candidate to do it, given you did the OpenBSC crypto support. > The need for a SIM interface grows quickly :) well, as inidicated, at the moment we're likely to run layer23 (or at least the '3' part) on the PC for a long time to come, a PC/SC reader interface might actually make more sense than remotely driving the sim card reader in the phone. > Some 'gotchas' you might encounter that are not fixed yet: > > - The L1 completion handler crashes. > In target/firmware/layer1/prim_tx_nb.c , > l1s.completion[L1_COMPL_TX_NB] is set in l1s_tx_test() but that's > never called. So you need to comment out > l1s_compl_sched(L1_COMPL_TX_NB) in the 'resp' handler temporarly until > a proper fix. the proper fix is to either move all the l1s.completion[] assignments to l1s_init(), as they only need to be set once - or to have a initialization function for each primitive. The first option requires making the completion functions non-static, which I would actually try to avoid. But having an init callback function for each primitive that only assigns one pointer is probably a stupid idea, too. > - Wireshark SDCCH8 subchannel decoding in IMMEDIATE ASSIGNEMENT is > just plain wrong. (source code uses % 0x38 instead of & 0x38), need to > send a patch for this ok, good (sending patch). probably best to send an example pcap along with it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Jun 24 07:44:25 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 24 Jun 2010 09:44:25 +0200 Subject: Some L1 status updates In-Reply-To: <20100623173031.GD3301@prithivi.gnumonks.org> References: <20100623173031.GD3301@prithivi.gnumonks.org> Message-ID: <20100624074425.GC3890@prithivi.gnumonks.org> Hi Sylvain, On Wed, Jun 23, 2010 at 07:30:31PM +0200, Harald Welte wrote: > > Some 'gotchas' you might encounter that are not fixed yet: > > > > - The L1 completion handler crashes. > > In target/firmware/layer1/prim_tx_nb.c , > > l1s.completion[L1_COMPL_TX_NB] is set in l1s_tx_test() but that's > > never called. So you need to comment out > > l1s_compl_sched(L1_COMPL_TX_NB) in the 'resp' handler temporarly until > > a proper fix. > > the proper fix is to either move all the l1s.completion[] assignments to > l1s_init(), as they only need to be set once - or to have a initialization > function for each primitive. The first option requires making the completion > functions non-static, which I would actually try to avoid. But having an > init callback function for each primitive that only assigns one pointer is > probably a stupid idea, too. I think the cleanest solution is to use __attribute__ ((constructor)) like this: diff --git a/src/target/firmware/layer1/prim_fbsb.c b/src/target/firmware/layer1/prim_fbsb.c index fe87996..2c58033 100644 --- a/src/target/firmware/layer1/prim_fbsb.c +++ b/src/target/firmware/layer1/prim_fbsb.c @@ -561,5 +561,9 @@ void l1s_fbsb_req(uint8_t base_fn, struct l1ctl_fbsb_req *req) else if (fbs.req.flags & L1CTL_FBSB_F_SB) tdma_schedule_set(base_fn, sb_sched_set, 0); +} + +static __attribute__ ((constructor)) void l1s_prim_fbsb_init(void) +{ l1s.completion[L1_COMPL_FB] = &l1a_fb_compl; } diff --git a/src/target/firmware/layer1/prim_rach.c b/src/target/firmware/layer1/prim_rach.c index b8fcaae..6781384 100644 --- a/src/target/firmware/layer1/prim_rach.c +++ b/src/target/firmware/layer1/prim_rach.c @@ -128,5 +128,9 @@ void l1a_rach_req(uint8_t fn51, uint8_t ra) l1a_unlock_sync(); memset(&last_rach, 0, sizeof(last_rach)); +} + +static __attribute__ ((constructor)) void prim_rach_init(void) +{ l1s.completion[L1_COMPL_RACH] = &l1a_rach_compl; } diff --git a/src/target/firmware/layer1/prim_tx_nb.c b/src/target/firmware/layer1/prim_tx_nb.c index 7a72ca3..b721a86 100644 --- a/src/target/firmware/layer1/prim_tx_nb.c +++ b/src/target/firmware/layer1/prim_tx_nb.c @@ -188,8 +188,6 @@ void l1s_tx_test(uint8_t base_fn, uint8_t type) tdma_schedule(base_fn + 4, &l1s_tx_resp, 2, 2, 0); tdma_schedule(base_fn + 5, &l1s_tx_resp, 2, 3, 0); } - - l1s.completion[L1_COMPL_TX_NB] = &l1a_tx_nb_compl; } /* sched sets for uplink */ @@ -203,3 +201,7 @@ const struct tdma_sched_item nb_sched_set_ul[] = { SCHED_END_SET() }; +static __attribute__ ((constructor)) void prim_tx_nb_init(void) +{ + l1s.completion[L1_COMPL_TX_NB] = &l1a_tx_nb_compl; +} however, this means that our linker script and initialization code actually supports the constructor construct. I will take care about this today. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Thu Jun 24 16:19:24 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 24 Jun 2010 18:19:24 +0200 Subject: Some L1 status updates In-Reply-To: <20100624074425.GC3890@prithivi.gnumonks.org> References: <20100623173031.GD3301@prithivi.gnumonks.org> <20100624074425.GC3890@prithivi.gnumonks.org> Message-ID: <20100624161924.GJ3890@prithivi.gnumonks.org> Hi again, On Thu, Jun 24, 2010 at 09:44:25AM +0200, Harald Welte wrote: > On Wed, Jun 23, 2010 at 07:30:31PM +0200, Harald Welte wrote: > > > Some 'gotchas' you might encounter that are not fixed yet: > > > > > > - The L1 completion handler crashes. > > > In target/firmware/layer1/prim_tx_nb.c , > > > l1s.completion[L1_COMPL_TX_NB] is set in l1s_tx_test() but that's > > > never called. So you need to comment out > > > l1s_compl_sched(L1_COMPL_TX_NB) in the 'resp' handler temporarly until > > > a proper fix. > > > > the proper fix is to either move all the l1s.completion[] assignments to > > l1s_init(), as they only need to be set once - or to have a initialization > > function for each primitive. The first option requires making the completion > > functions non-static, which I would actually try to avoid. But having an > > init callback function for each primitive that only assigns one pointer is > > probably a stupid idea, too. > > I think the cleanest solution is to use __attribute__ ((constructor)) > like this: I've now finished the neccessary linker script magic and code to actually call the constructor functions. It has all been merged to master. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Jun 25 01:28:09 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 25 Jun 2010 03:28:09 +0200 Subject: Constructors Message-ID: <20100625012809.GR3890@prithivi.gnumonks.org> Hi! As indicated in other mails, we now have support for gcc-style constructors in OsmocomBB. The way to use them is relatively easy: Simply put "__attribute__((constructor))" at the function that you want to be called during initialization. The way how this works is like this: * gcc and the linker create a table of function pointers to all the functions with that attribute * the code in compal_ramload_start.S takes care of calling lib/ctors.s:do_global_ctors() which iterates over the list and calls each constructor This concept is now used for things like prim_fbsb_init() in layer1, but I have also started to use it for board_init(). This means that board_init() no longer needs to be called from the main() function of each app. We can probably put more stuff into constructors, but we should also be careful as with gcc-4.0.2 we cannot yet indicate priorities and thus there is no explicit way to control the ordering in case of dependencies. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From squalyl at gmail.com Mon Jun 28 14:19:01 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Mon, 28 Jun 2010 16:19:01 +0200 Subject: Constructors In-Reply-To: <20100625012809.GR3890@prithivi.gnumonks.org> References: <20100625012809.GR3890@prithivi.gnumonks.org> Message-ID: Hi, If I understand correctly, this is the same type of idea of the linux kernel's __init magic, except that no code cleanup is done? Regards Sebastien On Fri, Jun 25, 2010 at 3:28 AM, Harald Welte wrote: > Hi! > > As indicated in other mails, we now have support for gcc-style constructors > in OsmocomBB. The way to use them is relatively easy: Simply put > "__attribute__((constructor))" at the function that you want to be > called during initialization. > > The way how this works is like this: > * gcc and the linker create a table of function pointers to all the > functions with that attribute > * the code in compal_ramload_start.S takes care of calling > lib/ctors.s:do_global_ctors() which iterates over the list > and calls each constructor > > This concept is now used for things like prim_fbsb_init() in layer1, > but I have also started to use it for board_init(). This means that > board_init() no longer needs to be called from the main() function > of each app. > > We can probably put more stuff into constructors, but we should also > be careful as with gcc-4.0.2 we cannot yet indicate priorities and thus > there is no explicit way to control the ordering in case of dependencies. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jal2 at gmx.de Mon Jun 28 21:35:36 2010 From: jal2 at gmx.de (Joerg Albert) Date: Mon, 28 Jun 2010 23:35:36 +0200 Subject: Constructors In-Reply-To: References: <20100625012809.GR3890@prithivi.gnumonks.org> Message-ID: <4C2915A8.8070400@gmx.de> On 06/28/2010 04:19 PM, S?bastien Lorquet wrote: > Hi, > > If I understand correctly, this is the same type of idea of the linux > kernel's __init magic, except that no code cleanup is done? > AFAIK it is the same type of idea but implemented in a different way: the linux kernel uses several (self-defined) sections, see http://lxr.free-electrons.com/source/include/linux/init.h lines 170ff. (and 187ff.) #define __define_initcall(level,fn,id) \ static initcall_t __initcall_##fn##id __used \ __attribute__((__section__(".initcall" level ".init"))) = fn to define the init functions and the order they should be called in. Cheers, J?rg. From laforge at gnumonks.org Tue Jun 29 10:25:04 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 29 Jun 2010 12:25:04 +0200 Subject: Constructors In-Reply-To: References: <20100625012809.GR3890@prithivi.gnumonks.org> Message-ID: <20100629102504.GU2940@prithivi.gnumonks.org> On Mon, Jun 28, 2010 at 04:19:01PM +0200, S?bastien Lorquet wrote: > Hi, > > If I understand correctly, this is the same type of idea of the linux > kernel's __init magic, except that no code cleanup is done? It is similar in concept/iea, but as indicated we align the implementation closer to what the GNU GCC C++ runtime does. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Jun 26 13:38:18 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jun 2010 15:38:18 +0200 Subject: OsmocomBB Layer1 progress Message-ID: <20100626133818.GB3890@prithivi.gnumonks.org> Hi all! JFYI: The AGC control in L1 is now active. At least it didn't make things worse for me. Maybe people who have had problems acquiring weak cells should give it a try again. I've also fixed some compile problems due to a missing header file, and there is now a L1CTL_DM_REL_REQ where Layer23 can explicitly release the dedicated mode and return to idle mode. Right now the 'mobile' program (specifically gsm322/gsm48_rr) issue another L1CTL_PM_REQ after a location update reject hap[pens, i.e. layer1 is still in dedicated mode but it gets some power measurements. This results in L1 trying to do Transmit in parallel with power measurements and it crashes at some point. I suggest to add the L1CTL_DM_REL_REQ into the state machine, I suppose it should avoid that problem. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Wed Jun 30 07:56:57 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 30 Jun 2010 09:56:57 +0200 Subject: RSL of Osmocom Message-ID: hi, i like to do extensions to the RSLms layer of osmocom. before that i like to ask and discuss if this would be the correct way: instead directly of calling l1ctl_* functions of l1ctl.c, i would like to use RSL messages between layer 2 and layer 3. the lapdm.c would then convert these messages and call l1ctl_* functions. (maybe i could split up lapdm.c into lapdm.c and layer2.c. the selecting the handler for an RSL request could be made at layer2.c, as well as selecting the right handler for the frames received from layer1. only the lapdm part could be handled in lapdm.c. ) the RACH request could be sent using RSL_MT_CHAN_RQD, the confirm could be the same message type, but i prefer to invent a new one: 0x18, but using the same IE layout. also including RSL_IE_MS_POWER_PARAM with the RACH request, could tell the layer 1 about usage of power and TA (which is normally 0 for RACH request). the (UNIT) DATA request may also include RSL_IE_MS_POWER_PARAMS. if omitted, the stored value from the last message with RSL_IE_MS_POWER_PARAMS could used. the (UNIT) DATA indication and request of SACCH may include RSL_IE_L1_INFO IE to receive power and timing control as well as send the actual power and timing advance. i could handle these IE at layer 3 (radio ressource) and forward them to layer 1 (RSL_IE_MS_POWER_PARAM) depending on the supported radio power and on special VTY settings to mess with power and fake timing advance. regards, andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jun 30 11:59:42 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 30 Jun 2010 13:59:42 +0200 Subject: RSL of Osmocom In-Reply-To: References: Message-ID: <20100630115942.GH4876@prithivi.gnumonks.org> Hi Andreas, On Wed, Jun 30, 2010 at 09:56:57AM +0200, Andreas.Eversberg wrote: > i like to do extensions to the RSLms layer of osmocom. before that i > like to ask and discuss if this would be the correct way: I agree with all of your points. Feel free to go ahead :) And yes, splitting in layer2.c and lapdm.c sounds like a reasonable plan, too. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From drasko.draskovic at gmail.com Wed Jun 30 21:33:38 2010 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Wed, 30 Jun 2010 23:33:38 +0200 Subject: Project hardware question Message-ID: Hi, I have been looking for sometime at OsmocomBB project, but haven't tied it yet. I have seen that software supports a number of Compal phones : Supported Phone hardware Information specific to certain Calypso based phones that we support Designed + Manufactured by Compal, OEM by Motorola MotorolaC115/C117 (E87) MotorolaC123/C121/C118 (E88) -- our primary target MotorolaC140/C139 (E86) MotorolaC155 (E99) -- our secondary target MotorolaV171 (E68/E69) SonyEricssonJ100i So, I was wondering: 1) Which would be best to have to start with, as the most supported target ? 2) Where I can get this phone quickly and easily ? 3) What additional equipment is needed (how do you flash the software and how do you debug) ? 4) Is there some software simulator in which I could see what is happening and how the SW works without actual HW equipment ? Best regards, Drasko From steve at steve-m.de Wed Jun 30 22:29:35 2010 From: steve at steve-m.de (Steve Markgraf) Date: Thu, 01 Jul 2010 00:29:35 +0200 Subject: Project hardware question In-Reply-To: References: Message-ID: <4C2BC54F.5040903@steve-m.de> Hi, At 30.06.2010 23:33, Drasko DRASKOVIC wrote: > So, I was wondering: > 1) Which would be best to have to start with, as the most supported target ? Well, most people have the C123, but the C155 is equally well supported. The C115/C117 is almost identical with the C123 and will work very good as well. > 2) Where I can get this phone quickly and easily ? There are many phones one eBay, and some sellers in Europe who sell them brand new. > 3) What additional equipment is needed (how do you flash the software > and how do you debug) ? For all this you need simple serial cable: http://bb.osmocom.org/trac/wiki/CalypsoSerialCable Currently we're loading the software to the phone ram, starting it from there, execution from flash is in the works (prom/loader branch). Please look a bit around at the wiki, since most questions will straighten out then. > 4) Is there some software simulator in which I could see what is > happening and how the SW works without actual HW equipment ? So far, no. Regards, Steve