Wait a minute. Aren't you the person who originally proposed this,
and you don't know how it's used?
Here are 2 possibilities:
a. Some pre-production motherboards are built with serial ports on
them, only for debugging. Never shipped to customers like this.
The documented I/O resources for this serial port are in the
special ACPI table that you referred to last Thursday.
(second one is below)
> > There was some talk about using a low level IP console over ethernet,
> > but I would imagine this is more complex than the same thing on a
> > parallel-port. I could be wrong. Of course, an IP console has the
> > advantage of being useful over a longer distance than a parallel cable,
> > but may have the disadvantage of poor security.
> >
>
> IP console qould require a significant amount of network protocol stack
> to be up and running. That would make console available pretty late in
> bootup sequence. IMO, console should be simple and reliable if it is to
> be used for debugging at all. Even if console were to be used to print
> just errors and information messages, it should still be pretty simple
> to ensure those messages do get printed out. A serial port meets those
> requirements. USB is too complex, as you said, unless it could be
> managed fully in firmware/BIOS. But then again I would hate to have
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> kernel make calls into firmware for simple console I/O.
b. Bingo. USB chipsets "could" do this -- i.e., could translate
"simple" reads/writes into USB protocol transfers.
-- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/