Given integral type A and non integral type B and depending on rounding
mode, optimization, compiler, and phase of the moon A(A)*B != A(A*B) so
split the two cases.
While at it, also make the template automagically work for complex types
instead of requiring manual casts, the general idea here is to allow
inlining and vectorization by treating all args as plain arrays, which is fine.
This works as expected with -tune=native, x64 implies sse2, and we do not
target any neon-less arm versions either.
Clang only array length hints can improve this even more.
Change-Id: I93f077f967daf2ed382d12cc20a54846b3688634
5561f1129d introduced some changes,
but while RadioInterface lost its call to close() that was previously
used to improperly reset the buffers upon init() that call was
accidentally not removed for RadioInterfaceMulti and
RadioInterfaceResamp, so those reset previously initialized values to 0
during init(), which break osmo-trx for weird setups.
Change-Id: I74fc1586f8ae0832f4093ba8a44a1c70c78ec3d8
The MS TRX was intentionally added [1] as an optional feature, which
requires a git submodule to be present in order to build libtrxcon.
This feature can be enabled by passing --with-mstrx to the configure.
But autoconf/automake is a mess. Despite in the root Makefile.am we
are adding full submodule path to the SUBDIRS *conditionally*, the
configure script would still fail if the submodule is not fetched:
Makefile.am:32: error: required directory
./osmocom-bb/src/host/trxcon
does not exist
It would not even enter that directory if it's present, but somehow
it's still required to exist. For the end user this means that
cloning the submodule becomes a *necessary* step in order to build
osmo-trx from source, even when the MS TRX is not really needed.
The fact that we're unconditionally requiring the submodule, which
is meant to be used by an optional feature feels wrong to me. It's
also unusual for osmocom projects to require submodules, so it may
(and already did) cause build failures when cloning as usual.
Let's work this problem around by defining LIBTRXCON_DIR variable
in configure.ac and using it in the root Makefile.am. If the MS
TRX is not enabled explicitly, make autoconf/automake happy by
assigning LIBTRXCON_DIR the submodule's root directory, which is
always present but empty if the submodule is not fetched.
Change-Id: I02ae2b37c82ae2f55e7d9bd92e226f2b8b023968
Related: [1] b7253c6fdc
Related: OS#5599, OS#5846
Condition 'test ENABLE_MS_TRX' is always true because 'ENABLE_MS_TRX'
is a string literal, not a variable... Because of this, automeke will
unconditionally try to configure the submodule.
Change-Id: Icbb9278c688bfe506d5ad726f16a6c200572de1b
Fixes: b7253c6fdc
Related: OS#5599
This also uncovers very interesting design decisions like the copying of
mutexes and condition vars depending on recursive locks that were
previously hidden by shady c function calls..
We have perfectly good c++11 versions for all of that.
While we're at it, also use the initialization list for the other (still
copy constructable) vectors, which cleans up the radio interfaces.
Change-Id: Idc9e3b1144c5b93f5dad2f8e0e30f1058477aa52
This is basically a trxcon that includes a transceiver, and can just
be used with existing and future apps supporting the trxcon interface,
i.e. mobile or ccch_scan.
Supports bladerf and uhd.
Currently using hardcoded sched/prios aimed at a setup with working,
reliable usb and reserved cores, for example a raspi 4 (ONLY 4, not 3,
not 2, not any other version)
Additionally builds test tools used for development: osmo-trx-syncthing*
see https://osmocom.org/projects/baseband/wiki/MS-side_GPRS for the
project description and details
Change-Id: I36c65a8c725c4da76dc70006cd96b0a2b6878e84
Grabbed from gr-gsm 2de47e28ce1fb9a518337bfc0add36c8e3cff5eb
Had a few rounds of extensive cleanup (not the va itself). Uses gcc
multiversioning for x86 targets.
Change-Id: I5466c522cf4de984a4810ec46df43a10b52ed78f
This is not really finished, there are multiple reasons to not use this:
1) main clock is not a gsm multiple, so it will continously drift
2) small buffer sizes lead to tx gaps that are hard to detect and break
everything.
Change-Id: I455c34bb9520d5f09eeb1ac76fceb4bdea94d1ac
- do not lint the submodule
- do not lint the grgsm code
- do not lint headers, checkpatch does not understand that this is a c++
project and any change to existing headers will cause issues.
- also do not do arcane C varargs checks that do not apply to C++
Change-Id: Ie7a9fbd021e12a88db30212240af2332c6cdcb37
It does not make sense for the MS to use 11-bit Access Bursts on
PTCCH/U because the payload does not matter, only the ToA does.
Change-Id: I5fb9f1c6810cdcd26a885b183e414d01d422eb28
By default systemd will execute service with root directory
(or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it
to 'osmocom' subdir of state directory
(/var/lib for system instance) instead.
Related: OS#4821
Change-Id: I041bb9e0b4250826d2d15d0ea2cdb93d7a0cd04b
Avoid building osmo-trx a second time on arm during "make distcheck". If
the build of osmo-trx already passed on arm, running "make distcheck"
should give the exact same result as on x86_64.
This should shorten the build time significantly for osmo-trx jobs
running on raspberry pis, currently they take half an hour.
Change-Id: Ib4fbf7d54d479bbdda3c1415493bfc57b37d3971
Fix for the following error we see since building master-osmo-trx on
debian 10 instead of 9:
/usr/bin/ld: ipc_driver_test-uhdwrap.o: undefined reference to symbol '_ZTIN5boost6detail16thread_data_baseE'
/usr/bin/ld: //usr/lib/x86_64-linux-gnu/libboost_thread.so.1.67.0: error adding symbols: DSO missing from command line
After spending a lot of time on researching this, my understanding is
now that uhd.pc should have had "-lboost_thread" in versions up to the
latest release 4.2.0 because before that it would include boost thread
headers in its logging code:
04a83b6e76
ld is able to figure out which library provides the missing symbol, and
apparently depending on the binutils version and linker flags, it may
just ignore this and not show an error. This is why apparently it worked
with debian 9 and still does work in OBS (different flags), and why it
was not fixed upstream in uhd.pc. By now fixing it is not needed in the
latest version anymore, and there are already versions of uhd.pc in
various linux distributions without -lboost_thread, so I think it's
appropriate to add the workaround here in configure.ac.
Fixes: OS#5608
Related: https://stackoverflow.com/q/19901934
Change-Id: I0367f1c2981bf56252e7514d5993cbbec960b21b
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I816689e2aeac9decbc44ba210956a929cc7a3169
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I8ba71ab9ccde4ba25151ecbeb2a323f706b57d43
Before this patch, reconnecting to osmo-trx and attempting to configure it for
another band is not going to work without restarting the process.
The new variable is added in order to still allow POWEROFF followed by a
POWERON without need to reconfigure the device. In that case, previous
configuration is kept.
Change-Id: I43e5e1e4dcb36be605c6bd25dd6a5f3649e244e7
Remove this workaround, as we are not building for debian 8 anymore.
Related: OS#5223
Depends: osmo-ci Ibe7ba124557969df62798ba49c4489e9606c2341
Change-Id: I5519075a7f95fa61b0b5f1825e4e9324b9eede76
Eric Wild
Oliver Smith
Vadim Yanitskiy
Pau Espin
Max
Harald Welte