Age | Commit message (Collapse) | Author | Files | Lines |
|
This patch fixes [currently missing] Jenkins build verification.
Currently it's just skipping the firmware due to errors:
make -C target/firmware CROSS_COMPILE=arm-none-eabi-
make[1]: Entering directory '/build/src/target/firmware'
/usr/bin/env: 'python': No such file or directory
/usr/bin/env: 'python': No such file or directory
/usr/bin/env: 'python': No such file or directory
/usr/bin/env: 'python': No such file or directory
/usr/bin/env: 'python': No such file or directory
/usr/bin/env: 'python': No such file or directory
...
Change-Id: Ibfcc17ca2736da82d60db3b0e350b74e788031b0
|
|
It seems that those flags have always been gcc flags, and not ld flags.
After decades of tolerating this, binutils 2.36.x no longer tolerates
those flags but prints an error:
arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles (did you mean --nostartfiles ?)
See also https://github.com/apache/nuttx/issues/3826 and the related
https://github.com/apache/nuttx/pull/3836 how this was solved in another
project - I adopted that solution here 1:1
Change-Id: Id199e4d03d5aae07a347c98f47791f42c12008c6
|
|
As was reported by roox, osmocom-bb currently fails to build on OBS:
https://build.opensuse.org/build/home:mnhauke:osmocom:nightly/openSUSE_Tumbleweed/x86_64/osmocom-bb/_log
[ 24s] layer1/prim_tch.c: In function 'l1s_tch_meas_avg':
[ 24s] layer1/prim_tch.c:183:2: error: 'for' loop initial declarations are only allowed in C99 mode
[ 24s] layer1/prim_tch.c:183:2: note: use option -std=c99 or -std=gnu99 to compile your code
We don't specify the C standard explicitly, so let's move the variable
declaration out of the for-loop in l1s_tch_meas_avg().
Change-Id: I6c65fbead4e612c81728e9c6601d5f2107616ee6
Fixes: 7286560a3 "firmware/layer1: fill-in DL info for L1CTL TRAFFIC.ind"
|
|
Change-Id: Ib73210b273826ded56d42c41ffeb835eef96dd2b
Related: OS#4396
|
|
Even if the DSP marks a traffic frame as bad (B_BFI), we still want
to deliver something to the upper layers, just like we do for FACCH.
Change-Id: I559793a3506089b1c1758ee7022cceb7753afb30
Related: OS#4396
|
|
Change-Id: I1c9727b183214f3d1a4f9a48489479f8435a4c5a
Related: OS#4396
|
|
Change-Id: Idd48438e47ac3ef1172621e77688d094cdcdbf34
Related: OS#4396
|
|
* Reset both A_DD_0 and A_DD_1 headers, like in the case of FACCH.
* Reduce nesting, fix minor coding style issues.
* Add a FIXME for proper B_BFI checking.
Change-Id: Ie4faf386f54720888e73171bee26f93dfa0562d5
Related: OS#4396
|
|
Change-Id: Ie32501df19cc2eedd1042c9917583d7386a665bc
Related: OS#4396
|
|
Change-Id: If4f0bb37cb3e12e09078027461cd5040524e43b2
Related: OS#4396
|
|
The upper layers usually request either of the two configurations:
* (AUDIO_TX_MICROPHONE | AUDIO_RX_SPEAKER) - in this configuration
the phone (PHY) is both the origin and the destination of the TCH
frames. DL frames are played via the built-in speaker; UL frames
recorded using the built-in microphone.
* (AUDIO_TX_TRAFFIC_REQ | AUDIO_RX_TRAFFIC_IND) - in this case
the upper layers (host side) become the origin and the destination
of the TCH frames. The built-in speaker and microphone are
expected to be disabled.
However, when using the second configuration, one can still hear
DL TCH frames being played by the built-in speaker. The built-in
microphone does not seem to be causing any issues, but still we
definitely don't want the vocoder to interfere with the host.
Change-Id: I390db1889f079dea8112794c3e039a9136b897df
Related: OS#4396
|
|
A different identity code can be used on uplink access bursts on voice
group channel. This is optional for the network, but mandatory for the
MS side. If the network does not define a UIC, the BSIC is used instead.
BSIC is used for RACH channel and handover.
Related: OS#5364
Change-Id: I4039734676949aefa5be4b5298764b8ba7e1b8ed
|
|
This is required to access a TCH during handover or to access the uplink
of a VGCS channel.
The patch is taken from the handover branch.
Change-Id: I1a972d9bac5749c67c1b139825400854f7cf1490
|
|
This flag can be used to turn transmitter off for "group receive mode"
or for handover procedure. The flag is stored in the channel description
of the mobile application. It is sent to layer 1 when switching to
dedicated channel or when changing TCH mode.
At the layer 1 the transmitter is turned off while the receiver is still
active. This is done by:
* scheduling a TX dummy task for TCH bursts
* scheduling no TX task for SACCH bursts
* not enabling the transmit window
Related: OS#5364
Change-Id: I20133523adc3b204cd2181bfe664fe66020a10e3
|
|
iWOW TR-800 is a packaged GSM modem module based on Calypso+Iota+Rita
chipset; it is fully quadband, and reverse engineering of its PCB
confirms that this module is nothing but a mass-produced version of
the core of TI's legendary Leonardo+ reference platform. The same
module is also known as FreeCalypso Tango - a rebranded version of
the same hardware module with different firmware and a different
Responsible Party for official support.
FreeCalypso HQ is contributing OsmocomBB support for this Calypso
modem module for two reasons:
1) Harm reduction - sooner or later someone in Osmocom universe is
going to run OBB firmware on TR-800 once they lay their hands on
this hardware, and the resulting operation will be less harmful /
closer to correct if we provide the basic board support patch.
2) There exists a large surplus of FreeCalypso Caramel2 development
boards that are based around FC Tango modules. Having this hw
supported by both firmwares will hopefully increase the chances
that these boards will find loving homes, as opposed to continuing
to gather dust in a cardboard box.
Legal and ethical disclaimer: OsmocomBB firmware running on ANY
Calypso+Iota+Rita target is *known*, through confirmed observations
with a measuring instrument (R&S CMU200), to put out radio transmissions
that are *severely out of spec*, and this defect does NOT go away
with the present patch which merely adds support for a different C+I+R
board target. The present patch has been produced as a harm reduction
measure, to reduce (but not to zero) the harm that will be caused
by parties who run OsmocomBB firmware on C+I+R hardware despite having
been advised not to. As the party seeking to reduce rather than cause
that harm, Mother Mychaela and her related business entities explicitly
disclaim all liability for damage that will be caused by parties who
continue running OsmocomBB firmware despite having been repeatedly
advised to switch to manufacturer-approved published-source firmware
instead.
Change-Id: I84d564f052f12a25ea3bfb9c78860e9dc6262be8
|
|
Change-Id: I90fbe583983de34f39ec402d5a35712dfe57222b
|
|
Change-Id: Ic426c9bc01733ff923f33cafe8012f9068b709ef
|
|
Includes RF frontend configuration, TIFFS config, keymap.
Currently still using the rf_tables and afcparams from gta0x.
No display driver yet.
Make sure to run osmocon with -m romload -i 10
Change-Id: I711702862b1cec5a8089dac071f8a171ca026003
|
|
This is a partial revert of d49a748cbbf7d7b5bb77f3d906179da9b462e6d1.
The GAPK based audio I/O implementation of the mobile app is now capable
of handling TI's specific TCH frame format, which can be configured via
the VTY interface ('io-tch-format ti'). Thus there is no need to have
the conversion logic in the firmware anymore.
This patch also fixes the layer1 firmware, so it does not hang on
receipt of Uplink TCH frames anymore when compiled with recent
arm-none-eabi toolchain (v12.2.0 on my machine).
Change-Id: I5afd4e4ddd9c06d32768d01bc1e3e18d476706fb
Related: OS#3400
|
|
This regression was introduced with the experimental PDCH support
back in 2020. In particular, I made a mistake in the l1s_nb_resp()
resetting rxnb.dl->link_id to 0x00 if MF_F_PTCCH is not set, which
is of course not set for non-PDCH channels.
Change-Id: I8593f9b001e669e7cd10cc42c05221a6037e8ae1
Fixes: 67c49ba664f7d7d7f07986a20e6d6363a27e3fc4
Fixes: OS#5791, OS#5133
|
|
This allows TTCN3 L1CTL module (used in BTS_Tests) to transmit and
receive AMR payloads towards osmo-bts-trx.
Related: SYS#5987
Change-Id: Ia20bc96e39726a919a556c83c8be48cb31af7331
|
|
Change-Id: I7a7fb32eab0ab20672a47861c3b66da92bd83015
|
|
Change-Id: I3e9bbc21aec57dea84034d233a2ba1902602bdb2
|
|
Change-Id: I20d41111d6f611202dcefada8091ccda0cc51dad
|
|
Change-Id: I4bb1dae28c07218e8b801bc162b82d03fd083bad
|
|
Below in the common path for both true and false branches we do
have a conditional block setting ARFCN_UPLINK if uplink is true.
Change-Id: If3adc5d1f11d3f43cb4c17bdb355b160ab61dc56
|
|
In this function we have the following condition:
if (pm_mode == PM_IDLE && (mode == MODE_MAIN || mode == MODE_SPECTRUM))
so the 'mode' can be either MODE_MAIN or MODE_SPECTRUM. Still,
GCC throws false-positive warnings that 'a' and 'e' may be used
uninitialized in handle_pm().
Let's eliminate these warnings by using 'if-else' statement.
Change-Id: I86d241c41d4de135f4cd79f56f7fdd18696b7890
|
|
Change-Id: If8c3da3908c1dab7a93e69daee13426f9bdbccad
|
|
Change-Id: I4c38599b29de73e26e9b603564f63b88e65e16b9
|
|
arm-none-eabi-gcc versions 11.2.0 shows the following warning:
layer1/l23_api.c: In function 'chan_nr2mf_task_mask':
layer1/l23_api.c:123:25: warning: comparison is always true due to
limited range of data type [-Wtype-limits]
123 | if (second_task >= 0) /* optional */
Let's get rid of {master,second}_task by using a macro.
Change-Id: I00bd3e11a14f10b78fd91f0e6915ca4fc0817d6a
|
|
Change-Id: I8224f8c2dba6891ef3fffcb6eed6572d35132d2e
|
|
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
|
|
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
|
|
Change-Id: I3203790c529f93d0084c82136645683a26faf986
Related: I26546dcbc853166e351d00260936b1b9d584ae03
|
|
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
|
|
Change-Id: Ibbdb0093d8f502dcd57ea92b53e7e56b09ee9e5f
|
|
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
|
|
GIT_SHORTHASH is used by the recently introduced snake game.
Change-Id: I837e3dcc5c44e64ca7f6c243c08981ed01f35dd1
|
|
Change-Id: I3c3f012552f2a7474ade911fc071c89e55e19352
|
|
Change-Id: Id8856ace2a31ba4ebcd04746e0c96c23a679cc40
|
|
button is pressed
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
|
|
Change-Id: I91780146d066c45c42b037c22cb49fd8a96e832b
|