summaryrefslogtreecommitdiffstats
path: root/src/target/firmware
AgeCommit message (Collapse)AuthorFilesLines
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
2020-07-31firmware: add possibility to configure TCH loops in the DSPVadim Yanitskiy3-3/+9
Change-Id: Ide7b0527ad64a044977a10da4a82a8ecd1fbd8dc
2020-06-18firmware/layer1: cosmetic: add missing comma to debug printVadim Yanitskiy1-1/+1
Change-Id: Icfc403e500c24628da722ab378fba31923afd1a1
2020-06-18firmware/apps/rssi: enlarge text buffer in refresh_display()Vadim Yanitskiy1-1/+1
This change fixes several warnings reported by GCC 10.1.0: apps/rssi/main.c:238:30: warning: 'sprintf' may write a terminating nul past the end of the destination apps/rssi/main.c:238:4: note: 'sprintf' output between 10 and 17 bytes into a destination of size 16 apps/rssi/main.c:413:26: warning: '.' directive writing 1 byte into a region of size between 0 and 9 apps/rssi/main.c:413:3: note: 'sprintf' output between 10 and 20 bytes into a destination of size 16 Change-Id: I7980727b78f7622d792d82170f73c90ac5770397
2020-06-09firmware/layer1: remove redundant l1a_*_req declarationsVadim Yanitskiy1-6/+0
Both symbols are declared in 'layer1/prim.h'. Change-Id: I36f41870bd63c70259316204ee17071853257ca4
2020-06-09firmware: fix compilation with arm-none-eabi-gcc 10.1.0Vadim Yanitskiy2-7/+0
These symbols are defined, but never used: - struct last_rach - seems to be copy-pasted from prim_rach.c, - tall_msgb_ctx - already defined in libosmocore. Change-Id: I6077c8e9b441f7848d1a4c25a8b5e1aed82f4b7d
2020-04-25firmware/rfch.[ch]: Document functions + constify input argumentsHarald Welte2-5/+16
Change-Id: I16d5190b3cdc997c5609b52d41203f10264b017c
2020-04-01firmware/layer1: introduce experimental PDCH supportVadim Yanitskiy5-1/+71
This change implements basic (receive only) support of the PDCH channels that are used in GPRS. Several coding schemes are defined by 3GPP TS 45.003, however we can only do CS-1 for now, since it's basically an equivalent of xCCH. In order to support the other schemes (CS2-4), we would need to know how to configure the DSP (look at Freecalypso code?). Change-Id: I44531bbe8743c188cc5d4a6ca2a63000e41d6189
2019-10-22Fix typo: miliseconds -> millisecondsMartin Hauke1-1/+1
Change-Id: I472c12fd1dfbff4ca1ead972535d735857f1c3e7
2019-10-17Fix common misspellings and typosMartin Hauke20-28/+28
Change-Id: I962b42871693f33b1054d43d195817e9cd84bb64
2019-08-11fw: Add support for Huawei GTM900-B modulesSteve Markgraf5-1/+464
Both MG01GSMT and MG01GSMT hardware variants are supported and automatically detected based on the flash manufacturer. Change-Id: I3a770ea93fc72c4e9b63078e253602f204b5be23
2019-08-11fw/flash: Read extended ID, expose APISteve Markgraf2-14/+36
We now unlock the flash before reading the extended ID (required for Spansion and Samsung flash chips). These commands will be ignored by Intel/ST flash chips, and this change has been verified with all flash chips we support. Furthermore, expose the API for reading the flash ID. Change-Id: I3bcd71c84c8931bcd574953063737b51a41738a3
2019-08-11fw/keypad: Poll Iota powerbutton if requiredSteve Markgraf4-8/+27
This commit adds polling of the TWL3025 PWON signal. If the powerbutton is pressed on targets that use it (Pirelli DP-L10, Huawei GTM900-B), a normal keypad scanning cycle is started in order to preserve the timing, required for the 500ms power off press duration for example. Change-Id: I904baf40d621bd680b602b88d12ff462b3c17596
2019-08-11fw/abb/twl3025: Add function to query PWON stateSteve Markgraf2-0/+30
This allows us to detect power button presses on the Pirelli DP-L10 and the Huawei GTM900-B module. Polling will only be activated once the power button has been pressed and we received the interrupt. The goal is to reduce the required amount of TWL3025 register accesses to a minimum. Change-Id: I31be61c8089173aed616abd1ede6c4cf5c9b6770
2019-08-11fw/build: Use arm-none-eabi as default toolchainSteve Markgraf1-1/+1
This is what we describe in our wiki and what ships with recent distros. Change-Id: I70da7eeb33275fa5fff1d8a3581c384e031b12e5
2019-07-16target/*.py: shebang: use /usr/bin/env pythonAlexander Couzens1-1/+1
Use the system default python instead of a hardcoded python2 Allow to use python2 and python3. Change-Id: Iab185759b574eff1ca1b189dcbb4e1a3eec52132
2019-07-11firmware/solve_envs.py: make it compatible with python3Alexander Couzens1-1/+1
Change-Id: I711df515012f5542de5e5008c8fe4e601609759e
2019-05-28firmware/scheduler: Fix CBCH related RSL channel numbersVadim Yanitskiy2-10/+15
CBCH support in the firmware has been introduced almost at the same time it was implemented in trxcon, and the same mistake was made as described in Ia9a415628c659cbc2dd5dc65b875b7f935d6e211. Despite Calypso based PHY does not support PDCH (GPRS channels), let's avoid collisions and use the following cbits values: 0x19 / 0b11001 - MF_TASK_SDCCH4_CBCH on GSM_DCHAN_SDCCH_4_CBCH, 0x1a / 0b11010 - MF_TASK_SDCCH8_CBCH on GSM_DCHAN_SDCCH_8_CBCH. Change-Id: Ibb0f90695460e6ede12016c12a0cfdf9c74dfb24 Related: OS#4027
2019-05-13firmware/Makefile: clarify toolchain configuration includeVadim Yanitskiy1-1/+1
Change-Id: I77ce68d5904ff623f10f6475309052666bab7742
2019-05-13firmware/Makefile.inc: fix sections with overlapping VMAHarald Welte2-4/+4
Starting from [1], not only LMA but also VMA areas are now checked for overlaps (see also [2]). This results into linking errors: arm-none-eabi-ld: section .text.exceptions VMA [000000000080001c,0000000000800037] overlaps section .compal.reservedram VMA [0000000000800000,00000000008000fe] arm-none-eabi-ld: section .text.exceptions VMA [000000000080001c,0000000000800037] overlaps section .compal.loader VMA [0000000000800000,00000000008000ff] Let's try to work around this. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a87dd97a2098b7e18ff2574a4e81ae521ef7e6f2 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=18452 Change-Id: I098ddd33aabd7ec27981e2f09d8582f167bb649b Fixes: OS#1917
2019-03-06target/firmware/tiffs: update copyright statementsVadim Yanitskiy2-6/+8
In OS#3582, the autor of TIFFS code, Mychaela Falconia, has noted: ... all of my code contributions are in the public domain and are NOT copyrighted by me, and I strenuously object to anyone taking it upon themselves to insert a copyright notice with my name in it. Let's update the copyright statements as recommended by the author. Change-Id: If115991425372a4cdbcfefa115532c9c410e58c4
2019-02-19firmware/lib: introduce TIFFS filesystem supportMychaela Falconia17-2/+496
All known TI GSM firmwares implement some kind of flash file system, or FFS. We call it TIFFS (Texas Instruments FFS) because it is TI's invention. TIFFS is a file system with a hierarchical directory tree structure, and with Unixy forward-slash-separated, case-sensitive pathnames; the semantics of "what is a file" and "what is a directory" are exactly the same as in UNIX; and TIFFS even supports symlinks, although that support is a little under-developed, and apparently no FFS symlinks were ever used in any production GSM device. Thus the FFS implemented in TI-based GSM devices (modems and "dumbphone" handsets) is really no different from, for example, JFFS2 in embedded Linux systems. The FFS in a GSM device typically stores two kinds of content: - Factory data: IMEI, RF calibration values, device make/model/revision ID strings etc. These files are expected to be programmed on the factory production line and not changed afterward. - Dynamic data written into the FFS in normal device operation: contacts, settings / preferences, call history, received SMS, etc. It should be noted that both Compal (Mot C1xx) and Foxconn (Pirelli DP-L10) vendors moved their vital per-unit factory data out of the FFS into their own ad hoc flash data structures, leaving their FFS only for less critical data. However, we do enable TIFFS access for them anyway. The location of TIFFS within the flash memory of a given GSM device is defined by the firmware design of that device, but is always some integral number of contiguous flash sectors. - On Motorola/Compal C139/140 phones, the FFS used by the original proprietary firmware occupies 5 sectors of 64 KiB each (320 KiB in total), starting at 0x370000. C11x/123 use smaller FFS configurations, whereas C155/156 seem to have switched to some other FFS format, different from our familiar TIFFS. - On the Pirelli DP-L10, the FFS used by the original proprietary firmware occupies 18 sectors of 256 KiB each (for 4.5 MiB in total), starting at the beginning of the 2nd flash chip select (0x02000000 in the ARM7 address space). - On FCDEV3B (FreeCalypso hardware), the FFS is located in the first 8 sectors (of 256 KiB each) in the 2nd flash chip select bank, which appears at 0x01800000 in the ARM7 address space. - On the GTA01/02 GSM modem, FFS occupies 7 sectors of 64 KiB each, starting at flash offset 0x380000. For more information, please refer to the FreeCalypso project documentation, from where this great contribution comes from. Please note that existing MediaTek targets most likely use different storage format as they have nothing from TI Calypso. Also, we don't (yet) know the location of TIFFS on SE J100i and Compal E99 targets. The TIFFS support is needed for the follow-up change, that implements reading of the factory RF calibration values. Tweaked (coding style changes) by Vadim Yanitskiy <axilirator@gmail.com> Change-Id: If6e212baeb10953129fb0d5253d263567f5e12d6 Related: OS#3582
2019-02-19firmware/board: introduce new FCDEV3B (FreeCalypso) targetMychaela Falconia2-1/+148
FCDEV3B (stands for "FreeCalypso development board, triband") is a GSM mobile station development board by FreeCalypso project. The board features the same legendary TI Calypso GSM MS chipset that was used in commercial GSM/GPRS modems such as Openmoko's, and functions as a standalone (or "bare") GSM modem. For more information, please see the project's web side: https://www.freecalypso.org/fcdev3b.html. Change-Id: I09bd35a18d3ea094000050169a62fd82ba6eccfe Related: OS#3581
2019-02-13firmware/board/compal_e99: enable reading the second half of flashMychaela Falconia1-0/+6
The ability to read the second half of flash on E99 is needed for the follow-up change, that implements reading of the factory RF calibration values. Change-Id: Ia677ebdc1ada9fd41daf211fd9da06cd118365fa Related: OS#3582
2019-02-13firmware/board/compal: indicate both DCS and PCS Rx ports as connectedMychaela Falconia2-4/+44
Each given Mot C1xx phone is made either for 900+1800 MHz, in which case only the DCS Rx port is connected, or for 850+1900 MHz, in which case only the PCS Rx port is connected. Let's tell the TRF6151 driver that both DCS and PCS ports are connected, so that the same binary build can be used on both EU-band and US-band C1xx phones. If one needs to tune the TRF6151 receiver out of spec, or at least outside of the DCS/PCS Rx SAW filter's legitimate passband (or if the SAW filter was changed or removed), then the rffe_get_rx_ports() function might be changed to indicate which Rx port is physically connected: PORT_DCS1800 only or PORT_PCS1900 only. Change-Id: I620084c33ad165faffbbfc45923faedad77aafb2
2019-02-12firmware/board/gta0x: fix GPIO and ASIC_CONF_REG configurationMychaela Falconia1-13/+10
Most Calypso peripheral interface signals are unconnected on Openmoko GTA0x. Let's configure them to be GPIOs in IO_CONF_REG, then configure them to be outputs in IO_CNTL_REG, then set the outputs to 0 in ARMIO_LATCH_OUT. Change-Id: I306ffacb623d2b06a188f84026ccadab408d1676
2019-02-12firmware/board/pirelli_dpl10: fix ASIC_CONF_REG settingMychaela Falconia1-2/+2
Set LPG and PWL pin mux like Pirelli's firmware does. Change-Id: I099e13800b7821a8fb274c5264c9823153afe564
2018-11-05l1ctl_proto.h: use flexible array member for traffic messagesVadim Yanitskiy1-2/+4
Unlike the DATA messages, traffic frames may have different length. Instead of having fixed payload (i.e. TCH frame) length, let's introduce a flexible array member. This would allow one to calculate the frame length using the MSGB API. Change-Id: I119fa36c84e95c3003d57c19e25f8146ed45c3c6
2018-10-22firmware: set corret shebang in solve_envs.py python2 scriptPau Espin Pedrol1-1/+1
Change-Id: I64582568f7390b7f4e3253508209a59eb78ee4dd
2018-10-03l1ctl_proto.h: extend ccch_mode enum with CBCHVadim Yanitskiy2-0/+8
According to GSM TS 05.02, there are two ways to enable CBCH: a) replace sub-slot number 2 of CCCH+SDCCH/4 (comb. V), b) replace sub-slot number 2 of SDCCH/8 (comb. VII). Unlike SDCCH/8 (case b), CCCH+SDCCH/4 can be allocated on TS0 only, and shall not use frequency hopping. This means that implementing CBCH support on SDCCH/8 would require much more efforts than on combined CCCH+SDCCH/4, as in last case CBCH messages can be received without the need to switch from idle to dedicated mode. This change introduces a new ccch_mode item, which should be used by the higher layers to indicate presence of CBCH channel on C0/TS0, so the PHY would enable decoding of CBCH messages on CCCH+SDCCH/4 (case a) in idle mode. Regarding to CBCH on SDCCH/8 (case b), it makes sense to extend the 'l1ctl_dm_est_req', so it would be handled in dedicated mode on request from the higher layers. Change-Id: Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2
2018-10-03firmware/layer1: add scheduler tasks for CBCHAlex Badea4-0/+36
According to GSM TS 05.02, section 3.3.5, Cell Broadcast Channel (CBCH) is a downlink only channel, which is used to carry the short message service cell broadcast (SMSCB). CBCH is optional, and uses the same physical channel as SDCCH. More precisely, CBCH replaces sub-slot number 2 of SDCCH channels when enabled. This change introduces the following CBCH related tasks: - MF_TASK_SDCCH4_CBCH (CBCH on C0/TS0 SDCCH/4), - MF_TASK_SDCCH8_CBCH (CBCH on SDCCH/8), which are identified using the following Osmocom specific cbits: - MF_TASK_SDCCH4_CBCH - 0x18 (0b11000), - MF_TASK_SDCCH8_CBCH - 0x19 (0b11001). The only way to enable these tasks at the moment is to send L1CTL_DM_EST_REQ message with required cbits and tn. Change-Id: I1d7f02cba1cd8f6527360589d2d2747b6426f78b
2018-10-03firmware/layer1: inform about unhandled scheduler tasksVadim Yanitskiy1-3/+5
The mframe_task2chan_nr() is used to get the channel number (encoded according to 08.58 Chapter 9.3.1) corresponding to a given multi-frame task type. It makes sense to at least print some debug message in cases when there is no matching channel number for a given task type. Change-Id: I34587b6c67015513de35d85a7a3291f452ee7f3b
2018-09-06firmware/l23_api.c: cosmetic: use proper format specifierVadim Yanitskiy1-1/+1
The '%u' format specifier should be used for unsigned values. Change-Id: I1108c34e864304126e581d30b75bbd95b93f60b8
2018-07-06calypso: Print warning about unsupported encryption algorithmsPau Espin Pedrol1-0/+3
Unfortunately current code architecture doesn't support a return path with an error so tell the caller of L1CTL on the other side that something's wrong. Change-Id: Ib9b622dd5c9770c5e97fa58deee124a409544d3b
2018-06-08trf6151: Actually fix setting of uplink ARFCNSteve Markgraf1-1/+1
Some time ago a broken fix was committed which then has been reverted again in commit 17240037376169369b526ee8a8284961b85adbfa. The purpose of this line is to clear the uplink flag from the ARFCN. So far this worked because both gsm_arfcn2band() and gsm_arfcn2freq10() already do this internally. Change-Id: Ie8a05ffc0ddec53d7fd6a25e03ea285fb216df29 Signed-off-by: Steve Markgraf <steve@steve-m.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-20 21:01:52 +0000