---
firmware/src/pcd/main_dumbreader.c | 2 +-
firmware/src/pcd/main_hid.c | 2 +-
firmware/src/pcd/main_presence.c | 2 +-
firmware/src/pcd/main_pwm.c | 2 +-
firmware/src/pcd/main_usb.c | 2 +-
firmware/src/picc/main_openpicc.c | 2 +-
firmware/src/simtrace/main_simtrace.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/firmware/src/pcd/main_dumbreader.c b/firmware/src/pcd/main_dumbreader.c
index 62695f0..9c8dd13 100644
--- a/firmware/src/pcd/main_dumbreader.c
+++ b/firmware/src/pcd/main_dumbreader.c
@@ -88,7 +88,7 @@ void _main_func(void)
/* first we try to get rid of pending to-be-sent stuff */
usb_out_process();
- /* next we deal with incoming reqyests from USB EP1 (OUT) */
+ /* next we deal with incoming requests from USB EP1 (OUT) */
usb_in_process();
rc632_unthrottle();
diff --git a/firmware/src/pcd/main_hid.c b/firmware/src/pcd/main_hid.c
index 9735c3d..c9d8fd1 100644
--- a/firmware/src/pcd/main_hid.c
+++ b/firmware/src/pcd/main_hid.c
@@ -50,7 +50,7 @@ void _main_func(void)
/* first we try to get rid of pending to-be-sent stuff */
usb_out_process();
- /* next we deal with incoming reqyests from USB EP1 (OUT) */
+ /* next we deal with incoming requests from USB EP1 (OUT) */
usb_in_process();
/* try unthrottling sources since we now are [more] likely to
diff --git a/firmware/src/pcd/main_presence.c b/firmware/src/pcd/main_presence.c
index f61878f..4ead264 100644
--- a/firmware/src/pcd/main_presence.c
+++ b/firmware/src/pcd/main_presence.c
@@ -157,7 +157,7 @@ void _main_func(void)
/* first we try to get rid of pending to-be-sent stuff */
usb_out_process();
- /* next we deal with incoming reqyests from USB EP1 (OUT) */
+ /* next we deal with incoming requests from USB EP1 (OUT) */
usb_in_process();
rc632_unthrottle();
}
diff --git a/firmware/src/pcd/main_pwm.c b/firmware/src/pcd/main_pwm.c
index 7db6b72..50fd363 100644
--- a/firmware/src/pcd/main_pwm.c
+++ b/firmware/src/pcd/main_pwm.c
@@ -262,7 +262,7 @@ void _main_func(void)
/* first we try to get rid of pending to-be-sent stuff */
usb_out_process();
- /* next we deal with incoming reqyests from USB EP1 (OUT) */
+ /* next we deal with incoming requests from USB EP1 (OUT) */
usb_in_process();
/* try unthrottling sources since we now are [more] likely to
diff --git a/firmware/src/pcd/main_usb.c b/firmware/src/pcd/main_usb.c
index fcd3306..7892e77 100644
--- a/firmware/src/pcd/main_usb.c
+++ b/firmware/src/pcd/main_usb.c
@@ -35,7 +35,7 @@ void _main_func(void)
/* first we try to get rid of pending to-be-sent stuff */
usb_out_process();
- /* next we deal with incoming reqyests from USB EP1 (OUT) */
+ /* next we deal with incoming requests from USB EP1 (OUT) */
usb_in_process();
/* try unthrottling sources since we now are [more] likely to
diff --git a/firmware/src/picc/main_openpicc.c b/firmware/src/picc/main_openpicc.c
index 74700f8..93ca4b6 100644
--- a/firmware/src/picc/main_openpicc.c
+++ b/firmware/src/picc/main_openpicc.c
@@ -251,7 +251,7 @@ void _main_func(void)
/* first we try to get rid of pending to-be-sent stuff */
usb_out_process();
- /* next we deal with incoming reqyests from USB EP1 (OUT) */
+ /* next we deal with incoming requests from USB EP1 (OUT) */
usb_in_process();
udp_unthrottle();
diff --git a/firmware/src/simtrace/main_simtrace.c b/firmware/src/simtrace/main_simtrace.c
index 5e4302e..740d35d 100644
--- a/firmware/src/simtrace/main_simtrace.c
+++ b/firmware/src/simtrace/main_simtrace.c
@@ -95,7 +95,7 @@ void _main_func(void)
/* first we try to get rid of pending to-be-sent stuff */
usb_out_process();
- /* next we deal with incoming reqyests from USB EP1 (OUT) */
+ /* next we deal with incoming requests from USB EP1 (OUT) */
usb_in_process();
udp_unthrottle();
--
1.7.3.5
--------------090305060903020708070409--
Hello,
Has anyone managed to read (receive) or to send an SMS to Osmocom phone? I haven't found any vty command that would allow this. Also if I send an SMS to Osmocom the phone starts a location update every 1 minute or so and on the phone that sent the message I get the non-delivery report. Could someone give me some tips on how to send/receive SMS?
Hi,
Could it be possible to enable the ticket system in trac ?
It could be used to add suggestions/bugs/todo/..., avoid overloading the
mailing list, and keep trac of them.
For example, how about changing the mobile welcome message from:
Welcome to the OpenBSC Control interface
to:
Welcome to the osmocom Control interface
it makes more sense when using osmocomBB.
thanks,
kevin
When I look in the output of the mobile app I see that IMSI paging goes almos up to 50%. It's almost like for every TMSI I get below a IMSI paging. That's why I asked from the beginning because I get a lot of IMSI there.
When I look in the output of the mobile app I see that IMSI paging goes almos up to 50%. It's almost like for every TMSI I get below a IMSI paging. That's why I asked from the beginning because I get a lot of IMSI there.
Hi!
I've been playing with some code earlier today, trying to reuse the RR
implementation of 'mobile' but without 'MM' and '03.22' code. Next step was to
play with RR+MM but without 03.22.
Both were not that easy to do, given the various different function calls
between those modules.
While trying to resolve it, I discovered that we have many sequences like
gsm322_msgb_alloc() followed by some error checking and a final
gsm322_plmn_senmsg(). Similar pattersn could be seen for gsm48_mmevent.
I've tried to simplify/unify this code a bit, as you can see from the
attached patches (also in laforge/mobile_event branch). It's not tested
yet, but I would like to get some comments on it.
Initially I thought to use libosmocore signal code, but then signals are
_emitted_, and they don't fit the picture where we have some incoming events
into e.g. 03.22 code - as all the events are already labelled GSM322
and thus by the recipient, not its originator.
So now there is one gsm322_event_input() and a gsm48_mmevent_input()
function each. Somebody who wants to reuse partial 'mobile' code can simply
provide stub functions for either one of those (or both)...
The goal of this exercise is to have a tool that can open a dedicated
channel to a user-specified cell and then send user-specified messages
while optionally taking care of loc upd / auth / ciphering in order
to make the network happy.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello,
I noticed that when I start the mobile application, after the phone chooses a specific channel I get different messages regarding IMSI saying that it's not for us. What are these messages? Phones that camp on this channel? If so, I tried turning off/on a phone from the same operator but I can't see my IMSI showing up.
Hello,
I have created few patches that aim to add abstraction for gpio
handling. First patch adds functions:
gpio_config - configure gpio as input/output
gpio_read - read state of gpio(s)
gpio_write - write/toggle state of gpio(s)
gpio_set_handler - enables interrupt on given gpio.
Also changes board init files to make them more sane :-)
Second patch adds interrupt demuxing and masking into keypad driver as
gpio and keypad are handled by the same peripheral.
It would make sense to split the keypad driver into calypso-specific
and generic stuff once there is support for other chipsets.
Also note that interrupt levels in datasheet are active low (p.120),
my testing shows otherwise.
Michal Demin
Hi,
sorry if I shouldn`t write correclly, i`m not that good in english.
i have a Motorola c118 and this usb/serial cable:
http://www.gsmbase.de/shop/show_product.php?products_id=620 here
my problem:
compiling was successfully.
than i run osmocon:
./osmocon -p /dev/ttyUSB0 -m c123xor
/home/test/install/osmocom-bb/src/target/firmware/board/compal_e88/layer1.ramload.bin
i pressed power on the phone.
nothing happend.
again.
nothing happend, no output, no upload/download to/from the phone...
what is my fault? can you help me?
i have tested it with: -m 123 ; -m 118xor ; -m 118 (the same thing)
my system is ubuntu 10.10 (not in a virtual box or something else).
thanks a lot,
tobsen
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/doesn-t-get-output-from-osmocon-…
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi guys,
I think it is desparately needed that we write more documentation about the
'mobile' program in our wiki. It just occurred to me today that no such
page exists so far, and I've created it at
http://bb.osmocom.org/trac/wiki/mobile
I believe a simple reference of commands is not even all that important (after
all, there is 'list' in the telnet interface), but somethnig like common
scenarios like
* behaving like a normal phone with cell-selection (using real sim)
* behaving like a normal phone with cell-selection (using simulated sim)
* how to lock to a certain ARFCN/cell
* how to manually trigger location area update
* how to send/receive sms
* how to make mo/mt phone call
It would be great if some of the more experienced people would find a
couple of minutes to contribute to it. Thanks a lot in advance.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
This is a Mailman mailing list bounce action notice:
List: baseband-devel
Member: arslangali(a)inbox.ru
Action: Subscription disabled.
Reason: Excessive or fatal bounces.
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
mailman(a)lists.osmocom.org.
>> To make it work you have to recompile the module pl2303, with this
>> patch
>> (my kernel is 2.6.35.10-74.fc14.i686). Be careful to setup the right
>> values in the kernel root Makefile in order to fit your running
>> kernel.
>
> Not necessarily. You should also be able to check without recompiling.
>
> Just go to the drivers-directory in sysfs:
>
> cd /sys/bus/usb/drivers/<driver>
>
which <driver>?I cannot find any pl2303 driver here. (Debian and ubuntu
8.04)> and echo the data to the file new_id (as root):
>
> echo "067b 0307" > new_id
>
> This should bind the driver to the new_id.
Niko
Hi baseband developers,
a couple days ago I managed to compile osmocom's binaries and firmware
files from a NetBSD host, using a cross-compilation toolchain generated
with the standard build script on this system. This was actually quite
straightforward, but required some patches and tricks, so I figured it'd
be worth posting it here.
I will write the procedure in more details on my blog [1], in my case it
was enough to do this:
$ CPATH="/usr/include" gmake \
CROSS_TOOL_PREFIX="/home/arm/tools/bin/arm--netbsdelf-"
The patch itself is certainly more interesting to discuss here. I do not
expect it to be fully merged, but I think it may raise interesting points:
- src/shared/libosmocore/src/Makefile.am
linking with "-ldl" is hardcoded, but breaks the build on systems
where it is not required; this is a usual portability issue, already
solved about a thousand times, I'll try to come up with a cleaner
solution here.
- src/shared/libosmocore/src/gsm_utils.c
I think this one is quite elegant, allowing to build even without
support for backtraces; an additional #warning would help though/
- src/shared/libosmocore/src/msgfile.c
here I had to bluntly emulate the functionality of the getline()
call, which seems to be specific to glibc; again, it'd certainly be
nicer if I added a test for HAVE_GETLINE or something along this line.
- src/shared/libosmocore/src/talloc.c
again, talloc seems to rely on strnlen() being part of the libc, which
is already known to not be the case on MacOS X; considering it also
absent of NetBSD fixes the build for me.
- src/target/firmware/include/stdint.h
this one is definitely more ugly, since I tricked the cross-compiler
to believe /usr/include matches its specific needs I ended up with
some essential type definitions already; therefore, I am not sure if
this workaround would not be more harmful upstream than not.
Anyway, the actual patch is attached.
A few more things to NetBSD users:
- my previous patch about building without GNU make is also necessary;
- I haven't tested the resulting binaries on a NetBSD host;
- the firmware images seem to be only partly functional at the moment.
HTH,
--
khorben
On 06/08/2010 09:41 PM, Huseyin Turan wrote:
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ls -l arm-elf-gcc
> -rwxrwxrwx 1 name1 name1 112344 2006-02-17 23:59 arm-elf-gcc
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ./arm-elf-gcc
> bash: ./arm-elf-gcc: cannot execute binary file
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# uname -a
> Linux name1-desktop 2.6.28-19-generic #61-Ubuntu SMP Wed May 26 23:35:15
> UTC 2010 i686 GNU/Linux
>
please try b.) again (you miss the file part) and also please reply to
the mailinglist.
I just thought of another way of using cell_log without GPS. The resulting KML could be parsed and sent to opencellid project, this way we could get the lat-long coordinates and afterward create another kml and send it to Google.
Ex: http://www.opencellid.org/cell/get?mcc=232&mnc=01&cellid=1721&lac=4269
Or even better, use Google API and this way you could also include the Signal strenght and Timing advance for a better position.
See http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&…
--- On Wed, 1/26/11, Bogdan Alecu <b.alecu(a)yahoo.com> wrote:
From: Bogdan Alecu <b.alecu(a)yahoo.com>
Subject: Re: Cell_log > gsmmap
To:
Cc: baseband-devel(a)lists.osmocom.org
Date: Wednesday, January 26, 2011, 7:27 AM
I just thought of another way of using cell_log without GPS. The resulting KML could be parsed and sent to opencellid project, this way we could get the lat-long coordinates and afterward create another kml and send it to Google.
Ex: http://www.opencellid.org/cell/get?mcc=232&mnc=01&cellid=1721&lac=4269
The gnuarm.com toolchain works fine but is very old. And although it is
based on newlib, the os name in the tuple that we used to configure for
is arm-elf-linux, which is of course bogus since we are not building
Linux applications.
Finally, CC= should never be set, instead configure should detect the
right compiler using the --host tuple.
---
src/Makefile | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/Makefile b/src/Makefile
index b3594c1..e66f0ff 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -1,10 +1,10 @@
# this is not really used as we don't do 'make install'. You can still specify
# it in case you _want_ to manually 'make install' the target libosmocore.
-CROSS_INST_PREFIX=/usr/local/stow/osmocom-bb/arm-elf
+CROSS_INST_PREFIX ?= /usr/local/stow/osmocom-bb/arm-2010.09
# this is the prefix of your cross-toolchain programs
-CROSS_TOOL_PREFIX=arm-elf-
+CROSS_TOOL_PREFIX ?= arm-none-eabi-
TOPDIR=$(shell pwd)
OSMOCORE_CONFIGURE_ENV= LIBOSMOCORE_LIBS=$(TOPDIR)/shared/libosmocore/build-host/src/.libs/libosmocore.a \
@@ -37,9 +37,9 @@ shared/libosmocore/build-target:
shared/libosmocore/build-target/Makefile: shared/libosmocore/configure shared/libosmocore/build-target
cd shared/libosmocore/build-target && ../configure \
- --host=arm-elf-linux --disable-vty --enable-panic-infloop \
+ --host=arm-none-eabi --disable-vty --enable-panic-infloop \
--disable-shared --disable-talloc --disable-tests \
- CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs"
+ CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs"
shared/libosmocore/build-target/src/.libs/libosmocore.a: shared/libosmocore/build-target/Makefile
cd shared/libosmocore/build-target && make
--
1.7.2
The gnuarm.com toolchain works fine but is very old. And although
it is based on newlib, the tuple that we used to configure for was
arm-elf-linux, which is of course bogus since we aren't building
Linux applications.
This patch optimizes for the CodeSourcery G++ Lite 2010.09 ARM EABI
toolchain, and assumes that it was unpacked next to the old one.
Download here:
http://www.codesourcery.com/sgpp/lite/arm/portal/release1592
(I haven't gotten the Linux Installer to work, so I recommend the TAR.)
And since CC is detected by configure when a valid host tuple is given
and that toolchain is sane there's no need for us to hard-code the
gnuarm.com compiler name in our Makefile.
---
src/Makefile | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/Makefile b/src/Makefile
index b3594c1..f2d935b 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -1,10 +1,13 @@
# this is not really used as we don't do 'make install'. You can still specify
# it in case you _want_ to manually 'make install' the target libosmocore.
-CROSS_INST_PREFIX=/usr/local/stow/osmocom-bb/arm-elf
+CROSS_INST_PREFIX ?= /usr/local/stow/osmocom-bb/arm-2010.09
+
+# this is the host tuple of your cross-toolchain
+HOST ?= arm-none-eabi-
# this is the prefix of your cross-toolchain programs
-CROSS_TOOL_PREFIX=arm-elf-
+CROSS_TOOL_PREFIX ?= $(CROSS)-
TOPDIR=$(shell pwd)
OSMOCORE_CONFIGURE_ENV= LIBOSMOCORE_LIBS=$(TOPDIR)/shared/libosmocore/build-host/src/.libs/libosmocore.a \
@@ -37,9 +40,9 @@ shared/libosmocore/build-target:
shared/libosmocore/build-target/Makefile: shared/libosmocore/configure shared/libosmocore/build-target
cd shared/libosmocore/build-target && ../configure \
- --host=arm-elf-linux --disable-vty --enable-panic-infloop \
+ --host=$(HOST) --disable-vty --enable-panic-infloop \
--disable-shared --disable-talloc --disable-tests \
- CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs"
+ CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs"
shared/libosmocore/build-target/src/.libs/libosmocore.a: shared/libosmocore/build-target/Makefile
cd shared/libosmocore/build-target && make
--
1.7.2
--dMyqICaxQaaUjrCL--
The gnuarm.com toolchain works fine but is very old. And although
it is based on newlib, the tuple that we used to configure for was
arm-elf-linux, which is bogus since we aren't building for Linux.
This patch optimizes for the CodeSourcery G++ Lite 2010.09 ARM EABI
toolchain instead, and for libosmocore installation it assumes that
the new toolchain was unpacked next to the old one. Download it here:
http://www.codesourcery.com/sgpp/lite/arm/portal/release1592
(The Linux Installer seems not to work reliably so I recommend the TAR.)
Since CC is detected by configure when the host tuple points to a sane
toolchain we shouldn't hard-code the gnuarm.com compiler.
The patch autodetects arm-elf-gcc installed in PATH, and uses arm-elf
as prefix if it is found. Otherwise, it defaults to arm-none-eabi.
make CROSS_HOST=arm-xyzzy can be used to override on the command line.
---
src/Makefile | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/Makefile b/src/Makefile
index b3594c1..402f28a 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -1,10 +1,13 @@
# this is not really used as we don't do 'make install'. You can still specify
# it in case you _want_ to manually 'make install' the target libosmocore.
-CROSS_INST_PREFIX=/usr/local/stow/osmocom-bb/arm-elf
+CROSS_INST_PREFIX ?= /usr/local/stow/osmocom-bb/arm-2010.09
+
+# this is the host tuple of your cross-toolchain
+CROSS_HOST ?= $(shell which arm-elf-gcc >/dev/null 2>&1 && echo arm-elf || echo arm-none-eabi)
# this is the prefix of your cross-toolchain programs
-CROSS_TOOL_PREFIX=arm-elf-
+CROSS_TOOL_PREFIX=$(CROSS_HOST)-
TOPDIR=$(shell pwd)
OSMOCORE_CONFIGURE_ENV= LIBOSMOCORE_LIBS=$(TOPDIR)/shared/libosmocore/build-host/src/.libs/libosmocore.a \
@@ -37,9 +40,9 @@ shared/libosmocore/build-target:
shared/libosmocore/build-target/Makefile: shared/libosmocore/configure shared/libosmocore/build-target
cd shared/libosmocore/build-target && ../configure \
- --host=arm-elf-linux --disable-vty --enable-panic-infloop \
+ --host=$(CROSS_HOST) --disable-vty --enable-panic-infloop \
--disable-shared --disable-talloc --disable-tests \
- CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs"
+ CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs"
shared/libosmocore/build-target/src/.libs/libosmocore.a: shared/libosmocore/build-target/Makefile
cd shared/libosmocore/build-target && make
--
1.7.2
--ibvzjYYg+QDzMCy1--
The gnuarm.com toolchain works fine but is very old. And although
it is based on newlib, the tuple that we used to configure for was
arm-elf-linux, which is of course bogus since we aren't building
Linux applications.
This patch optimizes for the CodeSourcery G++ Lite 2010.09 ARM EABI
toolchain, and assumes that it was unpacked next to the old one.
Download here:
http://www.codesourcery.com/sgpp/lite/arm/portal/release1592
(I haven't gotten the Linux Installer to work, so I recommend the TAR.)
And since CC is detected by configure when a valid host tuple is given
and that toolchain is sane there's no need for us to hard-code the
gnuarm.com compiler name in our Makefile.
---
src/Makefile | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/Makefile b/src/Makefile
index b3594c1..bb34175 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -1,10 +1,13 @@
# this is not really used as we don't do 'make install'. You can still specify
# it in case you _want_ to manually 'make install' the target libosmocore.
-CROSS_INST_PREFIX=/usr/local/stow/osmocom-bb/arm-elf
+CROSS_INST_PREFIX ?= /usr/local/stow/osmocom-bb/arm-2010.09
+
+# this is the host tuple of your cross-toolchain
+HOST ?= arm-none-eabi-
# this is the prefix of your cross-toolchain programs
-CROSS_TOOL_PREFIX=arm-elf-
+CROSS_TOOL_PREFIX ?= $(HOST)-
TOPDIR=$(shell pwd)
OSMOCORE_CONFIGURE_ENV= LIBOSMOCORE_LIBS=$(TOPDIR)/shared/libosmocore/build-host/src/.libs/libosmocore.a \
@@ -37,9 +40,9 @@ shared/libosmocore/build-target:
shared/libosmocore/build-target/Makefile: shared/libosmocore/configure shared/libosmocore/build-target
cd shared/libosmocore/build-target && ../configure \
- --host=arm-elf-linux --disable-vty --enable-panic-infloop \
+ --host=$(HOST) --disable-vty --enable-panic-infloop \
--disable-shared --disable-talloc --disable-tests \
- CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs"
+ CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs"
shared/libosmocore/build-target/src/.libs/libosmocore.a: shared/libosmocore/build-target/Makefile
cd shared/libosmocore/build-target && make
--
1.7.2
--nEsDIrWrg+hrB7l1--
Hello Holger,
On Tue, 25 Jan 2011 16:51:02 +0100, "Holger Hans Peter Freyther" <holger(a)freyther.de> wrote:
>
> Almost perfect. I can apply and modify myself or you could do two things. We
> tend to avoid the '//' comments, they were only added in C99 and used to be a
> GCC extension for C.
This is a good one ;-) One of the biggest problems when I tried a long
time ago to compile any of OpenBSC or OsmocomBB with a different compiler
than GCC were designated initializer which are _heavily_ used all over the
sources (I don't question their advantage, I only mention it). They are
a C99 feature (besides the library function snprintf() in the patch you
commented). So I would not care about the '//', this was the smallest
problem I had when I did my porting experiment (in fact the compilers
I am aware of silently accept it).
Just out of interest, do we really want to to avoid C99 ? I know there
is this implicit "kernel style" coding rule, does it include C99 ?
Please note that I don't want to discuss this, I use GCC from
Cygwin and can find workarounds for Linux specific issues on Windows
on my own, so I don't care that much. I am just interested in the
reasons for using C99 or not.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Do i need a GPS Reciver ?
I tought that it will calculate the location over Triangulation ?
On Tue, Jan 25, 2011 at 10:34 AM, Holger Hans Peter Freyther <
holger(a)freyther.de> wrote:
> On 01/25/2011 08:33 AM, MArc Richter wrote:
>
> > But when i convert it into a kml file with gsmmap i can't see any GPS
> > koordinates. Why ?
>
> Do you have a GPS receiver attached to your computer?
>
>
Hey!
I've tryed out the Cell_log tool to get the Location of the GSM cells.
But when i convert it into a kml file with gsmmap i can't see any GPS
koordinates. Why ?
I use the Sylvain branch an compiled with TX support
thx
I looked more into this phone recently and found out it supported SIP over
WiFi as well.
Does anyone know about the software running the phone? How are the VOIP
codecs handled? Is there hardware support for them?
Finally, does code and/or drivers already exist for the hardware components?
I happened to be looking for something exactly like this anyway. Cool to
know that OsmocomBB can (potentially) work on it too.
Scott
Hi all,
it appears that we all know of some issues but we are not writing them down.
Would it make sense to start using the bugtracker for that? Or just a
dedicated wiki site?
Hi,
maybe I'm missing something, but when I read that the Pirelli DP-L10
would be supported I tried to get it running:
I didn't patch my usb-module, but used:
modprobe -v cp210x
echo "0489 e003" > /sys/bus/usb-serial/drivers/cp210x/new_id
from the steve-m/testing-branch I compiled the firmware and loaded it with
./host/osmocon/osmocon -p /dev/ttyUSB0 -m romload target/firmware/board/pirelli_dpl10/hello_world.highram.bin
onto the phone... that worked but I was never able to see any messages
after the upload:
Received block ack from phone
Sending checksum: 0xaa
Checksum on phone side matches, let's branch to your code
Branching to 0x00820000
Received branch ack, your code is running now!
... there it stayed forever ...
I'm pretty sure that the code runs, because I commented in init.c the
keyboard lighting code and it didn't light up after upload. I've tried
other bins but to no success.
Any hint or am it too early playing with that hardware?
Greetings Leif
Hello,
In order for this attack to work it has to be on a GSM network because on 3G there is a higher security mechanism. A way to protect against this, for the opperator, could be to implement 3G over 900Mhz so this way even if the targeted phones are on 2G they will still be protected. Am I right?
Regards,
Bogdan
Hey, I ordered the serial cable coming from dealextreme and it has not
arrived yet. I noticed today that the link was taken off the wiki due to it
not being at TTL levels. I was wondering if I bought a Nokia serial cable
(the ones that have the prolific chips in them) which runs at 3.3v out of
the box, could I just connect the tx and rx pins to the cable I had bought
and it would possibly work or would that be a bad idea and I should cut my
losses and kill the order.
--
-Tom
Hello All,
Pls help me, any one who can
Kindly give me code or even binary file for sniff code which Sylvain
demonstrated in chao meeting, it will solve my purpose,
i can See, in video he made the same interface to tune to a ARFCN,
TS , and hopping sequence as i requested a long time back to mailling
list It will
be great help for poor students.
my project don't required any a5 creaking so it wont be used as unlawful means.
so far i have arranged 12 USRP1 to run openBTS.
I just wanted to do the same, which Sylvain have done in video @ chao
presentation, except cracking the encryption as i will configure
openBTS as a5/0
coz it’s education transmission not necessary to encrypt kindly do me a
favour in shake of charity.
Pls reply to my query pls help me in the shake of poor students.
I promise will keep that code secret and will not disclose to any one else.
or pls advise me how i can modify existing code up to that level.
Kindly reply on my request , can you pls provide me Sniff software?
it will help me allot, my NGO can deploy a pilot project at least
Kind Regards,
Hi,
I'm trying to get the burst_ind branch working at the higher speed baud rates. I
have a USB to Serial FTDI Cable (FT232R) plus the T191. This setup works fine
with the main trunk of osmocombb. When I fire up osmocon, layer1 appears to
download to the phone and runs successfully. Osmocon then logs 'Received
DOWNLOAD ACK from phone, your code is running now!'. The phone has layer1.bin
displayed as usual. However it goes no further and just hangs.
Could anyone please give any advice on what to try next?
Thanks,
Matt.
Thanks to Tomas and ton, I can run osmocombb on the phone. But the phone
can't attach the network, can't make a call, can't recognise the SIM card. I
found that this was no BCCH received in wireshark.
And when I type some command via telnet localhost, it always output "Command
incomplete"
Anybody can give me some solution? Thanks!
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Why-my-phone-can-t-attach-the-ne…
Sent from the baseband-devel mailing list archive at Nabble.com.
I guess you have the default configuration:
"No Mobile Station defined, creating: MS '1'"
After you start "mobile" application, select "enable" and then "write". This will write your configuration to /etc/osmocom/osmocom.cfg After that edit this file and set from no sim to sim reader. Restart the mobile application and it should work.
Hello everydoby
I have Motorola-branded prolific usb cable. This cable, once inserted in
a port, claims to be a 0307 chipset adapter, and Linux kernel doesn't
recognize it: not working. Someone told me that Motorola has changed the
label in those cables that claim to be 0307, but they are pl2303.
Does anyone have one of these cables working? I've tried many ways,
including udev, to make it work, but no success. My next step is to
recompile the kernel module, but I was wondering if someone has solved
it in another way.
Bye
Dario.
Hi all,
last weekend I have grinded down a DP-L10 pcb and traced the TSPACT
wiring of this board. I've added support for this phone, along with a
few other changes in my branch steve-m/testing.
Changes include:
* Add support for Pirelli DP-L10
* Add TX support for the gta0x devices
* separate board images for the Compal E86 (Motorola C139/C140)
(display/keypad backlight now works by default)
If anyone wants to test those changes (especially the freerunner TX
support, since I have no freerunner), please feel free to do so. I
tested the other changes and didn't find any regressions, so if no one
else does, we can merge it to master soon.
One thing I noticed during testing: The C139/C140 seem to have a
different SYSTEM_INHERENT_GAIN, I compared the RX levels of several
C118/C123/C155 with several C139/C140, and the reported rx level was
always at around 18-20dBm worse than with the C123.
Regards,
Steve
Hi,
I tried to follow instruction on SIM Reader wiki, but seems I got different result.
OsmocomBB> enable
OsmocomBB# sim reader 1
OsmocomBB# show subscriber
Mobile Subscriber of MS '1':
IMSI:
Status: U2_NOT_UPDATED IMSI detached LAI: invalid
Access barred cells: no
Access classes:
OsmocomBB# show support
Supported features of MS '1':
Phase 2 mobile station
R-GSM : yes
E-GSM : yes
P-GSM : yes
GSM900 Class: 4
DCS 1800 : yes
DCS Class : 1
CECS : no
VGCS : no
VBS : no
SMS : yes
SS_IND : yes
PS_CAP : no
CMSP : no
SoLSA : no
LCSVA : no
LOC_SERV : no
A5/1 : yes
A5/2 : yes
A5/3 : no
A5/4 : no
A5/5 : no
A5/6 : no
A5/7 : no
A5/1 : yes
Channels : SDCCH + TCH/F + TCH/H
Full-Rate V1: yes
Full-Rate V2: yes
Full-Rate V3: no
Half-Rate V1: yes
Half-Rate V3: no
Min RXLEV : -106
OsmocomBB# show ms
MS '1' is down, radio is not started
IMEI: 000000000000000
IMEISV: 0000000000000000
IMEI generation: fixed
automatic network selection state: A0 null
cell selection state: C0 null
radio ressource layer state: idle
mobility management layer state: MM idle, PLMN search
from the layer23 part,
$ ./mobile -i 127.0.0.1 -d
Copyright (C) 2008-2010 ...
Contributions by ...
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
mobile: option requires an argument -- d
VTY available on port 4247.
No Mobile Station defined, creating: MS '1'
<000e> sim.c:1206 init SIM client
<0005> gsm48_cc.c:61 init Call Control
<0001> gsm48_rr.c:4944 init Radio Ressource process
<0004> gsm48_mm.c:1220 init Mobility Management process
<0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM.
<0002> gsm322.c:3471 init PLMN process
<0003> gsm322.c:3472 init Cell Selection process
<0003> gsm322.c:3526 No stored BA list
Mobile '1' initialized, please start phone now!
<0004> subscriber.c:556 Requesting SIM file 0x2fe2
<000e> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000e> sim.c:697 go MF
<000e> sim.c:241 SELECT (file=0x3f00)
<000e> sim.c:187 sending APDU (class 0xa0, ins 0xa4)
can't perform location update, and from the error, is that mean the application failed to read the simcard correctly?
and what's the meaning of "Mobile '1' initialized, please start phone now!", is it starting the phone by push the power button? if so, since the firmware is loaded I can't make the phone start like using original firmware. If i push the button, it will show message like
Found flash of 2097152 bytes at 0x0 with 2 regions
Region 0 of 31 pages with 65536 bytes each.
Region 1 of 8 pages with 8192 bytes each.
key=20 pressed
Powering off due to keypress.
I am using motorola c118 anw. any clue about this error?
Thanks.
Best Regards,
Rasyid
Hi all,
i noticed that article
http://www.eetimes.com/electronics-news/4212228/Picochip-shares-femtocell-r…
speaking about 3G basestation on USB dongle.
That's really cool, i don't know about the hardware, but for sure when
those device will be out the hacking perspective would be really
interesting for projects like OpenBSC and OsmocomBB .
-naif
Hi all!
In order to avoid the most common problems, I propose exporting something like
a feature bitmask on the L1CTL, i.e.
* L1CTL user code (layer23) can send a L1CTL_GET_FEAT_REQ request
* laye1 in the phone sends a L1CTL_GET_FEAT_RESP with all the bits
set to 1 for the features it supports
* L1CTL user code (layer23) can then check if all the features it needs are
supported by the L1. IF not, it can simply abort or print a warning to the
user.
We can simply extend the size of the bitmask over time if we need more bits.
Obvious bits I would consider are:
- is this firmware compiled with TX support?
- does this firmware contain a SIM reader driver?
- does this firmware support BURST_IND?
Maybe we could also include a static header containing a compile timestamp or
the git date/revision that the firmware was built, as well as a name of the
board.
Now I know, nice idea, who will implement it? I currently have othe
priorities, but if somebody lurking on this list is looking for a relatively
simple way to contribute back to the project (without knowing anything about
GSM!) this might be something useful you could do.
Thanks in advance,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
On Mon, Jan 17, 2011 at 11:46:50AM -0800, Bogdan Alecu wrote:
> Hello,
>
> Sorry for writing you directly to your email. Thank you very much for the wiki. I was wondering if you have some knowledge about the "sim test" mode. I tried it by filling in the IMSI and MCC MNC. After I start the layer2 in a few seconds layer1 crashes. What I am trying to achieve is to send a IMSI detach to the network for the specified IMSI. Maybe you could give me a hand with this.
This is often second question after getting SIM working, so I want to
share what I know. However, I'm not an expert, and most of this is
gathered from presentations and speaking with people who know more than
I do, so I wanted to bounce this against mailing list for additional
comments.
As far as I understand it, to connect to provider network, you need
provider's ki which is shared secret between network and sim card.
There are some practical attacks on older sim cards which are used by
multi-network sim cards. It seems there is limited number of brute-force
interations that cards support before disabling themself and that
changed somehow in recent cards.
Best SIM explanation I found so far is on 27C3 wiki about GSM network:
http://events.ccc.de/congress/2010/wiki/GSM#Why_do_I_need_to_buy_your_SIM_c…
> --- On Mon, 1/17/11, Dobrica Pavlinusic <dpavlin(a)rot13.org> wrote:
>
>
> From: Dobrica Pavlinusic <dpavlin(a)rot13.org>
> Subject: wiki: SIMReader Was: Sim on C115 & C118
> To: "Bogdan Alecu" <b.alecu(a)yahoo.com>
> Cc: dario.lombardo(a)libero.it, baseband-devel(a)lists.osmocom.org
> Date: Monday, January 17, 2011, 7:05 PM
>
>
> On Mon, Jan 17, 2011 at 10:24:51AM -0800, Bogdan Alecu wrote:
> > I was going to ask the same question because I have same problem with sim reader mode. However I haven't used Sylvain test. I will and come back with an update.
>
> There seems to be sufficiant interest for using SIM reader, so I created
> page on wiki which might serve as good pointer:
>
> http://bb.osmocom.org/trac/wiki/SIMReader
>
> --
> Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org
> Unix addict. Internet consultant. http://www.rot13.org/~dpavlin
>
>
>
>
--
Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org
Unix addict. Internet consultant. http://www.rot13.org/~dpavlin
~/src/osmocom-bb/src/host/osmocon$ ./osmocon -p /dev/ttyUSB0 -m c123
../../target/firmware/board/compal_e88/layer1.compalram.bin
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 2f /
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 1b .
got 2 bytes from modem, data looks like: f6 02 ..
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 01 .
got 1 bytes from modem, data looks like: 40 @
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/layer1.compalram.bin):
file_size=50932, hdr_len=4, dnload_len=50939
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: f6 .
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 43 C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/50939)
handle_write(): 4096 bytes (8192/50939)
handle_write(): 4096 bytes (12288/50939)
handle_write(): 4096 bytes (16384/50939)
handle_write(): 4096 bytes (20480/50939)
handle_write(): 4096 bytes (24576/50939)
handle_write(): 4096 bytes (28672/50939)
handle_write(): 4096 bytes (32768/50939)
handle_write(): 4096 bytes (36864/50939)
handle_write(): 4096 bytes (40960/50939)
handle_write(): 4096 bytes (45056/50939)
handle_write(): 4096 bytes (49152/50939)
handle_write(): 1787 bytes (50939/50939)
handle_write(): finished
It stopped here for very long time, I have tried with XOR and without XOR
for many times! Please help me to verify this issue! thanks very much!
--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Why-my-C118-can-t-send-DOWNLOAD-…
Sent from the baseband-devel mailing list archive at Nabble.com.
Hi,
at 27c3, I tested some toolchains with osmocom-bb and found a few
build-problems, even with the recommended gnuarm-3.4.3. I want to
document them here, so other people can find hints about it.
*** GNUARM 3.4.3 TOOLCHAIN
master branch
=============
../../src/rate_ctr.c:24:22: inttypes.h: No such file or directory
Holger suggested to manually remove this line. It is fixed upstream
in libosmocore and osmocom-bb needs to be synced to it. Please do :)
remotes/origin/steve-m/loader_sciphone
======================================
1) First problem is:
In file included from ../../include/osmocore/msgb.h:23,
from ../../src/msgb.c:27:
/home/wsa/Dev/osmocom-bb/src/target/firmware/include/stdint.h:13:25: stdint.h: No such file or directory
Cherry-picking e0a605819c39187a494e43cf591f2e79a9d9903f (stdint.h: Next attempt at making this work with various compilers) helps.
2) It then runs into the problem of the master branch.
3) After this is fixed, I get
../../../src/codec/gsm610.c:24:20: stdint.h: No such file or directory
../../../src/codec/gsm610.c:33: error: parse error before "gsm610_bitorder"
which needs 733c894c18c127ce5c023e39609b7d2b9e748e7e (build: Use absolute path in the CFLAGS for libosmocore target build) as a fix.
4) This then, leads to:
arm-elf-ld: address 0x400054d4 of board/mt62xx/loader.mtkram.elf section .text is not within region LRAM
which is sadly also present when you just cherry-pick the main patch
d04761d19c432201f7c0f10c72f788fb695d466a ([WIP] Modify loader for use as first stage bootloader on MT62xx devices)
on top of current master + its build fix. So, does it seem sensible to simply
rebase this branch to master which would eliminate the first three problems?
Or at least cherry-pick the above fixes?
Also, the workarounds for gcc3 do not look very sustainable (see custom stdint.h).
Is it a mid-term option to remove that stuff if a reliable pre-built gcc4 is
available? (I am working on that, see below).
BTW the linker error was not further worked on yet. I got a prebuilt binary now.
It is possibly helpful to put it on the G2-wikipage, so people wanting to
work on the Linux-support only are spared from the above hassle.
*** CUSTOM 4.3.2 TOOLCHAIN
every branch
============
The configure-stage of libosmocom already fails for the target with error
77. The config.log says in detail:
configure:3231: checking whether the C compiler works
configure:3253: arm-elf-gcc -Os -ffunction-sections -I/home/wsa/Dev/osmocom-bb/src/target/firmware/include conftest.c >&5
/home/opt/OSELAS.Toolchain-1.99.3/arm-elf/gcc-4.3.2-newlib-1.16.0-binutils-2.18/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libc.a(lib_a-exit.o): In function `exit':
/home/mkl/himalia-pengutronix/toolchain/releases/OSELAS.Toolchain-1.99.3.6/platform-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18/build-target/newlib-1.16.0/newlib/libc/stdlib/exit.c:65: undefined reference to `_exit'
/home/opt/OSELAS.Toolchain-1.99.3/arm-elf/gcc-4.3.2-newlib-1.16.0-binutils-2.18/bin/../lib/gcc/arm-elf/4.3.2/../../../../arm-elf/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
/home/mkl/himalia-pengutronix/toolchain/releases/OSELAS.Toolchain-1.99.3.6/platform-arm-elf-gcc-4.3.2-newlib-1.16.0-binutils-2.18/build-target/newlib-1.16.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk'
27c3 was too interesting ;) so I haven't fixed this yet. The Mac-toolchains
also throw this and I also have seen it on the list before, so I hope I
can work on it the next days.
So much for now. It would be nice if someone with write-access to the repo
could comment on my questions and/or fix the low-hanging fruits. I will
hopefully be able to send some updates soon, too (famous last words).
It was great to meet you all in person!
All the best,
Wolfram
Hi Lia,
I have tested another cable (USB <-> 2,5 jack, speacial for Compal
phones) - it is the same chip (Prolific) and I am able to load firmware
too. Although it is the same chip, there is a difference that this one
makes the osmocon printing those messages instantly when phone is not
connected:
got 1 bytes from modem, data looks like: f5 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: f5 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: f5 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: fd .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: f5 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: fd .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: ea .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: ea .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: ea .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: ea .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: fd .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: ea
If I connect phone, printing stops. Here is what happened when I tried
to load firmware without xor (-m c123) and pressed the button:
(This happened every attempt without xor flag)
Received PROMPT2 from phone, starting download
handle_write(): 1087 bytes (1087/50947)
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: f6 .
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 45 E
got 1 bytes from modem, data looks like: 53 S
got 1 bytes from modem, data looks like: 16 .
Received DOWNLOAD NACK from phone, something went wrong :(
got 1 bytes from modem, data looks like: 66 f
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6d m
got 1 bytes from modem, data looks like: 74 t
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 6c l
Received FTMTOOL from phone, ramloader has aborted
got 1 bytes from modem, data looks like: 65 e
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 6f o
got 1 bytes from modem, data looks like: 72 r
got 1 bytes from modem, data looks like: 00 .
If you have USB adapter (I guess you have), you dont need to check
model, check 'lsusb'
[root@amilo osmocon]# lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
*Bus 002 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303
Serial Port*
If you have Prolific, which is very common, I encourage you to use xor
flag. You can also try to switch on your phone to check if original
firmware boots. I experienced during my early tests, that phone crashed
(probably SRAM) and it was unable to boot even original fw. In case
phone is crashed, reconnect battery and it will fix itself.
Here is the ACK after hello world load:
handle_write(): 768 bytes (17919/19787)
handle_write(): 768 bytes (18687/19787)
handle_write(): 768 bytes (19455/19787)
handle_write(): 332 bytes (19787/19787)
handle_write(): finished
got 1 bytes from modem, data looks like: 1b .
got 1 bytes from modem, data looks like: f6 .
got 1 bytes from modem, data looks like: 02 .
got 1 bytes from modem, data looks like: 00 .
got 1 bytes from modem, data looks like: 41 A
got 1 bytes from modem, data looks like: 03 .
got 1 bytes from modem, data looks like: 42 B
Received DOWNLOAD ACK from phone, your code is running now!
OSMOCOM Hello World (revision osmocon_v0.0.0-754-gb5abcb6-modified)
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: efce3b1ce1001255
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
==============================================
Looking forward your response,
Tomas
> Hi Tomas,
>
> thanks for your feedback.
>
> Actually, I've tried both flags (woth/without xor extension), but hte
> result is the same.
>
> So, in your opinioni, the problem could depend on the cable?
>
> I don't have the cable model now, but I can send you this information
> Tuesday.
>
> Thanks again.
>
> cheers.
>
> lia
>
> ----Messaggio originale----
> Da: deacon(a)volny.cz
> Data: 16-gen-2011 4.26
> A: <list_mailing(a)libero.it>
> ubut Ogg: Re: C115 loader.compalram.bin
>
> Hello,
> I have C115 too and I use '-m c123xor' switch, the phone mostly
> boots on 1st button push (I never reacher full load with '-m c123').
>
> ./osmocon -p /dev/ttyUSB0 -m c123xor
> ../../target/firmware/board/compal_e88/hello_world.compalram.bin
> ./osmocon -p /dev/ttyUSB0 -m c123xor
> ../../target/firmware/board/compal_e88/loader.compalram.bin
> ./osmocon -p /dev/ttyUSB0 -m c123xor
> ../../target/firmware/board/compal_e88/layer1.compalram.bin
>
> I have FTDI USB<->RS232 + Calypso serial. When load fails (with
> xor), I have a feeling that it helps reconnection cable to the phone.
> (I have also Calypso USB cable which I haven't tested yet, will
> report later.)
>
> - Tomas
>
>
>>> Hello.
>>> I'm trying to load the loader.compalram.bin.
>>> The behaviour is very strange because sometimes the download is complete and
>>> successfull, sometimes; in particular, in this case, the download is complete,
>>> but any ACK is sent back from the mobile phone (see below).
>>> ./osmocon -p /dev/ttyUSB0 -m c123 ../..
>>> /target/firmware/board/compal_e99/loader.compalram.bin
>>> got 2 bytes from modem, data looks like: 2e c8 ..
>>> got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A
>>> got 1 bytes from modem, data looks like: 01 .
>>> got 1 bytes from modem, data looks like: 40 @
>>> Received PROMPT1 from phone, responding with CMD
>>> read_file(../../target/firmware/board/compal_e99/loader.compalram.bin):
>>> file_size=21752, hdr_len=4, dnload_len=21759
>>> got 1 bytes from modem, data looks like: 1b .
>>> got 1 bytes from modem, data looks like: f6 .
>>> got 1 bytes from modem, data looks like: 02 .
>>> got 1 bytes from modem, data looks like: 00 .
>>> got 1 bytes from modem, data looks like: 41 A
>>> got 1 bytes from modem, data looks like: 02 .
>>> got 1 bytes from modem, data looks like: 43 C
>>> Received PROMPT2 from phone, starting download
>>> handle_write(): 4096 bytes (4096/21759)
>>> handle_write(): 4096 bytes (8192/21759)
>>> handle_write(): 4096 bytes (12288/21759)
>>> handle_write(): 4096 bytes (16384/21759)
>>> handle_write(): 4096 bytes (20480/21759)
>>> handle_write(): 1279 bytes (21759/21759)
>>> handle_write(): finished
>>>
>>>
>>> The target phone is C115. I tried compal_exx and the result is the same :-(
>>>
>>> Please, can someone help me to understand the reasons?
>>> Thanks in advance.
>>>
>>>
>>>
>>>
>>
>
>
>
Several toolchains are missing syscalls provided by the libc used. For example,
if the newlib was build with the configure flag "--disable-newlib-supplied-syscalls".
To prevent the configure check for things like "_exit" in osmocom
the CFLAGS+="-nostartfiles -nodefaultlibs" helps a lot.
Signed-off-by: Michael Grzeschik <mgr(a)xviews.de>
Acked-by: Wolfram Sang <wolfram(a)the-dreams.de>
---
src/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/Makefile b/src/Makefile
index a0dea5d..b3594c1 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -39,7 +39,7 @@ shared/libosmocore/build-target/Makefile: shared/libosmocore/configure shared/li
cd shared/libosmocore/build-target && ../configure \
--host=arm-elf-linux --disable-vty --enable-panic-infloop \
--disable-shared --disable-talloc --disable-tests \
- CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include"
+ CC="$(CROSS_TOOL_PREFIX)gcc" CFLAGS="-Os -ffunction-sections -I$(TOPDIR)/target/firmware/include -nostartfiles -nodefaultlibs"
shared/libosmocore/build-target/src/.libs/libosmocore.a: shared/libosmocore/build-target/Makefile
cd shared/libosmocore/build-target && make
--
1.7.2.3