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

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

Hello Steve,

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@diasemi.com>
> > > > > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> > > >
> > > > 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< ---
> 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:   46 C, calibration data 0x5f15527d

huh, it's hot in your office :-)

> 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 [WDOG ]
> 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 = 5951108 (5ace84 hex)
> ## Booting kernel from Legacy Image at 12000000 ...
>    Image Name:
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    5951044 Bytes =  5.7 MB
>    Load Address: 10800000
>    Entry Point:  10800000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> à\x1cü\x1cü\x1cpþ\x1càüþü\x1cà\x1càà\x1càüþü\x1c\x1c\x1c\x1càüü\x1cþü\x1cà\x1cü\x1cà\x1cà\x1càüŽ\x1c\x1càü\x1càü\x1c\x1c\x1c\x1c\x1càà\x1cà\x1cà\x1c€à\x1càüþü\x1c\x1c\x1c\x1cààü\x1c\x1cüÿ
> à\x1càüŽü\x1cþü\x1càüàð\x1c\x1cààðàà\x1c\x1cà\x1c\x1c\x1cþ\x1c\x1c\x1c~pà\x1cœà\x1c`þ\x1cü\x1càüŽà\x1cà\x1c\x1cà\x1cü\x1cà\x1c\x1cþ\x1cüþ\x1c\x1c\x1c\x1cà\x1cü\x1c\x1cà\x1cŽàà\x1c\x1cà\x1c\x1c\x1c
> ààü\x1c\x1cüÿ\x1cà\x1càüŽü\x1cþü\x1càüàð\x1c\x1c€àà\x1c\x1cààààðàà\x1cðàüààüðààðààà\x1c\x1c\x1c\x1cþ\x1c\x1cüÿ\x1c\x1cüðü\x1c\x1cüŽ\x1cà\x1c\x1cüŽà\x1cà\x1c\x1cà\x1cüü
> \x1c\x1c\x1c\x1cþ\x1c\x1c\x1cüÿ\x1cà\x1càü\x1cü\x1cpð\x1c\x1cüÀ\x1c\x1cüþü\x1c\x1cü\x1càà\x1càüpÿ\x1c\x1cüààðàà\x1cðàüàð\x1c\x1cà\x1cüàŽ\x1c\x1c~8à\x1cŽàà\x1cŽààü€ààðààüp
> Ž\x1cà\x1c\x1cà\x1c\x1c\x1c\x1c\x1cüà\x1cà\x1c\x1cà\x1cààðàüðàà\x1cðà\x1cüàpþàüðàüðààþà\x1cðà\x1cüààà\x1cà\x1c\x1c\x1cààðàà\x1cðàüüàŽà\x1c€ü\x1c\x1c\x1c\x1c\x1c\x1càà\x1c
> \x1c\x1cŽ\x1cüà~ÿ\x1cüàà\x1càà\x1cü\x1c\x1c\x1cüŽà\x1cà\x1cü\x1cþ\x1càü~Žüàðààðààà\x1c\x1cà\x1cþà\x1c€\x1cü\x1cààð\x1c\x1cü~ÿ\x1càüŽà\x1càüŽü\x1cþü\x1cà\x1cðààà\x1c
> \x1c\x1cŽ\x1cüà~ÿ\x1cüàŽà\x1c\x1càü€\x1c\x1cþ\x1cüà\x1cðààü€\x1c\x1càüðààüüà€à\x1cüà\x1c€ü\x1c\x1c\x1c\x1c\x1c\x1càà\x1c\x1c\x1cŽ\x1c\x1c\x1càü\x1c\x1càà\x1c\x1cààã\x1cpŽ\x1cààü\x1cü
> \x1cþü\x1c\x1càü\x1càüŽ\x1cà\x1càüþü\x1cà\x1càà\x1c\x1càþ\x1c\x1càü€\x1c\x1c\x1cü\x1c\x1cüð\x1c\x1càà\x1c\x1cààã\x1cpŽ\x1cà\x1c€\x1càü\x1càüŽ\x1cà\x1càüþü\x1cà\x1cà\x1cŽ\x1cü

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).

> --- 8< ---
> 
> >  - 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.

Can you try to just remove the line

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

that was introduced in the last hunk by commit e61c38d85b7?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |