This commit adds polling of the TWL3025 PWON
signal. If the powerbutton is pressed on targets
that use it (Pirelli DP-L10, Huawei GTM900-B),
a normal keypad scanning cycle is started in order
to preserve the timing, required for the 500ms
power off press duration for example.
Change-Id: I904baf40d621bd680b602b88d12ff462b3c17596
Unfortunately current code architecture doesn't support a return path
with an error so tell the caller of L1CTL on the other side that
something's wrong.
Change-Id: Ib9b622dd5c9770c5e97fa58deee124a409544d3b
In order to allow applications to use the power button, the keypad handler
will wait half a second if the key is pressed and hold, until the power
is turned off. This way the application does not need to handle it.
The power off function will then wait until the button is released, so the
phone will not start again while the button is still pressed.
I2C bus support up to 128 devices (mask 0x7F), but current calypso driver
is masked it to 64 (0x3F). I discover it because Motorola W220 has an I/O
expander PCA9537 at address 0x49 which could be reached.
Signed-off-by: Alan Carvalho de Assis <acassis@gmail.com>
Signed-off-by: Steve Markgraf <steve@steve-m.de>
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>
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>
Don't assign to the variable given as argument. This prevents
clobbering the local 'reg' variables in uart_reg_{read,write}(),
which would in turn prevent the latch bits from being restored
correctly.
Signed-off-by: Alex Badea <vamposdecampos@gmail.com>
Store old_lcr only when switching to LCR == 0xBF. We don't want
to clobber old_lcr when switching back, otherwise we can't restore
the previous LCR value.
Signed-off-by: Alex Badea <vamposdecampos@gmail.com>
This works for both the default ROM bootloader and for our
custom one.
This will allow to implement easy patch loading.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Copying to/from the DSP API shared memory must be done using
16 bits word only. Using those method, we avoid the hassle of
repeating the code when we copy buffer back and forth.
API address must be 16 bits aligned but for our purpose, it's
good enough.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The keys are correctly detected and debounced. There is no delay_ms in the
interrupt handler anymore.
When a key is pressed, the columns of the keypad are polled and debounced
via timer interrupt. If no key is pressed, the timer interrupt is ignored
again.
Additional initialisations for the UART to make the data corruption
from the PC to the Phone go away.
I've seen a lot of systematic character swaps on the serial port,
especially in the vincinity of 0-bytes. As the XON/XOFF registers
are the only thing in the UART that look like they would consider
the actual data sent, I've added this initialisation to uart.c
This makes the problem go away completely on my C123.
To check for it I've added CRCs to the HDLC protocol and checked
for bad frames, and also compared them in a (patched) osmocon
that just sends random garbate in a special DLCI. The bad
frames I observed always looked like this (number in
parenthesis define number of omitted bytes, for brevity):
<------ good bytes ----------> <-recvd|sent-> <----- identical again
------>
d0 e0 00 00..(107)..f7 ce 17 c4 < 0c 00|00 0c > db 70 ba cb..(67)..d8 6d 3a 1f
31 e1 00 00..(47)..38 ca 2f e5 < 0c 00|00 0c > f8 a3 77 5f..(127)..5b 72 ff 4a
<-- good -> <--- bad -----> <---- good again ------------->
dc e1 00 00 < 0c 00|00 0c > 87 cb 24 83..(178)..2f 69 b3 51
ae e2 00 00..(167)..bd 18 6f a1 < 0c 00|00 0c > 2f 53 d2 b2..(7)..da c7 1b 63
dc e3 00 00..(131)..8e 2c b0 a8 < 0c 00|00 0c > 40 62 56 5f..(43)..f0 3a 47 f7
Formerly I was observing about 10 packets for every 2000 sent (with 192
bytes of payload each). Now, with the added initialisation, I see
(as the time of writing this email) 12000 packets with 192 bytes each
sent, with 0 bytes missing, corrupted, flipped).
* bit 8 always needs to be 1 when overriding the setting of the nIBOOT pin, so now we set both bits (9 and 8) to 1, and clear bit 9 if we want to enable the romloader
* to be sure, this was tested on a target with nIBOOT high (C155) and a Alcatel VLE5 pulled to low, and works fine
Signed-off-by: Steve Markgraf <steve@steve-m.de>
* introduce display_driver layer
* port st7558 and ssd1783 drivers to display_driver
* allow for run-time selection of display driver from board/init.c
* replace st7558_puts() calls with display_puts() calls
* remove linuxlist.h copy and use osmocore
* don't put 'struct gsm_time' into l1ctl packets
* include rx_level and snr for each burst in l1ctl
* properly build libosmocore.a for target
* move gsmtime functions into libosmocore
* move ctype.h to standard location
Martin Hauke
Steve Markgraf
Pau Espin
Harald Welte
Sylvain Munaut
Christian Vogel
Dieter Spaar