osmo-bts.git branch master updated. 0.4.0-461-ga8bf666

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Osmocom BTS-side code (Abis, scheduling, ...)". The branch, master has been updated via a8bf666a099ecc7bb8436f31b7f30e246ef50015 (commit) via cb5a969a4548ec70ff16a74aa834cb5ebf50dc0a (commit) via 450714b19cb5cc5ac9f630e30058ff1469f76f83 (commit) from 43c763f5af1dc2e21f0b092019d1e1a0f3851075 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://cgit.osmocom.org/osmo-bts/commit/?id=a8bf666a099ecc7bb8436f31b7f30e2… commit a8bf666a099ecc7bb8436f31b7f30e246ef50015 Author: Harald Welte &lt;laforge(a)gnumonks.org&gt; Date: Sun May 28 16:00:36 2017 +0200 sysmobts: Re-order the bit-endianness of every HR codec parameter The so-called "RTP mode" of the DSP contains a bug on all firmware versions < 5.3.3 which causes the bit-order within each of the non-aligned codec parameters to be wrong. Introduce a function originally written by Sylvain Munaut during 32C3 in http://git.osmocom.org/openbsc/commit/?h=sylvain/32c3_codec&id=5b4a16bb… to bring the bits into [the correct] order. This has never been seen in a "pure sysmoBTS" setup, as all BTSs would use the same (wrong) bit-ordering and thus interoperate. This patch now checks for an affected DSP firmware version and then jumbles (old DSP firmware version) or does nothing (new DSP firmware version). Change-Id: Ia0eee4f514fb8fd81c052bb44a4facba898d6afb Closes: SYS#2452 http://cgit.osmocom.org/osmo-bts/commit/?id=cb5a969a4548ec70ff16a74aa834cb5… commit cb5a969a4548ec70ff16a74aa834cb5ebf50dc0a Author: Harald Welte &lt;laforge(a)gnumonks.org&gt; Date: Sun May 28 16:00:14 2017 +0200 l1_if: Add inline functions to check dsp/fgpa version at runtime Change-Id: Iddae9c8de33aca6663dca77908fa4852ad704ce9 http://cgit.osmocom.org/osmo-bts/commit/?id=450714b19cb5cc5ac9f630e30058ff1… commit 450714b19cb5cc5ac9f630e30058ff1469f76f83 Author: Harald Welte &lt;laforge(a)gnumonks.org&gt; Date: Sat May 27 14:15:39 2017 +0200 vty: Remove command for manual channel activation/deactivation OsmoBTS won't run without being connected to a BSC. The BTS wouldn't start to transmit if the BSC doesn't properly initialize it. So if we want to activate some channels manually for testing, we should do so from the BSC, and not inside the BTS code. Doing this in the BTS means that the BSC is not aware of it and might want to use that channel for something else meanwhile. Osmo{BSC,NITB} has gained ability to manually activate a channel from the VTY in Change-Id I44fc3904678eb48bd3ab1a3da8c0c265fa082e0d as can be seen at https://gerrit.osmocom.org/2759 So let's remove the old/obsoleted code here. Change-Id: I7ba0301b55cc283aa6a441899f84357e28a97321 ----------------------------------------------------------------------- Summary of changes: src/common/vty.c | 60 ---------------------------------------------- src/osmo-bts-sysmo/l1_if.c | 3 +++ src/osmo-bts-sysmo/l1_if.h | 16 +++++++++++++ src/osmo-bts-sysmo/tch.c | 59 ++++++++++++++++++++++++++++++++++++++++----- 4 files changed, 72 insertions(+), 66 deletions(-) hooks/post-receive -- Osmocom BTS-side code (Abis, scheduling, ...)