Originally written by dexter and then Andreas did a lot of cleanup
work to bring it into shape for inclusion in master
Written-by: Philipp Maier <zero-kelvin@gmx.de>
Written-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The Compal E86 (C139/C140) has a different RFFE-configuration
than the other Compal phones. The Motorola C139 schematics
on this part look exactly the same, but in fact the board is missing
a transistor (U16), and it uses TSPACT2 adittionally.
This fixes the long-known problem with the C139/C140 phones
of the rx-level being over -20dBm worse as compared to the
E88/E89 phones, as well as the band selection on the
antenna switch in TX-mode (which was completely wrong,
but sort of worked anyway).
Signed-off-by: Steve Markgraf <steve@steve-m.de>
So far, the PA-enable signal has been enabled way to early and
also has been disabled much too late.
We're now setting the RFFE to TX-mode after opening the ABB
window, and setting the RFFE to RX-mode again after TX. This
yields to an almost perfectly timed TX-window, just like with the
stock firmware of the phone.
Signed-off-by: Steve Markgraf <steve@steve-m.de>
Found by clang:
warning: argument to 'sizeof' in 'memset' call is the same expression
as the destination; did you mean to remove the addressof?
Signed-off-by: Steve Markgraf <steve@steve-m.de>
This file was handled as a binary(!) file by git (thus the git rm).
Also, it missed the uppermost line of pixels in each character.
It will be replaced with a correct font in the next commit.
Signed-off-by: Steve Markgraf <steve@steve-m.de>
Since the powerbutton on the Pirelli DP-L10 doesn't seem to be
connected to the keypad scan matrix at all, we're using Iota's
PWON interrupt to determine if the powerbutton has been pressed,
and power off the phone after it has been released again.
This also affects the Compal phones, since the interrupt happens
quite some time before the keypad driver notices the keypress.
The code in the keypad driver that has been used so far to power
off the phone will remain as a backup when running without
interrupts at all (e.g. the loader application).
Signed-off-by: Steve Markgraf <steve@steve-m.de>
Also hard limit to maximum 4 pending frames (should not happen !), the
upstream is supposed to do its own flow control.
Written-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
- It's broken by the use of compute_gain
- Since there is now an AGC loop, manually setting the register
as no effect.
If someone needs manual gain control for testing, he'll have to
re-implement a proper AGC override.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When listening to BCCH, layer1 may measure the power level of neighbour
cells. A list of neighbour cell frequencies need to be sent to layer1.
After the measurement is done, the results are indicated to layer23.
rffe_compute_gain() is the new name for rffe_set_gain(). I needed to change
this, to solve the name collision with the rffe_set_gain() function, which
actually sets the absolute gain.
rffe_get_gain() will now read the absolute gain which has been computed by
rffe_compute_gain() or set by rffe_set_gain().
First we add 55500 to an int16_t, then later we subtract it again.
The bug only didn't become apparent as we wrap twice, once adding
then subtracting.
Discovered by Smatch:
firmware/layer1/tpu_window.c +127 l1s_rx_win_ctrl(24) warn: value 55000 can't fit into 32767 'stop'
Credits to Andreas Eversberg for finding this bug after countless
hours of debug and providing initial patch :)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Credits to Andreas Eversberg for finding this bug after countless
hours of debug :)
Written-by: Andreas Eversberg <jolly@eversberg.eu>
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Ideally we should only panic in interrupt context. In user
context, we could wait ...
We could also return NULL and let the calling code deal with it
but it's not ready for that yet.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
gcc3 (and some gcc4) produce code which does not fit into the
0x5000-sized RAM sections. Extend them to 0x6000 for now, so it will
build correctly again. The created binary (gcc3) has been successfully
tested on my G2.
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
We also disable them by default because:
- It can operate fine out of spec
- Some phone will actually do it (like using the DCS port for PCS)
- It's verbose for nothing for most people anyway
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
* We actually support TX 850/1900 now
* We try to find the better settings for a given frequency,
no matter if it's in spec or not ...
(for e.g. TXin in DCS downlink is better done with PCS config)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Depending on the chipset and the HW, not all ports are connected
and we need to know what we can use when we have the choice ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
We are just interested in the loaders here, no other applications needed.
Split it from the compal-based phones. Add mt62xx as first user.
Based on a patch by steve-m, but cleaned up and seperated from compal/calypso.
Signed-off-by: Steve Markgraf <steve@steve-m.de>
Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
This patch changes include paths to get osmocom-bb working with
the current libosmocore tree.
Among all these renames, you can notice several tweaks that I
added on purpose, and that require some explanation, they are:
* hexdump() in osmocon.c and osmoload.c has been renamed to avoid
clashing with hexdump() defined in libosmocore.
* gsmmap now depends on libosmogsm. Actually I had to cleanup
Makefile.am because I was experiencing weird linking problems,
probably due to a bug in the autotools. With the change included
in this patch, I got it compiled and linked here correctly.
This patch has been tested with the phone Motorola C123 and the
following images files:
* firmware/board/compal_e88/hello_world.compalram.bin
* firmware/board/compal_e88/layer1.compalram.bin
Using the osmocon, bcch_scan and mobile tools.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
Without the delay we would fill the sercomm buffer faster than its
content can be sent, and the phone would end up in a panic and hang.
Signed-off-by: Steve Markgraf <steve@steve-m.de>