We now support arbitrary timers by means of 'struct timer_list'.
Any part of the program can register such a callback by means
of schedule_timer() on a millisecond-granularity. However, there
is no guarantee on the timer precision. It will not execute before
the timer expires - but it might expire quite a bit later than we
have asked it for, depending on how busy the cpu is with other work.
The timer code is in the 'comm/' directory, as it is intended to be
migrated into libosmocore soon.
Furthermore, as we currently don't yet have a scheduler or tasks,
the main() routine explicitly has to call update_timers() to check
for any expired timers and run them.
successive calls to cons_puts() writing to the same msgb resulted in
osmcoom printing null-characters while writing strings. We don't
really need that...
We now
* properly decode the L1 header of SACCH frames
* properly hand-off SACCH payload such as SI5/SI6
* display the summary of the GSMTAP and SACCH_L1 dissectors in the protocol tree
* use GSMTAP for uplink frames (generated by layer23; sent to L1)
* only use GSMTAP if the user specifies the '-i dstip' arguments
* properly encode the GSMTAP channel type
* requires GSMTAP protocol version 0x02 (see next commit for wireshark patch)
* print HDLC packets received from L2
* print Tx MAC block as it is written to DSP API RAM
* ensure we don't msgb_free() a message that we've enqueued for l1s
Tx support is considered experimental and potentially dangerous.
Thus, the default build of the firmware does not have Tx support
enabled.
If you want Tx support, compile with -DCONFIG_TX_ENABLE by uncommenting
the apropriate line in Makefile.inc
L1 and L2 now pass UI frames like BCCH and CCCH downlink up into
L3, which detects an IMMediate ASSignment command and instructs
the L1 to switch to SDCCH/4.
From this point on, SDCCH/4 and SACCH4/C messages end up in our
L2 LAPDm implementation and are forwarded to L3.
Using the following changes, it is now possible to receive the PCH and AGCH
messages in the PC-side layer3, as well as trigger RACH sending inside the phone
from the PC:
* merge l1_dedic_mode_data_ind, l1_dedic_mode_data_req and l1_ccch_info_ind into l1_data_ind
* add partial LAPDm implementation (layer2/src/lapdm.c)
* introduce RSLms between LAPDm and L3 (layer2/src/osmocom_rslms.c)
* use new layer1 header field of msgb
* tx_ph_rach_req() and tx_ph_data_req() to send data from PC to target
* implement DEDIC_MODE_DATA_REQ on firmware side
This enables the layer2 to identify on which channel
(BCCH/CCCH/SDCCH/TCH/...) the respective message was received.
* Encode MFrame Task Number + SACCH info in 'p3' parameter
* Generate channel number and link identifier
* Decode channel number in layer2 program
The idea of the third parameter is that it can be specified on a
tdma_schedule_set() level. The multi-frame scheduler can thus use
it to pass some context information into the l1s_{cmd,resp}_*()
functions, such as the MF TASK and whether or not it is SDCCH or
SACCH.
Using the new rach_sched_set_ul and nb_sched_set_ul TDMA scheduler
sets it is possible to transmit RACH bursts as well as sets of four
normal bursts, i.e. everything needed to get a SDCCH established
on a combined CCCH (with SDCCH/4).
Known Limitations:
* Uses constant transmit power (2 dBm)
* Only works on SDCCH/4 so far
* SACCH is received but cannot be transmitted yet
* TSC (traning sequence code) is hard-coded to '7'
* Tell DSP to properly initialize ABB(TWL3025) registers at first DSP interrupt
* Initialize the entire API RAM to zero on dsp_power_on()
* Tell DSP to initialize the APCRAM to all-zero to preven accidential Tx
* Set number of GUARD bits to 8
* Add function to configure TCH parameters: dsp_load_tch_param()
This scheduler enables us to schedule repeating events that occur
every multiframe. It e.g. includes definitions for BCCH and CCCH
reading.
The mframe_sched is layered on top of the tdma_sched.
This has the advantage that any caller or other reference does not
need to know the size of the set, which makes it simpler to use the
sched_set as a constant initializer in some other const/static data
structure.
The write queue can be a dropin replacement for the bsc_fd. It
is featuring two callbacks. One for ready read and one for ready
write. Whenever there is a message in the queue the write_queue
will set the BSC_FD_WRITE flag and then call the write callback.
It will make sure to delete the msgb after the write function
has been called. This class is intended to be be used in the
osmocom, layer2, bsc_msc_ip, bsc_hack and other applications.
In commit 9a18ba40d940c9bf173504b941e10f9638032823 (old git), this
was changed to 'fix compiler warnings'.
But %ux is not a valid format specifier at all so that produces
wrong output !
%lx is the correct format AFAICT because uint32_t is typedef'd from
unsigned long in my toolchain (ARM GCC 4.3.3 - newlib 1.17.0). This
doesn't produce any warning here.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Using #define TPU_DEBUG, we can now send the full TPU RAM contents
to the host PC (using a sercomm DLCI) at the time of tpu_enable()
which is very helpful for TPU debugging.
If we perform the downlink calibration too early, the TRF6151 might
not yet provide a stable signal and we'll not be able to receive
anything.
From the desired "BDLENA" time, we subtract all the delays and
latencies to determine the point in time at which the calibration
process should start.
In the sercomm_cons layer, ee used to enqueue a msgb for sending
every time there is an end-of-line. However, if we send a number
of very short lines, we easily run out of msgbs.
Now we check how much msgb backlog there is in the transmit queue,
and decide to skip the end-of-line flushing if needed.
This still doesn't solve all our problems, but its still a useful
mechanism.
libosmocore is a new library that has been created out of OpenBSC,
and it provides almost everything we've tried here with libosmocom.
The only remaining part is the 'debug' part
* remove commented-out code
* explain what GSMTAP is and reference projects that can generate it
* update copyright notice
I will submit this to wireshark mainline now.
The cause is really not clear. The formual using 2*Pi to convert
from radians to frequency is perfectly correct.
However, measurements with various test equipment (including Racal 6103)
have shown our frequency error estimate is always off by a power of two...
Ingo Albrecht
Harald Welte
Sylvain Munaut