summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-05-03mobile/gsm48_rr.h: mark gsm48_rr_hdr struct as packedVadim Yanitskiy1-1/+1
In both gsm48_mm.c and gsm48_rr.c we put / push 'gsm48_rr_hdr' structure into the message buffers, so then it's retrieved by the message receivers. The AddressSanitizer complains about unaligned pointer access and potentially unexpected behaviour. Change-Id: I8aa2c0074b405afd0e76044ef076b6819fe1083b
2019-05-03mobile/gsm322.c: fix heap-use-after-free in gsm322_unselect_cell()Vadim Yanitskiy1-0/+2
In gsm322_l1_signal(), if S_L1CTL_FBSB_ERR is received, we free stored System Information of the current cell, but cs->si may still point to it. Let's set it to NULL. Found with AddressSanitizer: DL1C ERROR l1ctl.c:96 FBSB RESP: result=255 DCS INFO gsm322.c:2995 Channel sync error, try again DCS INFO gsm322.c:467 Sync to ARFCN=860(DCS) rxlev=-106 DRR INFO gsm48_rr.c:665 MON: no cell info DRR INFO gsm48_rr.c:665 MON: no cell info DRR INFO gsm48_rr.c:665 MON: no cell info DRR INFO gsm48_rr.c:665 MON: no cell info DL1C ERROR l1ctl.c:96 FBSB RESP: result=255 DCS INFO gsm322.c:3008 Channel sync error. DCS DEBUG gsm322.c:3013 free sysinfo ARFCN=860(DCS) DCS INFO gsm322.c:3020 Unselect cell due to sync error! DCS INFO gsm322.c:509 Unselecting serving cell. ================================================================= ==6014==ERROR: AddressSanitizer: heap-use-after-free on address 0x61b0000000e6 at pc 0x00000050d6dd bp 0x7fff7f84aa60 sp 0x7fff7f84aa58 Change-Id: I9cc526c18d69695d810de98703579818408de011
2019-04-27lua: Add a sentinel for the fd function tableHolger Hans Peter Freyther1-0/+1
Change-Id: I4fe2fd6584a453a951361e1b67fb986583b176be
2019-04-24trx_toolkit/data_msg.py: fix TOA256 MIN/MAX constantsVadim Yanitskiy1-3/+3
The old TOA256 range was bigger than we can actually store: struct.error: 'h' format requires -32768 <= number <= 32767 Change-Id: I5d4e1fea9d07f2c49f01e6644d1c0d1dc8cf4e40
2019-04-22trxcon: introduce extended (11-bit) RACH supportVadim Yanitskiy2-52/+128
According to 3GPP TS 05.03, section 5.3, two coding schemes are specified for access bursts: one for regular 8-bit bursts, another - for extended 11-bit packet access bursts. According to 3GPP TS 05.02, section 5.2.7, there are two additional training (synchronization) sequences for RACH bursts: TS1 & TS2. By default, TS0 synch. sequence is used, unless explicitly stated otherwise (see 3GPP TS 04.60). According to 3GPP TS 04.60, section 11.2.5a, the EGPRS capability can be indicated by the MS using an alternative training sequence (i.e. TS1 or TS2) and the 11-bit RACH coding scheme. Change-Id: I36fd20cd5502ce33c52f644ee4c22abb83350df8
2019-04-22l1ctl_proto.h: add extended RACH (11-bit) request messageVadim Yanitskiy1-0/+12
According to 3GPP TS 04.60, section 11.2.5a, the extended (11-bit) Access Burst on RACH/PRACH is used by the MS to indicate its EGPRS capability. One of the alternative synch. sequences (see 3GPP TS 05.02, TS1 and TS2) shall be used. Change-Id: Iae0267a31b3314c990eb41acb2f570ca3219021c
2019-03-21trxcon: use static helper to prepare FBSBMax1-12/+15
Use static helper to prepare l1ctl_fbsb_conf - this simplifies fbsb-related functions and make difference between timer callback and regular response more obvious. Change-Id: I43832d6a912a32ea5795ed0110981e0b714a7a61
2019-03-21trxcon: log FBSB timer eventsMax1-1/+2
Change-Id: I0168d43951494f4010df891f391ddad4b57493d7
2019-03-21trxcon: use helper to add l1ctl_info_dlMax1-24/+18
Use static helpers to add l1ctl_info_dl to msgb - this simplifies l1ctl_* routines and reduce code duplication. Change-Id: I0b5b81f1fcd2984136e553a93735ea5456d2b3df
2019-03-21trxcon: use bool for fbsb_conf_sentMax2-4/+4
It's only used as a boolean value so let's set proper type for it. Change-Id: Iaf50cdd19ac2139ee2d625671410a486edae2999
2019-03-10trxcon/scheduler: clarify decoding of incomplete xCCH blocksVadim Yanitskiy1-0/+4
Inspired by Sylvain's message at #osmocom. Change-Id: I3f499837413e1dbd0ca62229dc9cb6f0f7475a42
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-21trxcon/scheduler: count number of measurementsVadim Yanitskiy6-14/+8
Instead of counting both RSSI and ToA measurements separately, let's have a single counter in trx_lchan_state.meas struct. Change-Id: I45454a3ac92b8cc85dd74092e4ab6eb350f20c9a
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
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 fake_trx.py descriptionVadim Yanitskiy1-2/+3
Since Ibff31fb3a958a714c828d0dea7e87d47f778fd80, fake_trx.py does support multiple transceivers. Let's update its description. Change-Id: I6e4351693da3a1f7e3eadd8e11971c34044dde20
2019-01-14trx_toolkit/transceiver.py: add optional transceiver nameVadim Yanitskiy2-13/+26
Since fake_trx.py 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] transceiver.py:104 Init transceiver 'BTS@127.0.0.1:5700' [INFO] transceiver.py:104 Init transceiver 'MS@127.0.0.1:6700' [INFO] transceiver.py:104 Init transceiver '127.0.0.1:5700/1' 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@127.0.0.1:5700 or --trx bar@127.0.0.1:5700/1 --trx ipv6@[2001:0db8:85a3:0000:0000:8a2e:0370:7334]:6700 Change-Id: I2f58f02e7819bb008b8aab1a8bf9e0adeb2e44ec
2019-01-14trx_toolkit/transceiver.py: 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}_if.py: add init log messageVadim Yanitskiy3-1/+8
Change-Id: I1a2caf6999ed4f33df76328e48ff5076d166d9fe
2019-01-14trx_toolkit/fake_trx.py: enrich TRX logging messagesVadim Yanitskiy3-30/+41
Since fake_trx.py 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] ctrl_if_trx.py:83 (127.0.0.1:5700) Recv POWEROFF cmd [INFO] ctrl_if_trx.py:85 (127.0.0.1:5700) Stopping transceiver... [DEBUG] ctrl_if_trx.py:95 (127.0.0.1:5700/1) Recv RXTUNE cmd [DEBUG] ctrl_if_trx.py:102 (127.0.0.1:5700/1) Recv TXTUNE cmd [DEBUG] ctrl_if_trx.py:155 (127.0.0.1:5700/1) Ignore CMD SETTSC [DEBUG] ctrl_if_trx.py:155 (127.0.0.1:5700/1) Ignore CMD SETPOWER Change-Id: I1f706790a2da226f1418f89d2cfbb55baa6ea624
2019-01-14trx_toolkit/fake_trx.py: 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 fake_trx.py, 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] https://git.osmocom.org/softsim/ Change-Id: I77bb108615bb2c94c441568f195b04e0a5421643
2019-01-13trx_toolkit/fake_trx.py: 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/fake_trx.py: 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 fake_trx.py 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 127.0.0.1:5703 --trx [2001:0db8:85a3:0000:0000:8a2e:0370:7334]:6703 If optional TRX_NUM > 0 is specified, e.g.: --trx 127.0.0.1:5700/1 then this transceiver is considered as a child of another one. See I7e97b7f32dde7ab74779133e9d7504f1d0fce60c for details. Change-Id: Ibff31fb3a958a714c828d0dea7e87d47f778fd80
2019-01-13trx_toolkit/transceiver.py: 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/burst_fwd.py: 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/Makefile.am: 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-23 14:59:18 +0000