4.16 OMAP serial transmit corruption?

4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

Hi,

I'm not entirely sure what's going on, but I see corrupted characters
with the serial console on the OMAP4430 SDP board.  During boot,
everything seems fine, the problem appears to be userspace output.

For example, if I edit a file, then quit vi:

:q■■%■■B■■Z■root@omap-4430sdp:~#

The hexdump of that is:

00000000  1b 5b 32 35 3b 31 48 1b  5b 30 4b 3a 71 1b db db  |.[25;1H.[0K:q...|
                                                     ^^^^^
00000010  da 25 aa da 8a 42 b5 b4  05 5a fd 72 6f 6f 74 40  |.%...B...Z.root@|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000020  6f 6d 61 70 2d 34 34 33  30 73 64 70 3a 7e 23 20  |omap-4430sdp:~# |

This appears to come from these write calls in vi:

write(1, "\33[25;1H\33[0K:"..., 12)     = 12
write(1, "q"..., 1)                     = 1
write(1, "\33[1;1H\r\33[25;1H- kexec-test 1/9 11%\33[0K\33[1;1H"..., 44) = 44
write(1, "\33[25;1H\33[0K"..., 11)      = 11

It appears to be timing related, as stracing vi produces different output:

- k9■root@omap-4430sdp:~#

00000000  1b 5b 32 35 3b 31 48 1b  5b 30 4b 3a 71 1b 5b 31  |.[25;1H.[0K:q.[1|
00000010  3b 31 48 0d 1b 5b 32 35  3b 31 48 2d 20 6b 39 ff  |;1H..[25;1H- k9.|
                                                     ^^^^^
00000020  72 6f 6f 74 40 6f 6d 61  70 2d 34 34 33 30 73 64  |root@omap-4430sd|
00000030  70 3a 7e 23 20                                    |p:~# |

Similar, but more severe effects can be seen with "dmesg | less":

00000000  0d 72 6f 6f 74 40 6f 6d  61 70 2d 34 34 33 30 73  |.root@omap-4430s|
00000010  64 70 3a 7e 23 20 64 6d  65 73 67 20 7c 20 6c 65  |dp:~# dmesg | le|
00000020  73 73 1b 5b 4a 0d 0a 1b  5b 30 3b 30 48 1b 5b 4b  |ss.[J...[0;0H.[K|
00000030  0d 0a 1b 5b 4b 7e cd d4  a4 68 b4 b5 ca 35 52 da  |...[K~...h...5R.|
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000040  b4 b5 ca 35 52 da b4 b5  ca 35 52 da b4 b5 ca 35  |...5R....5R....5|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000050  52 da b4 b5 ca 35 52 da  b4 b5 ca 35 52 da b4 b5  |R....5R....5R...|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000060  ca 35 52 da b4 b5 ca 35  52 da b4 b5 ca 35 52 da  |.5R....5R....5R.|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000070  b4 b5 ca 35 52 da b4 b5  ca 35 52 da b4 b5 ca 35  |...5R....5R....5|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000080  52 da b4 b5 ca 35 52 da  b4 b5 ca 35 52 da b4 b5  |R....5R....5R...|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000090  ca 35 52 da b4 25 aa da  82 42 b5 b4 b5 6a b4 75  |.5R..%...B...j.u|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000a0  6a cd d1 85 b9 91 85 c9  91 81 4a b9 c1 d5 d1 6d  |j.........J....m|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000b0  da c1 6a 6d da c1 da 82  42 b5 b4 b5 4a ea eb 8b  |..jm....B...J...|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000c0  57 cb eb 16 12 2a cb ab  17 81 7a b9 81 82 a1 e5  |W....*....z.....|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000d0  cd a5 8d 85 b1 81 1a 41  55 81 82 c2 c1 6a 52 b4  |.......AU....jR.|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000e0  b4 b5 8a 2a cb ab 17 81  b2 95 c9 cd a5 bd b9 81  |...*............|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000f0  a2 72 8a b2 72 82 5a 02  42 92 b5 ad 01 c9 b5 ad  |.r..r.Z.B.......|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000100  b5 82 0d b9 0a c9 b5 b1  a5 b9 d5 e1 b9 7a c9 9d  |.............z..|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000110  b9 aa ad a5 02 42 3a 8d  8d 81 b2 95 c9 cd a5 bd  |.....B:.........|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000120  b9 81 a2 72 ba 72 a2 02  42 3a 35 35 2a 29 09 d2  |...r.r..B:55*)..|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000130  52 53 48 68 b4 b5 0a b2  02 9a d5 05 05 a9 ea cb  |RSHh............|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000140  0b 52 14 2e 2e 48 4c 9b  90 31 33 3a 33 30 3a 30  |.R...HL..13:30:0|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000150  39 20 42 53 54 20 32 30  31 38 0d 0a 1b 5b 4b 43  |9 BST 2018...[KC|
00000160  50 55 3a 20 41 52 4d 76  37 20 50 72 6f 63 65 73  |PU: ARMv7 Proces|

Since this uses a USB adapter (built onto the board) it could be
that there could be a bug in the driver for that rather than the
OMAP4430 SDP, but I've no way to check that hypothesis.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

Hi,

I'm not entirely sure what's going on, but I see corrupted characters
with the serial console on the OMAP4430 SDP board.  During boot,
everything seems fine, the problem appears to be userspace output.

For example, if I edit a file, then quit vi:

:q??%??B??Z?root at omap-4430sdp:~#

The hexdump of that is:

00000000  1b 5b 32 35 3b 31 48 1b  5b 30 4b 3a 71 1b db db  |.[25;1H.[0K:q...|
                                                     ^^^^^
00000010  da 25 aa da 8a 42 b5 b4  05 5a fd 72 6f 6f 74 40  |.%...B...Z.root@|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000020  6f 6d 61 70 2d 34 34 33  30 73 64 70 3a 7e 23 20  |omap-4430sdp:~# |

This appears to come from these write calls in vi:

write(1, "\33[25;1H\33[0K:"..., 12)     = 12
write(1, "q"..., 1)                     = 1
write(1, "\33[1;1H\r\33[25;1H- kexec-test 1/9 11%\33[0K\33[1;1H"..., 44) = 44
write(1, "\33[25;1H\33[0K"..., 11)      = 11

It appears to be timing related, as stracing vi produces different output:

- k9?root at omap-4430sdp:~#

00000000  1b 5b 32 35 3b 31 48 1b  5b 30 4b 3a 71 1b 5b 31  |.[25;1H.[0K:q.[1|
00000010  3b 31 48 0d 1b 5b 32 35  3b 31 48 2d 20 6b 39 ff  |;1H..[25;1H- k9.|
                                                     ^^^^^
00000020  72 6f 6f 74 40 6f 6d 61  70 2d 34 34 33 30 73 64  |root at omap-4430sd|
00000030  70 3a 7e 23 20                                    |p:~# |

Similar, but more severe effects can be seen with "dmesg | less":

00000000  0d 72 6f 6f 74 40 6f 6d  61 70 2d 34 34 33 30 73  |.root at omap-4430s|
00000010  64 70 3a 7e 23 20 64 6d  65 73 67 20 7c 20 6c 65  |dp:~# dmesg | le|
00000020  73 73 1b 5b 4a 0d 0a 1b  5b 30 3b 30 48 1b 5b 4b  |ss.[J...[0;0H.[K|
00000030  0d 0a 1b 5b 4b 7e cd d4  a4 68 b4 b5 ca 35 52 da  |...[K~...h...5R.|
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000040  b4 b5 ca 35 52 da b4 b5  ca 35 52 da b4 b5 ca 35  |...5R....5R....5|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000050  52 da b4 b5 ca 35 52 da  b4 b5 ca 35 52 da b4 b5  |R....5R....5R...|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000060  ca 35 52 da b4 b5 ca 35  52 da b4 b5 ca 35 52 da  |.5R....5R....5R.|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000070  b4 b5 ca 35 52 da b4 b5  ca 35 52 da b4 b5 ca 35  |...5R....5R....5|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000080  52 da b4 b5 ca 35 52 da  b4 b5 ca 35 52 da b4 b5  |R....5R....5R...|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000090  ca 35 52 da b4 25 aa da  82 42 b5 b4 b5 6a b4 75  |.5R..%...B...j.u|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000a0  6a cd d1 85 b9 91 85 c9  91 81 4a b9 c1 d5 d1 6d  |j.........J....m|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000b0  da c1 6a 6d da c1 da 82  42 b5 b4 b5 4a ea eb 8b  |..jm....B...J...|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000c0  57 cb eb 16 12 2a cb ab  17 81 7a b9 81 82 a1 e5  |W....*....z.....|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000d0  cd a5 8d 85 b1 81 1a 41  55 81 82 c2 c1 6a 52 b4  |.......AU....jR.|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000e0  b4 b5 8a 2a cb ab 17 81  b2 95 c9 cd a5 bd b9 81  |...*............|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
000000f0  a2 72 8a b2 72 82 5a 02  42 92 b5 ad 01 c9 b5 ad  |.r..r.Z.B.......|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000100  b5 82 0d b9 0a c9 b5 b1  a5 b9 d5 e1 b9 7a c9 9d  |.............z..|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000110  b9 aa ad a5 02 42 3a 8d  8d 81 b2 95 c9 cd a5 bd  |.....B:.........|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000120  b9 81 a2 72 ba 72 a2 02  42 3a 35 35 2a 29 09 d2  |...r.r..B:55*)..|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000130  52 53 48 68 b4 b5 0a b2  02 9a d5 05 05 a9 ea cb  |RSHh............|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000140  0b 52 14 2e 2e 48 4c 9b  90 31 33 3a 33 30 3a 30  |.R...HL..13:30:0|
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
00000150  39 20 42 53 54 20 32 30  31 38 0d 0a 1b 5b 4b 43  |9 BST 2018...[KC|
00000160  50 55 3a 20 41 52 4d 76  37 20 50 72 6f 63 65 73  |PU: ARMv7 Proces|

Since this uses a USB adapter (built onto the board) it could be
that there could be a bug in the driver for that rather than the
OMAP4430 SDP, but I've no way to check that hypothesis.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: 4.16 OMAP serial transmit corruption?

[Tony Lindgren]

* Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> Hi,
> 
> I'm not entirely sure what's going on, but I see corrupted characters
> with the serial console on the OMAP4430 SDP board.  During boot,
> everything seems fine, the problem appears to be userspace output.
> 
> For example, if I edit a file, then quit vi:
> 
> :q■■%■■B■■Z■root@omap-4430sdp:~#

I don't think I've seen that one. What I've seen few times is
typing a key on the serial console echoing back the previous
character typed while the new character won't get displayed
until hitting keyboard again. Only rebooting the device seems
to solve this. This is with 4430 ES2.3 revision.

I wonder if we're missing some parts of errata i202 handling
in omap_8250_mdr1_errataset()?

Also, I'm seeing an issue where the UARTs won't idle on init
with 8250_omap driver if connected to the wl12xx bluetooth port
unless I write some data to the port first. It does not seem
to be related to the rts/cts lines being wired as I've tested
muxing them out of the way.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Tony Lindgren]

* Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> Hi,
> 
> I'm not entirely sure what's going on, but I see corrupted characters
> with the serial console on the OMAP4430 SDP board.  During boot,
> everything seems fine, the problem appears to be userspace output.
> 
> For example, if I edit a file, then quit vi:
> 
> :q??%??B??Z?root at omap-4430sdp:~#

I don't think I've seen that one. What I've seen few times is
typing a key on the serial console echoing back the previous
character typed while the new character won't get displayed
until hitting keyboard again. Only rebooting the device seems
to solve this. This is with 4430 ES2.3 revision.

I wonder if we're missing some parts of errata i202 handling
in omap_8250_mdr1_errataset()?

Also, I'm seeing an issue where the UARTs won't idle on init
with 8250_omap driver if connected to the wl12xx bluetooth port
unless I write some data to the port first. It does not seem
to be related to the rts/cts lines being wired as I've tested
muxing them out of the way.

Regards,

Tony

Re: 4.16 OMAP serial transmit corruption?

[Tony Lindgren]

* Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> Since this uses a USB adapter (built onto the board) it could be
> that there could be a bug in the driver for that rather than the
> OMAP4430 SDP, but I've no way to check that hypothesis.

Does it go away when you do a warm reboot of the sdp? Then
it should not be related to the USB iff the ftdi chip is bus
powered by VBUS.

Regards,

Tony

4.16 OMAP serial transmit corruption?

[Tony Lindgren]

* Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> Since this uses a USB adapter (built onto the board) it could be
> that there could be a bug in the driver for that rather than the
> OMAP4430 SDP, but I've no way to check that hypothesis.

Does it go away when you do a warm reboot of the sdp? Then
it should not be related to the USB iff the ftdi chip is bus
powered by VBUS.

Regards,

Tony

Re: 4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Mon, Apr 16, 2018 at 08:52:59AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > Since this uses a USB adapter (built onto the board) it could be
> > that there could be a bug in the driver for that rather than the
> > OMAP4430 SDP, but I've no way to check that hypothesis.
> 
> Does it go away when you do a warm reboot of the sdp? Then
> it should not be related to the USB iff the ftdi chip is bus
> powered by VBUS.

Yes, the FTDI chip is bus powered.

I booted, ran vi, quit vi, saw corruption, typed reboot, waited for
it to reboot, ran vi, quit vi, and still saw corruption.  So the
reboot seems to have had no effect.

I don't see it with other USB serial consoles on other machines...
I have two of these using the same FTDI chipset:

Bus 001 Device 021: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 001 Device 020: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC

Device 20 is the SDP board, and device 21 is a ZII board.  Both use
port 2 on the quad ftdi device.  The serial console on the ZII board
is fine, so that seems to rule out the FTDI driver / FTDI hardware.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Mon, Apr 16, 2018 at 08:52:59AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > Since this uses a USB adapter (built onto the board) it could be
> > that there could be a bug in the driver for that rather than the
> > OMAP4430 SDP, but I've no way to check that hypothesis.
> 
> Does it go away when you do a warm reboot of the sdp? Then
> it should not be related to the USB iff the ftdi chip is bus
> powered by VBUS.

Yes, the FTDI chip is bus powered.

I booted, ran vi, quit vi, saw corruption, typed reboot, waited for
it to reboot, ran vi, quit vi, and still saw corruption.  So the
reboot seems to have had no effect.

I don't see it with other USB serial consoles on other machines...
I have two of these using the same FTDI chipset:

Bus 001 Device 021: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC
Bus 001 Device 020: ID 0403:6011 Future Technology Devices International, Ltd FT4232H Quad HS USB-UART/FIFO IC

Device 20 is the SDP board, and device 21 is a ZII board.  Both use
port 2 on the quad ftdi device.  The serial console on the ZII board
is fine, so that seems to rule out the FTDI driver / FTDI hardware.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: 4.16 OMAP serial transmit corruption?

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [180416 15:47]:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > Hi,
> > 
> > I'm not entirely sure what's going on, but I see corrupted characters
> > with the serial console on the OMAP4430 SDP board.  During boot,
> > everything seems fine, the problem appears to be userspace output.
> > 
> > For example, if I edit a file, then quit vi:
> > 
> > :q■■%■■B■■Z■root@omap-4430sdp:~#
> 
> I don't think I've seen that one. What I've seen few times is
> typing a key on the serial console echoing back the previous
> character typed while the new character won't get displayed
> until hitting keyboard again. Only rebooting the device seems
> to solve this. This is with 4430 ES2.3 revision.
> 
> I wonder if we're missing some parts of errata i202 handling
> in omap_8250_mdr1_errataset()?

Trying to see what we might be missing in 8250_omap compared
to omap-serial, your description sounds like it could be similar
issue compared to what got fixed for omap-serial earlier with
commit 0ba5f66836c9 ("tty: serial: OMAP: use a 1-byte RX FIFO
threshold in PIO mode").

> Also, I'm seeing an issue where the UARTs won't idle on init
> with 8250_omap driver if connected to the wl12xx bluetooth port
> unless I write some data to the port first. It does not seem
> to be related to the rts/cts lines being wired as I've tested
> muxing them out of the way.

I'll try to debug this one a bit.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [180416 15:47]:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > Hi,
> > 
> > I'm not entirely sure what's going on, but I see corrupted characters
> > with the serial console on the OMAP4430 SDP board.  During boot,
> > everything seems fine, the problem appears to be userspace output.
> > 
> > For example, if I edit a file, then quit vi:
> > 
> > :q??%??B??Z?root at omap-4430sdp:~#
> 
> I don't think I've seen that one. What I've seen few times is
> typing a key on the serial console echoing back the previous
> character typed while the new character won't get displayed
> until hitting keyboard again. Only rebooting the device seems
> to solve this. This is with 4430 ES2.3 revision.
> 
> I wonder if we're missing some parts of errata i202 handling
> in omap_8250_mdr1_errataset()?

Trying to see what we might be missing in 8250_omap compared
to omap-serial, your description sounds like it could be similar
issue compared to what got fixed for omap-serial earlier with
commit 0ba5f66836c9 ("tty: serial: OMAP: use a 1-byte RX FIFO
threshold in PIO mode").

> Also, I'm seeing an issue where the UARTs won't idle on init
> with 8250_omap driver if connected to the wl12xx bluetooth port
> unless I write some data to the port first. It does not seem
> to be related to the rts/cts lines being wired as I've tested
> muxing them out of the way.

I'll try to debug this one a bit.

Regards,

Tony

Re: 4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Mon, Apr 16, 2018 at 02:26:53PM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [180416 15:47]:
> > * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > > Hi,
> > > 
> > > I'm not entirely sure what's going on, but I see corrupted characters
> > > with the serial console on the OMAP4430 SDP board.  During boot,
> > > everything seems fine, the problem appears to be userspace output.
> > > 
> > > For example, if I edit a file, then quit vi:
> > > 
> > > :q■■%■■B■■Z■root@omap-4430sdp:~#
> > 
> > I don't think I've seen that one. What I've seen few times is
> > typing a key on the serial console echoing back the previous
> > character typed while the new character won't get displayed
> > until hitting keyboard again. Only rebooting the device seems
> > to solve this. This is with 4430 ES2.3 revision.
> > 
> > I wonder if we're missing some parts of errata i202 handling
> > in omap_8250_mdr1_errataset()?
> 
> Trying to see what we might be missing in 8250_omap compared
> to omap-serial, your description sounds like it could be similar
> issue compared to what got fixed for omap-serial earlier with
> commit 0ba5f66836c9 ("tty: serial: OMAP: use a 1-byte RX FIFO
> threshold in PIO mode").

... except this is the transmit side, not the receive side.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Mon, Apr 16, 2018 at 02:26:53PM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [180416 15:47]:
> > * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > > Hi,
> > > 
> > > I'm not entirely sure what's going on, but I see corrupted characters
> > > with the serial console on the OMAP4430 SDP board.  During boot,
> > > everything seems fine, the problem appears to be userspace output.
> > > 
> > > For example, if I edit a file, then quit vi:
> > > 
> > > :q??%??B??Z?root at omap-4430sdp:~#
> > 
> > I don't think I've seen that one. What I've seen few times is
> > typing a key on the serial console echoing back the previous
> > character typed while the new character won't get displayed
> > until hitting keyboard again. Only rebooting the device seems
> > to solve this. This is with 4430 ES2.3 revision.
> > 
> > I wonder if we're missing some parts of errata i202 handling
> > in omap_8250_mdr1_errataset()?
> 
> Trying to see what we might be missing in 8250_omap compared
> to omap-serial, your description sounds like it could be similar
> issue compared to what got fixed for omap-serial earlier with
> commit 0ba5f66836c9 ("tty: serial: OMAP: use a 1-byte RX FIFO
> threshold in PIO mode").

... except this is the transmit side, not the receive side.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: 4.16 OMAP serial transmit corruption?

[Vignesh R]

On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>> Hi,
>>
>> I'm not entirely sure what's going on, but I see corrupted characters
>> with the serial console on the OMAP4430 SDP board.  During boot,
>> everything seems fine, the problem appears to be userspace output.
>>
>> For example, if I edit a file, then quit vi:
>>
>> :q■■%■■B■■Z■root@omap-4430sdp:~#
> 
> I don't think I've seen that one. What I've seen few times is
> typing a key on the serial console echoing back the previous
> character typed while the new character won't get displayed
> until hitting keyboard again. Only rebooting the device seems
> to solve this. This is with 4430 ES2.3 revision.
> 
> I wonder if we're missing some parts of errata i202 handling
> in omap_8250_mdr1_errataset()?
> 
> Also, I'm seeing an issue where the UARTs won't idle on init
> with 8250_omap driver if connected to the wl12xx bluetooth port
> unless I write some data to the port first. It does not seem
> to be related to the rts/cts lines being wired as I've tested
> muxing them out of the way.
> 

If this instance of UART is using DMA then it might be due an errata
worked around in AM33/AM43/DRA7:
https://patchwork.kernel.org/patch/6784331/


-- 
Regards
Vignesh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Vignesh R]

On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>> Hi,
>>
>> I'm not entirely sure what's going on, but I see corrupted characters
>> with the serial console on the OMAP4430 SDP board.  During boot,
>> everything seems fine, the problem appears to be userspace output.
>>
>> For example, if I edit a file, then quit vi:
>>
>> :q??%??B??Z?root at omap-4430sdp:~#
> 
> I don't think I've seen that one. What I've seen few times is
> typing a key on the serial console echoing back the previous
> character typed while the new character won't get displayed
> until hitting keyboard again. Only rebooting the device seems
> to solve this. This is with 4430 ES2.3 revision.
> 
> I wonder if we're missing some parts of errata i202 handling
> in omap_8250_mdr1_errataset()?
> 
> Also, I'm seeing an issue where the UARTs won't idle on init
> with 8250_omap driver if connected to the wl12xx bluetooth port
> unless I write some data to the port first. It does not seem
> to be related to the rts/cts lines being wired as I've tested
> muxing them out of the way.
> 

If this instance of UART is using DMA then it might be due an errata
worked around in AM33/AM43/DRA7:
https://patchwork.kernel.org/patch/6784331/


-- 
Regards
Vignesh

Re: 4.16 OMAP serial transmit corruption?

[Tony Lindgren]

* Vignesh R <vigneshr@ti.com> [180417 09:21]:
> On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > Also, I'm seeing an issue where the UARTs won't idle on init
> > with 8250_omap driver if connected to the wl12xx bluetooth port
> > unless I write some data to the port first. It does not seem
> > to be related to the rts/cts lines being wired as I've tested
> > muxing them out of the way.
> 
> If this instance of UART is using DMA then it might be due an errata
> worked around in AM33/AM43/DRA7:
> https://patchwork.kernel.org/patch/6784331/

It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
seem to help with the reset. Also disabling DMA does not seem
to help. So far the only way to clear it seems to be to write
a character (TX) on the device. Then things work just fine
even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
this more at some point.

Regards,

Tony

4.16 OMAP serial transmit corruption?

[Tony Lindgren]

* Vignesh R <vigneshr@ti.com> [180417 09:21]:
> On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > Also, I'm seeing an issue where the UARTs won't idle on init
> > with 8250_omap driver if connected to the wl12xx bluetooth port
> > unless I write some data to the port first. It does not seem
> > to be related to the rts/cts lines being wired as I've tested
> > muxing them out of the way.
> 
> If this instance of UART is using DMA then it might be due an errata
> worked around in AM33/AM43/DRA7:
> https://patchwork.kernel.org/patch/6784331/

It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
seem to help with the reset. Also disabling DMA does not seem
to help. So far the only way to clear it seems to be to write
a character (TX) on the device. Then things work just fine
even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
this more at some point.

Regards,

Tony

Re: 4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Tue, Apr 17, 2018 at 10:31:35AM -0700, Tony Lindgren wrote:
> * Vignesh R <vigneshr@ti.com> [180417 09:21]:
> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > > Also, I'm seeing an issue where the UARTs won't idle on init
> > > with 8250_omap driver if connected to the wl12xx bluetooth port
> > > unless I write some data to the port first. It does not seem
> > > to be related to the rts/cts lines being wired as I've tested
> > > muxing them out of the way.
> > 
> > If this instance of UART is using DMA then it might be due an errata
> > worked around in AM33/AM43/DRA7:
> > https://patchwork.kernel.org/patch/6784331/
> 
> It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
> seem to help with the reset. Also disabling DMA does not seem
> to help. So far the only way to clear it seems to be to write
> a character (TX) on the device. Then things work just fine
> even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
> this more at some point.

Classic case of thread hijack.  So, Tony's idle problem gets more
attention on _my_ thread than _my_ issue about TX corruption, yea,
that's fair...  Come on guys, what about my problem, which is the
subject of this thread?

I don't have CONFIG_SERIAL_8250_DMA set, so DMA can't be the issue.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Tue, Apr 17, 2018 at 10:31:35AM -0700, Tony Lindgren wrote:
> * Vignesh R <vigneshr@ti.com> [180417 09:21]:
> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > > Also, I'm seeing an issue where the UARTs won't idle on init
> > > with 8250_omap driver if connected to the wl12xx bluetooth port
> > > unless I write some data to the port first. It does not seem
> > > to be related to the rts/cts lines being wired as I've tested
> > > muxing them out of the way.
> > 
> > If this instance of UART is using DMA then it might be due an errata
> > worked around in AM33/AM43/DRA7:
> > https://patchwork.kernel.org/patch/6784331/
> 
> It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
> seem to help with the reset. Also disabling DMA does not seem
> to help. So far the only way to clear it seems to be to write
> a character (TX) on the device. Then things work just fine
> even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
> this more at some point.

Classic case of thread hijack.  So, Tony's idle problem gets more
attention on _my_ thread than _my_ issue about TX corruption, yea,
that's fair...  Come on guys, what about my problem, which is the
subject of this thread?

I don't have CONFIG_SERIAL_8250_DMA set, so DMA can't be the issue.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: 4.16 OMAP serial transmit corruption?

[Tony Lindgren]

* Russell King - ARM Linux <linux@armlinux.org.uk> [180417 22:12]:
> On Tue, Apr 17, 2018 at 10:31:35AM -0700, Tony Lindgren wrote:
> > * Vignesh R <vigneshr@ti.com> [180417 09:21]:
> > > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > > > Also, I'm seeing an issue where the UARTs won't idle on init
> > > > with 8250_omap driver if connected to the wl12xx bluetooth port
> > > > unless I write some data to the port first. It does not seem
> > > > to be related to the rts/cts lines being wired as I've tested
> > > > muxing them out of the way.
> > > 
> > > If this instance of UART is using DMA then it might be due an errata
> > > worked around in AM33/AM43/DRA7:
> > > https://patchwork.kernel.org/patch/6784331/
> > 
> > It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
> > seem to help with the reset. Also disabling DMA does not seem
> > to help. So far the only way to clear it seems to be to write
> > a character (TX) on the device. Then things work just fine
> > even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
> > this more at some point.
> 
> Classic case of thread hijack.  So, Tony's idle problem gets more
> attention on _my_ thread than _my_ issue about TX corruption, yea,
> that's fair...  Come on guys, what about my problem, which is the
> subject of this thread?

Just trying to brainstorm what all can go wrong still :) OK so
it's not DMA then.

> I don't have CONFIG_SERIAL_8250_DMA set, so DMA can't be the issue.

Is this happening also with v4.16 or with v4.17-rc1?

So you just edit something in vi and and on exit it happens?
Not happening here for me..

Regards,

Tony

4.16 OMAP serial transmit corruption?

[Tony Lindgren]

* Russell King - ARM Linux <linux@armlinux.org.uk> [180417 22:12]:
> On Tue, Apr 17, 2018 at 10:31:35AM -0700, Tony Lindgren wrote:
> > * Vignesh R <vigneshr@ti.com> [180417 09:21]:
> > > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > > > Also, I'm seeing an issue where the UARTs won't idle on init
> > > > with 8250_omap driver if connected to the wl12xx bluetooth port
> > > > unless I write some data to the port first. It does not seem
> > > > to be related to the rts/cts lines being wired as I've tested
> > > > muxing them out of the way.
> > > 
> > > If this instance of UART is using DMA then it might be due an errata
> > > worked around in AM33/AM43/DRA7:
> > > https://patchwork.kernel.org/patch/6784331/
> > 
> > It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
> > seem to help with the reset. Also disabling DMA does not seem
> > to help. So far the only way to clear it seems to be to write
> > a character (TX) on the device. Then things work just fine
> > even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
> > this more at some point.
> 
> Classic case of thread hijack.  So, Tony's idle problem gets more
> attention on _my_ thread than _my_ issue about TX corruption, yea,
> that's fair...  Come on guys, what about my problem, which is the
> subject of this thread?

Just trying to brainstorm what all can go wrong still :) OK so
it's not DMA then.

> I don't have CONFIG_SERIAL_8250_DMA set, so DMA can't be the issue.

Is this happening also with v4.16 or with v4.17-rc1?

So you just edit something in vi and and on exit it happens?
Not happening here for me..

Regards,

Tony

Re: 4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Tue, Apr 17, 2018 at 05:57:48PM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180417 22:12]:
> > On Tue, Apr 17, 2018 at 10:31:35AM -0700, Tony Lindgren wrote:
> > > * Vignesh R <vigneshr@ti.com> [180417 09:21]:
> > > > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > > > > Also, I'm seeing an issue where the UARTs won't idle on init
> > > > > with 8250_omap driver if connected to the wl12xx bluetooth port
> > > > > unless I write some data to the port first. It does not seem
> > > > > to be related to the rts/cts lines being wired as I've tested
> > > > > muxing them out of the way.
> > > > 
> > > > If this instance of UART is using DMA then it might be due an errata
> > > > worked around in AM33/AM43/DRA7:
> > > > https://patchwork.kernel.org/patch/6784331/
> > > 
> > > It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
> > > seem to help with the reset. Also disabling DMA does not seem
> > > to help. So far the only way to clear it seems to be to write
> > > a character (TX) on the device. Then things work just fine
> > > even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
> > > this more at some point.
> > 
> > Classic case of thread hijack.  So, Tony's idle problem gets more
> > attention on _my_ thread than _my_ issue about TX corruption, yea,
> > that's fair...  Come on guys, what about my problem, which is the
> > subject of this thread?
> 
> Just trying to brainstorm what all can go wrong still :) OK so
> it's not DMA then.
> 
> > I don't have CONFIG_SERIAL_8250_DMA set, so DMA can't be the issue.
> 
> Is this happening also with v4.16 or with v4.17-rc1?

4.16

> So you just edit something in vi and and on exit it happens?
> Not happening here for me..

Or run less, eg, dmesg | less or less /some/file.  It doesn't happen
with cat though.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Tue, Apr 17, 2018 at 05:57:48PM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [180417 22:12]:
> > On Tue, Apr 17, 2018 at 10:31:35AM -0700, Tony Lindgren wrote:
> > > * Vignesh R <vigneshr@ti.com> [180417 09:21]:
> > > > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > > > > Also, I'm seeing an issue where the UARTs won't idle on init
> > > > > with 8250_omap driver if connected to the wl12xx bluetooth port
> > > > > unless I write some data to the port first. It does not seem
> > > > > to be related to the rts/cts lines being wired as I've tested
> > > > > muxing them out of the way.
> > > > 
> > > > If this instance of UART is using DMA then it might be due an errata
> > > > worked around in AM33/AM43/DRA7:
> > > > https://patchwork.kernel.org/patch/6784331/
> > > 
> > > It sure sounds similar but UART_ERRATA_CLOCK_DISABLE does not
> > > seem to help with the reset. Also disabling DMA does not seem
> > > to help. So far the only way to clear it seems to be to write
> > > a character (TX) on the device. Then things work just fine
> > > even without UART_ERRATA_CLOCK_DISABLE set. I'll try to debug
> > > this more at some point.
> > 
> > Classic case of thread hijack.  So, Tony's idle problem gets more
> > attention on _my_ thread than _my_ issue about TX corruption, yea,
> > that's fair...  Come on guys, what about my problem, which is the
> > subject of this thread?
> 
> Just trying to brainstorm what all can go wrong still :) OK so
> it's not DMA then.
> 
> > I don't have CONFIG_SERIAL_8250_DMA set, so DMA can't be the issue.
> 
> Is this happening also with v4.16 or with v4.17-rc1?

4.16

> So you just edit something in vi and and on exit it happens?
> Not happening here for me..

Or run less, eg, dmesg | less or less /some/file.  It doesn't happen
with cat though.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: 4.16 OMAP serial transmit corruption?

[Vignesh R]

On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> 
> 
> On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
>> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>>> Hi,
>>>
>>> I'm not entirely sure what's going on, but I see corrupted characters
>>> with the serial console on the OMAP4430 SDP board.  During boot,
>>> everything seems fine, the problem appears to be userspace output.
>>>
>>> For example, if I edit a file, then quit vi:
>>>
>>> :q■■%■■B■■Z■root@omap-4430sdp:~#
>>
>> I don't think I've seen that one. What I've seen few times is
>> typing a key on the serial console echoing back the previous
>> character typed while the new character won't get displayed
>> until hitting keyboard again. Only rebooting the device seems
>> to solve this. This is with 4430 ES2.3 revision.
>>
>> I wonder if we're missing some parts of errata i202 handling
>> in omap_8250_mdr1_errataset()?
>>

I wonder if the extra read of MDR1 register at the beginning of
omap_8250_mdr1_errataset() compared to omap-serial is the issue.
errata i202 says access to MDR1 can cause data corruption. 
Assuming both reads and writes can cause glitch then, that read
is not following advisory:

I don't have SDP board so, could you verify if below diff helps:


diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 6aaa84355fd1..8ab9d0a1b1eb 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
                                     struct omap8250_priv *priv)
 {
        u8 timeout = 255;
-       u8 old_mdr1;
-
-       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
-       if (old_mdr1 == priv->mdr1)
-               return;
 
        serial_out(up, UART_OMAP_MDR1, priv->mdr1);
        udelay(2);



-- 
Regards
Vignesh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Vignesh R]

On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> 
> 
> On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
>> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>>> Hi,
>>>
>>> I'm not entirely sure what's going on, but I see corrupted characters
>>> with the serial console on the OMAP4430 SDP board.  During boot,
>>> everything seems fine, the problem appears to be userspace output.
>>>
>>> For example, if I edit a file, then quit vi:
>>>
>>> :q??%??B??Z?root at omap-4430sdp:~#
>>
>> I don't think I've seen that one. What I've seen few times is
>> typing a key on the serial console echoing back the previous
>> character typed while the new character won't get displayed
>> until hitting keyboard again. Only rebooting the device seems
>> to solve this. This is with 4430 ES2.3 revision.
>>
>> I wonder if we're missing some parts of errata i202 handling
>> in omap_8250_mdr1_errataset()?
>>

I wonder if the extra read of MDR1 register at the beginning of
omap_8250_mdr1_errataset() compared to omap-serial is the issue.
errata i202 says access to MDR1 can cause data corruption. 
Assuming both reads and writes can cause glitch then, that read
is not following advisory:

I don't have SDP board so, could you verify if below diff helps:


diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 6aaa84355fd1..8ab9d0a1b1eb 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
                                     struct omap8250_priv *priv)
 {
        u8 timeout = 255;
-       u8 old_mdr1;
-
-       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
-       if (old_mdr1 == priv->mdr1)
-               return;
 
        serial_out(up, UART_OMAP_MDR1, priv->mdr1);
        udelay(2);



-- 
Regards
Vignesh

Re: 4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> 
> 
> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> > 
> > 
> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> >>> Hi,
> >>>
> >>> I'm not entirely sure what's going on, but I see corrupted characters
> >>> with the serial console on the OMAP4430 SDP board.  During boot,
> >>> everything seems fine, the problem appears to be userspace output.
> >>>
> >>> For example, if I edit a file, then quit vi:
> >>>
> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
> >>
> >> I don't think I've seen that one. What I've seen few times is
> >> typing a key on the serial console echoing back the previous
> >> character typed while the new character won't get displayed
> >> until hitting keyboard again. Only rebooting the device seems
> >> to solve this. This is with 4430 ES2.3 revision.
> >>
> >> I wonder if we're missing some parts of errata i202 handling
> >> in omap_8250_mdr1_errataset()?
> >>
> 
> I wonder if the extra read of MDR1 register at the beginning of
> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> errata i202 says access to MDR1 can cause data corruption. 
> Assuming both reads and writes can cause glitch then, that read
> is not following advisory:
> 
> I don't have SDP board so, could you verify if below diff helps:
> 
> 
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
>                                      struct omap8250_priv *priv)
>  {
>         u8 timeout = 255;
> -       u8 old_mdr1;
> -
> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> -       if (old_mdr1 == priv->mdr1)
> -               return;
>  
>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
>         udelay(2);

That doesn't appear to help.

Looking at the bitstream and comparing what should have been sent with
what was sent, there appears to be some correlation between the two.
It looks like the FTDI is not properly synchronised to the bitstream
coming from the OMAP4430.

Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
improve the issue, but not completely solve it.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> 
> 
> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> > 
> > 
> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> >>> Hi,
> >>>
> >>> I'm not entirely sure what's going on, but I see corrupted characters
> >>> with the serial console on the OMAP4430 SDP board.  During boot,
> >>> everything seems fine, the problem appears to be userspace output.
> >>>
> >>> For example, if I edit a file, then quit vi:
> >>>
> >>> :q??%??B??Z?root at omap-4430sdp:~#
> >>
> >> I don't think I've seen that one. What I've seen few times is
> >> typing a key on the serial console echoing back the previous
> >> character typed while the new character won't get displayed
> >> until hitting keyboard again. Only rebooting the device seems
> >> to solve this. This is with 4430 ES2.3 revision.
> >>
> >> I wonder if we're missing some parts of errata i202 handling
> >> in omap_8250_mdr1_errataset()?
> >>
> 
> I wonder if the extra read of MDR1 register at the beginning of
> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> errata i202 says access to MDR1 can cause data corruption. 
> Assuming both reads and writes can cause glitch then, that read
> is not following advisory:
> 
> I don't have SDP board so, could you verify if below diff helps:
> 
> 
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
>                                      struct omap8250_priv *priv)
>  {
>         u8 timeout = 255;
> -       u8 old_mdr1;
> -
> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> -       if (old_mdr1 == priv->mdr1)
> -               return;
>  
>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
>         udelay(2);

That doesn't appear to help.

Looking at the bitstream and comparing what should have been sent with
what was sent, there appears to be some correlation between the two.
It looks like the FTDI is not properly synchronised to the bitstream
coming from the OMAP4430.

Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
improve the issue, but not completely solve it.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: 4.16 OMAP serial transmit corruption?

[Michael Nazzareno Trimarchi]

Hi

On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
>>
>>
>> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
>> >
>> >
>> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
>> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>> >>> Hi,
>> >>>
>> >>> I'm not entirely sure what's going on, but I see corrupted characters
>> >>> with the serial console on the OMAP4430 SDP board.  During boot,
>> >>> everything seems fine, the problem appears to be userspace output.
>> >>>
>> >>> For example, if I edit a file, then quit vi:
>> >>>
>> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
>> >>
>> >> I don't think I've seen that one. What I've seen few times is
>> >> typing a key on the serial console echoing back the previous
>> >> character typed while the new character won't get displayed
>> >> until hitting keyboard again. Only rebooting the device seems
>> >> to solve this. This is with 4430 ES2.3 revision.
>> >>
>> >> I wonder if we're missing some parts of errata i202 handling
>> >> in omap_8250_mdr1_errataset()?
>> >>
>>
>> I wonder if the extra read of MDR1 register at the beginning of
>> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
>> errata i202 says access to MDR1 can cause data corruption.
>> Assuming both reads and writes can cause glitch then, that read
>> is not following advisory:
>>
>> I don't have SDP board so, could you verify if below diff helps:
>>
>>
>> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
>> index 6aaa84355fd1..8ab9d0a1b1eb 100644
>> --- a/drivers/tty/serial/8250/8250_omap.c
>> +++ b/drivers/tty/serial/8250/8250_omap.c
>> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
>>                                      struct omap8250_priv *priv)
>>  {
>>         u8 timeout = 255;
>> -       u8 old_mdr1;
>> -
>> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
>> -       if (old_mdr1 == priv->mdr1)
>> -               return;
>>
>>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
>>         udelay(2);
>
> That doesn't appear to help.
>
> Looking at the bitstream and comparing what should have been sent with
> what was sent, there appears to be some correlation between the two.
> It looks like the FTDI is not properly synchronised to the bitstream
> coming from the OMAP4430.
>
> Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> improve the issue, but not completely solve it.

Are you sure about clock error above some tollerance?

>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Michael Nazzareno Trimarchi]

Hi

On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
>>
>>
>> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
>> >
>> >
>> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
>> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>> >>> Hi,
>> >>>
>> >>> I'm not entirely sure what's going on, but I see corrupted characters
>> >>> with the serial console on the OMAP4430 SDP board.  During boot,
>> >>> everything seems fine, the problem appears to be userspace output.
>> >>>
>> >>> For example, if I edit a file, then quit vi:
>> >>>
>> >>> :q??%??B??Z?root at omap-4430sdp:~#
>> >>
>> >> I don't think I've seen that one. What I've seen few times is
>> >> typing a key on the serial console echoing back the previous
>> >> character typed while the new character won't get displayed
>> >> until hitting keyboard again. Only rebooting the device seems
>> >> to solve this. This is with 4430 ES2.3 revision.
>> >>
>> >> I wonder if we're missing some parts of errata i202 handling
>> >> in omap_8250_mdr1_errataset()?
>> >>
>>
>> I wonder if the extra read of MDR1 register at the beginning of
>> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
>> errata i202 says access to MDR1 can cause data corruption.
>> Assuming both reads and writes can cause glitch then, that read
>> is not following advisory:
>>
>> I don't have SDP board so, could you verify if below diff helps:
>>
>>
>> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
>> index 6aaa84355fd1..8ab9d0a1b1eb 100644
>> --- a/drivers/tty/serial/8250/8250_omap.c
>> +++ b/drivers/tty/serial/8250/8250_omap.c
>> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
>>                                      struct omap8250_priv *priv)
>>  {
>>         u8 timeout = 255;
>> -       u8 old_mdr1;
>> -
>> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
>> -       if (old_mdr1 == priv->mdr1)
>> -               return;
>>
>>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
>>         udelay(2);
>
> That doesn't appear to help.
>
> Looking at the bitstream and comparing what should have been sent with
> what was sent, there appears to be some correlation between the two.
> It looks like the FTDI is not properly synchronised to the bitstream
> coming from the OMAP4430.
>
> Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> improve the issue, but not completely solve it.

Are you sure about clock error above some tollerance?

>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

Re: 4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> >>
> >>
> >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> >> >
> >> >
> >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> >> >>> Hi,
> >> >>>
> >> >>> I'm not entirely sure what's going on, but I see corrupted characters
> >> >>> with the serial console on the OMAP4430 SDP board.  During boot,
> >> >>> everything seems fine, the problem appears to be userspace output.
> >> >>>
> >> >>> For example, if I edit a file, then quit vi:
> >> >>>
> >> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
> >> >>
> >> >> I don't think I've seen that one. What I've seen few times is
> >> >> typing a key on the serial console echoing back the previous
> >> >> character typed while the new character won't get displayed
> >> >> until hitting keyboard again. Only rebooting the device seems
> >> >> to solve this. This is with 4430 ES2.3 revision.
> >> >>
> >> >> I wonder if we're missing some parts of errata i202 handling
> >> >> in omap_8250_mdr1_errataset()?
> >> >>
> >>
> >> I wonder if the extra read of MDR1 register at the beginning of
> >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> >> errata i202 says access to MDR1 can cause data corruption.
> >> Assuming both reads and writes can cause glitch then, that read
> >> is not following advisory:
> >>
> >> I don't have SDP board so, could you verify if below diff helps:
> >>
> >>
> >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> >> --- a/drivers/tty/serial/8250/8250_omap.c
> >> +++ b/drivers/tty/serial/8250/8250_omap.c
> >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
> >>                                      struct omap8250_priv *priv)
> >>  {
> >>         u8 timeout = 255;
> >> -       u8 old_mdr1;
> >> -
> >> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> >> -       if (old_mdr1 == priv->mdr1)
> >> -               return;
> >>
> >>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> >>         udelay(2);
> >
> > That doesn't appear to help.
> >
> > Looking at the bitstream and comparing what should have been sent with
> > what was sent, there appears to be some correlation between the two.
> > It looks like the FTDI is not properly synchronised to the bitstream
> > coming from the OMAP4430.
> >
> > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> > improve the issue, but not completely solve it.
> 
> Are you sure about clock error above some tollerance?

No idea at the moment.  Looking at the bitstream with a scope is the
next step, but it's not easy to do that with just two hands.  I also
need to find some way to trigger it reliably.

Another cause could be that the UART pin is being held high/low for
some reason (maybe a pinmux problem.)

Another interesting observation is that if I login over the network and
then do:

	while :; do :; done &
	while :; do :; done &

to occupy both CPUs, and then do:

	dmesg | less

on the console, the problem goes away.  If I only do one while loop,
the problem is present, but the corruption looks like it happens at a
different point in the serial stream.

This would seem to point the blame away from clocks or pinmux, and back
to power management issues.

I've also tried mimicking the less output with a stand-alone program,
and that doesn't exhibit the problem - I've tried with various initial
delays between program start and first output, but this doesn't seem
to have much effect.  So it seems to need rather precise timing.

stracing less does change where the corruption happens in the output,
which also suggests a timing related cause.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> >>
> >>
> >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> >> >
> >> >
> >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> >> >>> Hi,
> >> >>>
> >> >>> I'm not entirely sure what's going on, but I see corrupted characters
> >> >>> with the serial console on the OMAP4430 SDP board.  During boot,
> >> >>> everything seems fine, the problem appears to be userspace output.
> >> >>>
> >> >>> For example, if I edit a file, then quit vi:
> >> >>>
> >> >>> :q??%??B??Z?root at omap-4430sdp:~#
> >> >>
> >> >> I don't think I've seen that one. What I've seen few times is
> >> >> typing a key on the serial console echoing back the previous
> >> >> character typed while the new character won't get displayed
> >> >> until hitting keyboard again. Only rebooting the device seems
> >> >> to solve this. This is with 4430 ES2.3 revision.
> >> >>
> >> >> I wonder if we're missing some parts of errata i202 handling
> >> >> in omap_8250_mdr1_errataset()?
> >> >>
> >>
> >> I wonder if the extra read of MDR1 register at the beginning of
> >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> >> errata i202 says access to MDR1 can cause data corruption.
> >> Assuming both reads and writes can cause glitch then, that read
> >> is not following advisory:
> >>
> >> I don't have SDP board so, could you verify if below diff helps:
> >>
> >>
> >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> >> --- a/drivers/tty/serial/8250/8250_omap.c
> >> +++ b/drivers/tty/serial/8250/8250_omap.c
> >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
> >>                                      struct omap8250_priv *priv)
> >>  {
> >>         u8 timeout = 255;
> >> -       u8 old_mdr1;
> >> -
> >> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> >> -       if (old_mdr1 == priv->mdr1)
> >> -               return;
> >>
> >>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> >>         udelay(2);
> >
> > That doesn't appear to help.
> >
> > Looking at the bitstream and comparing what should have been sent with
> > what was sent, there appears to be some correlation between the two.
> > It looks like the FTDI is not properly synchronised to the bitstream
> > coming from the OMAP4430.
> >
> > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> > improve the issue, but not completely solve it.
> 
> Are you sure about clock error above some tollerance?

No idea at the moment.  Looking at the bitstream with a scope is the
next step, but it's not easy to do that with just two hands.  I also
need to find some way to trigger it reliably.

Another cause could be that the UART pin is being held high/low for
some reason (maybe a pinmux problem.)

Another interesting observation is that if I login over the network and
then do:

	while :; do :; done &
	while :; do :; done &

to occupy both CPUs, and then do:

	dmesg | less

on the console, the problem goes away.  If I only do one while loop,
the problem is present, but the corruption looks like it happens at a
different point in the serial stream.

This would seem to point the blame away from clocks or pinmux, and back
to power management issues.

I've also tried mimicking the less output with a stand-alone program,
and that doesn't exhibit the problem - I've tried with various initial
delays between program start and first output, but this doesn't seem
to have much effect.  So it seems to need rather precise timing.

stracing less does change where the corruption happens in the output,
which also suggests a timing related cause.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: 4.16 OMAP serial transmit corruption?

[Michael Nazzareno Trimarchi]

Hi

On Wed, Apr 18, 2018 at 1:00 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
>> <linux@armlinux.org.uk> wrote:
>> > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
>> >>
>> >>
>> >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
>> >> >
>> >> >
>> >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
>> >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>> >> >>> Hi,
>> >> >>>
>> >> >>> I'm not entirely sure what's going on, but I see corrupted characters
>> >> >>> with the serial console on the OMAP4430 SDP board.  During boot,
>> >> >>> everything seems fine, the problem appears to be userspace output.
>> >> >>>
>> >> >>> For example, if I edit a file, then quit vi:
>> >> >>>
>> >> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
>> >> >>
>> >> >> I don't think I've seen that one. What I've seen few times is
>> >> >> typing a key on the serial console echoing back the previous
>> >> >> character typed while the new character won't get displayed
>> >> >> until hitting keyboard again. Only rebooting the device seems
>> >> >> to solve this. This is with 4430 ES2.3 revision.
>> >> >>
>> >> >> I wonder if we're missing some parts of errata i202 handling
>> >> >> in omap_8250_mdr1_errataset()?
>> >> >>
>> >>
>> >> I wonder if the extra read of MDR1 register at the beginning of
>> >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
>> >> errata i202 says access to MDR1 can cause data corruption.
>> >> Assuming both reads and writes can cause glitch then, that read
>> >> is not following advisory:
>> >>
>> >> I don't have SDP board so, could you verify if below diff helps:
>> >>
>> >>
>> >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
>> >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
>> >> --- a/drivers/tty/serial/8250/8250_omap.c
>> >> +++ b/drivers/tty/serial/8250/8250_omap.c
>> >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
>> >>                                      struct omap8250_priv *priv)
>> >>  {
>> >>         u8 timeout = 255;
>> >> -       u8 old_mdr1;
>> >> -
>> >> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
>> >> -       if (old_mdr1 == priv->mdr1)
>> >> -               return;
>> >>
>> >>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
>> >>         udelay(2);
>> >
>> > That doesn't appear to help.
>> >
>> > Looking at the bitstream and comparing what should have been sent with
>> > what was sent, there appears to be some correlation between the two.
>> > It looks like the FTDI is not properly synchronised to the bitstream
>> > coming from the OMAP4430.
>> >
>> > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
>> > improve the issue, but not completely solve it.
>>
>> Are you sure about clock error above some tollerance?
>
> No idea at the moment.  Looking at the bitstream with a scope is the
> next step, but it's not easy to do that with just two hands.  I also
> need to find some way to trigger it reliably.
>
> Another cause could be that the UART pin is being held high/low for
> some reason (maybe a pinmux problem.)
>
> Another interesting observation is that if I login over the network and
> then do:
>
>         while :; do :; done &
>         while :; do :; done &
>

You can disable it. Anyway when uart from Ti go in idle mode that can loose
the first char on receiving

> to occupy both CPUs, and then do:
>
>         dmesg | less
>
> on the console, the problem goes away.  If I only do one while loop,
> the problem is present, but the corruption looks like it happens at a
> different point in the serial stream.
>
> This would seem to point the blame away from clocks or pinmux, and back
> to power management issues.
>

Do you have statistics from the uart under proc?

Michael

> I've also tried mimicking the less output with a stand-alone program,
> and that doesn't exhibit the problem - I've tried with various initial
> delays between program start and first output, but this doesn't seem
> to have much effect.  So it seems to need rather precise timing.
>
> stracing less does change where the corruption happens in the output,
> which also suggests a timing related cause.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Michael Nazzareno Trimarchi]

Hi

On Wed, Apr 18, 2018 at 1:00 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
>> <linux@armlinux.org.uk> wrote:
>> > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
>> >>
>> >>
>> >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
>> >> >
>> >> >
>> >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
>> >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
>> >> >>> Hi,
>> >> >>>
>> >> >>> I'm not entirely sure what's going on, but I see corrupted characters
>> >> >>> with the serial console on the OMAP4430 SDP board.  During boot,
>> >> >>> everything seems fine, the problem appears to be userspace output.
>> >> >>>
>> >> >>> For example, if I edit a file, then quit vi:
>> >> >>>
>> >> >>> :q??%??B??Z?root at omap-4430sdp:~#
>> >> >>
>> >> >> I don't think I've seen that one. What I've seen few times is
>> >> >> typing a key on the serial console echoing back the previous
>> >> >> character typed while the new character won't get displayed
>> >> >> until hitting keyboard again. Only rebooting the device seems
>> >> >> to solve this. This is with 4430 ES2.3 revision.
>> >> >>
>> >> >> I wonder if we're missing some parts of errata i202 handling
>> >> >> in omap_8250_mdr1_errataset()?
>> >> >>
>> >>
>> >> I wonder if the extra read of MDR1 register at the beginning of
>> >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
>> >> errata i202 says access to MDR1 can cause data corruption.
>> >> Assuming both reads and writes can cause glitch then, that read
>> >> is not following advisory:
>> >>
>> >> I don't have SDP board so, could you verify if below diff helps:
>> >>
>> >>
>> >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
>> >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
>> >> --- a/drivers/tty/serial/8250/8250_omap.c
>> >> +++ b/drivers/tty/serial/8250/8250_omap.c
>> >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
>> >>                                      struct omap8250_priv *priv)
>> >>  {
>> >>         u8 timeout = 255;
>> >> -       u8 old_mdr1;
>> >> -
>> >> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
>> >> -       if (old_mdr1 == priv->mdr1)
>> >> -               return;
>> >>
>> >>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
>> >>         udelay(2);
>> >
>> > That doesn't appear to help.
>> >
>> > Looking at the bitstream and comparing what should have been sent with
>> > what was sent, there appears to be some correlation between the two.
>> > It looks like the FTDI is not properly synchronised to the bitstream
>> > coming from the OMAP4430.
>> >
>> > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
>> > improve the issue, but not completely solve it.
>>
>> Are you sure about clock error above some tollerance?
>
> No idea at the moment.  Looking at the bitstream with a scope is the
> next step, but it's not easy to do that with just two hands.  I also
> need to find some way to trigger it reliably.
>
> Another cause could be that the UART pin is being held high/low for
> some reason (maybe a pinmux problem.)
>
> Another interesting observation is that if I login over the network and
> then do:
>
>         while :; do :; done &
>         while :; do :; done &
>

You can disable it. Anyway when uart from Ti go in idle mode that can loose
the first char on receiving

> to occupy both CPUs, and then do:
>
>         dmesg | less
>
> on the console, the problem goes away.  If I only do one while loop,
> the problem is present, but the corruption looks like it happens at a
> different point in the serial stream.
>
> This would seem to point the blame away from clocks or pinmux, and back
> to power management issues.
>

Do you have statistics from the uart under proc?

Michael

> I've also tried mimicking the less output with a stand-alone program,
> and that doesn't exhibit the problem - I've tried with various initial
> delays between program start and first output, but this doesn't seem
> to have much effect.  So it seems to need rather precise timing.
>
> stracing less does change where the corruption happens in the output,
> which also suggests a timing related cause.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

Re: 4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Wed, Apr 18, 2018 at 01:45:12PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Wed, Apr 18, 2018 at 1:00 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
> >> Hi
> >>
> >> On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
> >> <linux@armlinux.org.uk> wrote:
> >> > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> >> >>
> >> >>
> >> >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> >> >> >
> >> >> >
> >> >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> >> >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> I'm not entirely sure what's going on, but I see corrupted characters
> >> >> >>> with the serial console on the OMAP4430 SDP board.  During boot,
> >> >> >>> everything seems fine, the problem appears to be userspace output.
> >> >> >>>
> >> >> >>> For example, if I edit a file, then quit vi:
> >> >> >>>
> >> >> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
> >> >> >>
> >> >> >> I don't think I've seen that one. What I've seen few times is
> >> >> >> typing a key on the serial console echoing back the previous
> >> >> >> character typed while the new character won't get displayed
> >> >> >> until hitting keyboard again. Only rebooting the device seems
> >> >> >> to solve this. This is with 4430 ES2.3 revision.
> >> >> >>
> >> >> >> I wonder if we're missing some parts of errata i202 handling
> >> >> >> in omap_8250_mdr1_errataset()?
> >> >> >>
> >> >>
> >> >> I wonder if the extra read of MDR1 register at the beginning of
> >> >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> >> >> errata i202 says access to MDR1 can cause data corruption.
> >> >> Assuming both reads and writes can cause glitch then, that read
> >> >> is not following advisory:
> >> >>
> >> >> I don't have SDP board so, could you verify if below diff helps:
> >> >>
> >> >>
> >> >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> >> >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> >> >> --- a/drivers/tty/serial/8250/8250_omap.c
> >> >> +++ b/drivers/tty/serial/8250/8250_omap.c
> >> >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
> >> >>                                      struct omap8250_priv *priv)
> >> >>  {
> >> >>         u8 timeout = 255;
> >> >> -       u8 old_mdr1;
> >> >> -
> >> >> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> >> >> -       if (old_mdr1 == priv->mdr1)
> >> >> -               return;
> >> >>
> >> >>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> >> >>         udelay(2);
> >> >
> >> > That doesn't appear to help.
> >> >
> >> > Looking at the bitstream and comparing what should have been sent with
> >> > what was sent, there appears to be some correlation between the two.
> >> > It looks like the FTDI is not properly synchronised to the bitstream
> >> > coming from the OMAP4430.
> >> >
> >> > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> >> > improve the issue, but not completely solve it.
> >>
> >> Are you sure about clock error above some tollerance?
> >
> > No idea at the moment.  Looking at the bitstream with a scope is the
> > next step, but it's not easy to do that with just two hands.  I also
> > need to find some way to trigger it reliably.
> >
> > Another cause could be that the UART pin is being held high/low for
> > some reason (maybe a pinmux problem.)
> >
> > Another interesting observation is that if I login over the network and
> > then do:
> >
> >         while :; do :; done &
> >         while :; do :; done &
> >
> 
> You can disable it. Anyway when uart from Ti go in idle mode that can loose
> the first char on receiving

That may be, but what happens on the OMAP receive side is not relevant.
This issue is about the OMAP4430 transmit side.

> > to occupy both CPUs, and then do:
> >
> >         dmesg | less
> >
> > on the console, the problem goes away.  If I only do one while loop,
> > the problem is present, but the corruption looks like it happens at a
> > different point in the serial stream.
> >
> > This would seem to point the blame away from clocks or pinmux, and back
> > to power management issues.
> >
> 
> Do you have statistics from the uart under proc?

You mean on the OMAP4430?

# cat /proc/tty/driver/OMAP-SERIAL
serinfo:1.0 driver revision:
0: uart:OMAP UART0 mmio:0x4806A000 irq:32 tx:0 rx:0
1: uart:OMAP UART1 mmio:0x4806C000 irq:33 tx:0 rx:0
2: uart:OMAP UART2 mmio:0x48020000 irq:34 tx:638807 rx:5406 RTS|CTS|DTR
3: uart:OMAP UART3 mmio:0x4806E000 irq:35 tx:0 rx:0

Of course, there won't be anything of interest there because I'm
talking about the *transmit* side on the OMAP4430 and there's no
way to detect or monitor errors in the transmit side.

The ftdi-sio driver on the host machine, which would be involved in
the receive, doesn't keep statistics and make them available through
/proc.  (Another reason why I hate usb-serial based development
boards.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Wed, Apr 18, 2018 at 01:45:12PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Wed, Apr 18, 2018 at 1:00 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
> >> Hi
> >>
> >> On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
> >> <linux@armlinux.org.uk> wrote:
> >> > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> >> >>
> >> >>
> >> >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> >> >> >
> >> >> >
> >> >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> >> >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> I'm not entirely sure what's going on, but I see corrupted characters
> >> >> >>> with the serial console on the OMAP4430 SDP board.  During boot,
> >> >> >>> everything seems fine, the problem appears to be userspace output.
> >> >> >>>
> >> >> >>> For example, if I edit a file, then quit vi:
> >> >> >>>
> >> >> >>> :q??%??B??Z?root at omap-4430sdp:~#
> >> >> >>
> >> >> >> I don't think I've seen that one. What I've seen few times is
> >> >> >> typing a key on the serial console echoing back the previous
> >> >> >> character typed while the new character won't get displayed
> >> >> >> until hitting keyboard again. Only rebooting the device seems
> >> >> >> to solve this. This is with 4430 ES2.3 revision.
> >> >> >>
> >> >> >> I wonder if we're missing some parts of errata i202 handling
> >> >> >> in omap_8250_mdr1_errataset()?
> >> >> >>
> >> >>
> >> >> I wonder if the extra read of MDR1 register at the beginning of
> >> >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> >> >> errata i202 says access to MDR1 can cause data corruption.
> >> >> Assuming both reads and writes can cause glitch then, that read
> >> >> is not following advisory:
> >> >>
> >> >> I don't have SDP board so, could you verify if below diff helps:
> >> >>
> >> >>
> >> >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> >> >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> >> >> --- a/drivers/tty/serial/8250/8250_omap.c
> >> >> +++ b/drivers/tty/serial/8250/8250_omap.c
> >> >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
> >> >>                                      struct omap8250_priv *priv)
> >> >>  {
> >> >>         u8 timeout = 255;
> >> >> -       u8 old_mdr1;
> >> >> -
> >> >> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> >> >> -       if (old_mdr1 == priv->mdr1)
> >> >> -               return;
> >> >>
> >> >>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> >> >>         udelay(2);
> >> >
> >> > That doesn't appear to help.
> >> >
> >> > Looking at the bitstream and comparing what should have been sent with
> >> > what was sent, there appears to be some correlation between the two.
> >> > It looks like the FTDI is not properly synchronised to the bitstream
> >> > coming from the OMAP4430.
> >> >
> >> > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> >> > improve the issue, but not completely solve it.
> >>
> >> Are you sure about clock error above some tollerance?
> >
> > No idea at the moment.  Looking at the bitstream with a scope is the
> > next step, but it's not easy to do that with just two hands.  I also
> > need to find some way to trigger it reliably.
> >
> > Another cause could be that the UART pin is being held high/low for
> > some reason (maybe a pinmux problem.)
> >
> > Another interesting observation is that if I login over the network and
> > then do:
> >
> >         while :; do :; done &
> >         while :; do :; done &
> >
> 
> You can disable it. Anyway when uart from Ti go in idle mode that can loose
> the first char on receiving

That may be, but what happens on the OMAP receive side is not relevant.
This issue is about the OMAP4430 transmit side.

> > to occupy both CPUs, and then do:
> >
> >         dmesg | less
> >
> > on the console, the problem goes away.  If I only do one while loop,
> > the problem is present, but the corruption looks like it happens at a
> > different point in the serial stream.
> >
> > This would seem to point the blame away from clocks or pinmux, and back
> > to power management issues.
> >
> 
> Do you have statistics from the uart under proc?

You mean on the OMAP4430?

# cat /proc/tty/driver/OMAP-SERIAL
serinfo:1.0 driver revision:
0: uart:OMAP UART0 mmio:0x4806A000 irq:32 tx:0 rx:0
1: uart:OMAP UART1 mmio:0x4806C000 irq:33 tx:0 rx:0
2: uart:OMAP UART2 mmio:0x48020000 irq:34 tx:638807 rx:5406 RTS|CTS|DTR
3: uart:OMAP UART3 mmio:0x4806E000 irq:35 tx:0 rx:0

Of course, there won't be anything of interest there because I'm
talking about the *transmit* side on the OMAP4430 and there's no
way to detect or monitor errors in the transmit side.

The ftdi-sio driver on the host machine, which would be involved in
the receive, doesn't keep statistics and make them available through
/proc.  (Another reason why I hate usb-serial based development
boards.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: 4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Wed, Apr 18, 2018 at 12:00:33PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi
> > 
> > On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
> > <linux@armlinux.org.uk> wrote:
> > > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> > >>
> > >>
> > >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> > >> >
> > >> >
> > >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > >> >>> Hi,
> > >> >>>
> > >> >>> I'm not entirely sure what's going on, but I see corrupted characters
> > >> >>> with the serial console on the OMAP4430 SDP board.  During boot,
> > >> >>> everything seems fine, the problem appears to be userspace output.
> > >> >>>
> > >> >>> For example, if I edit a file, then quit vi:
> > >> >>>
> > >> >>> :q■■%■■B■■Z■root@omap-4430sdp:~#
> > >> >>
> > >> >> I don't think I've seen that one. What I've seen few times is
> > >> >> typing a key on the serial console echoing back the previous
> > >> >> character typed while the new character won't get displayed
> > >> >> until hitting keyboard again. Only rebooting the device seems
> > >> >> to solve this. This is with 4430 ES2.3 revision.
> > >> >>
> > >> >> I wonder if we're missing some parts of errata i202 handling
> > >> >> in omap_8250_mdr1_errataset()?
> > >> >>
> > >>
> > >> I wonder if the extra read of MDR1 register at the beginning of
> > >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> > >> errata i202 says access to MDR1 can cause data corruption.
> > >> Assuming both reads and writes can cause glitch then, that read
> > >> is not following advisory:
> > >>
> > >> I don't have SDP board so, could you verify if below diff helps:
> > >>
> > >>
> > >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> > >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> > >> --- a/drivers/tty/serial/8250/8250_omap.c
> > >> +++ b/drivers/tty/serial/8250/8250_omap.c
> > >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
> > >>                                      struct omap8250_priv *priv)
> > >>  {
> > >>         u8 timeout = 255;
> > >> -       u8 old_mdr1;
> > >> -
> > >> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> > >> -       if (old_mdr1 == priv->mdr1)
> > >> -               return;
> > >>
> > >>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> > >>         udelay(2);
> > >
> > > That doesn't appear to help.
> > >
> > > Looking at the bitstream and comparing what should have been sent with
> > > what was sent, there appears to be some correlation between the two.
> > > It looks like the FTDI is not properly synchronised to the bitstream
> > > coming from the OMAP4430.
> > >
> > > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> > > improve the issue, but not completely solve it.
> > 
> > Are you sure about clock error above some tollerance?
> 
> No idea at the moment.  Looking at the bitstream with a scope is the
> next step, but it's not easy to do that with just two hands.  I also
> need to find some way to trigger it reliably.
> 
> Another cause could be that the UART pin is being held high/low for
> some reason (maybe a pinmux problem.)
> 
> Another interesting observation is that if I login over the network and
> then do:
> 
> 	while :; do :; done &
> 	while :; do :; done &
> 
> to occupy both CPUs, and then do:
> 
> 	dmesg | less
> 
> on the console, the problem goes away.  If I only do one while loop,
> the problem is present, but the corruption looks like it happens at a
> different point in the serial stream.
> 
> This would seem to point the blame away from clocks or pinmux, and back
> to power management issues.
> 
> I've also tried mimicking the less output with a stand-alone program,
> and that doesn't exhibit the problem - I've tried with various initial
> delays between program start and first output, but this doesn't seem
> to have much effect.  So it seems to need rather precise timing.
> 
> stracing less does change where the corruption happens in the output,
> which also suggests a timing related cause.

Okay, I think I'm getting somewhere...  `less' does an ioctl(, TCSETS, )
after outputting a screenful in order to change c_iflag and c_lflag.
The differences are:

	c_iflag 0x1500 -> 0x1000
	c_lflag 0x083b -> 0x0831

Other settings are kept the same.

The iflag changes are IXON | ICRNL, and the lflag changes are
ECHO | ICANON.  Reproducing those changes in my test program shows
the same corruption.

Removing the lflag changes makes no difference.  Removing the ICRNL
also makes no difference - the problem is still there.  Removing
the IXON change and the problem vanishes.

Given that the serial driver rewrites the entire UART configuration
on a termios change that affects any hardware settings, this is
rather expected to happen.

So, the question becomes whether userspace is acting correctly - and
I'd say no.  Looking at _real_ `less' (iow, not the busybox version
that I seem to have on the OMAP4430) it doesn't do this fiddling with
termios settings just before waiting for input.  Moreover, I can't see
_any_ reason for `less' of any kind to be fiddling with IXON.

There is the remaining question about the proper behaviour of setting
termios modes while there is a transmit operation in progress - I know
of several programs that do this.  A TCSETS operation is defined to
occur "immediately" by the spec, but is it reasonable to change the
modes mid-transmission of a character (which _will_ corrupt the
character), or should they be changed at a character boundary (or at
whatever character boundary the hardware is capable of.)

I note that if DMA is enabled, 8250_omap delays a TCSETS operation
until DMA has completed, so I suspect that the problem I'm seeing
will go away if I enable DMA.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

4.16 OMAP serial transmit corruption?

[Russell King - ARM Linux]

On Wed, Apr 18, 2018 at 12:00:33PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 18, 2018 at 12:27:02PM +0200, Michael Nazzareno Trimarchi wrote:
> > Hi
> > 
> > On Wed, Apr 18, 2018 at 11:59 AM, Russell King - ARM Linux
> > <linux@armlinux.org.uk> wrote:
> > > On Wed, Apr 18, 2018 at 02:41:43PM +0530, Vignesh R wrote:
> > >>
> > >>
> > >> On Tuesday 17 April 2018 02:50 PM, Vignesh R wrote:
> > >> >
> > >> >
> > >> > On Monday 16 April 2018 09:15 PM, Tony Lindgren wrote:
> > >> >> * Russell King - ARM Linux <linux@armlinux.org.uk> [180416 15:19]:
> > >> >>> Hi,
> > >> >>>
> > >> >>> I'm not entirely sure what's going on, but I see corrupted characters
> > >> >>> with the serial console on the OMAP4430 SDP board.  During boot,
> > >> >>> everything seems fine, the problem appears to be userspace output.
> > >> >>>
> > >> >>> For example, if I edit a file, then quit vi:
> > >> >>>
> > >> >>> :q??%??B??Z?root at omap-4430sdp:~#
> > >> >>
> > >> >> I don't think I've seen that one. What I've seen few times is
> > >> >> typing a key on the serial console echoing back the previous
> > >> >> character typed while the new character won't get displayed
> > >> >> until hitting keyboard again. Only rebooting the device seems
> > >> >> to solve this. This is with 4430 ES2.3 revision.
> > >> >>
> > >> >> I wonder if we're missing some parts of errata i202 handling
> > >> >> in omap_8250_mdr1_errataset()?
> > >> >>
> > >>
> > >> I wonder if the extra read of MDR1 register at the beginning of
> > >> omap_8250_mdr1_errataset() compared to omap-serial is the issue.
> > >> errata i202 says access to MDR1 can cause data corruption.
> > >> Assuming both reads and writes can cause glitch then, that read
> > >> is not following advisory:
> > >>
> > >> I don't have SDP board so, could you verify if below diff helps:
> > >>
> > >>
> > >> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> > >> index 6aaa84355fd1..8ab9d0a1b1eb 100644
> > >> --- a/drivers/tty/serial/8250/8250_omap.c
> > >> +++ b/drivers/tty/serial/8250/8250_omap.c
> > >> @@ -163,11 +163,6 @@ static void omap_8250_mdr1_errataset(struct uart_8250_port *up,
> > >>                                      struct omap8250_priv *priv)
> > >>  {
> > >>         u8 timeout = 255;
> > >> -       u8 old_mdr1;
> > >> -
> > >> -       old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> > >> -       if (old_mdr1 == priv->mdr1)
> > >> -               return;
> > >>
> > >>         serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> > >>         udelay(2);
> > >
> > > That doesn't appear to help.
> > >
> > > Looking at the bitstream and comparing what should have been sent with
> > > what was sent, there appears to be some correlation between the two.
> > > It looks like the FTDI is not properly synchronised to the bitstream
> > > coming from the OMAP4430.
> > >
> > > Setting two stop bits on both ends (OMAP4430 and FTDI) appears to
> > > improve the issue, but not completely solve it.
> > 
> > Are you sure about clock error above some tollerance?
> 
> No idea at the moment.  Looking at the bitstream with a scope is the
> next step, but it's not easy to do that with just two hands.  I also
> need to find some way to trigger it reliably.
> 
> Another cause could be that the UART pin is being held high/low for
> some reason (maybe a pinmux problem.)
> 
> Another interesting observation is that if I login over the network and
> then do:
> 
> 	while :; do :; done &
> 	while :; do :; done &
> 
> to occupy both CPUs, and then do:
> 
> 	dmesg | less
> 
> on the console, the problem goes away.  If I only do one while loop,
> the problem is present, but the corruption looks like it happens at a
> different point in the serial stream.
> 
> This would seem to point the blame away from clocks or pinmux, and back
> to power management issues.
> 
> I've also tried mimicking the less output with a stand-alone program,
> and that doesn't exhibit the problem - I've tried with various initial
> delays between program start and first output, but this doesn't seem
> to have much effect.  So it seems to need rather precise timing.
> 
> stracing less does change where the corruption happens in the output,
> which also suggests a timing related cause.

Okay, I think I'm getting somewhere...  `less' does an ioctl(, TCSETS, )
after outputting a screenful in order to change c_iflag and c_lflag.
The differences are:

	c_iflag 0x1500 -> 0x1000
	c_lflag 0x083b -> 0x0831

Other settings are kept the same.

The iflag changes are IXON | ICRNL, and the lflag changes are
ECHO | ICANON.  Reproducing those changes in my test program shows
the same corruption.

Removing the lflag changes makes no difference.  Removing the ICRNL
also makes no difference - the problem is still there.  Removing
the IXON change and the problem vanishes.

Given that the serial driver rewrites the entire UART configuration
on a termios change that affects any hardware settings, this is
rather expected to happen.

So, the question becomes whether userspace is acting correctly - and
I'd say no.  Looking at _real_ `less' (iow, not the busybox version
that I seem to have on the OMAP4430) it doesn't do this fiddling with
termios settings just before waiting for input.  Moreover, I can't see
_any_ reason for `less' of any kind to be fiddling with IXON.

There is the remaining question about the proper behaviour of setting
termios modes while there is a transmit operation in progress - I know
of several programs that do this.  A TCSETS operation is defined to
occur "immediately" by the spec, but is it reasonable to change the
modes mid-transmission of a character (which _will_ corrupt the
character), or should they be changed at a character boundary (or at
whatever character boundary the hardware is capable of.)

I note that if DMA is enabled, 8250_omap delays a TCSETS operation
until DMA has completed, so I suspect that the problem I'm seeing
will go away if I enable DMA.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up