20 Jan
2013
20 Jan
'13
12:14 p.m.
Hi!
First I do not know if this is the proper mailing lists, as I am not a
developer but a user. But I couldn't find a user list. So please advice
if there is a better list.
I started playing with Osmocom and my "brand new" C118 :-) and meanwhile
I made my first open source GSM phone call. Following is my list of
questions and suggestions I experienced so far:
- Build System: since the "Use the system wide libosmocore for host
applications" commit it is required that libosmocore is built
separately. But the documentation is still confusing. Thus I think it
would be good to:
- remove the libosmocore subtree git from osmocom-bb git
- remove this line of text from
http://bb.osmocom.org/trac/wiki/libosmocore: "When you download and
build OsmocomBB, then libosmocore is automatically part of the package,
no special action is required."
- osmocom: some wiki pages refer to an "osmocom" application. Is there
an osmocom binary? (I think most times it is a typo for osmocon)
- I use Wireshark to capture the GSMTAP packets of "monitor". How do I
find out in the Wireshark trace if a message is sent from the MS or is
received by the MS?
- I want to study the high layer messages (e.g. not cell selection but
call setup, registering to the network) but I am lost in the debug
flags: DCS:DNB:DPLMN:DRR:DMM:DSIM:DCC:DMNCC:DSS:DLSMS:DPAG:DSUM. Which
ones are needed in my case? Is there somewhere a description of the flags?
- Some tools (e.g. cell_log) give 'SAP' log messages, e.g:
Failed to connect to '/tmp/osmocom_sap'.
Failed during sap_open(), no SIM reader
I suspect this is for communcation with SIM cards. How it is supposed to
work?
- Is this 'SAP' stuff only needed/useful for softSIMs?
- Which application should create the /tmp/osmocom_sap socket? (osmocon
only creates /tmp/osmocom_l2 and /tmp/osmocom_loader)
- Would it be possible to remove the SIM card from my C118 and put it in
an external SIM reader, and then let "mobile" use the SIM card in the
external reader instead?
Thanks
Klaus
PS: I'm willing to improve the documentation in the wiki with your
answers ;-)
20 Jan
20 Jan
1:24 p.m.
Hi,
- remove the libosmocore subtree git from osmocom-bb
git
We can't do that. libosmocore subtree is still used to compile the
embedded ARM version of libosmocore.
- remove this line of text from
http://bb.osmocom.org/trac/wiki/libosmocore: "When you download and build
OsmocomBB, then libosmocore is automatically part of the package, no special
action is required."
Indeed. Feel free to edit it.
- osmocom: some wiki pages refer to an
"osmocom" application. Is there an
osmocom binary? (I think most times it is a typo for osmocon)
It's most likely a typo.
- I use Wireshark to capture the GSMTAP packets of
"monitor". How do I find
out in the Wireshark trace if a message is sent from the MS or is received
by the MS?
Look at the ARFCN field of GSMTAP Header. It should indicate uplink or
downlink direction.
- I want to study the high layer messages (e.g. not
cell selection but call
setup, registering to the network) but I am lost in the debug flags:
DCS:DNB:DPLMN:DRR:DMM:DSIM:DCC:DMNCC:DSS:DLSMS:DPAG:DSUM. Which ones are
needed in my case? Is there somewhere a description of the flags?
You're probably better off with wireshark to view the messages.
The debug category are explained in src/host/layer23/src/common/logging.c
- Some tools (e.g. cell_log) give 'SAP' log
messages, e.g:
Failed to connect to '/tmp/osmocom_sap'.
Failed during sap_open(), no SIM reader
I suspect this is for communcation with SIM cards. How it is supposed to
work?
- Is this 'SAP' stuff only needed/useful for softSIMs?
- Which application should create the /tmp/osmocom_sap socket? (osmocon only
creates /tmp/osmocom_l2 and /tmp/osmocom_loader)
SAP support in mainline is incomplete and unsupported currently.
- Would it be possible to remove the SIM card from my
C118 and put it in an
external SIM reader, and then let "mobile" use the SIM card in the external
reader instead?
No
Cheers,
Sylvain
21 Jan
21 Jan
4:56 a.m.
Sylvain Munaut wrote:
I think we should change that, and instead require the ARM library
to be installed into a prefix which is set when building osmocom-bb
targets. A sane default could be to have the prefix next to the
osmocom-bb source tree.
//Peter
- remove the
libosmocore subtree git from osmocom-bb git
We can't do that. libosmocore subtree is still used to compile the
embedded ARM version of libosmocore.
7:15 a.m.
Hi,
We don't have an OS on the ARM, no libraries, no BSP ... it's all a
big static block, so we can't have an installed "ARM library" for it.
So we could ask the user to have the sources somewhere, but the issue
is that the ARM build is much more sensitive to libosmocore version
than the host one.
I don't really see the problem with having the libosmocore as subtree
for ARM build. For the host, it would sometime mix the intree and
installed versions during build and we also had to update it often,
but the subset used in the ARM is pretty small and doesn't require
much updates.
Cheers,
Sylvain
We can't
do that. libosmocore subtree is still used to compile the
embedded ARM version of libosmocore.
I think we should change that, and instead require the ARM library
to be installed into a prefix which is set when building osmocom-bb
targets. A sane default could be to have the prefix next to the
osmocom-bb source tree.
9 a.m.
Sylvain Munaut wrote:
We don't have an OS on the ARM, no libraries, no BSP ... it's all a
big static block, so we can't have an installed "ARM library" for it.
Sure we can - even if it's just a single .a file. Linker search path
has nothing to do with an OS, libraries can be used without an OS,
and no BSP is needed.
We can't do that. libosmocore subtree is still
used to compile the
embedded ARM version of libosmocore.
I think we should change that, and instead require the ARM library
to be installed into a prefix which is set when building osmocom-bb
targets. A sane default could be to have the prefix next to the
osmocom-bb source tree. So we could ask the user to have the sources
somewhere, but the issue
is that the ARM build is much more sensitive to libosmocore version
than the host one.
All the more reason to make the target library explicitly visible.
I don't really see the problem with having the
libosmocore as subtree
for ARM build. For the host, it would sometime mix the intree and
installed versions during build
Another good reason to clearly separate the two.
//Peter
10:51 a.m.
Sure we can - even if it's just a single .a file.
Linker search path
has nothing to do with an OS, libraries can be used without an OS,
and no BSP is needed.
Yes ok, but it's really more of an hassle than an advantage, and then
if you want to use the same toolchain to build different arm projects
that need different libosmocore version, that's going to be fun ...
All in all, I really fail to see how this is going to _HELP_ ... it's
going to be a bunch of additional step that can be messed up and IMHO
with _NO_ upsides at all.
The host build was becoming a problem and that's why it was moved out.
The target build has not caused issue so I don't see why we would
change it and give it the opportunity to fail.
Cheers,
Sylvain
1:09 p.m.
On Mon, Jan 21, 2013 at 10:51:53AM +0100, Sylvain Munaut wrote:
The host build was becoming a problem and that's
why it was moved out.
The target build has not caused issue so I don't see why we would
change it and give it the opportunity to fail.
btw, just for the record: the idea of the host build from inside
osmocom-bb.git was to make sure that the header files and APIs on both
sides would be identical, which was considered a helpful idea if more
and more code is eventually moved from host into the target (which never
happened so far).
--
- 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)
24 Jan
24 Jan
4:44 p.m.
Should we consider separating *only* the shared header definitions and APIs
into a separate "shared" folder which would be accessed by the ARM compiler
and host compilers from *all* Osmocom related projects?
I've been porting the code to Windows and can see the benefits of clear
separation of code.
B.
On Mon, Jan 21, 2013 at 5:39 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
On Mon, Jan 21, 2013 at 10:51:53AM +0100, Sylvain
Munaut wrote:
The host build was becoming a problem and
that's why it was moved out.
The target build has not caused issue so I don't see why we would
change it and give it the opportunity to fail.
btw, just for the record: the idea of the host build from inside
osmocom-bb.git was to make sure that the header files and APIs on both
sides would be identical, which was considered a helpful idea if more
and more code is eventually moved from host into the target (which never
happened so far).
--
- 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)
25 Jan
25 Jan
4:41 a.m.
Sylvain Munaut wrote:
That's what pkg-config is for, and libosmocore already installs a .pc file.
Set PKG_CONFIG_LIBDIR in order to pick up the correct libosmocore.
A sane default could maybe be set by the Makefile, meaning that no
special consideration is needed when following the default
recommended build approach as we document on the wiki.
I don't think it makes sense to install libosmocore into the
toolchain's own lib directory.
Sure we can -
even if it's just a single .a file. Linker search path
has nothing to do with an OS, libraries can be used without an OS,
and no BSP is needed.
Yes ok, but it's really more of an hassle than an advantage, and then
if you want to use the same toolchain to build different arm projects
that need different libosmocore version, that's going to be fun ... it's going to be a bunch of additional step that
can be messed up
and IMHO with _NO_ upsides at all.
I don't think it would be additional user-visible steps, and
internally the steps are still the same.
I don't see why we would change it
Because building both for host and target would use the same pattern,
and in particular a pattern (pkg-config) which is sadly not well
understood but very handy.
//Peter
4115
days inactive
4120
days old
baseband-devel@lists.osmocom.org
9 comments
5 participants
participants (5)
-
Bhaskar11 -
Harald Welte -
Klaus Darilion -
Peter Stuge -
Sylvain Munaut