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
The old TOA256 range was bigger than we can actually store:
struct.error: 'h' format requires -32768 <= number <= 32767
Change-Id: I5d4e1fea9d07f2c49f01e6644d1c0d1dc8cf4e40
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
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
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
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
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
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
Since Ibff31fb3a958a714c828d0dea7e87d47f778fd80, fake_trx.py does
support multiple transceivers. Let's update its description.
Change-Id: I6e4351693da3a1f7e3eadd8e11971c34044dde20
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
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
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
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
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
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
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
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
This change is a big step towards handling of multiple transceivers
in a single process, i.e. multiple MS and multiple BTS connections.
The old class hierarchy wasn't flexible enough, because initially
fake_trx was designed as a bridge between OsmocomBB and OsmoBTS,
but not as the burst router. There were two separate, but 90%
similar implementations of the CTRL interface, two variations
of each simulation parameter - one for UL, another for DL.
The following new classes are introduced:
- Transceiver - represents a single transceiver, that can be
used as for the BTS side, as for the MS side. Each instance
has its own CTRL, DATA, and (optionally) CLCK interfaces,
among with basic state variables, such as both RX / TX freq.,
power state (running or idle) and list of active timeslots.
- CTRLInterfaceTRX - unified control interface handler for
common transceiver management commands, such as POWERON,
RXTUNE, and SETSLOT. Deprecates both CTRLInterface{BB|BTS}.
- FakeTRX - basically, a child of Transceiver, extended with
RF path (burst loss, RSSI, TA, ToA) simulation. Implements
a custom CTRL command handler for CTRLInterfaceTRX.
The following classes were refactored:
- BurstForwarder - still performs burst forwarding, but now
it doesn't store any simulation parameters, and doesn't
know who is BTS, and who is MS. Actually, BurstForwarder
transforms each L12TRX message into a TRX2L1 message, and
dispatches it between running transceivers with matching
RX frequency and matching timeslot.
- FakePM - still generates random RSSI values, but doesn't
distinguish between MS and BTS anymore. As soon as a
measurement request is received, it attempts to find
at least one running TRX on a given frequency.
Please note that fake_trx.py still does handle only a single pair
of MS and BTS. No regressions have been observed. Both new and
refactored classes were documented.
Change-Id: Ice44e2b22566b3652ef6d43896055963b13ab185
Related: OS#3667
In I6b9a8b611ea1e9badc4d9ddf13aa9e237028e39a an optional legacy
message coding mode was introduced. Let's add the corresponding
argument to send_msg() and pass it to gen_msg().
Change-Id: I6b9a8b611ea1e9badc4d9ddf13aa9e237028e39a
Some transceivers (e.g. OsmoTRX) have inherited a rudiment from
OpenBTS - two dummy bytes at the end of TRX2L1 messages. Despite
they are absolutely useless, some L1 implementations, such as
trxcon and OpenBTS, still do expect them when checking
the message length.
Let's add an optional (disabled by default) argument to gen_msg(),
that would enable adding those two dummy bytes.
Change-Id: I0cf1314c399411886420176704cadd6e6d84787f
The built-in struct module is already used for toa256 decoding,
so let's use it for toa256 encoding, and TDMA frame number
coding too - no need to (re)implement the wheel!
Change-Id: I10d2e15ac57a0524e9bc1c80ed6a0f6f5a263436
A timeslot can be reconfigured at runtime, this is normal.
We should neither complain nor reject such commands.
Change-Id: I0a69ebceed5aa724093e6d1b23faad8c16705055
False is not iterable, so we should properly handle the case
when parsing of the whole DATA dump was failed (e.g. due to
incorrect offset specified).
Change-Id: I5443efb39bb9d3377290ce7ec5e34016cae0edb2
Found using Flake8, F841 "local variable 'pf_group' is assigned
to but never used". The filtering related options should be
defined in 'pf_group' group, not in 'cnt_group'.
Change-Id: I15d17c134cbbbd54d761113a56c1f83910ab6407
Found using Flake8:
- data_if.py:57:4: F405 'log' may be undefined, or defined
from star imports: data_msg
- clck_gen.py:29:1: F401 'time' imported but unused
- clck_gen.py:30:1: F401 'sys' imported but unused
- trx_sniff.py:28:1: F401 'signal' imported but unused
Change-Id: Id0c42319b445db218b77fd5e99a9a0a89724281d
This change extends DATAInterface class with new methods:
- recv_raw_data() - read raw data from socket;
- recv_l12trx_msg() - read raw data and parse as L12TRX;
- recv_trx2l1_msg() - read raw data and parse as TRX2L1;
which would simplify the further usage of this class.
Change-Id: I761c4e63864622d3882b8f9c80ea43b58f092cb1
It makes much more sense to read data from socket in handle_rx(),
instead of expecting a buffer with received data from caller.
Change-Id: I83479c60c54e36a2a7582714a6043090585957ae
There is no need to (re)define the arguments of UDPLink's constructor.
Let's use non-keyworded variable length argument list (*args).
Change-Id: Ia312a5e15ce88d5f7e8d76c4ea8c93c59d91be5a
Since I8fd2a2ab7784b38bde5ebcfd0359b7e2cb53f5a7, SETTA command
handling was broken, because the range limitation was removed
together with argument parsing. Let's fix this.
Change-Id: If582af3849359866de129504cc5b2dc6d64edbd5
Since we have introduced ApplicationBase class, that are used
by all existing applications, let's merge the copyright
printing helper into it.
Change-Id: I8b70ec2dd08cb2ffed733d2c4e1215b094f8d3d5
Before this change, it was impossible to configure logging
parameters from command line, such as log level and format.
This change introduces the following optional arguments:
--log-level - logging level for stderr (by default, DEBUG);
--log-format - logging message format for stderr;
--log-file-name - enable logging to a given file;
--log-file-level - logging level for file (by default, DEBUG);
--log-file-format - logging message format for file;
which are defined in a new class called ApplicationBase, so
all existing applications should inherit them now.
Change-Id: Ic3b0440cd73946ad444bd7e48feb7a92d45f6488
Both '--bind-addr' and '--burst-type' had the same short '-b'.
Let's use the upper case version for '--burst-type'.
Change-Id: Ib8a46e25cbc6266c3e147582f9e8045362270151
There are multiple advantages of using Python's logging module:
- advanced message formatting (file name, line number, etc.),
- multiple logging targets (e.g. stderr, file, socket),
- logging levels (e.g. DEBUG, INFO, ERROR),
- the pythonic way ;)
so, let's replace multiple print() calls by logging calls,
add use the following logging message format by default:
[%(levelname)s] %(filename)s:%(lineno)d %(message)s
Examples:
[INFO] ctrl_if_bts.py:57 Starting transceiver...
[DEBUG] clck_gen.py:87 IND CLOCK 26826
[DEBUG] ctrl_if_bts.py:71 Recv POWEROFF cmd
[INFO] ctrl_if_bts.py:73 Stopping transceiver...
[INFO] fake_trx.py:127 Shutting down...
Please note that there is no way to filter messages by logging
level yet. This is to be introduced soon, together with argparse.
Change-Id: I7fcafabafe8323b58990997a47afdd48b6d1f357
The randomization of both UL/DL RSSI and ToA values is optional,
and can be configured from the control interface (see both
FAKE_RSSI and FAKE_TOA commands).
The command line options for enabling / disabling the randomization
were redundant, so let's get rid of them and check if the
corresponding treshold value is set.
Change-Id: I6adc13b8989ade2fab895673525c0ca17bf9b3f2
For some reason, the time-slot pass-filtering was only done for
DL bursts, but not for UL bursts. BurstForwarder shall not pass
UL bursts for unconfigured time-slots too.
Let's also print a warning if an UL burst is sent on a not
configured time-slot, i.e. before sending SETSLOT command.
Change-Id: Idb7f5b212e5814aeff8ca8bc875ad066674267cd
Previously it was only possible to configure a single time-slot
that would be pass-filtered by a BurstForwarder instance. In some
applications it would be useful to configure multiple time-slots,
so let's refactor the time-slot pass-filtering algorithm.
Change-Id: Ie1490adaf7a7c62c966aeb60c1898eaf3b5a1e84
Instead of having all configuration variables of BurstForwarder
initialized in the class heading, let's introduce two functions
for initialization (resetting to defaults) of both UL/DL params.
This would allow to reset a BurstForwarder instance from the
control interface in follow-up patches.
Let's also introduce some basic documentation for the class
fields, which were defined in the heading previously.
Change-Id: I6b1bf41cf22f01a7e7ecc91c625fb0d2bf4bfeac
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
Since FakeTRX is a proxy, it basically emulates transceiver for
both osmo-bts-trx and trxcon, hence there are two separate and
independent control interfaces (usually, ports 6701 and 5701).
All simulation commands (see 'FAKE_*') are usually implemented
on both interfaces separately:
- ctrl_if_bb.py - simulation commands affecting Uplink,
- ctrl_if_bts.py - simulation commands affecting Downlink.
This change introduces the 'FAKE_RSSI' command for both CTRL
interfaces in two variations:
- absolute: CMD FAKE_RSSI <BASE> <THRESH>
- relative: CMD FAKE_RSSI <+-BASE_DELTA>
where 'THRESH' affects optional value randomization.
Change-Id: Ic01c31fb0304345dd7337c3ee1c7ee3c2d3e8460
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
Vadim Yanitskiy
Harald Welte
Pau Espin