Non-console UART issues with 8xx

Non-console UART issues with 8xx

[Eran Duchan]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

Hey list

I have a custom MPC875 board running 2.6.37. SMC1 is the console, SCC4 is a
general purpose UART (DTS is set up accordingly). No hardware or software
flow control for either.

The issue is simple: the non-console UART transmits garbled characters at
the end of the transmission. For example, set up SMC1 to console (works
perfect) and SCC4 as non-console, run stty -F /dev/ttyCPM1 19200 raw and
then echo -n 1234567890 > /dev/ttyCPM1 - transmission may be something like
"1234567ø". Set the SCC4 as console (same baud rates) and the problem is
reversed (SCC4 works perfect, SMC1 transmit garbled).

Rx direction seems fine, after some rudementary testing.

I dived into the code and see that the console UART has a completely
different initialization sequence than the non-console UART. Short of diving
into this ancient CPM architecture - does anyone have an idea?

Thanks
Eran

[-- Attachment #2: Type: text/html, Size: 1159 bytes --]

Re: Non-console UART issues with 8xx

[Scott Wood]

On Fri, 15 Apr 2011 02:52:22 +0300
Eran Duchan <pavius@gmail.com> wrote:

> Hey list
>=20
> I have a custom MPC875 board running 2.6.37. SMC1 is the console, SCC4 is=
 a
> general purpose UART (DTS is set up accordingly). No hardware or software
> flow control for either.
>=20
> The issue is simple: the non-console UART transmits garbled characters at
> the end of the transmission.

Hmm, there's a wait_closing field in uart_cpm_port that doesn't seem to be
initialized anywhere.

The driver should also be sending the STOP_TX/GRA_STOP_TX command *before*
clearing the transmit enable bits, rather than after.

>  For example, set up SMC1 to console (works
> perfect) and SCC4 as non-console, run stty -F /dev/ttyCPM1 19200 raw and
> then echo -n 1234567890 > /dev/ttyCPM1 - transmission may be something li=
ke
> "1234567=C3=B8". Set the SCC4 as console (same baud rates) and the proble=
m is
> reversed (SCC4 works perfect, SMC1 transmit garbled).
>=20
> Rx direction seems fine, after some rudementary testing.
>=20
> I dived into the code and see that the console UART has a completely
> different initialization sequence than the non-console UART. Short of div=
ing
> into this ancient CPM architecture - does anyone have an idea?

The console is a bit different because it has a user that isn't tied to an
open file-handle -- which doesn't interact well with the driver's
(possibly misguided) desire to actually deconfigure the hardware when not
open.

-Scott

Re: Non-console UART issues with 8xx

[Eran Duchan]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

Thanks for the pointers, Scott.
Looks like some elbow grease is in order. I will post any results I have
once I get to this :-/

Eran

On Fri, Apr 15, 2011 at 11:41 PM, Scott Wood <scottwood@freescale.com>wrote:

> On Fri, 15 Apr 2011 02:52:22 +0300
> Eran Duchan <pavius@gmail.com> wrote:
>
> > Hey list
> >
> > I have a custom MPC875 board running 2.6.37. SMC1 is the console, SCC4 is
> a
> > general purpose UART (DTS is set up accordingly). No hardware or software
> > flow control for either.
> >
> > The issue is simple: the non-console UART transmits garbled characters at
> > the end of the transmission.
>
> Hmm, there's a wait_closing field in uart_cpm_port that doesn't seem to be
> initialized anywhere.
>
> The driver should also be sending the STOP_TX/GRA_STOP_TX command *before*
> clearing the transmit enable bits, rather than after.
>
> >  For example, set up SMC1 to console (works
> > perfect) and SCC4 as non-console, run stty -F /dev/ttyCPM1 19200 raw and
> > then echo -n 1234567890 > /dev/ttyCPM1 - transmission may be something
> like
> > "1234567ø". Set the SCC4 as console (same baud rates) and the problem is
> > reversed (SCC4 works perfect, SMC1 transmit garbled).
> >
> > Rx direction seems fine, after some rudementary testing.
> >
> > I dived into the code and see that the console UART has a completely
> > different initialization sequence than the non-console UART. Short of
> diving
> > into this ancient CPM architecture - does anyone have an idea?
>
> The console is a bit different because it has a user that isn't tied to an
> open file-handle -- which doesn't interact well with the driver's
> (possibly misguided) desire to actually deconfigure the hardware when not
> open.
>
> -Scott
>
>

[-- Attachment #2: Type: text/html, Size: 2343 bytes --]