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 ;-)
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
Sylvain Munaut wrote:
- 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.
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
Hi,
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.
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
Sylvain Munaut wrote:
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.
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.
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
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
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).
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@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@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Sylvain Munaut wrote:
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 ...
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.
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
baseband-devel@lists.osmocom.org
-
Bhaskar11 -
Harald Welte -
Klaus Darilion -
Peter Stuge -
Sylvain Munaut