Odd-looking serial console prompt on RPI2

[Jayachandran C.]

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.