RE: Serial console ports on systems with no console connected.

RE: Serial console ports on systems with no console connected.

[Richard Williams]

I've had a board hang in the same place before. Can't remember exactly the
circumstances but it was triggered by me turning on a lot of debug messages
in kernel modules.

Perhaps buffer overrun on the console port?

Regards,
Richard

-----Original Message-----
From: Arun Dharankar [mailto:ADharankar@ATTBI.Com]
Sent: Wednesday, 10 July 2002 12:08 a.m.
To: Wolfgang Denk
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Serial console ports on systems with no console connected.



Hello, and thanks for your reply!

The board has SCC4 and SMC1 based serial ports. I have
tried both of these as console ports under Linux and PPCBOOT.
PPCBOOT code is unmodified (as it is from the distribution) for
SCC4 and SMC1 code. The Linux code is unmodified for
SMC1, and I see this behavior in case of both these serial
ports.

The place where the BDI shows the PC to hang is in
serial_putc(...) waiting for the transmit buffer to be drained by the
8260:

    /* Wait for last character to go.
    */
    while (tbdf->cbd_sc & BD_SC_READY)
        ;

Ofcourse, when the cable is present, things work well.

Though I dont see any code path, or from hardware perspective
what could be wrong, I am open to any guesses/hints at
debugging it.


Best regards,
-Arun.



On Tuesday 09 July 2002 01:14 am, Wolfgang Denk wrote:
> In message <200207082127.16518.ADharankar@ATTBI.Com> you wrote:
> > This question is common to both ppcboot and ppc-linux.
> > The ppcboot I am using is 1.1.5 and Linux kernel 2.4.18.
> >
> > If there is no console connected to the serial console port,
> > is it true that a thread sending output to it hangs? If this is
>
> No, this is NOT true.
>
> Why should it? There is no flow control used - neither in the PPCBoot
> nor in the Linux UART drivers...
>
> > I have a MPC8260ADS based board, and see the above
>
> ...at least not in the standard MPC8xx and MPC8260 UART drivers.
>
> > behavior under ppcboot. Under Linux using a BDI debugger
> > the thread sending output to the console hangs. Perhaps
>
> You must be doing something wrong.
>
> Wolfgang Denk


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial console ports on systems with no console connected.

[Arun Dharankar]

Thanks for your reply, Richard!

This is definitely not so in my case, there is very little output
generated. Also have the serial port speed set at 115200,  I
dont believe this is buffer overrun issue.

Anyway, I could work around the problem by checking for
the previous buffer's state and drop the characters. Would be
nice to get to the root cause.

Best regards,
-Arun.


On Tuesday 09 July 2002 06:08 pm, Richard Williams wrote:
> I've had a board hang in the same place before. Can't remember exactly the
> circumstances but it was triggered by me turning on a lot of debug messages
> in kernel modules.
>
> Perhaps buffer overrun on the console port?
>
> Regards,
> Richard
>
> -----Original Message-----
> From: Arun Dharankar [mailto:ADharankar@ATTBI.Com]
> Sent: Wednesday, 10 July 2002 12:08 a.m.
> To: Wolfgang Denk
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: Re: Serial console ports on systems with no console connected.
>
>
>
> Hello, and thanks for your reply!
>
> The board has SCC4 and SMC1 based serial ports. I have
> tried both of these as console ports under Linux and PPCBOOT.
> PPCBOOT code is unmodified (as it is from the distribution) for
> SCC4 and SMC1 code. The Linux code is unmodified for
> SMC1, and I see this behavior in case of both these serial
> ports.
>
> The place where the BDI shows the PC to hang is in
> serial_putc(...) waiting for the transmit buffer to be drained by the
> 8260:
>
>     /* Wait for last character to go.
>     */
>     while (tbdf->cbd_sc & BD_SC_READY)
>         ;
>
> Ofcourse, when the cable is present, things work well.
>
> Though I dont see any code path, or from hardware perspective
> what could be wrong, I am open to any guesses/hints at
> debugging it.
>
>
> Best regards,
> -Arun.
>
> On Tuesday 09 July 2002 01:14 am, Wolfgang Denk wrote:
> > In message <200207082127.16518.ADharankar@ATTBI.Com> you wrote:
> > > This question is common to both ppcboot and ppc-linux.
> > > The ppcboot I am using is 1.1.5 and Linux kernel 2.4.18.
> > >
> > > If there is no console connected to the serial console port,
> > > is it true that a thread sending output to it hangs? If this is
> >
> > No, this is NOT true.
> >
> > Why should it? There is no flow control used - neither in the PPCBoot
> > nor in the Linux UART drivers...
> >
> > > I have a MPC8260ADS based board, and see the above
> >
> > ...at least not in the standard MPC8xx and MPC8260 UART drivers.
> >
> > > behavior under ppcboot. Under Linux using a BDI debugger
> > > the thread sending output to the console hangs. Perhaps
> >
> > You must be doing something wrong.
> >
> > Wolfgang Denk
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial console ports on systems with no console connected.

[Murray Jensen]

On Tue, 9 Jul 2002 19:45:19 -0400, Arun Dharankar <ADharankar@ATTBI.Com> writes:
>Also have the serial port speed set at 115200,  I
>dont believe this is buffer overrun issue.

If you want to go faster than about than about 38400, you need to get a
different clock source for your baud rate generators (Tom Rini has a patch
from me to add support for an external clock source for BRGs on the 8260
in linuxppc_2_4_devel). By default, the SCCs and SMCs use a clock source that
won't divide cleanly at the higher baud rates - the error becomes so large
that it simply stops working - which is what you are getting by the looks of it.

Try running the serial ports at 19200 and see if that works. Cheers!
								Murray...

PS: the patch Tom has is trivial - you still need to hack the 8260 uart driver
to use the new code (also trivial), plus your hardware needs an external clock
source (distinctly non-trivial if your board design doesn't include one already
- our hymod board has a 3686400Hz clock source wired appropriately, which allows
up to 230400bps if you use 16x oversampling)

PPS: ppcboot already has support for external BRG clock sources - see
include/config_hymod.h for an example of how to configure it.
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial console ports on systems with no console connected.

[Jerry Van Baren]

Disclaimer: This is all generic speculation (not based on knowledge of the
board, just based on cruel experience :-)...

Your description sounds a lot like flow control, either hardware or
software, is happening.  It could also be an unhandled (or mishandled)
error condition.  Addressing these possibilities...

Hardware flow control was discounted because the hardware flow control
lines are not run to the serial connector.  This still could cause
problems, however, because the linux driver doesn't necessarily know that
and quite likely still sets up the UART for hardware flow control.  If the
flow control line (CTS*) is unterminated or used for some other purpose, it
could be going low inadvertently, causing the hardware flow control to stop
the UART.  Check your port initialization and what is connected to the CTS*
line.  You want the port to be initialized so that the CTS* line is always
high or you want to configure (or modify) the serial driver to disable
hardware flow control.  Since your problem description explicitly stated
that it occurred with both the SCC (has CTS*) and the SMC (no CTS*) this
doesn't seem likely.

A quick perusal of the UM indicates software flow control (XON/XOFF)
requires software handling, so that doesn't appear to apply.  However, this
fits your problem description fairly well.  One complaint was that an
_unterminated_ serial connector causes problems, but plugging it into a
terminal works.  The explanation here is that an unterminated (or
terminated too weakly) RxData line will tend to flop around.  This will
cause spurious characters to be received and, if ever an XOFF character is
received (synthesized :-), the output will freeze just as you
described.  Note that transmitting more characters will cause more spurious
characters to be received, increasing the probability of an inadvertent
XOFF, which also matches the problem description.  Of course, once an XOFF
is received, the TxData stops generating noise on the RxData line and you
never get the XON synthesized :-(.

This theory also applies to an unhandled error condition: the same thing
happens, but lots of bad characters are synthesized causing error
interrupts.  If an error condition is unhandled or mishandled, the also Tx
could wedge just like you described.

Solutions in this case are:
1) Add or increase the termination to prevent the RxData line from flopping
around when nothing is plugged in.  This is the best, but hardest, fix.

2) Unplug the serial cable: if you have a serial cable plugged into the
board but unterminated at the far end, you just put a noise antenna onto
your RxData line.  I've had equipment that was OK when nothing was plugged
into the serial port, but locked up when a 6' serial cable was plugged in,
even though there was nothing plugged into the far side.

3) Configure (or modify) the serial driver to disable software flow control
in the driver.

4) If it is an unhandled or mishandled error condition, fix the driver.

gvb


At 07:45 PM 7/9/2002 -0400, Arun Dharankar wrote:

>Thanks for your reply, Richard!
>
>This is definitely not so in my case, there is very little output
>generated. Also have the serial port speed set at 115200,  I
>dont believe this is buffer overrun issue.
>
>Anyway, I could work around the problem by checking for
>the previous buffer's state and drop the characters. Would be
>nice to get to the root cause.
>
>Best regards,
>-Arun.
>
>
>On Tuesday 09 July 2002 06:08 pm, Richard Williams wrote:
> > I've had a board hang in the same place before. Can't remember exactly the
> > circumstances but it was triggered by me turning on a lot of debug messages
> > in kernel modules.
> >
> > Perhaps buffer overrun on the console port?
> >
> > Regards,
> > Richard
> >
> > -----Original Message-----
> > From: Arun Dharankar [mailto:ADharankar@ATTBI.Com]
> > Sent: Wednesday, 10 July 2002 12:08 a.m.
> > To: Wolfgang Denk
> > Cc: linuxppc-embedded@lists.linuxppc.org
> > Subject: Re: Serial console ports on systems with no console connected.
> >
> >
> >
> > Hello, and thanks for your reply!
> >
> > The board has SCC4 and SMC1 based serial ports. I have
> > tried both of these as console ports under Linux and PPCBOOT.
> > PPCBOOT code is unmodified (as it is from the distribution) for
> > SCC4 and SMC1 code. The Linux code is unmodified for
> > SMC1, and I see this behavior in case of both these serial
> > ports.
> >
> > The place where the BDI shows the PC to hang is in
> > serial_putc(...) waiting for the transmit buffer to be drained by the
> > 8260:
> >
> >     /* Wait for last character to go.
> >     */
> >     while (tbdf->cbd_sc & BD_SC_READY)
> >         ;
> >
> > Ofcourse, when the cable is present, things work well.
> >
> > Though I dont see any code path, or from hardware perspective
> > what could be wrong, I am open to any guesses/hints at
> > debugging it.
> >
> >
> > Best regards,
> > -Arun.
> >
> > On Tuesday 09 July 2002 01:14 am, Wolfgang Denk wrote:
> > > In message <200207082127.16518.ADharankar@ATTBI.Com> you wrote:
> > > > This question is common to both ppcboot and ppc-linux.
> > > > The ppcboot I am using is 1.1.5 and Linux kernel 2.4.18.
> > > >
> > > > If there is no console connected to the serial console port,
> > > > is it true that a thread sending output to it hangs? If this is
> > >
> > > No, this is NOT true.
> > >
> > > Why should it? There is no flow control used - neither in the PPCBoot
> > > nor in the Linux UART drivers...
> > >
> > > > I have a MPC8260ADS based board, and see the above
> > >
> > > ...at least not in the standard MPC8xx and MPC8260 UART drivers.
> > >
> > > > behavior under ppcboot. Under Linux using a BDI debugger
> > > > the thread sending output to the console hangs. Perhaps
> > >
> > > You must be doing something wrong.
> > >
> > > Wolfgang Denk
> >
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial console ports on systems with no console connected.

[Arun Dharankar]

This too is an excellent response! Thanks Jerry!

Here are some thoughts on the issue:

- The problem is may be because of hardware signals/flow control
  (RTS/CTS and/or DSR/DTR).  Perhaps, null modem cross
  connections may be made on the board itself for the console port.

- However, many boards have more than one serial port. In which
  case it is not possible to know at hardware design time which
  port is going to be used at a later time as console, and which for
  general purpose access. For those port(s) not used as a console,
  the hardware flow control may be important.

Given this paradigm, the flow control needs ignored or used by
software depending on whether the port is to be used as a console.
The default implementation/behavior, I believe, is also done properly
in this context - just the console case needs to be specialized.


