RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off

From: Steve Twiss
Date: Wed May 24 2017 - 06:29:35 EST

Next message: tip-bot for Andy Lutomirski: "[tip:x86/mm] mm, x86/mm: Make the batched unmap TLB flush API more generic"
Previous message: tip-bot for Andy Lutomirski: "[tip:x86/mm] x86/mm: Reduce indentation in flush_tlb_func()"
Next in thread: Uwe Kleine-König: "Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Uwe,

On 23 May 2017 17:09, Uwe Kleine-KÃnig wrote:

> On Tue, May 23, 2017 at 03:01:26PM +0000, Steve Twiss wrote:
> > On 23 May 2017 15:37, Uwe Kleine-KÃnig wrote:
> > > Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off
> > > On Tue, May 23, 2017 at 02:28:11PM +0000, Steve Twiss wrote:
> > > > On 23 May 2017 15:10, Uwe Kleine-KÃnig wrote:
> > > > > On Tue, May 23, 2017 at 01:17:26PM +0100, Steve Twiss wrote:
> > > > > >
> > > > > > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > > > > > ensure DCD and RI irqs to be off")
> > > > > > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > > > > > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > > > > > The console becomes unreadable and unwritable.
> > > > > >
> > > > > > Tested-by: Steve Twiss <stwiss.opensource@xxxxxxxxxxx>
> > > > > > Signed-off-by: Steve Twiss <stwiss.opensource@xxxxxxxxxxx>
> > > > >
> > > > > You're not the first to report this issue but you still have the chance
> > > > > to be the first to test a suggested patch for it.
> > > >
> > > > I've just applied your patch against a clean linux-next/v4.12-rc2
> > > > I added your patch ...
> > > >
> > > > > http://marc.info/?l=linux-serial&m=149434029912947&w=2
> > > >
> > [...]
> > > > I've added that to my working directory, but I am still seeing the corrupted
> > > > console output on the i.MX6 Q (quad) board.
> > >
> > > I don't have a failing board (I think). So here are a few questions
> > > about yours:
> > >
> > > - how does the dts snippet for your failing device look like?
> >
> > I am using the standard DTS from the v4.12-rc2 kernel, no changes.
> > I did an earlier test yesterday using the DTS from v4.11 to see if it was the new
> > imx7 changes that have recently gone into the kernel but I still see the same
> > effect.
> >
> > > - This is not the device the console runs on, right?
> >
> > I am connected through the USB to UART, U22 on the i.MX6Q board.
> > Terminal set to 115200 baud, no parity, 8bit data.
> >
> > > - Can you initialize the device in the bootloader and check if it is working
> there?
> >
> > I can get U-boot ok for all cases.
> > Once I TFTP the kernel across, I am okay until I get to "Starting kernel ...",
> > then, the UART is "working" in the sense that I get the some characters in the style
> > of the kernel starting up, but they are all garbled.
> >
> > I expect the kernel has started ok, but I am unable to read/write through the UART
> > console because of corruptions.
> >
> > Console log:
> > --- 8< ---
[...]
> > Starting kernel ...
> >
> ÃÃÃpÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÅÃÃÃÃÃÃ
[...]
>
> did you check with an oscilloscope if the baud rate is as expected (hmm,
> but I wouldn't expect my patch to change the baud rate).

I did try several different baudrates on the terminal connection, but I didn't find any
that worked. I've only checked the obvious ones however. I have not tried to debug
this problem any further than diagnosing what kernel commit caused the difference.

We also swapped compilers to begin with, when the first investigation began.
I noticed kernelci.org had some i.MX sabre boards, but used a different compiler
and did not see any problem.
Swapping the compiler made no difference and led us to find it only happened
on the i.MX6Q not the i.MX6DL. The kernelci.org site does not test any i.MX6Q
boards.

> > > - Does it make a difference in Linux if the bootloader used the device before?
> >
> > If you mean, if U-boot uses the UART console before loading the kernel, then no.
> > Is that what you mean?
>
> I didn't expect that it destroys the console UART so I expected that you
> can make use of a 2nd UART in U-Boot somehow to already initialize the
> port and check if that makes it magically work in Linux.
>
> Note to myself: So we're taking about the UART at 0x02020000, it is
> operated in DCE mode.

> > It makes no difference until the kernel is loaded, then the serial
> > output gets corrupted.
> >
> > > - Can you dump the register space of the uart with v4.12-rc2 and
> > > v4.12-rc2 + revert of e61c38d85b7392e?
> >
> > Difficult to do that I think. The console is unusable in both directions. I can't get any
> > response from the console (through typing) once the kernel has started.
>
> ssh or telnet come to mind.

Yup. We thought of that also, but finding the time at this side is the problem.
I am looking at this Linux kernel i.MX6Q problem, but other customers are taking my
priority at the moment, so this does not have a very high level (probably because
we have found a "fix", at least to unblock our testing).
Dialog do want to assist the Linux community however. So I will try to help where I can.

> Can you try to just remove the line
> writel(0, sport->port.membase + UFCR);
> that was introduced in the last hunk by commit e61c38d85b7?

Yep. I can do this.
If I make this change, to the stock linux-next/v4.12-rc2 kernel, like this:

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 33509b4..68cfd3e 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2194,9 +2194,7 @@ static int serial_imx_probe(struct platform_device *pdev)
writel(IMX21_UCR3_RXDMUXSEL | UCR3_ADNIMP | UCR3_DSR,
sport->port.membase + UCR3);

- } else {
- writel(0, sport->port.membase + UFCR);
- }
+ }

