path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2019-02-21trxcon/l1ctl_link.h: get rid of pointer to a trx_instancefixeria/trxconVadim Yanitskiy2-4/+0
Change-Id: Ie154a9d25dd0e8828fa2c278c98f9d8ba8c037e3
2019-02-21trxcon/l1ctl.c: accept band_arfcn as a parameterVadim Yanitskiy3-4/+6
Change-Id: I74a23c73b03bad822272b9cfe76c2501666912b7
2019-02-21trxcon/l1ctl.c: pass trxcon_inst pointer to RX handlersVadim Yanitskiy3-76/+79
Change-Id: I4e59f547a165b30aa9538ae8f9d6bd822067315b
2019-02-21trxcon/l1ctl_link.c: use TRXCON_EV_L1CTL_REQ eventVadim Yanitskiy2-2/+14
Change-Id: I9ad19c158397f73ab1b6639a34ce20fc7a7431b3
2019-02-21trxcon/trxcon.h: introduce and use struct 'trxcon_inst'Vadim Yanitskiy2-23/+49
Change-Id: Id868dac54693be9a67527dba06a2b80c0ecb7bd4
2019-02-21trxcon/trxcon.h: do not expose pointer to trxcon_fsm instanceVadim Yanitskiy2-2/+1
Change-Id: I37812573a33e090e6edb45713d3132cb43bd4ffb
2019-02-21trxcon: make trxcon_fsm parent for both l1ctl_fsm and trx_fsmVadim Yanitskiy5-16/+22
Change-Id: I6262726f2b6e23abe543d6d67edfd634eece1b71
2019-02-21trxcon: refactor trxcon_fsm finite state machineVadim Yanitskiy6-86/+161
Change-Id: I035b2cb701e2d0b3fedec4d569507b79d400df5b
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 <> 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: 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
2019-02-02common/sim.c: use msgb_get() in gsm_sim_reply()Vadim Yanitskiy1-5/+1
Change-Id: Ie5843c8adafc37da0d69c335c97b422552b85049
2019-02-02common/sim.c: get rid of unused 'payload' pointerVadim Yanitskiy1-2/+0
This change fixes the following compiler warning: sim.c: In function ‘gsm_sim_reply’: sim.c:149:11: warning: variable ‘payload’ set but not used [-Wunused-but-set-variable] uint8_t *payload; Change-Id: I3767b23bb1b28d3f4bb515d399bce160ba2eee09
2019-02-02common/osmocom_data.h: use proper type for SAP card statusVadim Yanitskiy1-1/+4
Change-Id: I7388ec60ca2dff59c0a0e3fdacf5a3af0c244c73
2019-02-02common/sap_fsm.c: register SAP FSM on DSO loadVadim Yanitskiy1-4/+5
Change-Id: Id539c2a3477526b816918070bab93b26c900998a
2019-02-02mobile/gsm322.c: fix: properly print stored BA list entitiesVadim Yanitskiy1-6/+6
As we do iterate over all entities in the BA list, it makes more sense to print each one separately instead of printing the last one. Moreover, as soon as the iteration is finished, *ba points to some zero-initialized part of memory: gsm322.c:5170 Write stored BA list (mcc=000 mnc=000 Marshall Islands, 000) After this patch: gsm322.c:5162 Write stored BA list (mcc=250 mnc=99 Russian Federation, Beeline) gsm322.c:5162 Write stored BA list (mcc=250 mnc=01 Russian Federation, MegaFon) gsm322.c:5162 Write stored BA list (mcc=250 mnc=02 Russian Federation, MTS) gsm322.c:5162 Write stored BA list (mcc=544 mnc=31 Serbia, Telenor) Change-Id: I5160492e6125401c6a1765f54d129b1f1cd503fc
2019-01-23mobile/gsm480_ss.c: fix build: apply msgb_wrap_with_TL() renameVadim Yanitskiy1-1/+1
In If1e851ac605c8d2fde3da565b0bd674ea6350c2e, msgb_wrap_with_TL() was renamed to msgb_push_tl(). Let's use the new symbol name. Change-Id: Ief37424e0ca3cd696054518a0ffb07b7ef17a462
2019-01-17trxcon/l1ctl.c: fix memleak triggered by unsupported messagesVadim Yanitskiy1-0/+1
Change-Id: I6e636afec8e45d7dc786f5f159cd5d7784d9a83b
2019-01-17trxcon/trxcon.c: do not expose tall_trx_ctxVadim Yanitskiy4-15/+14
Both l1ctl_link_init() and trx_if_open() do accept 'tall_ctx' now, so there is no need to expose the root context anymore. For logging initialization, we can just pass a pointer. Change-Id: I7a2231eb880a995d3296b94481a7799e6ff07489
2019-01-17trxcon/l1ctl_link.c: refactor l1ctl_link_init()Vadim Yanitskiy3-22/+20
The main changes are: - return pointer to the allocated l1ctl_link or NULL, - accept the talloc context as 'tall_ctx' argument. Change-Id: I7fe1bc306494ac692c182dcfd2a2d9412929194b
2019-01-17trxcon/trx_if: refactor trx_if_open()Vadim Yanitskiy3-34/+32
The main changes are: - return pointer to the allocated trx_instance or NULL, - extend debug message with TRX address and base port, - accept the talloc context as 'tall_ctx' argument, - rename goto label 'error' to 'udp_error', - rename argument 'port' to 'base_port'. Change-Id: I39b24afee2f09d6a6c500cfc26ac45f206589c5c
2019-01-17trxcon: do not include trxcon.h everywhereVadim Yanitskiy9-9/+0
Change-Id: Ia78bd6dac7ab12970838e0b1a2929a106b898d9d
2019-01-17trxcon/trx_if.c: check if trx_fsm allocation failedVadim Yanitskiy1-4/+11
Change-Id: I31c9f2a651182b258d0a4d4504365b778529715a
2019-01-17trxcon/l1ctl_link.c: check if l1ctl_fsm allocation failedVadim Yanitskiy1-4/+11
Change-Id: Ibd9404a888f02798224238a7b9ff4ebf09f03850
2019-01-17trxcon: register both l1ctl_fsm and trx_fsm on DSO loadVadim Yanitskiy2-2/+10
Change-Id: I7111e368afa47c88ff3c610bae9044f2d5baf037
2019-01-15trxcon/sched_trx.c: use bool in sched_trx_reset()Vadim Yanitskiy4-7/+8
Change-Id: I4f6990520836edb5eecce38c04857a4b3bc6f2fc
2019-01-14trx_toolkit/README: update descriptionVadim Yanitskiy1-2/+3
Since Ibff31fb3a958a714c828d0dea7e87d47f778fd80, does support multiple transceivers. Let's update its description. Change-Id: I6e4351693da3a1f7e3eadd8e11971c34044dde20
2019-01-14trx_toolkit/ add optional transceiver nameVadim Yanitskiy2-13/+26
Since can handle multiple transceivers, it may be useful to name transceivers. If transceiver has some name, it will appear in logging messages, for example: [INFO] Init transceiver 'BTS@' [INFO] Init transceiver 'MS@' [INFO] Init transceiver '' This change additionally assigns names to the both default transceivers, and extends the '--trx' option with ability to specify some name, for example: --trx foo@ or --trx bar@ --trx ipv6@[2001:0db8:85a3:0000:0000:8a2e:0370:7334]:6700 Change-Id: I2f58f02e7819bb008b8aab1a8bf9e0adeb2e44ec
2019-01-14trx_toolkit/ add init logging messageVadim Yanitskiy1-0/+2
Change-Id: I9a8b327748fbfcbae438cb531cd0b2767b6ca4dd
2019-01-14trx_toolkit: use 'TRXC' and 'TRXD' in logging messagesVadim Yanitskiy5-7/+12
One can confuse TRX control interface with libosmoctrl's one. TRX toolkit is not using libosmoctrl, and will never do. But, in order to avoid this confusion, and potential confusion of DATA interface, let's call them 'TRXC' and 'TRXD' in logging. Change-Id: I67b1e850094cf8e279777c45c7544886be42a009
2019-01-14trx_toolkit/{ctrl,data} add init log messageVadim Yanitskiy3-1/+8
Change-Id: I1a2caf6999ed4f33df76328e48ff5076d166d9fe
2019-01-14trx_toolkit/ enrich TRX logging messagesVadim Yanitskiy3-30/+41
Since can handle multiple transceivers, it makes sense to print some info in logging messages about transceivers they belong to. This acvieved by defining __str__() for Transceiver. Some examples: [DEBUG] ( Recv POWEROFF cmd [INFO] ( Stopping transceiver... [DEBUG] ( Recv RXTUNE cmd [DEBUG] ( Recv TXTUNE cmd [DEBUG] ( Ignore CMD SETTSC [DEBUG] ( Ignore CMD SETPOWER Change-Id: I1f706790a2da226f1418f89d2cfbb55baa6ea624
2019-01-14trx_toolkit/ move init code to __init__()Vadim Yanitskiy1-30/+30
There should be no code in run() that does initialization, __init__() is the best place for this. This change allows to import the Application class from, and run it from script (e.g. for testing). Change-Id: I84969630348a189d237cc98354e568421839a37b
2019-01-15layer23/sap_interface.c: reimplement (BT)SAP interfaceVadim Yanitskiy12-386/+1259
The (BT)SAP (Bluetooth SIM Access Profile) is a part of Bluetooth specifications, that defines the protocol and procedures that shall be used to access a smart card (usually GSM SIM) via a Bluetooth link. The profile defines two roles: - Server - the side that has direct access to a smart card. It acts as a SIM card reader, which assists the Client in accessing and controlling the smart card. - Client - the side that accesses and controls the smart card inside the Server through the connection with Server. Typical examples of a Server are a simple SIM card holder or a portable phone in the car environment. A typical example of a Client is a car phone, which uses a subscription module in the Server for a connection to the cellular network. OsmocomBB implements the Client role providing abstract SAP interface API to the higher layers. Instead of Bluetooth, a UNIX socket is used to communicate with a Server. The previous implementation of (BT)SAP interface was incomplete and hard to maintain. This change (re)implements it almost from scratch on top of the Osmocom FSM framework. Besides that, the most significant changes are: - The implementation is separated into three parts: - sap_interface.{c|h} - public SAP interface API, - sap_proto.{c|h} - SAP protocol definition, - sap_fsm.{c|h} - SAP FSM implementation. - Both 'sap_message' and 'sap_param' structures follow the SAP message format definition according to 5.1 and 5.2. - The message parsing is done more carefully in order to prevent buffer overflow and NULL-pointer dereference. - Introduced public API for getting / adding message parameters, and checking the ResultCode. - Introduced public API for opening / closing a connection with the server, powering on / off and resetting the SIM card, sending ATR and APDU. - Introduced a call-back for handling the response message. - Card reader state is also a part of the public API. The new implementation was tested against softsim [1]. The only limitation is Server-initiated Release, that allows the Server to 'ask' a Client to release connection as soon as communication with the smart card is finished. This is not implemented (yet), and leads to immediate release. [1] Change-Id: I77bb108615bb2c94c441568f195b04e0a5421643
2019-01-13trx_toolkit/ fix: update trx_list of FakePMVadim Yanitskiy1-0/+1
It seems in Ice44e2b22566b3652ef6d43896055963b13ab185 I forgot to do this, so all measurements triggered by MEASURE command were incorrect (always noise). Let's fix this! Change-Id: I155f118b2d3e3b23eb148fe7e2630790f8fcd18c
2019-01-13trx_toolkit/ handle multiple transceiversVadim Yanitskiy1-31/+81
Since Ice44e2b22566b3652ef6d43896055963b13ab185 is merged, the class hierarchy has become much more flexible, so it's possible to create multiple Transceiver / FakeTRX instances and distribute bursts using a single instance of BurstForwarder. This change introduces a new command line option, that can be used to specify additional transceivers. Please note that still initializes a pair of BTS and BB transceivers by default. The new option has the following format: --trx REMOTE_ADDR:BASE_PORT[/TRX_NUM] Some examples for IPv4 and IPv6: --trx --trx [2001:0db8:85a3:0000:0000:8a2e:0370:7334]:6703 If optional TRX_NUM > 0 is specified, e.g.: --trx then this transceiver is considered as a child of another one. See I7e97b7f32dde7ab74779133e9d7504f1d0fce60c for details. Change-Id: Ibff31fb3a958a714c828d0dea7e87d47f778fd80
2019-01-13trx_toolkit/ add support for child transceiversVadim Yanitskiy2-6/+100
A BTS can (optionally) have more than one transceiver. In this case additional (let's say child) transceivers basically share the same clock source of the first transceiver, and being powered on / off as soon as the first transceiver is powered on / off. Change-Id: I7e97b7f32dde7ab74779133e9d7504f1d0fce60c
2019-01-13trx_toolkit/ fix trx_list cross-referenceVadim Yanitskiy1-2/+5
It was discovered that using an empty list as default argument value does result into the cross-reference, i.e. all instances of BurstForwarder would reference the same trx_list object. This is not an expected behaviour, let's fix this. Change-Id: Id71185de05b0ebc5adb105b10fad2cbde5f800b1
2019-01-07layer23/sap_interface.c: separate protocol definitionVadim Yanitskiy6-161/+205
Change-Id: Iad9b3d88b02cc7ec4cf64483bbc85e3a61c9ad10
2019-01-07layer23/include/ add missing headerVadim Yanitskiy1-1/+2
Change-Id: I0a379718eeb7db63696cabd5689e0625fb85d85e
2019-01-07layer23/sap_interface.c: avoid using 'osmo' prefixVadim Yanitskiy5-18/+18
The 'osmo' prefix is usually used by libosmo-* symbols. Change-Id: Id37d8553c2f2c20012fb1b729967b92a9a03f612
2019-01-07layer23/sap_interface.c: define missing enums and use themVadim Yanitskiy2-24/+55
Change-Id: I4ba5a8a42bf25d04b152ac3f1f0e4d7eac7f068f
2019-01-07layer23/sap_interface.c: terminate value_string definitionsVadim Yanitskiy1-0/+5
Change-Id: I0776bc43360dfa2229243fb022cd318242ca6400
2019-01-07layer23/sap_interface.c: prettify value_string definitionsVadim Yanitskiy2-54/+58
Change-Id: Ib3aa81986987027718e2a8b461afd28787bda4c2
2019-01-07layer23/sap_interface.c: fix: properly call sap_msg_free()Vadim Yanitskiy1-6/+8
Passing NULL to sap_msg_free() is not only meaningless, but also would result in NULL pointer dereference. We should call it in successful case only, so let's fix this. Change-Id: Icf868c4299e292a17c4b7aad1f9e728ea3653494
2019-01-02trxcon/scheduler: fix RSSI -> RX level conversionVadim Yanitskiy1-1/+11
Due to a mistake, average RSSI value of received bursts was not converted to GSM RX level (range 0..63), so trxcon has been sending incorrect values to the higher layers. Let's fix this, and also prevent possible division by zero. Change-Id: Id4659de899411ec1ba1718fdcb40aec562dbfd65
2018-12-26layer23/sap_interface.c: use LOGP() instead of fprintf()Vadim Yanitskiy1-3/+3
Change-Id: I054be24666fcd5eb8a70cfcac0e7ed566e909b90