All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: Angelo Dureghello <angelo@sysam.it>
Cc: Linux/m68k <linux-m68k@vger.kernel.org>
Subject: Re: coldfire uart question
Date: Mon, 16 Oct 2017 10:08:53 +1100 (AEDT)	[thread overview]
Message-ID: <alpine.LNX.2.00.1710160943040.3@nippy.intranet> (raw)
In-Reply-To: <1f18ad0d-d147-5c64-ad65-a4bc545d4bff@sysam.it>

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
> 

  reply	other threads:[~2017-10-15 23:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-15 17:28 coldfire uart question Angelo Dureghello
2017-10-15 23:08 ` Finn Thain [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.00.1710160943040.3@nippy.intranet \
    --to=fthain@telegraphics.com.au \
    --cc=angelo@sysam.it \
    --cc=linux-m68k@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.