clk_disable_unprepare(sport->clk_ipg);

This console works okay.
Everything is ok on our i.MX6Q board after this change to v4.12-rc2.

-- 8< --
U-Boot 2009.08-00001-gf65536a (Jan 12 2015 - 15:47:19)

CPU: Freescale i.MX6 family TO1.2 at 792 MHz
Thermal sensor with ratio = 200
Temperature: 25 C, calibration data 0x5f15527d
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock : 66000000Hz
ipg per clock : 66000000Hz
uart clock : 80000000Hz
cspi clock : 60000000Hz
ahb clock : 132000000Hz
axi clock : 264000000Hz
emi_slow clock: 132000000Hz
ddr clock : 528000000Hz
usdhc1 clock : 198000000Hz
usdhc2 clock : 198000000Hz
usdhc3 clock : 198000000Hz
usdhc4 clock : 198000000Hz
nfc clock : 24000000Hz
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [POR ]
Boot Device: SD
I2C: ready
DRAM: 1 GB
MMC: FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
In: serial
Out: serial
Err: serial
Found PFUZE100! deviceid=10,revid=11
Net: got MAC address from IIM: 00:04:9f:02:e3:0a
FEC0 [PRIME]
Hit any key to stop autoboot: 0
PHY indentify @ 0x1 = 0x004dd074
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage_dtb.imx6q.v4.12-rc2'.
Load address: 0x12000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##########################################################
done
Bytes transferred = 5951076 (5ace64 hex)
## Booting kernel from Legacy Image at 12000000 ...
Image Name:
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 5951012 Bytes = 5.7 MB
Load Address: 10800000
Entry Point: 10800000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 4.12.0-rc2 (stwiss@test) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #1 SMP Wed May 24 11:10:14 BST 2017
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt: Machine model: Freescale i.MX6 Quad SABRE Smart Device Board
...
-- 8< --

Regards,
Steve

Next message: tip-bot for Andy Lutomirski: "[tip:x86/mm] mm, x86/mm: Make the batched unmap TLB flush API more generic"
Previous message: tip-bot for Andy Lutomirski: "[tip:x86/mm] x86/mm: Reduce indentation in flush_tlb_func()"
Next in thread: Uwe Kleine-König: "Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]