summaryrefslogtreecommitdiffstats
path: root/src/target/firmware
AgeCommit message (Collapse)AuthorFilesLines
2024-01-10firmware: fix shebang in solve_envs.py: s/python/python3/Vadim Yanitskiy1-1/+1
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
2023-11-22firmware: -nostartfiles -nodefaultlibs are not flags of LD but flags of GCCHarald Welte1-4/+4
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
2023-11-21firmware/layer1: avoid 'for' loop initial declarationsVadim Yanitskiy1-1/+2
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"
2023-10-16firmware/layer1: handle CSD related channel modesVadim Yanitskiy2-0/+16
Change-Id: Ib73210b273826ded56d42c41ffeb835eef96dd2b Related: OS#4396
2023-10-16firmware/layer1: emit TRAFFIC.ind even if B_BFI is setVadim Yanitskiy1-2/+2
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
2023-10-16firmware/layer1: fill-in DL info for L1CTL TRAFFIC.indVadim Yanitskiy1-23/+46
Change-Id: I1c9727b183214f3d1a4f9a48489479f8435a4c5a Related: OS#4396
2023-10-16firmware/layer1: fix l1s_tch_resp(): use the right A_DD headerVadim Yanitskiy1-1/+1
Change-Id: Idd48438e47ac3ef1172621e77688d094cdcdbf34 Related: OS#4396
2023-10-16firmware/layer1: clean up l1s_tch_resp()Vadim Yanitskiy1-31/+34
* 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
2023-10-16firmware/layer1: cosmetic: labels should not be indentedVadim Yanitskiy1-2/+2
Change-Id: Ie32501df19cc2eedd1042c9917583d7386a665bc Related: OS#4396
2023-10-16firmware/layer1: clean up l1s_tch_cmd(): reduce nestingVadim Yanitskiy1-17/+11
Change-Id: If4f0bb37cb3e12e09078027461cd5040524e43b2 Related: OS#4396
2023-10-16firmware/layer1: mute UL/DL vocodec if it's not neededVadim Yanitskiy2-0/+14
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
2023-09-28ASCI: Add UIC support to random access burstAndreas Eversberg4-7/+12
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
2023-09-27Transmit access bursts on DCCH of TCH channelsAndreas Eversberg1-2/+15
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
2023-09-27ASCI: Add a flag to turn transmitter off or onAndreas Eversberg5-2/+28
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
2023-09-04firmware: board: add support for TR-800 targetMychaela N. Falconia5-1/+599
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
2022-12-09fw: Add display driver for K200i/K220iSteve Markgraf3-10/+208
Change-Id: I90fbe583983de34f39ec402d5a35712dfe57222b
2022-12-09fw: fix TIFFS geometry for Sony Ericsson K220i phonesSteve Markgraf1-2/+6
Change-Id: Ic426c9bc01733ff923f33cafe8012f9068b709ef
2022-12-09fw: Add initial support for Sony Ericsson K200i/K220i phonesSteve Markgraf4-1/+286
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
2022-12-06firmware: remove TCH/F specific bit re-orderingVadim Yanitskiy2-55/+1
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
2022-11-25fixup: firmware/layer1: introduce experimental PDCH supportVadim Yanitskiy1-1/+1
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
2022-09-07trxcon: Initial support for forwarding AMRPau Espin Pedrol1-1/+1
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
2022-05-13firmware/layer1: clarify L1CTL_DM_EST_REQ related loggingVadim Yanitskiy1-2/+6
Change-Id: I7a7fb32eab0ab20672a47861c3b66da92bd83015
2022-04-25firmware/battery: fix -Wunused-variable in battery_compal_e88_timer_cb()Vadim Yanitskiy1-1/+0
Change-Id: I3e9bbc21aec57dea84034d233a2ba1902602bdb2
2022-04-25firmware/apps/hello_world: remove unused test[] bufferVadim Yanitskiy1-2/+0
Change-Id: I20d41111d6f611202dcefada8091ccda0cc51dad
2022-04-25firmware/apps/layer1: remove unused 'atrLength' in main()Vadim Yanitskiy1-2/+1
Change-Id: I4bb1dae28c07218e8b801bc162b82d03fd083bad
2022-04-25firmware/apps/rssi: remove redundant block in handle_pm()Vadim Yanitskiy1-2/+0
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
2022-04-25firmware/apps/rssi: fix -Wmaybe-uninitialized in handle_pm()Vadim Yanitskiy1-2/+1
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
2022-04-25firmware/layer1: fix unused variable 'l1h' [-Wunused-variable]Vadim Yanitskiy1-2/+0
Change-Id: If8c3da3908c1dab7a93e69daee13426f9bdbccad
2022-04-21firmware/layer1: fix 'MFNONE' not handled in switch [-Wswitch]Vadim Yanitskiy1-0/+3
Change-Id: I4c38599b29de73e26e9b603564f63b88e65e16b9
2022-04-21firmware/layer1: fix -Wtype-limits in chan_nr2mf_task_mask()Vadim Yanitskiy1-20/+20
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
2022-04-21firmware/abb: fix missing 'break' in twl3025_unit_enable()Vadim Yanitskiy1-0/+1
Change-Id: I8224f8c2dba6891ef3fffcb6eed6572d35132d2e
2021-12-14treewide: remove FSF addressOliver Smith99-396/+0
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
2020-12-01firmware/layer1: invalidate hard-coded Measurement resultsVadim Yanitskiy1-2/+2
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
2020-12-01firmware/layer1: clarify the content of Measurement resultsVadim Yanitskiy1-3/+15
Change-Id: I3203790c529f93d0084c82136645683a26faf986 Related: I26546dcbc853166e351d00260936b1b9d584ae03
2020-10-25tpu: Fix TPU_DEBUG: keep local cache of instructionsHarald Welte1-35/+35
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
2020-10-24tpu: Fix msgb-write-beyond-tailroom in TPU_DEBUGHarald Welte1-1/+1
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
2020-10-01firmware: gtm900b: fix flash-based hardware variant autodetectionMychaela Falconia2-33/+72
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
2020-10-01firmware: gtm900b: fix MEMIF configurationMychaela Falconia1-3/+19
* 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
2020-10-01firmware: gtm900b: fix GPIO configurationMychaela Falconia1-6/+4
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
2020-10-01firmware: calibration: proper support for gtm900b targetMychaela Falconia3-596/+49
GTM900-B can share almost all calibration tables with GTA0x and FCDEV3B, only the VCXO is significantly different. Related: OS#3582 Change-Id: I52b63b1d086452139b1efd308d47a4183eace745
2020-10-01firmware: calibration: split afcparams.c from rf_tables.c for gta0xMychaela Falconia3-29/+55
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
2020-10-01firmware: implement reading of factory RF calibration valuesMychaela Falconia29-351/+4023
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
2020-09-30Menu App to select highram images from phone's flash memoryAndreas Eversberg2-1/+339
Change-Id: Ibbdb0093d8f502dcd57ea92b53e7e56b09ee9e5f
2020-09-27fix compilation with arm-none-eabi 8.3.1 20190703 on Debian unstableHarald Welte1-1/+1
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
2020-08-06firmware/makefile: Add GIT_SHORTHASHMartin Hauke1-0/+4
GIT_SHORTHASH is used by the recently introduced snake game. Change-Id: I837e3dcc5c44e64ca7f6c243c08981ed01f35dd1
2020-08-04firmware/app: Initial commit for the game SnakeMarcel `sdrfnord` McKinnon1-0/+521
Change-Id: I3c3f012552f2a7474ade911fc071c89e55e19352
2020-08-04firmware/fb: Implemtented fb_bw8_line and fb_set_p(uint16_t x,uint16_t y)Marcel `sdrfnord` McKinnon4-19/+60
Change-Id: Id8856ace2a31ba4ebcd04746e0c96c23a679cc40
2020-08-02firmware/abb: Wrote twl3025_power_off_now to restart the phone if the power ↵Marcel `sdrfnord` McKinnon2-0/+10
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
2020-07-31firmware/layer1: fix properly apply secondary multi-frame taskVadim Yanitskiy1-3/+5
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
2020-07-31firmware/layer1: refactor multi-frame task mask compositionVadim Yanitskiy1-5/+10
Change-Id: I91780146d066c45c42b037c22cb49fd8a96e832b