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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx
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
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