If the above is a common case for other boards too, a common
solution may also be discussed/investigated. This was my thought
in the starting post for looking at a clean/proper solution. Again,
I think, the problem is common to ppcboot and Linux.


Jerry has also some good points, I intend to check some of
these tomorrow. Will keep the list posted with my findings.

Best regards,
-Arun.

On Wednesday 10 July 2002 07:41 am, Jerry Van Baren wrote:
> Disclaimer: This is all generic speculation (not based on knowledge of the
> board, just based on cruel experience :-)...
>
> Your description sounds a lot like flow control, either hardware or
> software, is happening.  It could also be an unhandled (or mishandled)
> error condition.  Addressing these possibilities...
>
> Hardware flow control was discounted because the hardware flow control
> lines are not run to the serial connector.  This still could cause
> problems, however, because the linux driver doesn't necessarily know that
> and quite likely still sets up the UART for hardware flow control.  If the
> flow control line (CTS*) is unterminated or used for some other purpose, it
> could be going low inadvertently, causing the hardware flow control to stop
> the UART.  Check your port initialization and what is connected to the CTS*
> line.  You want the port to be initialized so that the CTS* line is always
> high or you want to configure (or modify) the serial driver to disable
> hardware flow control.  Since your problem description explicitly stated
> that it occurred with both the SCC (has CTS*) and the SMC (no CTS*) this
> doesn't seem likely.
>
> A quick perusal of the UM indicates software flow control (XON/XOFF)
> requires software handling, so that doesn't appear to apply.  However, this
> fits your problem description fairly well.  One complaint was that an
> _unterminated_ serial connector causes problems, but plugging it into a
> terminal works.  The explanation here is that an unterminated (or
> terminated too weakly) RxData line will tend to flop around.  This will
> cause spurious characters to be received and, if ever an XOFF character is
> received (synthesized :-), the output will freeze just as you
> described.  Note that transmitting more characters will cause more spurious
> characters to be received, increasing the probability of an inadvertent
> XOFF, which also matches the problem description.  Of course, once an XOFF
> is received, the TxData stops generating noise on the RxData line and you
> never get the XON synthesized :-(.
>
> This theory also applies to an unhandled error condition: the same thing
> happens, but lots of bad characters are synthesized causing error
> interrupts.  If an error condition is unhandled or mishandled, the also Tx
> could wedge just like you described.
>
> Solutions in this case are:
> 1) Add or increase the termination to prevent the RxData line from flopping
> around when nothing is plugged in.  This is the best, but hardest, fix.
>
> 2) Unplug the serial cable: if you have a serial cable plugged into the
> board but unterminated at the far end, you just put a noise antenna onto
> your RxData line.  I've had equipment that was OK when nothing was plugged
> into the serial port, but locked up when a 6' serial cable was plugged in,
> even though there was nothing plugged into the far side.
>
> 3) Configure (or modify) the serial driver to disable software flow control
> in the driver.
>
> 4) If it is an unhandled or mishandled error condition, fix the driver.
>
> gvb
>
> At 07:45 PM 7/9/2002 -0400, Arun Dharankar wrote:
> >Thanks for your reply, Richard!
> >
> >This is definitely not so in my case, there is very little output
> >generated. Also have the serial port speed set at 115200,  I
> >dont believe this is buffer overrun issue.
> >
> >Anyway, I could work around the problem by checking for
> >the previous buffer's state and drop the characters. Would be
> >nice to get to the root cause.
> >
> >Best regards,
> >-Arun.
> >
> >On Tuesday 09 July 2002 06:08 pm, Richard Williams wrote:
> > > I've had a board hang in the same place before. Can't remember exactly
> > > the circumstances but it was triggered by me turning on a lot of debug
> > > messages in kernel modules.
> > >
> > > Perhaps buffer overrun on the console port?
> > >
> > > Regards,
> > > Richard
> > >
> > > -----Original Message-----
> > > From: Arun Dharankar [mailto:ADharankar@ATTBI.Com]
> > > Sent: Wednesday, 10 July 2002 12:08 a.m.
> > > To: Wolfgang Denk
> > > Cc: linuxppc-embedded@lists.linuxppc.org
> > > Subject: Re: Serial console ports on systems with no console connected.
> > >
> > >
> > >
> > > Hello, and thanks for your reply!
> > >
> > > The board has SCC4 and SMC1 based serial ports. I have
> > > tried both of these as console ports under Linux and PPCBOOT.
> > > PPCBOOT code is unmodified (as it is from the distribution) for
> > > SCC4 and SMC1 code. The Linux code is unmodified for
> > > SMC1, and I see this behavior in case of both these serial
> > > ports.
> > >
> > > The place where the BDI shows the PC to hang is in
> > > serial_putc(...) waiting for the transmit buffer to be drained by the
> > > 8260:
> > >
> > >     /* Wait for last character to go.
> > >     */
> > >     while (tbdf->cbd_sc & BD_SC_READY)
> > >         ;
> > >
> > > Ofcourse, when the cable is present, things work well.
> > >
> > > Though I dont see any code path, or from hardware perspective
> > > what could be wrong, I am open to any guesses/hints at
> > > debugging it.
> > >
> > >
> > > Best regards,
> > > -Arun.
> > >
> > > On Tuesday 09 July 2002 01:14 am, Wolfgang Denk wrote:
> > > > In message <200207082127.16518.ADharankar@ATTBI.Com> you wrote:
> > > > > This question is common to both ppcboot and ppc-linux.
> > > > > The ppcboot I am using is 1.1.5 and Linux kernel 2.4.18.
> > > > >
> > > > > If there is no console connected to the serial console port,
> > > > > is it true that a thread sending output to it hangs? If this is
> > > >
> > > > No, this is NOT true.
> > > >
> > > > Why should it? There is no flow control used - neither in the PPCBoot
> > > > nor in the Linux UART drivers...
> > > >
> > > > > I have a MPC8260ADS based board, and see the above
> > > >
> > > > ...at least not in the standard MPC8xx and MPC8260 UART drivers.
> > > >
> > > > > behavior under ppcboot. Under Linux using a BDI debugger
> > > > > the thread sending output to the console hangs. Perhaps
> > > >
> > > > You must be doing something wrong.
> > > >
> > > > Wolfgang Denk
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial console ports on systems with no console connected.

