This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Ingo Albrecht prom at berlin.ccc.deIngo Albrecht wrote: > Harald Welte wrote: >> Hi! >> > > I must note though that I have not only been getting lost bytes but also > reversed bytes. We spent a while discussing this in IRC. steve-m could > reproduce this perfectly, as could I. The problem seems to be > data-dependend though, as sending the same frame twice (with the > bootloader tool) yields the same garbling. To clarify: "reversed bytes" means that "004000" becomes "400000". >> I think I've seen this at some point in the past, but now I'm seeing it >> constantly. >> >> Let's assume we're trying to send the following sequence of bytes from >> the PC side to the phone in one of the HLDC connections: >>> send_to_phone(dlci=5): 0a 00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d >>> 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 >>> 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d >> what we actually get from the sercomm callback on the phone is: >> >>> l1a_l23_rx_cb: 0a 00 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 >>> 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a >>> 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d >> as you can see, there is a '00 01' missing between the '00' and the '02'. >> >> Interestingly, putting a usleep(10000) after every serial write does not >> solve the problem, so it is not timing related. We don't get any UART >> overflows on the calypso, either. >> >> If I change the data pattern, then the first bytes are transmitted fine, >> but as soon as there is one 00 bytes, two characters are missing from >> the stream. >> >> If I strace osmocon, it is clear that we write every character, >> including the null-bytes, and all of the writes are successfully. >> >> I've again looked at (and played with) the termios settings, but could >> not find any problem (nor solution). >> >> It's also not the sercomm layer that is loosing bytes, as I the >> characters appear already lost when printing them from within the >> calypso UART driver, as you can see here: >> >> getchar_nb(1) = 7e // flag character >> getchar_nb(1) = 05 // hdlc >> getchar_nb(1) = 03 // hdlc >> getchar_nb(1) = 0a // l1ctl_hdr (undefined msg_type 10) >> getchar_nb(1) = 00 // padding >> getchar_nb(1) = 02 // here should be 00, 01, 02... >> getchar_nb(1) = 03 >> getchar_nb(1) = 04 >> getchar_nb(1) = 05 >> [...] >> >> Any ideas? It's really strange and I don't really know what else to do. >> I'm quite sure our binaries contain multiple successive null-bytes and >> their download is working great... >> >> Regards, >> Harald > >