linux-kernel - Re: imx: RS-485 problems during TX, maybe DMA related

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:   Sun, 8 Jan 2017 00:06:24 +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 Sat, Jan 07, 2017 at 07:43:48PM -0200, Fabio Estevam wrote:
> Hi Clemens,
> 
> On Sat, Jan 7, 2017 at 6:59 PM, Clemens Gruber
> <clemens.gruber@...ruber.com> wrote:
> 
> > Great!
> >
> > Did you observe the same effect I described, with the doubling of
> > characters in the front and the leftovers from previous transmissions at
> > the end?
> 
> No, I don't observe these errors when I use 'rts-gpios' in the device tree.
> 
> Maybe you could try to use 'rts-gpios' for a quick test by applying
> the patches I have just sent.
> 
> If you run this test, please remove 'uart-has-rtscts' from your dts.
> According to Documentation/devicetree/bindings/serial/serial.txt they
> are mutually-exclusive.

Just remuxed GPIO signals to these pads, applied your two patches and
used rts-gpios in the DT but I still see the same problem :/

When transmit something, I get doubled characters, then zeros and at the
end garbled data of previous transmissions, same as described in my
first post (Logic analyzer: https://pqgruber.com/rs485_results.png)
The data is always 4096 bytes long, this explains why the echo command
is blocking for about 4 seconds (<- 4096 bytes at a baudrate of 9600).
The TE line is also high until all 4096 bytes are sent.

I think this comes from the UART_XMIT_SIZE which is defined to the page
size.
Maybe there is something wrong in imx_transmit_buffer and leads to the
whole circular buffer being sent out all the time, not stopping..

Do these debug logs tell you anything?
https://gist.github.com/clemensg/1ac5ee8a8ea32acc9145c5aa8407aea5

I am analyzing the signals coming directly from the i.MX6Q, so this must
be a software problem, but I don't understand why it works for you, if
we use the same software.

Do you use any other patches on top of mainline and do you use the SDMA
scripts from the ROM?

Thanks,
Clemens