Re: git: df065f699f1f - main - stand: More sensible defaults when ConOut is missing

On Fri, Sep 23, 2022 at 3:29 PM John Baldwin <jhb@freebsd.org> wrote:

> On 8/26/22 9:18 PM, Warner Losh wrote:
> > The branch main has been updated by imp:
> >
> > URL:
> https://cgit.FreeBSD.org/src/commit/?id=df065f699f1ff819bb9607c44a6754275ab335ed
> >
> > commit df065f699f1ff819bb9607c44a6754275ab335ed
> > Author:     Warner Losh <imp@FreeBSD.org>
> > AuthorDate: 2022-08-26 21:46:33 +0000
> > Commit:     Warner Losh <imp@FreeBSD.org>
> > CommitDate: 2022-08-27 04:17:56 +0000
> >
> >      stand: More sensible defaults when ConOut is missing
> >
> >      When ConOut is missing, we used to default to serial. Except we did
> it
> >      in the worst way possible by just setting the howto bits and not
> >      updating the console setting, which lead to weird behavior where
> we'd
> >      get some things on the video port, others on serial.
> >
> >      Instead, set console to "efi,comconsole" for this case. Also set
> >      RB_MULTIPLE always (so we get dual consoles from the kernel) and or
> in
> >      RB_SERIAL when we can't find GOPs that suggest the precense of a
> video
> >      console. This will put output in the most places and have a sensible
> >      default for 'primary' console.
> >
> >      Sponsored by:           Netflix
> >      Reviewed by:            emaste, manu
> >      Differential Revision:  https://reviews.freebsd.org/D36299
>
> One possibly surprising result of this is that I did not get dual console
> output on my rpi after this.  (Curiously this only affected my arm64 image
> but not my armv7 image.)  Loader output goes to both, but kernel output is
> only on the video console (which I don't normally use for my pi).  (Also,
> none of the ANSI escape sequences used by the loader work on the pi's video
> console, so once the menu starts it just looks like raw ANSI code garbage
> until the kernel starts booting.)
>
> Not sure if this warrants UPDATING as the effect is that the serial console
> seems to stop working?  The lack of working dual console output is perhaps
> the only real bug.  Not sure what is up there.
>

We don't do the ANSI interpretation correctly on arm for reasons that I
don't recall. It may be just not defining TERM_EMU on arm. That's a separate
issue, one that might be easy to fix.

It is true that this change went from 'We don't know, so use both' to ' Oh,
there
might be a video thing, use only that'. I'm not completely happy with this,
but
was talked into it.

What does u-boot/rpi provide for ConIn?

>FWIW, using 'console="comconsole,efi"' did not work as a workaround.  Same
>results (used the video console only for the kernel).  Had to use
>'console="comconsole"' in /boot/loader.conf.

That's definitely a bug as well. comconsole on arm EFI is special as well,
but not
that special.

The loader gets to set the console, and it tells the kernel through some
rather byzantine
hints what to use. One can also set the console a little more directly with
hw.uart.console
which tells the kernel, when configuring a serial console, which one to
use. You can also
use boot_serial=yes boot_dual=no in the environment.

The whole interface / handoff has been a series of historical hacks that
have not layered
well at all...

Warner