AgeCommit message (Collapse)AuthorFilesLines
2020-10-25[HACK] Increase speed of l1ctl to 408250bps after bootlaforge/baudrateSylvain Munaut6-5/+36
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 <>
2020-10-25Use osmo_fd_*_{disable,enable}Harald Welte2-20/+20
Change-Id: I65d37821873767e61a7eca029f9b30938a299683 Depends: libosmocore.git Idb89ba7bc7c129a6304a76900d17f47daf54d17d
2020-10-25osmocon: More decoding of tpu_debug (on compal/rffe_dualband)Harald Welte1-1/+61
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
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-23gsm48_rr: Don't swap ber with snr in "MON:" log lineHarald Welte1-1/+1
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
2020-10-21mobile: Use osmo_fd_setup() in script_lua.cHarald Welte1-4/+3
Change-Id: Ib6f97b9b8f3af63b81b92071b7fdb1fd55da89a5
2020-10-19trxcon/l1ctl: fix: send confirmation for TCH mode requestVadim Yanitskiy1-2/+5
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
2020-10-18Use osmo_fd_setup() whenever applicable.Harald Welte6-46/+22
Change-Id: If9b636c295fc6b5349a54c70662f09efa616ee63
2020-10-18Use OSMO_FD_* instead of deprecated BSC_FD_*Harald Welte8-37/+37
Change-Id: Ibf64b18288b9109927035f650d6ef7ad9f15d688
2020-10-16fix trx_if_tx_burst(): do not drop Uplink bursts in TRX_STATE_RSP_WAITVadim Yanitskiy1-0/+2
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
2020-10-13layer23/cbch-sniff: fix: use Osmocom specific RSL channel numberVadim Yanitskiy1-2/+13
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
2020-10-13layer23/cbch-sniff: fix: do not blindly assume presence of CBCHVadim Yanitskiy1-1/+1
We cannot blindly assume that CBCH is present on TS0/SDCCH4 before decoding CBCH Channel Description in System Information Type 4. Change-Id: Ie8ce572df292d0b03c0f743bcf26184619176321
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: 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-26fake_trx: Implement RFMUTE TRXC cmdpespin/mutePau Espin Pedrol4-2/+20
Change-Id: I67d16858cd70cb0527c1da77bd3787d5e53100b4
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
2020-07-31layer23/mobile: implement handling of TCH test loop commandsVadim Yanitskiy7-15/+239
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
2020-07-31firmware: add possibility to configure TCH loops in the DSPVadim Yanitskiy4-5/+25
Change-Id: Ide7b0527ad64a044977a10da4a82a8ecd1fbd8dc
2020-07-30layer23/mobile: fix a memory leak (msgb) in gsm48_rr_data_ind()Vadim Yanitskiy1-1/+3
Change-Id: I55dcccf5b7d27d012908759954182eaec434d26b
2020-07-30layer23/mobile: fix wrong message type in gsm48_rr_tx_rr_status()Vadim Yanitskiy1-1/+1
Change-Id: I57c6a4e1e725da52c50e2a28e56627a3f3827c62
2020-07-29layer23/mobile: cosmetic: use GSM48_PDISC_TEST from gsm_04_08.hVadim Yanitskiy1-1/+1
Change-Id: Ie1f14b37f6138f5a019a25bdbc8a3531418df6c2
2020-07-27trx_toolkit/ fix: handle encoding exceptionsVadim Yanitskiy1-2/+8
Change-Id: I78163d41be3a912da1dd8c0543b1c3af3a0649fa Related: OS#4681
2020-07-27trx_toolkit/ do not validate TRXD message twiceVadim Yanitskiy1-4/+1
DATAMSG.gen_msg() does validete the message before encoding. Change-Id: Ia3691b3c18778cf7a1f16c71bef5c0b2e6241190 Related: OS#4681
2020-07-22Revert "trx_toolkit/ implement the transmit burst queue"Vadim Yanitskiy2-74/+4
This reverts commit 6e1c82d29836496b20e0d826976d9e71b32493d8. Unfortunately, solving one problem it introduced even more regressions. Change-Id: If29b4f6718cbc8af18fe18a5e3eca3912e8af01e Related: OS#4658
2020-07-16trx_toolkit/ remove unused import of 'time' moduleVadim Yanitskiy1-1/+0
Change-Id: I40628d32409543c9f4b40b7268a4538b4671102d
2020-07-16trx_toolkit: get rid of Python2 specific workaroundsVadim Yanitskiy2-4/+1
Change-Id: I16c63205c9133d964048588c25867ac7c310f951
2020-07-16trx_toolkit: use python3 in shebang of executable scriptsVadim Yanitskiy6-6/+6
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
2020-07-16trx_toolkit: remove shebang from non-executable scriptsVadim Yanitskiy12-12/+0
Change-Id: I5ddc531a4e98d4d6f8672d6ef14034fce605ba3d
2020-07-14trx_toolkit/ implement the transmit burst queueVadim Yanitskiy2-4/+75
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
2020-07-14trx_toolkit/ support optional clock handlerVadim Yanitskiy1-0/+6
Change-Id: I85b2182d9835ed035cf370e45ea039ac6a7e8405
2020-07-14trx_toolkit/ fix TDMA clock counter wrappingVadim Yanitskiy1-6/+2
Change-Id: I157447c7610402f6d62d2b74c9f04fcaa0bc1724
2020-07-14trx_toolkit/ call send_clck_ind() on every TDMA frameVadim Yanitskiy1-2/+1
Change-Id: I6d53e5266fa3b1f2eb55822d1c14975789b202ed
2020-07-13trx_toolkit/ move Rx burst handling to TransceiverVadim Yanitskiy2-2/+5
Change-Id: Ic1f44bfb21ac3173e9530a0a9966cd5e64b8bd48
2020-07-13trx_toolkit/ avoid using TRXList.__getitem__()Vadim Yanitskiy2-3/+4
Running with cProfile shows that there are quite a lot calls: 469896 0.254 0.000 0.254 0.000 Let's better avoid using it in performance critical parts. Change-Id: I2bbc0a2af8218af0b9a02d8e16d4216cf602892a
2020-07-13trx_toolkit/ inherit trx list API from TRXListVadim Yanitskiy2-24/+5
Change-Id: I1c589888991add435d88517094c7b4a7db93cbae
2020-07-13trxcon/scheduler: reduce default Uplink burst scheduling advanceVadim Yanitskiy1-2/+2
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
2020-07-12trxcon/scheduler: check TDMA frame order, drop out of order burstsVadim Yanitskiy1-5/+26
When running together with (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
2020-07-08trxcon/scheduler: fix subst_frame_loss(): do not compensate too muchVadim Yanitskiy1-0/+1
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