Date: Mon, 11 Mar 1996 17:37:00 -0800 From: Paul Traina <pst@shockwave.com> To: Douglas Ambrisko <ambrisko@tcs.com> Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org Subject: Re: COMCONSOLE: a patch and a problem Message-ID: <199603120137.RAA03439@precipice.shockwave.com> In-Reply-To: Your message of "Mon, 11 Mar 1996 13:29:57 PST." <199603112129.NAA02528@cozumel.tcs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Cool... send in patches From: Douglas Ambrisko <ambrisko@tcs.com> Subject: Re: COMCONSOLE: a patch and a problem Given all the talk about serial consoles, I've been playing with them as well >>. This is what I've done. - Modified sysinstall to work with a serial console or graphics console. This means you can install a machine without a graphics card. (it is a little messy when loading packages, I should probably turn that off, but I did load a system via the serial port). - Hacked the biosboot code to echo and take input from both the graphics screen/keyboard and com1. This way I can control the boot by either the normal console or serial console. It would be nice if I could save the boot mode for the default of the next boot. I also filter out garbage from the serial port incase a mouse is connected to it and is talking back. One problem would be trying to screen out a modem on com1 talking back ... is this very common? Also with the method, I don't have to worry about keyboard probes but may have to for a serial port. I'm not sure if this is that good of an idea, but it works pretty well and it was kind of neat to try. - Run getty on /dev/console and not on /dev/ttyv0, so I get a console getty no matter which way I boot. The advantage of this stuff is to simplify remote (or lazy) debugging of stuf >>f. It is nice to be able to steal the console and do everything via a serial port and then return it to normal operations. Doug A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603120137.RAA03439>