Odd-looking serial console prompt on RPI2

[Ian Lepore]

On Mon, 2017-03-06 at 13:59 +0530, Jayachandran C. wrote:
> Hi Ian,
> 
> On Sun, Mar 5, 2017 at 3:32 AM, Ian Lepore <ian at freebsd.org> wrote:
> > 
> > On Sat, 2017-03-04 at 22:24 +0530, Jayachandran C. wrote:
> > > 
> > > On Thu, Mar 2, 2017 at 7:35 AM, Ian Lepore <ian at freebsd.org>
> > > wrote:
> > > > 
> > > > 
> > > > On Wed, 2017-03-01 at 18:01 -0800, Oleksandr Tymoshenko wrote:
> > > > > 
> > > > > 
> > > > > Ian Lepore (ian at freebsd.org) wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, 2017-03-01 at 16:03 -0800, bob prohaska wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Wed, Mar 01, 2017 at 09:20:13PM +0100, Michael Tuexen
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Interesting... Let us know what works and what
> > > > > > > > doesn't...
> > > > > > > > 
> > > > > > > > Best regards
> > > > > > > > Michael
> > > > > > > > 
> > > > > > > As of FreeBSD 12.0-CURRENT (RPI2) #0 r314450: Wed Mar  1
> > > > > > > 14:48:26
> > > > > > > PST
> > > > > > > 2017
> > > > > > > the serial console is still corrupt (output truncated,
> > > > > > > input
> > > > > > > not
> > > > > > > echoed
> > > > > > > but treated like the enter key).  The serial console does
> > > > > > > seem to
> > > > > > > work
> > > > > > > with U-boot and loader, so I don't think it's the
> > > > > > > upstream
> > > > > > > hardware.
> > > > > > > 
> > > > > > > The HDMI console looks normal and USB keyboard input
> > > > > > > seems to
> > > > > > > work.
> > > > > > > 
> > > > > > > There have been several updates to /usr/src/sys/dev/uart
> > > > > > > and
> > > > > > > it
> > > > > > > looks
> > > > > > > as if kernel updates are still coming. Maybe the job
> > > > > > > simply
> > > > > > > isn't
> > > > > > > done yet.
> > > > > > > 
> > > > > > > bob
> > > > > > > 
> > > > > > It seems like this might be caused by r314318.  Can someone
> > > > > > having
> > > > > > this problem confirm if 314317 works and 314318 fails?
> > > > > Tested on my RPi2, 314317 - works, 314318 - broken
> > > > > 
> > > > CC'ing jchandra at .
> > > > 
> > > > I wonder if there is some bad interaction when the same uart is
> > > > used as
> > > > a console and a tty?
> > > I don't have a RPi3 setup to test now, I will look at the code
> > > again
> > > to see if
> > > I can find an issue.
> > > 
> > > Otherwise I will revert the change until we can find why the RPi
> > > UART
> > > breaks
> > > with these changes.
> > > 
> > > Thanks,
> > > JC.
> > The bugs should be fixed as of r314682.  It looks like the bugs
> > have
> > long been in the pl011 driver, but were masked by having a fifo
> > depth
> > of 1 byte -- it all sorta worked by accident previously.
> Looked thru r314681 and r314682, thanks for fixing this up.
> 
> There seems to be a difference in behavior in IFLS settings on
> different
> platforms. I did not see a reasonable way to handle the tx fifo being
> full
> when sc_txbuf is partially used, which is why I skipped this case in
> the
> original commit - that was a mistake.
> 
> Thanks,
> JC.

Hmm.  Does that imply the changes I made to set the fifo trigger level
to 3/4 may not work on some other platforms?  I was only able to test
on rpi-b.

I've always hated the tx interface between the core uart code and the
hardware drivers.  The idea that when a tx interrupt happens, the
hardware code has to accept exactly as many characters as the tx fifo
watermark level is just... strange.  It's especially hard to work with
when a uart device has dma support.  But redoing it without breaking
every existing driver is hard.

-- Ian