summaryrefslogtreecommitdiffstats
path: root/src/target/firmware
AgeCommit message (Collapse)AuthorFilesLines
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>
2018-03-14common/l1ctl.c move TCH bit-ordering to the firmwareVadim Yanitskiy2-1/+54
Previously, TCH frames coming from L1 were reordered to the RTP format. Moreover, the implementation had a few problems: - L1CTL is not the best place for such manipulations; - payloads with other than FR codec were corrupted. Let's use RTP-ordered payloads on the L1CTL interface, performing TCH frame reordering at the firmware. Please note, that actual FR reordering was moved to the firmware as is, without any codec determination. This could be fixed in a separate change. Change-Id: I81ec8ed3c9e72a62b22c1720c299cdc68b733cf1
2018-03-14L1CTL/L1CTL_CRYPTO_REQ: add key length and channel infoVadim Yanitskiy1-3/+2
Previously, the L1CTL_CRYPTO_REQ message contained only a ciphering algorithm and actual Kc key to be used. The key length was calculated manually using the MSGB API. Let's avoid manual calculations here, as it may cause unexpected behavior if the message structure is changed. Also, let's fill the UL header with minimal information about a channel, which is going to be encrypted. Change-Id: I5fab079907c5276322d3ec2b46cab81f10c7ed09
2017-12-07target/firmware: fix Mediatek firmware compilationCraig Comstock1-4/+6
The existing Makefile.mtk isn't compatible with the current Makefile scheme, so nothing would happen when it was called. This change updates the Makefile.mtk, so the Mediatek firmware can be successfully compiled again. Change-Id: Iecd619ed862f4d825095292ffde50544e647f6ff
2017-01-15Revert "trf6151: Fix setting of uplink ARFCN"Harald Welte1-1/+1
This reverts commit 17240037376169369b526ee8a8284961b85adbfa. For some reason the "obviously broken" code is working, but the fixed version is not. Let's go back to step 1 and analyze this in more detail, but meanwhile make the code work again.
2017-01-15define 'fprintf(stderr,' as a wrapper around printf(Harald Welte1-0/+1
This is in preparation to work with a more recent version of libosmocore, which wants to print to stderr in some cases.
2017-01-15Add an endian.h file as one step to build against later libosmocoreHarald Welte1-0/+12
2017-01-15Add libosmocore/build-target/include to include pathHarald Welte1-1/+1
Some header files are auto-generated and are thus in the build directory, not in the source directory. A cleaner way to handle this is most likely to install libosmocore to some directory, but I don't want to change the entire build process now.
2017-01-15fix various other compiler warningsHarald Welte3-5/+6
2017-01-15cfi_flash.c: Fix various format string compiler warningsHarald Welte1-6/+6
2017-01-15trf6151: Fix setting of uplink ARFCNHarald Welte1-1/+1
Somebody (me?) wrote exclamation marks instead of pipe symbols. Found by a modern gcc: rf/trf6151.c: In function 'trf6151_set_arfcn': rf/trf6151.c:439:8: warning: comparison is always true due to limited range of data type [-Wtype-limits] arfcn != ~ARFCN_UPLINK; ^ rf/trf6151.c:439:2: warning: statement with no effect [-Wunused-value] arfcn != ~ARFCN_UPLINK; ^
2017-01-15Avoid redefining __{packed,aligned,unused,section}Harald Welte1-0/+10
It seems modern version of newlib define those themselves, so we should avoid re-defining them. Removes tons of compiler warnings when compiling against libnewlib 2.4.0
2016-01-20fw: fix SPCA552 write timingSteve Markgraf1-0/+1
With GCC 4.9.3 the timing was broken and initializing the SPCA552 on the Pirelli DP-L10 did not work. Add a small delay which fixes that. Signed-off-by: Steve Markgraf <steve@steve-m.de>
2015-12-31cleanup some compile warningsMax6-24/+17
2015-07-21layer1: fix chan_nr2mf_task_mask for TCH/H channelFelix Domke1-1/+2
"multiframe", the frame layout (used to compute neighbor cell monitoring pattern) was uninitialized in TCH/H case. This, in combination with gcc optimizing the "switch(multiframe)"-statement into a LUT without bounds- checking (since using an uninitialized value is undefined behavior) caused neigh_task to be filled with an out-of- bounds value, eventually crashing the TDMA scheduler. Written-by: Felix Domke <tmbinc@elitedvb.net> Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2013-12-29fw: tell linker to add init_array to ctor sectionSteve Markgraf5-0/+5
Starting with version 4.8, gcc places functions with __attribute__ ((constructor)) in .init_array instead of .ctors by default. This broke firmware images built with gcc >= 4.8. Signed-off-by: Steve Markgraf <steve@steve-m.de>
2013-09-26Fix wrong msgb_pull usageSylvain Munaut2-4/+4
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2013-04-07fw: remove deprecated chainload appSteve Markgraf2-56/+1
Signed-off-by: Steve Markgraf <steve@steve-m.de>
2013-01-05fw: pirelli_dpl10: initialize address line 22 for flash accessSteve Markgraf1-0/+6
Signed-off-by: Steve Markgraf <steve@steve-m.de>
2013-01-05fw: apps/loader: initialize framebuffer and show somethingSteve Markgraf1-0/+23
Since we now initialize the display for all apps, it otherwise just shows the last content of the display ram, which is weird. Signed-off-by: Steve Markgraf <steve@steve-m.de>
2013-01-05fw: keypad driver overhaul, support for different keymapsSteve Markgraf10-80/+90
Now the Pirelli DP-L10 keymap is supported. Signed-off-by: Steve Markgraf <steve@steve-m.de>
2013-01-05fw: introduce per-board uart mappingSteve Markgraf17-65/+123
Signed-off-by: Steve Markgraf <steve@steve-m.de>
2013-01-05fw: introduce with_irq parameter for board_init()Steve Markgraf15-64/+53
So far the loader-app used to do the init on its own, which brought a lot of problems for board- specific initialization. Signed-off-by: Steve Markgraf <steve@steve-m.de>
2013-01-02target: Add support for IQ swap when requiredSylvain Munaut12-8/+82
Operation in GSM850 band requires IQ swap because of the offset PLL used in the TRF causing spectrum reversal. Thanks to Dieter Spaar for noticing the issue and the original patch Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2013-01-02fw: Fix link scripts to represent reality more accuratelySylvain Munaut2-17/+16
Previously they were hacks to allow build ... Not needed now. Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2013-01-02fw/build: Allow applications to filter environmentsSylvain Munaut3-1/+47
We use an external python script to solve which env to build, to mix board and app env list Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2013-01-02fw/build: Add ENV_ APP_ BOARD_ prefix to variables to cleanup namespaceSylvain Munaut6-49/+49
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2013-01-02fw/build: Group env / boards / applicationsSylvain Munaut1-42/+66
No functional changes, just moving things around Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2013-01-02fw/build: The app/board/env combo macro need to be lastSylvain Munaut1-5/+5
The app template will create the list of app specific objs so that needs to be before Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2013-01-02fw/build: Include app / board / env specific objs during buildSylvain Munaut1-2/+2
Just put the env with the rest and not manifest and also allow app additional files Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2013-01-02fw/build: Add a silent rule for the 'size' call as wellSylvain Munaut1-1/+2
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2012-11-20Tell L1CTL_FBSB_REQ the expected received signal levelHarald Welte1-1/+2
As Dieter points out, this drastically improves the resiliance to high receive levels on the C155. We cannot blindly assume a received signal level of -85 dBm if the BTS is 2m away and we actually receive -40 dBm. This patch extends the L1CTL_FBSB_REQ data structure in layer 1 with the respective field, as well as the l1ctl_tx_fbsb_req() API function called from the various layer23 apps. "mobile" and "bcch_scan" already did a PM request and thus know the expected signal power. "ccch_scan" and "cbch_sniff" apparently don't do, so the -85 dBm constant is now hardcoded into the host-side source code there, and should probably be fixed in a follow-up patch.
2012-11-14fw/comm: remove unused, outdated copy of msgb.hSteve Markgraf1-161/+0
Signed-off-by: Steve Markgraf <steve@steve-m.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-23 14:40:22 +0000