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: I73be012c01c0108fb6951dbff91d50eb19b40c51
I intentionally do not use 'Downlink' and 'Uplink' terms in this project
because both MS and BTS transmit and receive on the opposite directions.
A burst coming from demodulator may be a Downlink or an Uplink burst
depending on the context, so we definitely need more precise terms.
Back then when I started to work on TRX toolkit, I decided to use the
'TRX2L1' and 'L12TRX' for receive and transmit directions respectively.
Now I find them hard to read, so let's replace them with 'Rx' and 'Tx'.
Change-Id: I688f24a3c09dd7e1cc00b5530ec26c8e8cfd8f7c
Related: OS#4006, SYS#4895
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
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
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
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
This reverts commit 6e1c82d298.
Unfortunately, solving one problem it introduced even more regressions.
Change-Id: If29b4f6718cbc8af18fe18a5e3eca3912e8af01e
Related: OS#4658
Oliver Smith
Vadim Yanitskiy
Harald Welte
Mychaela Falconia
Pau Espin
Martin Hauke