lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 11 Jan 2017 01:33:20 +0100
From:   Clemens Gruber <clemens.gruber@...ruber.com>
To:     Fabio Estevam <festevam@...il.com>
Cc:     linux-serial@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>, Nandor Han <nandor.han@...com>,
        Lucas Stach <l.stach@...gutronix.de>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: imx: RS-485 problems during TX, maybe DMA related

Hi Fabio,

On Sun, Jan 08, 2017 at 07:46:29PM -0200, Fabio Estevam wrote:
> > What's the revision of the i.MX6Q on your board? Mine is 1.5 (TO 1.3)
> 
> Mine is a mx6solo rev1.1.

Could it be dependent upon SMP? Do you have an i.MX6Q board around to
try?

--

I made a few interesting discoveries in the meantime:

1) If I do not enable UCR4_TCEN, the data on TXD is fine. Of course the
TE pin does not toggle in that case, but it shows that the problem has
something to do with the actions taking place after the transmit
complete interrupt and not with the hardware or DMA internals.

2) I added a few custom printks when doing echo A > /dev/ttymxc4 in
RS-485 mode:

imx_start_tx
imx_dma_tx: tx_bytes=2, xmit->tail=0, xmit->head=2
imx_dma_tx: dma_tx_nents=1
imx-uart 21f4000.serial: TX: prepare to send 2 bytes by DMA
imx_transmit_buffer: xmit->tail set to 1, xmit->head=2
imx_transmit_buffer: xmit->tail set to 2, xmit->head=2
imx_stop_tx (returns immediately because dma_is_txing)
^ repeats multiple times
imx_stop_tx (goes through)
dma_tx_callback: xmit->tail=2 tx_bytes=2
dma_tx_callback: xmit->tail set to 4
imx-uart 21f4000.serial: we finish the TX DMA.
dma_tx_callback: xmit->tail=4 icount.tx=4
imx_dma_tx: tx_bytes=4094, xmit->tail=4, xmit->head=2		(!!)
imx_dma_tx: dma_tx_nents=2
..

That's why the data is garbled in that way: It wraps around the circular
buffer. xmit->tail jumps over xmit->head, which explains why I first see
the correct characters, then again followed by many zeros and at the end
again the correct characters.

Regards,
Clemens

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