summaryrefslogtreecommitdiffstats
path: root/src/target/firmware/calypso/uart.c
AgeCommit message (Collapse)AuthorFilesLines
2013-01-05fw: introduce per-board uart mappingSteve Markgraf1-5/+7
Signed-off-by: Steve Markgraf <steve@steve-m.de>
2011-07-16calypso/uart.c: Fix array bounds checkingHarald Welte1-1/+1
Found by Smatch: calypso/uart.c +433 uart_baudrate(7) error: buffer overflow 'divider' 7 <= 7
2011-05-05uart.h: move header out of calypso-directoryWolfram Sang1-1/+1
Everything defined is a pretty generic interface and can be used by mediatek, too. Signed-off-by: Wolfram Sang <wolfram@the-dreams.de>
2010-11-17target uart: remove REG_OFFS() macro side-effectAlex Badea1-1/+1
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>
2010-11-17target uart: fix preservation of LCRAlex Badea1-4/+4
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>
2010-04-12UART initialisation, serial port errorsChristian Vogel1-0/+10
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).
2010-03-21calypsu UART: add additional debug output in UART RX error caseHarald Welte1-1/+22
2010-03-07start to use libosmocore within the firmwareHarald Welte1-0/+1
* 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
2010-03-07fix even more compiler warningsHarald Welte1-2/+2
2010-03-07Allow use of uart driver without interrupts.Ingo Albrecht1-7/+19
2010-02-18Initial import of OsmocomBB into git repositoryHarald Welte1-0/+396