From mboxrd@z Thu Jan 1 00:00:00 1970 From: Angelo Dureghello Subject: Re: coldfire uart question Date: Wed, 18 Oct 2017 09:05:36 +0200 Message-ID: References: <1f18ad0d-d147-5c64-ad65-a4bc545d4bff@sysam.it> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from sysam.it ([5.39.81.93]:50649 "EHLO sysam.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966805AbdJRHFj (ORCPT ); Wed, 18 Oct 2017 03:05:39 -0400 In-Reply-To: Content-Language: en-US Sender: linux-m68k-owner@vger.kernel.org List-Id: linux-m68k@vger.kernel.org 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 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 >