Age | Commit message (Collapse) | Author | Files | Lines |
|
Most timeslots do not have eight lchan. Use the subslots_per_lchan
map to reduce the number of iterations. Looking at the ARM assembly
showed that no loop-unrolling was done so this could be a speed up.
|
|
|
|
calib_file.c: In function 'next_calib_file_idx':
calib_file.c:126:3: warning: implicit declaration of function 'band_femto2osmo' [-Wimplicit-function-declaration]
|
|
The parameter "uint8_t mute_state[8]" is actually a "uint8_t *mute_state"
so the ARRAY_SIZE is not what we think it is.
Fixes: Coverity CID 1125885
|
|
Fixes: Coverity CID 1047336
|
|
The information from band_mask has never been used as the return
was executed unconditionally.
Fixes: Coverity CID 1113473
|
|
Release/Free the lapdm resources _after_ the channel has
been fully released. Do not forward data unless the lchan
is in the active state.
Reading this code again, there is probably a memory leak for
everytime the PCU will re-connect to the BTS.
(gdb) p lchan->state
$4 = LCHAN_S_REL_REQ
(gdb) bt
#0 lapd_dl_flush_hist (dl=0x40454894) at lapd_core.c:164
#1 0x44873b54 in lapd_rx_u (lctx=0xbe9bd5a8, msg=0x92f90) at lapd_core.c:1040
#2 lapd_ph_data_ind (msg=0x92f90, lctx=0xbe9bd5a8) at lapd_core.c:1644
#3 0x44876d50 in l2_ph_data_ind (link_id=<optimized out>, chan_nr=<optimized out>,
le=<optimized out>, msg=0x92f90) at lapdm.c:637
#4 lapdm_phsap_up (oph=<optimized out>, le=<optimized out>) at lapdm.c:707
#5 0x0000c504 in handle_ph_data_ind (l1p_msg=0x97358, data_ind=0x97420, fl1=<optimized out>)
at l1_if.c:774
#6 l1if_handle_ind (fl1=<optimized out>, msg=0x97358) at l1_if.c:892
|
|
Use the lchan->rel_act_kind field for the BCCH activatiob by OML.
The lchan's should be marked as active but no event should be sent to
the BSC. This is mostly like the PCU. We can now remove the secnd
argument from lchan_activate.
|
|
There are existing deployments where the EEPROM either contains a
wrong value and/or the kernel can not be updated to support the
different EEPROM of revD. Revert to the old behavior that if no
nominal can be derived from the model_nr we assume that it is 23.
|
|
When using an old kernel on revD hardware we will read garabge
from the EEPROM and it is nice for debugging to see which model
number has been picked.
|
|
|
|
|
|
Nicolas ended up with linker issues due abis_rsl_sendmsg being
defined twice. Rename our version of the function and update the
code.
Patched with:
@i@
expression E;
@@
- abis_rsl_sendmsg(E)
+ abis_bts_rsl_sendmsg(E)
|
|
Currently it takes some time (around 30s) until it is detected that
the radio link is down after mute. Not till then the BSC is informed
and the call terminated.
This patch modifies this behaviour by sending a RSL_MT_CONN_FAIL
message with cause RSL_ERR_RADIO_LINK_FAIL for each muted and active
lchan immediately after the corresponding Change Administrative State
Request has been acknowledged.
Ticket: OW#976
Sponsored-by: On-Waves ehf
|
|
Currently only mute_state[0] (refers to ts[0]) is inspected to
determine, whether the Radio Carrier's state is set to LOCK.
This patch changes this by looking at all channels and using LOCK
if (and only if) all channels have been muted successfully.
Sponsored-by: On-Waves ehf
|
|
Currently the LEDs are being accessed directly from within the
l1_if.c file. So the handling of rf mute and activate/deactivate both
access LED_RF_ACTIVE directly. This may lead to an inconsistent LED
status.
This patch replaces these calls to sysmobts_led_set() by an abstract
equivalent bts_update_status(), that uses a set of independant status
ids. The associated values can than be combined into a visible LED
status. Currently LED_RF_ACTIVE is on iff BTS_STATUS_RF_ACTIVE is set
and BTS_STATUS_RF_MUTE is not set.
Sponsored-by: On-Waves ehf
|
|
Currently a Change Administrative State Request is just applied
unconditionally to the object's state object and then acknowledged.
This patch implements the special handling of setting the Radio
Carriers state to LOCK or UNLOCK. This is done by passing the
appropriate mute command to the L1 layer. Always all radio channels
are affected, it is not possible to lock single radio channels.
On success, an ACK is sent back to the bsc with the new state (based
on the state passed in the callback by the L1 layer). If something
went wrong or the firmware doesn't support RF mute, a NACK
(REQ_NOT_GRANTED) is sent instead.
Note that a NACK for such a request hasn't been sent by the BTS to
the BSC yet, so (albeit it's spec conformant to do so) the BSC must
be prepared to handle this correctly.
Ticket: OW#976
Sponsored-by: On-Waves ehf
|
|
This adds a new function
l1if_mute_rf(femtol1_hdl, ch_mute[8])
to set the mute state for each radio channel. On completion and iff
l1if_mute_rf() returned 0 the callback
oml_mo_rf_lock_chg(mo, ch_mute_state[8], success)
is invoked when the response from the superfemto DSP is received.
Ticket: OW#976
Sponsored-by: On-Waves ehf
|
|
This add the mappings for SuperFemto_PrimId_MuteRfReq and
SuperFemto_PrimId_MuteRfCnf to the arrays femtobts_sysprim_type,
femtobts_sysprim_names, and femtobts_sysprim_req2conf.
Sponsored-by: On-Waves ehf
|
|
Currently uninitialized elements of the femtobts_sysprim_type array
are mistaken as L1P_T_REQ (which is accidently the first element and
thus 0).
This patch adds a new element to the enum that has the value 0 to
detect uninitialized elements of the femtobts_sysprim_type array.
Those will then show up in the log as 'SYS Prim XXX is not a
Request!'.
This patch also adds missing definitions of the CalibTbl messages
in the femtobts_sysprim_type mapping so that the requests can still
be identified as such.
Sponsored-by: On-Waves ehf
|
|
The PCU is not capable of cleaning up properly. For now simply
exit the PCU in case the sysmobts has exited. This requires
osmo-pcu a30f47613abb7c22a26d534d66e478265a8c2c09 or later.
|
|
Even if one calibration table cannot be loaded, continue to try to
load the other tables, instead of aborting very early.
|
|
If L1 tells us that a certain band is not supported, then there is no
point in even trying to read+load calibration tables from EEPROM or
files.
|
|
|
|
The PCU is forcing the activation of a PDCH. Currently the BSC
will receive a channel act ack for a channel that was not
activated at all. Use the "release_reason" flag of the lchan
to see if we have requested a normal activation or a silent
one.
It feels a bit odd to do it in the TX function but it is the
most easy solution right now. I have added logging so it will
not be totally silent.
|
|
|
|
|
|
|
|
Fixes: Coverity CID 1040759
|
|
This is used in the sysmoBTS 2050, where the maximum power is 40 dBm
We might want to add a safeguard of some kind to prevent people from
overdriving their transmitters.
|
|
... no need for that
|
|
The TRX nominal output power (as seen by OML) is the aggregate power
of any gain internal to the sysmoBTS (and managed by L1) and any
external PA. This is what is used in trx->nominal_power;
fl1h->l1_power is the transmit power to which we configure the sysmoBTS
L1. This is 23 dBm (200mW) by default in the sysmoBTS 1002, and 40 dBm
(5W) in the sysmoBTS 2050. However, if sysmoBTS 2050 is used in
single-TRX configuration, it may be used with higher power, which we can
now configure in the config file / vty.
TODO: A separate, additional field that keeps track of any gain added by
an external PA, e.g. if the sysmoBTS 1002 is used with a sysmoAMP.
|
|
If the clock is provided by an external (like GPS) clock, we should not
use the calibration value. The latter is only used in context of the
OCXO or VCTCXO.
|
|
This enables the use of up to 5W for each TRX in a sysmoBTS 2050.
|
|
If the EEPROM tells us that a given unit doesn't support a given band,
we shouldn't try to use it, even if the BSC tells us to use an ARFCN in
such an unsupported band.
The reason is simple: The given BTS unit might have band specific
filter / duplexer / PA.
|
|
...rather than assuming that any v2 hardware supports all bands.
|
|
|
|
|
|
This introduces a new get_signlink_remote_ip() function whcih we also
use in the RSL code to determine the RTP remote address if the CRCX/MDCX
contains no remote IP address IE.
|
|
It might not be particularly useful, but then there's no disadvantage
either...
|
|
libosmoabis has a BTS-side implementation of the IPA protocol for years,
and osmo-bts should have used that all the time. Unfortunately it had
its own local hack, this patch is migrating to the libosmocore
implementation.
|
|
|
|
|
|
|
|
|
|
by splitting the rerutn code/status from the actual value, we support
negative values to be stored in the EEPROM
|
|
|
|
|
|
For the sysmoBTS 2050 this appears to have a different sign. We can't
test this with NWL right now so we will need to see if this is a case
of ping/pong.
|
|
By default read the clock calibration from the EEPROM. It is
still possible to set it using the cli.
Signed-off-by: Nicolas J. Bouliane <nicolas.bouliane@nutaq.com>
|