[Arun Dharankar]

Hello.

Thanks to all the many folks who replied directly to me and to
the list.

The conclusion for my case is that the RTS/CTS. DSR/DTR and
DCD need to be null modem'd. Working around by ignoring the
flow control  (as I mentioned in earlier port) also is workable for
me because I know which port is the console, and we dont
have a need for the other serial port for any other use.

Best regards,
-Arun.


On Wednesday 10 July 2002 09:53 pm, Arun Dharankar wrote:
> This too is an excellent response! Thanks Jerry!
>
> Here are some thoughts on the issue:
>
> - The problem is may be because of hardware signals/flow control
>   (RTS/CTS and/or DSR/DTR).  Perhaps, null modem cross
>   connections may be made on the board itself for the console port.
>
> - However, many boards have more than one serial port. In which
>   case it is not possible to know at hardware design time which
>   port is going to be used at a later time as console, and which for
>   general purpose access. For those port(s) not used as a console,
>   the hardware flow control may be important.
>
> Given this paradigm, the flow control needs ignored or used by
> software depending on whether the port is to be used as a console.
> The default implementation/behavior, I believe, is also done properly
> in this context - just the console case needs to be specialized.
>
>
> If the above is a common case for other boards too, a common
> solution may also be discussed/investigated. This was my thought
> in the starting post for looking at a clean/proper solution. Again,
> I think, the problem is common to ppcboot and Linux.
>
>
> Jerry has also some good points, I intend to check some of
> these tomorrow. Will keep the list posted with my findings.
>
> Best regards,
> -Arun.
>
> On Wednesday 10 July 2002 07:41 am, Jerry Van Baren wrote:
> > Disclaimer: This is all generic speculation (not based on knowledge of
> > the board, just based on cruel experience :-)...
> >
> > Your description sounds a lot like flow control, either hardware or
> > software, is happening.  It could also be an unhandled (or mishandled)
> > error condition.  Addressing these possibilities...
> >
> > Hardware flow control was discounted because the hardware flow control
> > lines are not run to the serial connector.  This still could cause
> > problems, however, because the linux driver doesn't necessarily know that
> > and quite likely still sets up the UART for hardware flow control.  If
> > the flow control line (CTS*) is unterminated or used for some other
> > purpose, it could be going low inadvertently, causing the hardware flow
> > control to stop the UART.  Check your port initialization and what is
> > connected to the CTS* line.  You want the port to be initialized so that
> > the CTS* line is always high or you want to configure (or modify) the
> > serial driver to disable hardware flow control.  Since your problem
> > description explicitly stated that it occurred with both the SCC (has
> > CTS*) and the SMC (no CTS*) this doesn't seem likely.
> >
> > A quick perusal of the UM indicates software flow control (XON/XOFF)
> > requires software handling, so that doesn't appear to apply.  However,
> > this fits your problem description fairly well.  One complaint was that
> > an _unterminated_ serial connector causes problems, but plugging it into
> > a terminal works.  The explanation here is that an unterminated (or
> > terminated too weakly) RxData line will tend to flop around.  This will
> > cause spurious characters to be received and, if ever an XOFF character
> > is received (synthesized :-), the output will freeze just as you
> > described.  Note that transmitting more characters will cause more
> > spurious characters to be received, increasing the probability of an
> > inadvertent XOFF, which also matches the problem description.  Of course,
> > once an XOFF is received, the TxData stops generating noise on the RxData
> > line and you never get the XON synthesized :-(.
> >
> > This theory also applies to an unhandled error condition: the same thing
> > happens, but lots of bad characters are synthesized causing error
> > interrupts.  If an error condition is unhandled or mishandled, the also
> > Tx could wedge just like you described.
> >
> > Solutions in this case are:
> > 1) Add or increase the termination to prevent the RxData line from
> > flopping around when nothing is plugged in.  This is the best, but
> > hardest, fix.
> >
> > 2) Unplug the serial cable: if you have a serial cable plugged into the
> > board but unterminated at the far end, you just put a noise antenna onto
> > your RxData line.  I've had equipment that was OK when nothing was
> > plugged into the serial port, but locked up when a 6' serial cable was
> > plugged in, even though there was nothing plugged into the far side.
> >
> > 3) Configure (or modify) the serial driver to disable software flow
> > control in the driver.
> >
> > 4) If it is an unhandled or mishandled error condition, fix the driver.
> >
> > gvb
> >
> > At 07:45 PM 7/9/2002 -0400, Arun Dharankar wrote:
> > >Thanks for your reply, Richard!
> > >
> > >This is definitely not so in my case, there is very little output
> > >generated. Also have the serial port speed set at 115200,  I
> > >dont believe this is buffer overrun issue.
> > >
> > >Anyway, I could work around the problem by checking for
> > >the previous buffer's state and drop the characters. Would be
> > >nice to get to the root cause.
> > >
> > >Best regards,
> > >-Arun.
> > >
> > >On Tuesday 09 July 2002 06:08 pm, Richard Williams wrote:
> > > > I've had a board hang in the same place before. Can't remember
> > > > exactly the circumstances but it was triggered by me turning on a lot
> > > > of debug messages in kernel modules.
> > > >
> > > > Perhaps buffer overrun on the console port?
> > > >
> > > > Regards,
> > > > Richard
> > > >
> > > > -----Original Message-----
> > > > From: Arun Dharankar [mailto:ADharankar@ATTBI.Com]
> > > > Sent: Wednesday, 10 July 2002 12:08 a.m.
> > > > To: Wolfgang Denk
> > > > Cc: linuxppc-embedded@lists.linuxppc.org
> > > > Subject: Re: Serial console ports on systems with no console
> > > > connected.
> > > >
> > > >
> > > >
> > > > Hello, and thanks for your reply!
> > > >
> > > > The board has SCC4 and SMC1 based serial ports. I have
> > > > tried both of these as console ports under Linux and PPCBOOT.
> > > > PPCBOOT code is unmodified (as it is from the distribution) for
> > > > SCC4 and SMC1 code. The Linux code is unmodified for
> > > > SMC1, and I see this behavior in case of both these serial
> > > > ports.
> > > >
> > > > The place where the BDI shows the PC to hang is in
> > > > serial_putc(...) waiting for the transmit buffer to be drained by the
> > > > 8260:
> > > >
> > > >     /* Wait for last character to go.
> > > >     */
> > > >     while (tbdf->cbd_sc & BD_SC_READY)
> > > >         ;
> > > >
> > > > Ofcourse, when the cable is present, things work well.
> > > >
> > > > Though I dont see any code path, or from hardware perspective
> > > > what could be wrong, I am open to any guesses/hints at
> > > > debugging it.
> > > >
> > > >
> > > > Best regards,
> > > > -Arun.
> > > >
> > > > On Tuesday 09 July 2002 01:14 am, Wolfgang Denk wrote:
> > > > > In message <200207082127.16518.ADharankar@ATTBI.Com> you wrote:
> > > > > > This question is common to both ppcboot and ppc-linux.
> > > > > > The ppcboot I am using is 1.1.5 and Linux kernel 2.4.18.
> > > > > >
> > > > > > If there is no console connected to the serial console port,
> > > > > > is it true that a thread sending output to it hangs? If this is
> > > > >
> > > > > No, this is NOT true.
> > > > >
> > > > > Why should it? There is no flow control used - neither in the
> > > > > PPCBoot nor in the Linux UART drivers...
> > > > >
> > > > > > I have a MPC8260ADS based board, and see the above
> > > > >
> > > > > ...at least not in the standard MPC8xx and MPC8260 UART drivers.
> > > > >
> > > > > > behavior under ppcboot. Under Linux using a BDI debugger
> > > > > > the thread sending output to the console hangs. Perhaps
> > > > >
> > > > > You must be doing something wrong.
> > > > >
> > > > > Wolfgang Denk
> >


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial console ports on systems with no console connected.

