This is required to deal with the increased traffic of a passive listener
Note that it break the 'auto-restart' of osmocon when active because
the bootloader will send the prompt at 115200 baud and we won't see it ...
Change-Id: I3434bb020286ab72ba3556124786656eeacf10a9
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Let's give a more human-readable decode of the TPU instructions,
naming the TSPACT pin names as well as the device_id/strobe.
Change-Id: Iac1ac74ac3e41cff9d3d347a167b43af58cc6e59
TPU_DEBUG used to read from TPU RAM, which unfortunately seems rather
slow, so copying it over from there broke overall timing leading to
infamous "DSP Error 24" when TPU_DEBUG is enabled.
Change-Id: Idde061df8c129aa51b2e4540c8ef2e4116468c9c
We need to make sure to allocte sufficient space to include
the 32bit frame number at the start of the TPU_DEBUG msgb.
Change-Id: Ifb3ce6f91131fc361b20c3b3fe5ebc7079633ac3
I was quite confused why I constantly see a bit error rate reported
by gsm48_rr, while at the same time the actual L1CTL_DATA_IND did
all state num_biterr == 0.
So the log statement was broken ...
Change-Id: I09bb6c606a8437b213bb444949c78a7c8a10542c
Both REQ and CNF share the same message structure, so we can
cheat a bit by changing the message type and sending it back.
Change-Id: I6f403ed0506b4b1872361d9976d3186bfe514b52
Related: OS#4799
Some commands, such as SETTA or SETPOWER, are expected to be sent
when the transceiver is powered on. We should not drop Uplink
bursts while waiting TRXC response.
For now it's easier to comment out the state check completely,
because the existing TRXC state machine is quite messy.
Change-Id: Iefe6030200b11b29a5790d1f4aa4070ed1d9a493
This way the layer1 can activate proper CBCH task and send us
CBCH block with proper RSL channel number, so they do not end
up being routed to LAPDm and rejected there.
Change-Id: Ib1d5c99587202a9d94aeb7b63de7ae8c4fb15af0
We cannot blindly assume that CBCH is present on TS0/SDCCH4 before
decoding CBCH Channel Description in System Information Type 4.
Change-Id: Ie8ce572df292d0b03c0f743bcf26184619176321
The original code used simplified logic whereby it assumed that
Spansion flash means MG01GSMT and Samsung flash means MGCxGSMT.
However, there exist MGC2GSMT hw variants with Spansion S71PL032J
flash in them, thus it is necessary to check the complete device ID
rather than just the flash manufacturer ID to distinguish between
MG01GSMT with 8 MiB flash (S71PL064J) and MGCxGSMT with 4 MiB flash
(S71PL032J, K5A3281CTM or K5L3316CAM).
Distinguishing between 4 MiB and 8 MiB flash chip types is also
necessary in order to configure TIFFS reader for the correct FFS
location matching that used by the original firmware, which is
in turn necessary in order to read factory RF calibration values.
Closes: OS#4769
Change-Id: Iaa5bd295e9cbf6b525fa385f9d6cd7fcd7f8a4dd
* Switch Calypso output CS4/ADD22 to ADD22 function as needed
in order to access the upper half of the flash on GTM900 hw
variant MG01GSMT.
* Set WS=4 for safety - please refer to this technical article for
the underlying theory:
https://www.freecalypso.org/hg/freecalypso-docs/file/tip/MEMIF-wait-states
Related: OS#4769
Change-Id: I1923243937d7251f6bcfe71a0b1cc0e206a81cfa
This change fixes one bug and one uncertainty:
Bug: Huawei defined Calypso GPIO 3 to be DTR input on this modem,
following TI's precedent from C-Sample and D-Sample platforms.
(Huawei's documentation calls the corresponding FPC interface pin
UART_DTR without even mentioning that it is actually wired to
Calypso GPIO 3 in the hardware.)
The previous code (erroneously copied from gta0x target which is
different in this regard) configured this GPIO to be an output,
creating a driver conflict.
Uncertainty: GPIOs 4, 6, 10, 11 and 12 power up as inputs, and
Huawei's official fw leaves them as such. But in the absence of
someone reverse-engineering a sacrificial GTM900 module by slicing
its PCB and imaging its copper layers and vias, we don't know if
these Calypso pins are simply unconnected like they are on Openmoko
devices (in which case they are floating inputs and should be
switched to driving dummy outputs), or if they are tied off in the
hardware in one way or another, in which case leaving them as inputs
is correct.
On the reasoning that floating inputs are a lesser evil than driver
conflicts or shorted outputs, leave these GPIOs as inputs until
we gain better knowledge of this aspect of the hardware.
Related: OS#4769
Change-Id: Ia41f8bc19fb1775b0587fe1ceaa8acd066710aa5
GTM900-B can share almost all calibration tables with GTA0x and FCDEV3B,
only the VCXO is significantly different.
Related: OS#3582
Change-Id: I52b63b1d086452139b1efd308d47a4183eace745
We have new hardware targets that have appeared since the original
OS#3582 patch was created, namely Huawei GTM900-B and the upcoming
FreeCalypso Caramel2 board. These new targets need the same APC
offset as gta0x and fcdev3b (TI's original Leonardo value), they
have proper calibration records in their FFS (meaning that all
compiled-in numbers become no-effect placeholders), and their PA
tracts are similar enough to Openmoko/FCDEV3B to where even in the
absence of calibration OM/FC numbers are close enough. Thus most
of the tables in board/gta0x/rf_tables.c should be reusable by
these new targets.
However, these new targets have quite different VCXOs from Openmoko
and FCDEV3B, thus they need different AFC parameters. Thus we split
board/gta0x/afcparams.c from board/gta0x/rf_tables.c, making the
latter more reusable.
Related: OS#3582
Change-Id: I92e245843253f279dd6d61bd5098766694c5215f
Since If6e212baeb10953129fb0d5253d263567f5e12d6, we can read the TIFFS
file-system, thus we can read and use the factory RF calibration values.
* Implement parsing of factory RF calibration values for Motorola C1xx,
Openmoko GTA0x, Pirelli DP-L10, and upcoming FCDEV3B targets.
* Remove the old Tx power level control code and tables, and replace
them with new logic that exactly matches what the official chipset
firmware (TI/FreeCalypso) does, using tables in TI/FreeCalypso
format. Compiled-in tables serve as a fallback and match each
target's respective original firmware.
* Use individual AFC slope values for different targets. The original
value was/is only correct for the Mot C1xx family, whereas
GTA0x/FCDEV3B and Pirelli DP-L10 need different values because
Openmoko's VCXO (copied on the FCDEV3B) and Pirelli's VCTCXO
are different from what Motorola used.
* Take the initial AFC DAC value for the FB search from factory
calibration records on those targets on which it has been
calibrated per unit at the factory.
* Use individual APC offset for different targets instead of
the hard-coded value. The Mot/Compal's and Pirelli's firmwares
(both heavily modified relative to TI) use different APC offset
settings: 32 for Compal and 0 for Pirelli, while Openmoko and
FreeCalypso devices use 48.
Change-Id: Icf2693b751d86ec1d2563412d606c13d4c91a806
Related: OS#3582
To make the situation about stdint.h even more complicated, this
toolchain doesn't anymore #define __int8_t_defined, which means
we again run into conflicting definitions :/
Let's try to use INT8_MAX as a key.
Change-Id: I1a74cdcd03366390e88b2d5bddf01329410b9f1c
I am not sure how other developers do this. There are probably better ways to
make testing faster but I kind of like it this way.
I just call the twl3025_power_off_now function when the power key is pressed.
Change-Id: I1e55910acd8584c74e5e190b3334a8cf6987f5f3
When a dedicated channel is activated, in chan_nr2mf_task_mask()
we calculate a bitmask of the corresponding multi-frame tasks to
be enabled. Three logical kinds of the multi-frame tasks exist:
- primary (master) - the main burst processing task,
e.g. MF_TASK_{TCH_F_ODD,SDCCH4_0,GPRS_PDTCH};
- secondary - additional burst processing task (optional),
e.g. MF_TASK_GPRS_PTCCH;
- measurement - neighbour measurement task (optional),
e.g. MF_TASK_NEIGH_{PM51,PM26E,PM26O}.
By default, the primary task is set to MF_TASK_BCCH_NORM (0x00).
Due to a mistake, the secondary task has also been set to BCCH,
so when we switch to a dedicated mode, we also enable the BCCH.
This leads to a race condition between the multi-frame tasks,
when both primary and secondary ones read bursts from the DSP
at the same time, so the firmware hangs because of that:
nb_cmd(0) and rxnb.msg != NULL
BURST ID 2!=0 BURST ID 3!=1
This regression was introduced together with experimental PDCH
support [1]. Let's use value -1 to indicate that the secondary
task is not set, and apply it properly.
Change-Id: I4d667b2106fd8453eac9e24019bdfb14358d75e3
Fixes: [1] I44531bbe8743c188cc5d4a6ca2a63000e41d6189
Related: OS#3155
For more information, see 3GPP TS 44.014, sections:
- 5.1 "Single-slot TCH loops", and
- 8 "Message definitions and contents".
This feature has nothing to do with the Mobility Management, so
let's handle GSM48_PDISC_TEST messages in the Radio Resources
layer implementation (gsm48_mm.c -> gsm48_rr.c).
Change-Id: If8efc57c7017aa8ea47b37c472d1bbb1914389ca
This reverts commit 6e1c82d298.
Unfortunately, solving one problem it introduced even more regressions.
Change-Id: If29b4f6718cbc8af18fe18a5e3eca3912e8af01e
Related: OS#4658
TRX Toolkit is still backwards compatible with Python2, but Python3
does much better in terms of performance. Also, on Debian Stretch
that is used as a base for our Docker images, Python 2.7 is still
the default. Let's require Python3 in shebang.
Change-Id: I8a1d7c59d3b5d49ec2ed94a7c77905e02134f216
In order to reflect the UL/DL delay caused by the premature burst
scheduling (a.k.a. 'fn-advance') in a virtual environment, the
Transceiver implementation now queues all to be transmitted bursts,
so they remain in the queue until the appropriate time of transmission.
The API user is supposed to call recv_data_msg() in order to obtain
a L12TRX message on the TRXD (data) inteface, so it gets queued by
this function. Then, to ensure the timeous transmission, the user
of this implementation needs to call clck_tick() on each TDMA
frame. Both functions are thread-safe (queue mutex).
In a multi-trx configuration, the use of queue additionally ensures
proper burst aggregation on multiple TRXD connections, so all L12TRX
messages are guaranteed to be sent in the right order, i.e. with
monolithically-increasing TDMA frame numbers.
Of course, this change increases the overall CPU usage, given that
each transceiver gets its own queue, and we need to serve them all
on every TDMA frame. According to my measurements, when running
test cases from ttcn3-bts-test, the average load is ~50% higher
than what it used to be. Still not significantly high, though.
Change-Id: Ie66ef9667dc8d156ad578ce324941a816c07c105
Related: OS#4658, OS#4546
Running with cProfile shows that there are quite a lot calls:
469896 0.254 0.000 0.254 0.000 trx_list.py:37(__getitem__)
Let's better avoid using it in performance critical parts.
Change-Id: I2bbc0a2af8218af0b9a02d8e16d4216cf602892a
In general, premature scheduling of to be transmitted bursts
inevitably increases the time delay between Uplink and Downlink.
The more we advance TDMA frame number, the greater gets this
delay. 20 TDMA frames is definitely more than a regular
transceiver needs to pre-process a burst before transmission.
Change-Id: Ia9b142b59d95f2cd7b2394596cf72c0bcd36d711
Related: OS#4487
When running together with fake_trx.py (mostly used back-end), it
is currently possible that Downlink bursts are received in a wrong
order if more than one transceiver is configured (multi-trx mode).
This is how it looks like:
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=629 rssi=-86 toa=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=629 ts=3 bid=1
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=630 rssi=-86 toa=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=630 ts=3 bid=2
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=631 rssi=-86 toa=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=631 ts=3 bid=3
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=633 (!) rssi=-86 toa=0
DSCHD NOTICE sched_trx.c:663 Substituting (!) lost TDMA frame 632 on TCH/F
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=632 ts=3 bid=0
DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=633 ts=3 bid=1
DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=632 (!) rssi=-86 toa=0
DTRXD NOTICE sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647)
since the last processed fn=633 (current fn=632)
so here a burst with TDMA fn=633 was received earlier than a burst
with TDMA fn=632. The burst loss detection logic considered the
latter one as lost, and substituted it with a dummy burst. When
finally the out-of-order burst with TDMA fn=632 was received, we
got the large number of allegedly elapsed frames:
((632 + 2715648) - 633) % 2715648 == 2715647
Given that late bursts get substituted, the best thing we can do
is to reject them and log an error. Passing them to the logical
channel handler (again) might lead to undefined behaviour.
Change-Id: I873c8555ea2ca190b1689227bb0fdcba87188772
Related: OS#4658, OS#4546
It's not something that we should be trying to fix, if the whole
TDMA multi-frame is lost. For some yet unknown reason, sometimes
the difference between the last processed TDMA frame number and
the current one is so huge, so trxcon eats a lot of CPU trying
to compensate nearly the whole TDMA hyper-frame:
sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647)
since the last processed fn=633 (current fn=632)
Let's just print a warning and do not compensate more than one
TDMA multi-frame period corresponding to the current layout.
Change-Id: I56251d0d2f6fa19195ff105d3bdfbc22df6db8cd
Sylvain Munaut
Harald Welte
Vadim Yanitskiy
Mychaela Falconia
Pau Espin
Martin Hauke