Re: serial console device, and installboot vs. /boot.cfg

On Sat, Feb 10, 2024 at 11:35:16AM -0800, Greg A. Woods wrote:
> At Thu, 8 Feb 2024 16:10:09 -0800, Steve Rikli <[email protected]> wrote:
> Subject: Re: serial console device, and installboot vs. /boot.cfg
> >
> > What constitutes a "fail" for the COM port? Iirc the man page said
> > "outputs a character" to each COM port, and if it succeeds then that's
> > the console; else it goes to the PC keyboard for console.
> 
> Well if there is a (UART) device, and if the device functions to output
> a character, then it works, even if the char goes blind into the ether!  :-)

I think that's essentially what I see. E.g. with serial cable connected
to the PC's COM port and /boot.confg "consdev=com0,115200", the serial
console works well as described elsewhere in this thread.

Same with "consdev=auto,115200".

If I disonnect the serial cable nothing changes. Of course there's no
output on the serial line, but NetBSD's notion of console has not moved
to keyboard+vga -- it still uses the com0 port. Re-connecting the serial
cable after NetBSD boots shows login: prompt as constty as usual.

Different but related, if I completely disable the COM port in PC's
BIOS, such that NetBSD doesn't see com0 at all, then console switches to
keyboard regardless of consdev=com0 in /boot.cfg; this seems like quite
reasonable behavior.

> I've always assumed myself that if the port was well-wired to a DCE
> device that was _not_ asserting DCD (and/or DSR, and CTS) then the
> output would fail and the code would move on to try the next device.  If
> I remember my RS232 right this should be the case for a disconnected
> RS232 line, but....

I could further experiment with a 3-wire (TXD,RXD,GND only) DB9 connector
instead of the full-pinned hood I'm using now; but for my use-case, the
serial console works properly with this connector, and the other useful
scenario for me would be what happens to console when the serial cable
connector is disconnected altogether.

> In any case I've never actually tested this with a connected line and a
> "down" DCE port -- it all might depend on just how the boot code
> configures the UART, and it may be too lenient and assuming the control
> lines are irrelevant, which is actually the wrong thing to do in the
> case where you want to test for a "connected" line.

In general, when I have a serial cable connected to the COM port, I use
that as the system console. Ideally, if there's no cable, then I'd like
it to punt back to the Pc keyboard+vga. That's presumably a harder
problem, and it doesn't happen with my setup, at least not with
"consdev=auto"; this is not a fatal problem for me at all, and the
status quo is entirely manageable for my purposes.