[Wolfgang Denk]

Dear Arun,

in message <200207211510.36128.ADharankar@ATTBI.Com> you wrote:
>
> The conclusion for my case is that the RTS/CTS. DSR/DTR and
> DCD need to be null modem'd. Working around by ignoring the
> flow control  (as I mentioned in earlier port) also is workable for
> me because I know which port is the console, and we dont
> have a need for the other serial port for any other use.

This makes little sense to me.

You mentioned before that you're on a 8260, using SMC1 and  SCC4  for
serial ports:

> The board has SCC4 and SMC1 based serial ports. I have
> tried both of these as console ports under Linux and PPCBOOT.
> PPCBOOT code is unmodified (as it is from the distribution) for
> SCC4 and SMC1 code. The Linux code is unmodified for
> SMC1, and I see this behavior in case of both these serial
> ports.

Well, I don;t know what you did to support SCC4  in  the  Linux  UART
driver,  and  if you added HW flow control there. The standard driver
does not contain any HW flow control.

And the SMC port does not even provide a chance to implement HW  flow
control since it has no handshake signals at all.

How can you null modem RTS/CTS, DSR/DTR  and  DCD  signals  if  there
aren't any such signals on the port?

I'm confused.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I am a computer. I am dumber than any human and smarter than any  ad-
ministrator.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial console ports on systems with no console connected.

