We do have TRXC/TRXD documentation in osmo-gsm-manuals repository.
These big comments are out of sync with what we have in the manuals,
so let's better remove them to avoid maintaining docs in several places.
Change-Id: I47786cf3039f712efadc85bc4e1c3ae89e79ff25
Related: OS#4006, SYS#4895
158 is basically: 8 + 148 + 2, where the last two are padding bytes
sent by legacy TRXDv0 transceivers. We don't need them, so do not
drop PDUs without these leggacy padding bytes.
Change-Id: I6c0734bc4669ccde2a93940c9cf50fdbbd67cb00
During an internal discussion, it was decided to keep field 'PWR'
as-is and move 'SCPIR' into a separate octet. This is easier to
parse, less confusing, and would save us some CPU cycles.
Change-Id: I482f72fd9305c51f43a0339d03904fb693d90ac9
Related: OS#4006, SYS#4895
Our build system is based on Debian 9 and EOL Python 3.5, so we have
to maintain backwards compatibility (sigh). Some type hints moved
to comments, some had to be commented out completely. Hopefully,
we can 'un-vandalize' the code by reverting this change once there
will be no requirement to support EOL stuff.
Change-Id: I7211cfbb7549b6e700aa3dd44464ff762fd51185
Related: OS#4006, SYS#4895
As it turns out, in Python < 3.9 class Thread defines 'is_alive'
and 'isAlive = is_alive'. In Python 3.9 the later has been
removed, so fake_trx.py crashes on receipt of 'POWEROFF':
File "/home/wmn/wmn/osmocom/bb/src/target/trx_toolkit/clck_gen.py",
line 63, in running
return self._thread.isAlive()
AttributeError: 'Thread' object has no attribute 'isAlive'
See https://bugs.python.org/issue35283 for more details.
Change-Id: Id441d76dddb659958803d507e0fb028fb06422a7
This is what the L1 sends to the network before the first SACCH
block is received from the higher layers. The indicated values
are of course invalid because they're hard-coded.
According to 3GPP TS 44.018, table 10.5.2.20.1:
0 The measurement results are valid
1 The measurement results are not valid
Change-Id: I136307baef3fa2ddd1d5cec2a7f8c9e6d4602499
Related: I7da767e146aec7cef1de71e4d735d6a02b6c5642
Related: SYS#4918
This is what trxcon sends to the network before the first SACCH
block is received from the higher layers. The indicated values
are of course invalid because they're hard-coded.
According to 3GPP TS 44.018, table 10.5.2.20.1:
0 The measurement results are valid
1 The measurement results are not valid
Change-Id: I7da767e146aec7cef1de71e4d735d6a02b6c5642
Related: SYS#4918
Table 10.5.2.20.0 "Measurement Results Contents" in 3GPP TS 44.018
is clear on what should be used as padding - '0**', i.e. zeroes.
Change-Id: I4db6845c98aded10291134f416da98fd0f4f58e3
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Ied0f47378a5d348b857424adb5c874c1c093b485
Fixes: OS#4865
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I6d80f3f2742d397e47f4f2970c951f2cf6d58172
Fixes: OS#4865
The signal handler was coded as if it was handling SIGABRT, but the
signal handler was not overwritten so it is actually used.
Change-Id: I5c597f3410fc97be138db6f3976df59f393819b6
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