* coldfire uart question @ 2017-10-15 17:28 Angelo Dureghello 2017-10-15 23:08 ` Finn Thain 2017-10-15 23:57 ` Greg Ungerer 0 siblings, 2 replies; 12+ messages in thread From: Angelo Dureghello @ 2017-10-15 17:28 UTC (permalink / raw) To: Linux/m68k Hi all, i was trying a file transfer with xmodem-1k and uClinux "rx" on the mcf54415 stnmark2 board side. This using a recent mainline kernel: / # cat /proc/version uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d / # So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and 2 bytes crc16. But "rx" timeouts waiting the block. Adding some traces to "rx", it timeouts since some bytes (5 to 10) randomly positioned in the block are not received. Of course they have been sent (scope checked). The same 1024 bytes transfer in u-boot (y-modem) always succeed. Since mcf54415 has a 4 slots RX fifo UART, i was wondering if the mcf.c uart driver is not fast enough to read the data, or, where the "linux" limitation could be. Regards, Angelo Dureghello ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-15 17:28 coldfire uart question Angelo Dureghello @ 2017-10-15 23:08 ` Finn Thain 2017-10-17 21:18 ` Angelo Dureghello 2017-10-15 23:57 ` Greg Ungerer 1 sibling, 1 reply; 12+ messages in thread From: Finn Thain @ 2017-10-15 23:08 UTC (permalink / raw) To: Angelo Dureghello; +Cc: Linux/m68k On Sun, 15 Oct 2017, Angelo Dureghello wrote: > Hi all, > > i was trying a file transfer with xmodem-1k and uClinux "rx" on the > mcf54415 stnmark2 board side. > > This using a recent mainline kernel: > / # cat /proc/version > uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d > / # > > So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and 2 > bytes crc16. But "rx" timeouts waiting the block. > What is the fastest baud rate that will work? > Adding some traces to "rx", it timeouts since some bytes (5 to 10) > randomly positioned in the block are not received. Of course they have > been sent (scope checked). > > The same 1024 bytes transfer in u-boot (y-modem) always succeed. > Does u-boot need to do any retransmissions? (If it polls the UART, it could probably avoid any fifo overflow.) You may also want to try lrzsz. > Since mcf54415 has a 4 slots RX fifo UART, Ouch. At 115200 baud, that FIFO overflows after about 347 microseconds. If the kernel takes one interrupt per 4 bytes, you're looking at thousands of interrupts per second. Add a little unexpected interrupt latency (say, 50 microseconds) and the next byte gets lost. -- > i was wondering if the mcf.c uart driver is not fast enough to read the > data, or, where the "linux" limitation could be. > > Regards, > Angelo Dureghello > -- > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-15 23:08 ` Finn Thain @ 2017-10-17 21:18 ` Angelo Dureghello 2017-10-18 0:06 ` Finn Thain 2017-10-18 7:12 ` Greg Ungerer 0 siblings, 2 replies; 12+ messages in thread From: Angelo Dureghello @ 2017-10-17 21:18 UTC (permalink / raw) To: Linux/m68k; +Cc: Finn Thain Hi Finn, On 16/10/2017 01:08, Finn Thain wrote: > On Sun, 15 Oct 2017, Angelo Dureghello wrote: > >> Hi all, >> >> i was trying a file transfer with xmodem-1k and uClinux "rx" on the >> mcf54415 stnmark2 board side. >> >> This using a recent mainline kernel: >> / # cat /proc/version >> uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d >> / # >> >> So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and 2 >> bytes crc16. But "rx" timeouts waiting the block. >> > > What is the fastest baud rate that will work? > >> Adding some traces to "rx", it timeouts since some bytes (5 to 10) >> randomly positioned in the block are not received. Of course they have >> been sent (scope checked). >> >> The same 1024 bytes transfer in u-boot (y-modem) always succeed. >> > > Does u-boot need to do any retransmissions? (If it polls the UART, it > could probably avoid any fifo overflow.) > > You may also want to try lrzsz. > >> Since mcf54415 has a 4 slots RX fifo UART, > > Ouch. At 115200 baud, that FIFO overflows after about 347 microseconds. If > the kernel takes one interrupt per 4 bytes, you're looking at thousands of > interrupts per second. Add a little unexpected interrupt latency (say, 50 > microseconds) and the next byte gets lost. > thanks for explaining this. Well, if i understand properly, this mcf54415 CPU has 2 interrupts flags that can be checked: RXRDY, for one or more character received (current mcf.c seems to use this flag) and FFULL, for all 4 fifo slots full. So we probably have even more interrupts per second right now. I am at 115200, will try to decrease, and also, will try zmodem in case. Regards, Angelo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-17 21:18 ` Angelo Dureghello @ 2017-10-18 0:06 ` Finn Thain 2017-10-18 6:37 ` Geert Uytterhoeven 2017-10-18 7:12 ` Greg Ungerer 1 sibling, 1 reply; 12+ messages in thread From: Finn Thain @ 2017-10-18 0:06 UTC (permalink / raw) To: Angelo Dureghello; +Cc: Linux/m68k On Tue, 17 Oct 2017, Angelo Dureghello wrote: > On 16/10/2017 01:08, Finn Thain wrote: > > On Sun, 15 Oct 2017, Angelo Dureghello wrote: > > > > > Hi all, > > > > > > i was trying a file transfer with xmodem-1k and uClinux "rx" on the > > > mcf54415 stnmark2 board side. > > > > > > This using a recent mainline kernel: > > > / # cat /proc/version > > > uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d > > > / # > > > > > > So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and > > > 2 bytes crc16. But "rx" timeouts waiting the block. > > > > > > > What is the fastest baud rate that will work? > > > > > Adding some traces to "rx", it timeouts since some bytes (5 to 10) > > > randomly positioned in the block are not received. Of course they > > > have been sent (scope checked). > > > > > > The same 1024 bytes transfer in u-boot (y-modem) always succeed. > > > > > > > Does u-boot need to do any retransmissions? (If it polls the UART, it > > could probably avoid any fifo overflow.) > > > > You may also want to try lrzsz. > > > > > Since mcf54415 has a 4 slots RX fifo UART, > > > > Ouch. At 115200 baud, that FIFO overflows after about 347 > > microseconds. If the kernel takes one interrupt per 4 bytes, you're > > looking at thousands of interrupts per second. Add a little unexpected > > interrupt latency (say, 50 microseconds) and the next byte gets lost. > > > I should have said "86 microseconds", to guarantee an overflow, but the margin is lower than that even on an idle system, because time is lost in interrupt dispatch. This margin is the same whether the interrupt happens after one byte or four bytes. > thanks for explaining this. > > Well, if i understand properly, this mcf54415 CPU has 2 interrupts flags > that can be checked: RXRDY, for one or more character received (current > mcf.c seems to use this flag) and FFULL, for all 4 fifo slots full. > > So we probably have even more interrupts per second right now. > Even if you can reach 4 bytes per interrupt, the payoff is probably a reduction in CPU overhead due to interrupt load rather than a reduction in FIFO overflows. There seems to be too much interrupt latency to support the line rate. (Was that x-modem file transfer going to a storage device? Perhaps try sending it to tmpfs or /dev/null.) A line rate of 38400 or 57600 baud is probably more realistic. > I am at 115200, will try to decrease, and also, will try zmodem in case. > You could try transmitting a large number of bytes at full speed, counting them at the receiving end, and counting the number of interrupts from IRQ source 90 using /proc/interrupts. The bytes per interrupt ratio may already exceed 1, so the benefit from adopting the FFULL interrupt may not be what you expect. -- > Regards, > Angelo > -- > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-18 0:06 ` Finn Thain @ 2017-10-18 6:37 ` Geert Uytterhoeven 2017-10-18 7:05 ` Angelo Dureghello 0 siblings, 1 reply; 12+ messages in thread From: Geert Uytterhoeven @ 2017-10-18 6:37 UTC (permalink / raw) To: Finn Thain; +Cc: Angelo Dureghello, Linux/m68k On Wed, Oct 18, 2017 at 2:06 AM, Finn Thain <fthain@telegraphics.com.au> wrote: > On Tue, 17 Oct 2017, Angelo Dureghello wrote: >> On 16/10/2017 01:08, Finn Thain wrote: >> > On Sun, 15 Oct 2017, Angelo Dureghello wrote: >> > > i was trying a file transfer with xmodem-1k and uClinux "rx" on the >> > > mcf54415 stnmark2 board side. >> > > >> > > This using a recent mainline kernel: >> > > / # cat /proc/version >> > > uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d >> > > / # >> > > >> > > So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and >> > > 2 bytes crc16. But "rx" timeouts waiting the block. >> > > >> > >> > What is the fastest baud rate that will work? >> > >> > > Adding some traces to "rx", it timeouts since some bytes (5 to 10) >> > > randomly positioned in the block are not received. Of course they >> > > have been sent (scope checked). >> > > >> > > The same 1024 bytes transfer in u-boot (y-modem) always succeed. >> > > >> > >> > Does u-boot need to do any retransmissions? (If it polls the UART, it >> > could probably avoid any fifo overflow.) >> > >> > You may also want to try lrzsz. >> > >> > > Since mcf54415 has a 4 slots RX fifo UART, >> > >> > Ouch. At 115200 baud, that FIFO overflows after about 347 >> > microseconds. If the kernel takes one interrupt per 4 bytes, you're >> > looking at thousands of interrupts per second. Add a little unexpected >> > interrupt latency (say, 50 microseconds) and the next byte gets lost. > > I should have said "86 microseconds", to guarantee an overflow, but the > margin is lower than that even on an idle system, because time is lost in > interrupt dispatch. This margin is the same whether the interrupt happens > after one byte or four bytes. > >> thanks for explaining this. >> >> Well, if i understand properly, this mcf54415 CPU has 2 interrupts flags >> that can be checked: RXRDY, for one or more character received (current >> mcf.c seems to use this flag) and FFULL, for all 4 fifo slots full. >> >> So we probably have even more interrupts per second right now. > > Even if you can reach 4 bytes per interrupt, the payoff is probably a > reduction in CPU overhead due to interrupt load rather than a reduction in > FIFO overflows. In addition, if you already have FIFO overflows (of the remaining 3 entries) in between the issuing of the interrupt and the actual interrupt handling, you will have them for sure if you make the hardware issue an interrupt only when the FIFO is already full. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-18 6:37 ` Geert Uytterhoeven @ 2017-10-18 7:05 ` Angelo Dureghello 2017-10-18 8:15 ` Finn Thain 0 siblings, 1 reply; 12+ messages in thread From: Angelo Dureghello @ 2017-10-18 7:05 UTC (permalink / raw) To: Geert Uytterhoeven, Finn Thain; +Cc: Linux/m68k Hi Geert and Finn, On 18/10/2017 08:37, Geert Uytterhoeven wrote: > On Wed, Oct 18, 2017 at 2:06 AM, Finn Thain <fthain@telegraphics.com.au> wrote: >> On Tue, 17 Oct 2017, Angelo Dureghello wrote: >>> On 16/10/2017 01:08, Finn Thain wrote: >>>> On Sun, 15 Oct 2017, Angelo Dureghello wrote: >>>>> i was trying a file transfer with xmodem-1k and uClinux "rx" on the >>>>> mcf54415 stnmark2 board side. >>>>> >>>>> This using a recent mainline kernel: >>>>> / # cat /proc/version >>>>> uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d >>>>> / # >>>>> >>>>> So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and >>>>> 2 bytes crc16. But "rx" timeouts waiting the block. >>>>> >>>> >>>> What is the fastest baud rate that will work? >>>> >>>>> Adding some traces to "rx", it timeouts since some bytes (5 to 10) >>>>> randomly positioned in the block are not received. Of course they >>>>> have been sent (scope checked). >>>>> >>>>> The same 1024 bytes transfer in u-boot (y-modem) always succeed. >>>>> >>>> >>>> Does u-boot need to do any retransmissions? (If it polls the UART, it >>>> could probably avoid any fifo overflow.) >>>> >>>> You may also want to try lrzsz. >>>> >>>>> Since mcf54415 has a 4 slots RX fifo UART, >>>> >>>> Ouch. At 115200 baud, that FIFO overflows after about 347 >>>> microseconds. If the kernel takes one interrupt per 4 bytes, you're >>>> looking at thousands of interrupts per second. Add a little unexpected >>>> interrupt latency (say, 50 microseconds) and the next byte gets lost. >> >> I should have said "86 microseconds", to guarantee an overflow, but the >> margin is lower than that even on an idle system, because time is lost in >> interrupt dispatch. This margin is the same whether the interrupt happens >> after one byte or four bytes. >> >>> thanks for explaining this. >>> >>> Well, if i understand properly, this mcf54415 CPU has 2 interrupts flags >>> that can be checked: RXRDY, for one or more character received (current >>> mcf.c seems to use this flag) and FFULL, for all 4 fifo slots full. >>> >>> So we probably have even more interrupts per second right now. >> >> Even if you can reach 4 bytes per interrupt, the payoff is probably a >> reduction in CPU overhead due to interrupt load rather than a reduction in >> FIFO overflows. > > In addition, if you already have FIFO overflows (of the remaining 3 entries) > in between the issuing of the interrupt and the actual interrupt handling, > you will have them for sure if you make the hardware issue an interrupt > only when the FIFO is already full. > > Gr{oetje,eeting}s, > > Geert > Ok, many thanks for the clarifications, so mainly this is a linux limitation and seems i have to live whit it. Ok will do some test, maybe also adding 1 stop bit or killing some processes may help ? I am already into initramfs, so the write should not be that heavy. Will try also zmodem in case. Regards, Angelo > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-18 7:05 ` Angelo Dureghello @ 2017-10-18 8:15 ` Finn Thain 0 siblings, 0 replies; 12+ messages in thread From: Finn Thain @ 2017-10-18 8:15 UTC (permalink / raw) To: Angelo Dureghello; +Cc: Geert Uytterhoeven, Linux/m68k On Wed, 18 Oct 2017, Angelo Dureghello wrote: > Ok will do some test, maybe also adding 1 stop bit Adding a stop bit or two will marginally reduce the effective data rate but it could be that 115200 baud is unrealistic. > or killing some processes may help ? I am already into initramfs, so the > write should not be that heavy. I take it you mean storing into rootfs. So the latency is caused by some other interrupt source (not flash storage) with higher priority than the uart irq... > Will try also zmodem in case. > Keep in mind that a larger block size would mean a larger penalty for a single overrun, which can reduce throughput. -- > Regards, > Angelo > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-17 21:18 ` Angelo Dureghello 2017-10-18 0:06 ` Finn Thain @ 2017-10-18 7:12 ` Greg Ungerer 2017-10-18 7:19 ` Angelo Dureghello 1 sibling, 1 reply; 12+ messages in thread From: Greg Ungerer @ 2017-10-18 7:12 UTC (permalink / raw) To: Angelo Dureghello, Linux/m68k; +Cc: Finn Thain Hi Angelo, On 18/10/17 07:18, Angelo Dureghello wrote: > On 16/10/2017 01:08, Finn Thain wrote: >> On Sun, 15 Oct 2017, Angelo Dureghello wrote: >> >>> Hi all, >>> >>> i was trying a file transfer with xmodem-1k and uClinux "rx" on the >>> mcf54415 stnmark2 board side. >>> >>> This using a recent mainline kernel: >>> / # cat /proc/version >>> uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d >>> / # >>> >>> So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and 2 >>> bytes crc16. But "rx" timeouts waiting the block. >>> >> >> What is the fastest baud rate that will work? >> >>> Adding some traces to "rx", it timeouts since some bytes (5 to 10) >>> randomly positioned in the block are not received. Of course they have >>> been sent (scope checked). >>> >>> The same 1024 bytes transfer in u-boot (y-modem) always succeed. >>> >> >> Does u-boot need to do any retransmissions? (If it polls the UART, it >> could probably avoid any fifo overflow.) >> >> You may also want to try lrzsz. >> >>> Since mcf54415 has a 4 slots RX fifo UART, >> >> Ouch. At 115200 baud, that FIFO overflows after about 347 microseconds. If >> the kernel takes one interrupt per 4 bytes, you're looking at thousands of >> interrupts per second. Add a little unexpected interrupt latency (say, 50 >> microseconds) and the next byte gets lost. >> > > thanks for explaining this. > > Well, if i understand properly, this mcf54415 CPU has 2 interrupts flags > that can be checked: > > RXRDY, for one or more character received (current mcf.c seems to use > this flag) and > FFULL, for all 4 fifo slots full. > > So we probably have even more interrupts per second right now. > > I am at 115200, will try to decrease, and also, will try zmodem in case. Can you use hardware flow control (the "crtscts" stty setting)? You will need to use a serial cable with RTS and CTS signals wired, and also for the sending end to be set for it. The ColdFire UART has hardware level support for automatically driving RTS/CTS when FIFO is full. Regards Greg ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-18 7:12 ` Greg Ungerer @ 2017-10-18 7:19 ` Angelo Dureghello 2017-10-18 7:35 ` Philippe De Muyter 0 siblings, 1 reply; 12+ messages in thread From: Angelo Dureghello @ 2017-10-18 7:19 UTC (permalink / raw) To: Greg Ungerer, Linux/m68k; +Cc: Finn Thain Hi Greg, On 18/10/2017 09:12, Greg Ungerer wrote: > Hi Angelo, > > On 18/10/17 07:18, Angelo Dureghello wrote: >> On 16/10/2017 01:08, Finn Thain wrote: >>> On Sun, 15 Oct 2017, Angelo Dureghello wrote: >>> >>>> Hi all, >>>> >>>> i was trying a file transfer with xmodem-1k and uClinux "rx" on the >>>> mcf54415 stnmark2 board side. >>>> >>>> This using a recent mainline kernel: >>>> / # cat /proc/version >>>> uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d >>>> / # >>>> >>>> So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and 2 >>>> bytes crc16. But "rx" timeouts waiting the block. >>>> >>> >>> What is the fastest baud rate that will work? >>> >>>> Adding some traces to "rx", it timeouts since some bytes (5 to 10) >>>> randomly positioned in the block are not received. Of course they have >>>> been sent (scope checked). >>>> >>>> The same 1024 bytes transfer in u-boot (y-modem) always succeed. >>>> >>> >>> Does u-boot need to do any retransmissions? (If it polls the UART, it >>> could probably avoid any fifo overflow.) >>> >>> You may also want to try lrzsz. >>> >>>> Since mcf54415 has a 4 slots RX fifo UART, >>> >>> Ouch. At 115200 baud, that FIFO overflows after about 347 microseconds. If >>> the kernel takes one interrupt per 4 bytes, you're looking at thousands of >>> interrupts per second. Add a little unexpected interrupt latency (say, 50 >>> microseconds) and the next byte gets lost. >>> >> >> thanks for explaining this. >> >> Well, if i understand properly, this mcf54415 CPU has 2 interrupts flags >> that can be checked: >> >> RXRDY, for one or more character received (current mcf.c seems to use >> this flag) and >> FFULL, for all 4 fifo slots full. >> >> So we probably have even more interrupts per second right now. >> >> I am at 115200, will try to decrease, and also, will try zmodem in case. > > Can you use hardware flow control (the "crtscts" stty setting)? > You will need to use a serial cable with RTS and CTS signals wired, > and also for the sending end to be set for it. The ColdFire UART > has hardware level support for automatically driving RTS/CTS when > FIFO is full. > many thanks for the hint, well for stmark2 board unfortunately/stupidly i didn't wired them out from the BGA package. But good to know. > Regards > Greg > Regards, Angelo > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-18 7:19 ` Angelo Dureghello @ 2017-10-18 7:35 ` Philippe De Muyter 0 siblings, 0 replies; 12+ messages in thread From: Philippe De Muyter @ 2017-10-18 7:35 UTC (permalink / raw) To: Angelo Dureghello; +Cc: Greg Ungerer, Linux/m68k, Finn Thain Hi all, it seems that mcf54415 has uart DMA support (https://community.nxp.com/thread/304877) could you use that ? Philippe On Wed, Oct 18, 2017 at 09:19:52AM +0200, Angelo Dureghello wrote: > Hi Greg, > > On 18/10/2017 09:12, Greg Ungerer wrote: >> Hi Angelo, >> On 18/10/17 07:18, Angelo Dureghello wrote: >>> On 16/10/2017 01:08, Finn Thain wrote: >>>> On Sun, 15 Oct 2017, Angelo Dureghello wrote: >>>> >>>>> Hi all, >>>>> >>>>> i was trying a file transfer with xmodem-1k and uClinux "rx" on the >>>>> mcf54415 stnmark2 board side. >>>>> >>>>> This using a recent mainline kernel: >>>>> / # cat /proc/version >>>>> uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d >>>>> / # >>>>> >>>>> So, as per xmodem-1k, i send 3 bytes header, a 1024 bytes block, and 2 >>>>> bytes crc16. But "rx" timeouts waiting the block. >>>>> >>>> >>>> What is the fastest baud rate that will work? >>>> >>>>> Adding some traces to "rx", it timeouts since some bytes (5 to 10) >>>>> randomly positioned in the block are not received. Of course they have >>>>> been sent (scope checked). >>>>> >>>>> The same 1024 bytes transfer in u-boot (y-modem) always succeed. >>>>> >>>> >>>> Does u-boot need to do any retransmissions? (If it polls the UART, it >>>> could probably avoid any fifo overflow.) >>>> >>>> You may also want to try lrzsz. >>>> >>>>> Since mcf54415 has a 4 slots RX fifo UART, >>>> >>>> Ouch. At 115200 baud, that FIFO overflows after about 347 microseconds. >>>> If >>>> the kernel takes one interrupt per 4 bytes, you're looking at thousands >>>> of >>>> interrupts per second. Add a little unexpected interrupt latency (say, >>>> 50 >>>> microseconds) and the next byte gets lost. >>>> >>> >>> thanks for explaining this. >>> >>> Well, if i understand properly, this mcf54415 CPU has 2 interrupts flags >>> that can be checked: >>> RXRDY, for one or more character received (current mcf.c seems to use >>> this flag) and >>> FFULL, for all 4 fifo slots full. >>> >>> So we probably have even more interrupts per second right now. >>> >>> I am at 115200, will try to decrease, and also, will try zmodem in case. >> Can you use hardware flow control (the "crtscts" stty setting)? >> You will need to use a serial cable with RTS and CTS signals wired, >> and also for the sending end to be set for it. The ColdFire UART >> has hardware level support for automatically driving RTS/CTS when >> FIFO is full. > > many thanks for the hint, well for stmark2 board unfortunately/stupidly i > didn't wired them out from the BGA package. But good to know. > >> Regards >> Greg >> > > Regards, > Angelo > -- > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-15 17:28 coldfire uart question Angelo Dureghello 2017-10-15 23:08 ` Finn Thain @ 2017-10-15 23:57 ` Greg Ungerer 2017-10-17 21:07 ` Angelo Dureghello 1 sibling, 1 reply; 12+ messages in thread From: Greg Ungerer @ 2017-10-15 23:57 UTC (permalink / raw) To: Angelo Dureghello, Linux/m68k Hi Angelo, On 16/10/17 03:28, Angelo Dureghello wrote: > i was trying a file transfer with xmodem-1k > and uClinux "rx" on the mcf54415 stnmark2 board side. > > This using a recent mainline kernel: > / # cat /proc/version > uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d > / # > > So, as per xmodem-1k, i send 3 bytes header, > a 1024 bytes block, and 2 bytes crc16. But "rx" timeouts > waiting the block. > > Adding some traces to "rx", it timeouts since some bytes > (5 to 10) randomly positioned in the block are not received. > Of course they have been sent (scope checked). Check if you are getting overruns on the port: cat /proc/tty/driver/mcf Regards Greg > The same 1024 bytes transfer in u-boot (y-modem) > always succeed. > > Since mcf54415 has a 4 slots RX fifo UART, i was wondering > if the mcf.c uart driver is not fast enough to read the data, > or, where the "linux" limitation could be. > > Regards, > Angelo Dureghello > -- > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: coldfire uart question 2017-10-15 23:57 ` Greg Ungerer @ 2017-10-17 21:07 ` Angelo Dureghello 0 siblings, 0 replies; 12+ messages in thread From: Angelo Dureghello @ 2017-10-17 21:07 UTC (permalink / raw) To: Greg Ungerer, Linux/m68k; +Cc: Finn Thain Hi Greg and all, On 16/10/2017 01:57, Greg Ungerer wrote: > Hi Angelo, > > On 16/10/17 03:28, Angelo Dureghello wrote: >> i was trying a file transfer with xmodem-1k >> and uClinux "rx" on the mcf54415 stnmark2 board side. >> >> This using a recent mainline kernel: >> / # cat /proc/version >> uClinux version 4.14.0-rc4stmark2-001-00118-g811fdbb62a9d >> / # >> >> So, as per xmodem-1k, i send 3 bytes header, >> a 1024 bytes block, and 2 bytes crc16. But "rx" timeouts >> waiting the block. >> >> Adding some traces to "rx", it timeouts since some bytes >> (5 to 10) randomly positioned in the block are not received. >> Of course they have been sent (scope checked). > > Check if you are getting overruns on the port: > > cat /proc/tty/driver/mcf thanks, yes, you are right / # cat /proc/tty/driver/mcf serinfo:1.0 driver revision: 0: uart:ColdFire UART mmio:0xFC060000 irq:90 tx:4047 rx:1057 oe:8 RTS|DTR|CD 1: uart:ColdFire UART mmio:0xFC064000 irq:91 tx:0 rx:0 CD 2: uart:ColdFire UART mmio:0xFC068000 irq:92 tx:0 rx:0 CD 3: uart:ColdFire UART mmio:0xFC06C000 irq:93 tx:0 rx:0 CD / # I am at 115200,n,8,1 now. I checked the u-boot driver and there is no interrupt handler, only a coldfire_serial_getc checking USR_RXRDY. Could the RxFIFO_Full interrupt flag be of any help ? > > Regards > Greg > > Regards, Angelo > >> The same 1024 bytes transfer in u-boot (y-modem) >> always succeed. >> >> Since mcf54415 has a 4 slots RX fifo UART, i was wondering >> if the mcf.c uart driver is not fast enough to read the data, >> or, where the "linux" limitation could be. >> >> Regards, >> Angelo Dureghello >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-10-18 8:15 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-15 17:28 coldfire uart question Angelo Dureghello 2017-10-15 23:08 ` Finn Thain 2017-10-17 21:18 ` Angelo Dureghello 2017-10-18 0:06 ` Finn Thain 2017-10-18 6:37 ` Geert Uytterhoeven 2017-10-18 7:05 ` Angelo Dureghello 2017-10-18 8:15 ` Finn Thain 2017-10-18 7:12 ` Greg Ungerer 2017-10-18 7:19 ` Angelo Dureghello 2017-10-18 7:35 ` Philippe De Muyter 2017-10-15 23:57 ` Greg Ungerer 2017-10-17 21:07 ` Angelo Dureghello
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.