[Murray Jensen]

On Thu, 25 Jul 2002 20:58:04 -0400, Arun Dharankar <ADharankar@ATTBI.Com> writes:
>As for what I meant to say is that the solution for me is to use the
>SCC4 based port which has been designated as the console port
>for the boards. This one does have the flow control wired to the
>8260 and makes a difference when I use a null modem.

I dealt with this a long time ago, so the details are a bit hazy, but I seem
to recall that you could set the I/O pins on the 8260 that provided the flow
control functions to be general purpose I/O pins, which forced the flow control
functions to be tied in a default state (which I think was equivalent to the
"tied high" state on the serial port side). This way you can use a much simpler
serial cable. Check out the I/O pin init table in your board configuration (you
also have to ensure that the secondary I/O pins for the flow control functions
are not enabled).

Did you try the serial port a lower speeds? Are you running your SCC port at
115200 still? If so, what are you using as the clock source for the BRG for
the SCC port? What is your BRG clock rate (it is printed by ppcboot when the
board powers up - as brg_clk)?

The default BRG clock is the VCO_OUT clock rate divided by 16. To find out the
value of VCO_OUT can be complicated, but on my 8260, which is a 133/133/66
device (cpu/cpm/bus clocks), VCO_OUT is twice the CPM clock rate (266MHz or
rather, 266,666,664 Hz give or take a couple). So 266,666,664 / 16 = 16666666Hz
We usually use 16 times over-sampling in the SCC, hence you have a number like
1041667 which you must divide to provide all your baud rates. This is not a
nice number for baud rates (the Hymod board has an external clock source that
is programmed to run at 3686400 which gives the number 230400 after accounting
for 16 times oversampling - a nice looking number for baud rates.

I still think you will have trouble with the mismatch in baud rate at speeds
higher than 38400 when you use the default BRG_CLK. Can anyone else confirm
this? Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech.      Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/

To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.

The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial console ports on systems with no console connected.

[Arun Dharankar]

Hello, and thanks for your reply!

The board has SCC4 and SMC1 based serial ports. I have
tried both of these as console ports under Linux and PPCBOOT.
PPCBOOT code is unmodified (as it is from the distribution) for
SCC4 and SMC1 code. The Linux code is unmodified for
SMC1, and I see this behavior in case of both these serial
ports.

The place where the BDI shows the PC to hang is in
serial_putc(...) waiting for the transmit buffer to be drained by the
8260:

    /* Wait for last character to go.
    */
    while (tbdf->cbd_sc & BD_SC_READY)
        ;

Ofcourse, when the cable is present, things work well.

Though I dont see any code path, or from hardware perspective
what could be wrong, I am open to any guesses/hints at
debugging it.


Best regards,
-Arun.



On Tuesday 09 July 2002 01:14 am, Wolfgang Denk wrote:
> In message <200207082127.16518.ADharankar@ATTBI.Com> you wrote:
> > This question is common to both ppcboot and ppc-linux.
> > The ppcboot I am using is 1.1.5 and Linux kernel 2.4.18.
> >
> > If there is no console connected to the serial console port,
> > is it true that a thread sending output to it hangs? If this is
>
> No, this is NOT true.
>
> Why should it? There is no flow control used - neither in the PPCBoot
> nor in the Linux UART drivers...
>
> > I have a MPC8260ADS based board, and see the above
>
> ...at least not in the standard MPC8xx and MPC8260 UART drivers.
>
> > behavior under ppcboot. Under Linux using a BDI debugger
> > the thread sending output to the console hangs. Perhaps
>
> You must be doing something wrong.
>
> Wolfgang Denk


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Serial console ports on systems with no console connected.

[Wolfgang Denk]

In message <200207082127.16518.ADharankar@ATTBI.Com> you wrote:
>
> This question is common to both ppcboot and ppc-linux.
> The ppcboot I am using is 1.1.5 and Linux kernel 2.4.18.
>
> If there is no console connected to the serial console port,
> is it true that a thread sending output to it hangs? If this is

No, this is NOT true.

Why should it? There is no flow control used - neither in the PPCBoot
nor in the Linux UART drivers...

> I have a MPC8260ADS based board, and see the above

...at least not in the standard MPC8xx and MPC8260 UART drivers.

> behavior under ppcboot. Under Linux using a BDI debugger
> the thread sending output to the console hangs. Perhaps

You must be doing something wrong.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with  a
different reality system.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Serial console ports on systems with no console connected.

[Arun Dharankar]

Greetings...

This question is common to both ppcboot and ppc-linux.
The ppcboot I am using is 1.1.5 and Linux kernel 2.4.18.

If there is no console connected to the serial console port,
is it true that a thread sending output to it hangs? If this is
ppcboot the bootup process would not proceed? What
consequences would we see on Linux?

I have a MPC8260ADS based board, and see the above
behavior under ppcboot. Under Linux using a BDI debugger
the thread sending output to the console hangs. Perhaps
under Linux we can set the termio modes to have no
flow control, but am not sure if this will solve the problem.

If this is true, is there a clean/proper way to have a setup
such that this hang can be avoided?

Best regards,
-Arun.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/