Hardware Console Redirection

Brian A. Seklecki lavalamp at spiritual-machines.org
Tue Oct 31 23:18:35 UTC 2006


God I miss the days of the good old PC Weasel.  Those guys would have made 
a killing selling the technology to Intel/Dell/Phoenix.  Instead this is 
what we're stuck with....

On two platforms I work with:

  1) Dell Poweredge [1,2][8,9]50
  2) Axiomtek VIA Embedded SBC83672

I have noticed that the "Phoenix BIOS" console redirection feature on both 
discontinues to operate once the kernel has booted (however, the 1st/2nd 
stage boot loaders work fine).

I'm trying to avoid having to use a combination of both hardware and 
software console redirection.

The advantage of native, hardware level BIOS -> VGA emulated console 
redirection is that, much like Sun/MacPPC or any OPF/PROM aware platform 
(Soekris), the OS/Bootblocks need not be aware of the serial console 
semantics; -- only of a benign VGA console.

The only limitation being interpretation of certain escape characters.

The question becomes:

Is there some routine in the *BSD kernel console code that performs an 
operation, perhaps a reset, on the serial ports, that wouldn't happen in 
DOS?

In the case of the Axiom device, the console is redirected to the BIOS 
level "com0" 0x3f8.  In the case of the PowerEdge, the redirection is to a 
"virtual com1" which is attached to the DRAC5 LOM card.

I tried the FreeBSD loader(8) hint.sio.1.flags="0x40" to attempt to have 
the kernel ignore the device without success.

There was some discussion of this on misc at openbsd.org:

http://archives.neohapsis.com/archives/openbsd/2006-08/1903.html

That essentially the os needs to "block" the virtual serial port.  Seems 
like a conflict of interest.

Now taking ideas on how to work around this.


l8*
 	-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
 	       http://www.spiritual-machines.org/

"...from back in the heady days when "helpdesk" meant nothing, "diskquota"
meant everything, and lives could be bought and sold for a couple of pages
of laser printout - and frequently were."


More information about the freebsd-questions mailing list