From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Content-Type: text/plain; charset="iso-8859-1" From: Arun Dharankar To: Jerry Van Baren , linuxppc-embedded@lists.linuxppc.org Subject: Re: Serial console ports on systems with no console connected. Date: Sun, 21 Jul 2002 15:10:36 -0400 References: <8D7C5F56B409554D9D46AC22195807F3156BEB@exchwenz01.smtp.dmcwave.co.nz> <5.1.0.14.2.20020710070749.0223f9a0@falcon.si.com> <200207102153.19746.ADharankar@ATTBI.Com> In-Reply-To: <200207102153.19746.ADharankar@ATTBI.Com> MIME-Version: 1.0 Message-Id: <200207211510.36128.ADharankar@ATTBI.Com> Sender: owner-linuxppc-embedded@lists.linuxppc.org List-Id: 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/