I am working on adding support for serial console on legacy free
machines. Legacy free machines are not expected to have the legacy COM
ports. The serial ports on these machines can exist in I/O space, memory
space or they could be PCI devices. This brings up the problem of
detecting where the serial console is. This problem is supposed to be
solved by ACPI 2.0 tables. The table that gives the details of serial
console is "Serial Port Console Redirection" (SPCR) table. This table
gives me almost all the information I need to initialize and use a
serial console. The bummer is this table was designed by Microsoft and
Microsoft owns the copyright on it. Microsoft primarily designed this
table for use by Whistler. Their copyright may cause potential problems
with using it in Linux. This makes me reluctant to use this table. I
would like to know how do others feel about using an ACPI table with
Microsoft copyright. I would like to try to push for another table in
ACPI spec that is free from copyright by any corporation and is simply a
part of spec, if most Linux developers are opposed to using a
copyrighted ACPI table.
Please ask questions if you need more info. URL for SPCR table
definition, if you would like to look at it, is
<http://www.microsoft.com/hwdev/headless/download/SerialPortRedir.zip>.
--
Khalid
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
> console is "Serial Port Console Redirection" (SPCR) table. This table
> gives me almost all the information I need to initialize and use a
> serial console. The bummer is this table was designed by Microsoft and
> Microsoft owns the copyright on it. Microsoft primarily designed this
> table for use by Whistler. Their copyright may cause potential problems
> with using it in Linux. This makes me reluctant to use this table. I
Such as ?
If its a table that microsoft added to ACPI and its well thought out I don't
see a big problem technically. There are a collection of BIOS services we
use that were microsoft originated
On Thu, 26 Jul 2001, Khalid Aziz wrote:
> The bummer is this table was designed by Microsoft and
> Microsoft owns the copyright on it.
This is an interface definition IMHO, so you cannot copyright it. But
IANAL.
Simon
--
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Alan Cox wrote:
>
> > console is "Serial Port Console Redirection" (SPCR) table. This table
> > gives me almost all the information I need to initialize and use a
> > serial console. The bummer is this table was designed by Microsoft and
> > Microsoft owns the copyright on it. Microsoft primarily designed this
> > table for use by Whistler. Their copyright may cause potential problems
> > with using it in Linux. This makes me reluctant to use this table. I
>
> Such as ?
>
> If its a table that microsoft added to ACPI and its well thought out I don't
> see a big problem technically. There are a collection of BIOS services we
> use that were microsoft originated
I can not say this table is part of ACPI 2.0. ACPI 2.0 Spec document
lists SPCR in the DESCRIPTION_HEADER signatures but calls it Microsoft
Serial Port Console Redirection Table and refers to the URL on Microsoft
web site. If you go to this URL, you see the Microsoft copyright and
terms of use license. The same applies to DBGP (Debug Port Table).
--
Khalid
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
Simon Richter wrote:
>
> On Thu, 26 Jul 2001, Khalid Aziz wrote:
>
> > The bummer is this table was designed by Microsoft and
> > Microsoft owns the copyright on it.
>
> This is an interface definition IMHO, so you cannot copyright it. But
> IANAL.
>
> Simon
>
That is a legal issue and I am not quite ready to go to battle with
Microsoft over a legal issue :-) From what I can see, the table
definition comes with a Microsoft copyright and terms of use license.
--
Khalid
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
On Thu, 26 Jul 2001, Khalid Aziz wrote:
> serial console. The bummer is this table was designed by Microsoft and
> Microsoft owns the copyright on it. Microsoft primarily designed this
Microsoft owns the copyright on that particular document.
If I were to give you an mp3 with descriptions of what
various bits to poke at you'd be free to do whatever you
want with that info ;)
In fact, I suspect you're already free to do whatever
you want with the info contained in the document...
Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
Rik van Riel wrote:
>
> On Thu, 26 Jul 2001, Khalid Aziz wrote:
>
> > serial console. The bummer is this table was designed by Microsoft and
> > Microsoft owns the copyright on it. Microsoft primarily designed this
>
> Microsoft owns the copyright on that particular document.
>
> If I were to give you an mp3 with descriptions of what
> various bits to poke at you'd be free to do whatever you
> want with that info ;)
>
> In fact, I suspect you're already free to do whatever
> you want with the info contained in the document...
>
You are possibly right. It would be better to use SPCR as opposed to
another equivalent table since every vendor is extremely likely to
include SPCR in their ACPI implementation in the firmware since
Microsoft would require it, which may not be the case with another
table. If everyone feels there is no problem with using SPCR as it is,
then I can release the code I have already done to support it. One thing
I should point out is since Microsoft owns the definition for SPCR (same
applies to DBGP which defines a Debug serial port), they can easily
change the defitnition of the table and Linux will have to play catch
up, although that situation would be nothing new.
Here is an excerpt from the disclaimer in the table description document
for anyone interested:
"Disclaimer: The information contained in this document represents the
current view of Microsoft Corporation on the issues discussed as of the
date of publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part
of Microsoft, and Microsoft cannot guarantee the accuracy of any
information presented. This document is for informational purposes only.
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft Corporation may have patents or pending patent applications,
trademarks, copyrights, or other intellectual property rights covering
subject matter in this document. The furnishing of this document does
not give you any license to the patents, trademarks, copyrights, or
other intellectual property rights except as expressly provided in any
written license agreement from Microsoft Corporation.
Microsoft does not make any representation or warranty regarding
specifications in this document or any product or item developed based
on these specifications. Microsoft disclaims all express and implied
warranties, including but not limited to the implied warranties or
merchantability, fitness for a particular purpose and freedom from
infringement. Without limiting the generality of the foregoing,
Microsoft does not make any warranty of any kind that any item
developed based on these specifications, or any portion of a
specification, will not infringe any copyright, patent, trade secret or
other intellectual property right of any person or entity in any
country. It is your responsibility to seek licenses for such
intellectual property rights where appropriate. Microsoft shall not be
liable for any damages arising out of or in connection with the use of
these specifications, including liability for lost profit, business
interruption, or any other damages whatsoever."
--
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
The acpitbl perl script doesn't display correctly the contents of the FADT
table flags, due to a 3-byte reserved field which is not handled correctly in
the show_table function.
I attached a patch to this e-mail.
Best regards,
Laurent Pinchart
Khalid Aziz writes:
> I am working on adding support for serial console on legacy free
> machines. Legacy free machines are not expected to have the legacy COM
> ports.
Has anyone considered allowing console devices to run over bi-directional
parallel ports? I imagine most of the required code is in PLIP and serial,
which unfortunately I know nothing about.
Several newer systems I have today do not have physical serial ports at all,
but all of them (even laptops) still have bi-directional parallel ports.
I suppose there may be some difficulties in exporting a "serial-like"
interface to the user apps (e.g. minicom and such), but maybe not.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Andreas Dilger wrote:
>
> Khalid Aziz writes:
> > I am working on adding support for serial console on legacy free
> > machines. Legacy free machines are not expected to have the legacy COM
> > ports.
>
> Has anyone considered allowing console devices to run over bi-directional
> parallel ports? I imagine most of the required code is in PLIP and serial,
> which unfortunately I know nothing about.
>
> Several newer systems I have today do not have physical serial ports at all,
> but all of them (even laptops) still have bi-directional parallel ports.
>
> I suppose there may be some difficulties in exporting a "serial-like"
> interface to the user apps (e.g. minicom and such), but maybe not.
>
SH supports console on line printer which I assume is a parallel port
console. You can check if that code will work for you and if it can be
ported to x86.
--
Khalid
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
Khalid Aziz writes:
> Andreas Dilger wrote:
> > Has anyone considered allowing console devices to run over bi-directional
> > parallel ports? I imagine most of the required code is in PLIP and serial,
> > which unfortunately I know nothing about.
> >
> > Several newer systems I have today do not have physical serial ports at all,
> > but all of them (even laptops) still have bi-directional parallel ports.
> >
> > I suppose there may be some difficulties in exporting a "serial-like"
> > interface to the user apps (e.g. minicom and such), but maybe not.
> >
>
> SH supports console on line printer which I assume is a parallel port
> console. You can check if that code will work for you and if it can be
> ported to x86.
From what I have been told, the "line printer console" is unidirectional
only. This would make it OK for console output, but you could not do real
debugging over such a setup.
What bothers me is that new systems don't have a serial port, and no ISA
slots, so there is no hope of getting a "serial console" support without
ACPI (which is rather heavyweight AFAIK). USB is far too complex to use
for early-boot debugging, so what else is left?
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.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
On Mon, 30 Jul 2001, Andreas Dilger wrote:
> What bothers me is that new systems don't have a serial port, and no ISA
> slots, so there is no hope of getting a "serial console" support without
> ACPI (which is rather heavyweight AFAIK). USB is far too complex to use
> for early-boot debugging, so what else is left?
You may still get a PCI serial controller card.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +
On Mon, Jul 30, 2001 at 04:40:31PM -0600, Andreas Dilger wrote:
> 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.
Well, you could use IP (If you use IP autoconfig you could even
route it), but also a proprietary protocol like MOP did centuries
ago. That would only give you access as long as you've on the
same physical network.
However - I'd love to see a networked console.
MfG, JBG
PS: And I'd like to see ~22 Am7990 Lance drivers to go away!!! Bloat...
Andreas Dilger wrote:
>
> What bothers me is that new systems don't have a serial port, and no ISA
> slots, so there is no hope of getting a "serial console" support without
> ACPI (which is rather heavyweight AFAIK). USB is far too complex to use
> for early-boot debugging, so what else is left?
I am puzzled. How would you get "serial console" support even with ACPI
unless there IS a serial port on the system????? All ACPI can do is tell
you where the serial port is.
>
> 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.
--
Khalid
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
Khalid Aziz wrote:
>
> Andreas Dilger wrote:
> >
> > What bothers me is that new systems don't have a serial port, and no ISA
> > slots, so there is no hope of getting a "serial console" support without
> > ACPI (which is rather heavyweight AFAIK). USB is far too complex to use
> > for early-boot debugging, so what else is left?
>
> I am puzzled. How would you get "serial console" support even with ACPI
> unless there IS a serial port on the system????? All ACPI can do is tell
> you where the serial port is.
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
Khalid Aziz writes:
> Andreas Dilger wrote:
> > What bothers me is that new systems don't have a serial port, and no ISA
> > slots, so there is no hope of getting a "serial console" support without
> > ACPI (which is rather heavyweight AFAIK). USB is far too complex to use
> > for early-boot debugging, so what else is left?
>
> I am puzzled. How would you get "serial console" support even with ACPI
> unless there IS a serial port on the system????? All ACPI can do is tell
> you where the serial port is.
OK, maybe I'm misunderstanding here, but even if I put in a PCI serial
card in such a machine, can I get serial console support without ACPI?
Not that it matters in my case, because there are no PCI slots on the
motherboard either.
> > 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.
Yes, this is another good reason why an IP console is less desirable.
AFAIK, some systems have such IP console support in BIOS (it may not
even be "IP" but raw ethernet).
> 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.
And I think "legacy" parallel ports also meet this simplicity requirement
as well, except for the fact that until now it was much more common to
also have a serial port, so nobody has done the work to have bidirectional
parallel port support. Sadly, I have _no_ idea even where to begin on it,
nor the time. I was hoping someone would chime in and say "I did that
already".
I guess the other need would be to allow programs like minicom, kgdb,
etc to open /dev/lp0 like a serial port on the client side, so we don't
need to re-write all of the user-space tools as well.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
On Mon, 30 Jul 2001, Andreas Dilger wrote:
> OK, maybe I'm misunderstanding here, but even if I put in a PCI serial
> card in such a machine, can I get serial console support without ACPI?
> Not that it matters in my case, because there are no PCI slots on the
> motherboard either.
Serial driver version 5.05a (2001-03-20) with MANY_PORTS MULTIPORT SHARE_IRQ
SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A <---On-board
ttyS01 at 0x02f8 (irq = 3) is a 16550A <-/
PCI: Found IRQ 11 for device 00:0c.0
ttyS04 at port 0xb400 (irq = 11) is a 16550A <---Lava DSerial-PCI
ttyS05 at port 0xb000 (irq = 11) is a 16550A <-/
ttyS02 at port 0x03e8 (irq = 5) is a 16550A <--ISA PnP modem
I guess the question is, how do I tell if my machine is using ACPI?
--
Ignacio Vazquez-Abrams <[email protected]>
"Randy.Dunlap" wrote:
>
> Khalid Aziz wrote:
> > I am puzzled. How would you get "serial console" support even with ACPI
> > unless there IS a serial port on the system????? All ACPI can do is tell
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > you where the serial port is.
>
> 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.
>
And that means system DOES have a serial port. All SPCR table does is
tell you where it is (in I/O, memory or PCI space). SPCR table does not
add a serial port. Some kind of serial port has to exist for SPCR table
to be meaningful. My understanding of Andreas' question was how to get
serial console support (or same kind of functionality) when the new
systems do not have a serial port.
If a USB chipset could "emulate" a serial port by doing proper
translation from read/write into USB protocol transfers, system still
has a serial port from OS point of view and all ACPI tables will do is
tell me where to find it.
--
Khalid
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
Andreas Dilger wrote:
>
> OK, maybe I'm misunderstanding here, but even if I put in a PCI serial
> card in such a machine, can I get serial console support without ACPI?
> Not that it matters in my case, because there are no PCI slots on the
> motherboard either.
>
AFAIK, you can not have console on a PCI serial port at this time. I
looked at it few months back and found out that PCI initialization
happens much too late for a serial console. It would take quite a bit of
work to get serial console working on PCI cards. PA-Linux faced the same
problem but they were able to get around it by using the firmware calls
to do console I/O. If serial console were working on PCI serial cards,
you wouldn't need ACPI to use it.
--
Khalid
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
Khalid Aziz wrote:
>
> "Randy.Dunlap" wrote:
> >
> > Khalid Aziz wrote:
> > > I am puzzled. How would you get "serial console" support even with ACPI
> > > unless there IS a serial port on the system????? All ACPI can do is tell
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > you where the serial port is.
> >
> > 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.
> >
>
> And that means system DOES have a serial port. All SPCR table does is
> tell you where it is (in I/O, memory or PCI space). SPCR table does not
> add a serial port. Some kind of serial port has to exist for SPCR table
> to be meaningful. My understanding of Andreas' question was how to get
> serial console support (or same kind of functionality) when the new
> systems do not have a serial port.
OK, thanks for the clarification. I misunderstood Andreas's question.
> If a USB chipset could "emulate" a serial port by doing proper
> translation from read/write into USB protocol transfers, system still
> has a serial port from OS point of view and all ACPI tables will do is
> tell me where to find it.
I agree (mostly).
--
~Randy
On Mon, 30 Jul 2001 16:40:31 -0600 (MDT),
Andreas Dilger <[email protected]> wrote:
>What bothers me is that new systems don't have a serial port, and no ISA
>slots, so there is no hope of getting a "serial console" support without
>ACPI (which is rather heavyweight AFAIK). USB is far too complex to use
>for early-boot debugging, so what else is left?
I briefly discussed this with the USB maintainers at the 2.5 kernel
developers conference. They thought that a stripped down USB serial
console was possible, without full USB support. Is that still the
case?
On Tue, Jul 31, 2001, Keith Owens <[email protected]> wrote:
> On Mon, 30 Jul 2001 16:40:31 -0600 (MDT),
> Andreas Dilger <[email protected]> wrote:
> >What bothers me is that new systems don't have a serial port, and no ISA
> >slots, so there is no hope of getting a "serial console" support without
> >ACPI (which is rather heavyweight AFAIK). USB is far too complex to use
> >for early-boot debugging, so what else is left?
>
> I briefly discussed this with the USB maintainers at the 2.5 kernel
> developers conference. They thought that a stripped down USB serial
> console was possible, without full USB support. Is that still the
> case?
I think so. Keyboards have a nice feature called boot protocol mode
which is a dumbed down version for BIOS' and the like to use.
What would be needed is a driver for UHCI and OHCI does polling
exclusively, which isn't a big problem and only does control and
interrupt pipes.
I think this can be done with a minimal amount of code. It would
probably be smaller than Linus' original USB driver.
JE
From: "Khalid Aziz" <[email protected]>
> AFAIK, you can not have console on a PCI serial port at this time. I
> looked at it few months back and found out that PCI initialization
> happens much too late for a serial console. It would take quite a bit of
That's very odd. That implies that serial consoles don't use the serial
driver at all then, as the pci serial port setup is done at the same
time as the regular serial port setups.
If a serial console is using serial.c, the pci serial ports will also
be available.
Hm, looking through the driver quick, I find some interesting things:
A) Serial console support is mutually exclusive with the serial driver
being a module.
B) The serial console will not share its irq. Other ports with the same
irq are set to polled mode. This may impact performance. It also suggests
that using the console on a pci board isn't a good idea, as pci will
share the irq to other devices.
C) serial.c contains a completely separate serial console driver,
complete with its own init routine. Which meshes with the current
suggestion that the "serial driver" isn't used, and pci init happens
too late.
> work to get serial console working on PCI cards. PA-Linux faced the same
> problem but they were able to get around it by using the firmware calls
> to do console I/O. If serial console were working on PCI serial cards,
> you wouldn't need ACPI to use it.
It seems like pci consoles won't work, now that I think about it. The
console driver gets an index, which I'm going to assume works thusly:
lilo console=ttyS1 ends up passing 1 as the index. That index is used
to pick a serial port out of the array of serial ports that the driver
knows about. If console init happens early, and serial driver init happens
late (it would be dependent on pci init) then only hard coded ports
would work. Those are defined in asm/serial.h, and for i386 include the
standard ports, and a number of isa ports from various board manufacturers.
Using one of our pci ports would require knowledge of its io address,
which wouldn't be available until the pci subsystem had inited. Perhaps
that could be changed to allow pci based consoles?
Elsethread someone mentions a stripped down usb console driver; that's
analogous to the serial console driver contained in serial.c. And if
serial can do it...
..Stu
In article <[email protected]>,
Stuart MacDonald <[email protected]> wrote:
>C) serial.c contains a completely separate serial console driver,
>complete with its own init routine. Which meshes with the current
>suggestion that the "serial driver" isn't used, and pci init happens
>too late.
That's because you expect printk() to work even if interrupts
don't (yet), so there's a mini driver in there that works in polled
mode and is completely anatomous (sp?).
Also, the `real' serial driver only works when /dev/ttySx is opened by
a process - it needs a lot of context (file handles etc) that is
dependent on stuff that is only available after the system has booted.
Mike.
--
"dselect has a user interface which scares small children"
-- Theodore Tso, on debian-devel
"Stuart MacDonald" <[email protected]> writes:
> From: "Khalid Aziz" <[email protected]>
> > AFAIK, you can not have console on a PCI serial port at this time. I
> > looked at it few months back and found out that PCI initialization
> > happens much too late for a serial console. It would take quite a bit of
>
> That's very odd. That implies that serial consoles don't use the serial
> driver at all then, as the pci serial port setup is done at the same
> time as the regular serial port setups.
>
> If a serial console is using serial.c, the pci serial ports will also
> be available.
>
> Hm, looking through the driver quick, I find some interesting things:
>
> A) Serial console support is mutually exclusive with the serial driver
> being a module.
> B) The serial console will not share its irq. Other ports with the same
> irq are set to polled mode. This may impact performance. It also suggests
> that using the console on a pci board isn't a good idea, as pci will
> share the irq to other devices.
> C) serial.c contains a completely separate serial console driver,
> complete with its own init routine. Which meshes with the current
> suggestion that the "serial driver" isn't used, and pci init happens
> too late.
>
> > work to get serial console working on PCI cards. PA-Linux faced the same
> > problem but they were able to get around it by using the firmware calls
> > to do console I/O. If serial console were working on PCI serial cards,
> > you wouldn't need ACPI to use it.
>
> It seems like pci consoles won't work, now that I think about it.
It depends. The pci iniitalization is straight forward. It should
be relatively simple to build a pci serial driver that hard codes the
pci card. I have done similiar things because for some debugging I
have done the current serial console is initialized too late. So I
hacked a hardcoded driver into printk.c
> The
> console driver gets an index, which I'm going to assume works thusly:
> lilo console=ttyS1 ends up passing 1 as the index. That index is used
> to pick a serial port out of the array of serial ports that the driver
> knows about. If console init happens early, and serial driver init happens
> late (it would be dependent on pci init) then only hard coded ports
> would work. Those are defined in asm/serial.h, and for i386 include the
> standard ports, and a number of isa ports from various board manufacturers.
>
> Using one of our pci ports would require knowledge of its io address,
> which wouldn't be available until the pci subsystem had inited. Perhaps
> that could be changed to allow pci based consoles?
I would say the simple solution would be to add a configure option to
do an early PCI init on the card, and to hard code it's ports.
> Elsethread someone mentions a stripped down usb console driver; that's
> analogous to the serial console driver contained in serial.c. And if
> serial can do it...
If it isn't too complex.
Eric
Stuart MacDonald wrote:
>
> It seems like pci consoles won't work, now that I think about it. The
> console driver gets an index, which I'm going to assume works thusly:
> lilo console=ttyS1 ends up passing 1 as the index. That index is used
> to pick a serial port out of the array of serial ports that the driver
> knows about. If console init happens early, and serial driver init happens
> late (it would be dependent on pci init) then only hard coded ports
> would work. Those are defined in asm/serial.h, and for i386 include the
> standard ports, and a number of isa ports from various board manufacturers.
>
> Using one of our pci ports would require knowledge of its io address,
> which wouldn't be available until the pci subsystem had inited. Perhaps
> that could be changed to allow pci based consoles?
>
That is precisely the problem with trying to use a PCI serial port as
console. It is not trivial to move the PCI initialization earlier in the
boot sequence.
--
Khalid
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
We are moving slightly off of my original question which still stands.
For machines that do have serial ports but not at legacy addresses
(COM1, COM2,....), is it acceptable to use the description of these
ports as provided by SPCR and DBGP tables even though Microsoft claims
copyright on these tables and retains the option to modify these tables
at any time? Would it be preferable to use a table defined as part of a
standard like ACPI 2.0 or DIG64 (such a table does not exist at this
time but with enough votes for it, it may be added)?
--
Khalid
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
Khalid Aziz wrote:
>
> We are moving slightly off of my original question which still stands.
> For machines that do have serial ports but not at legacy addresses
> (COM1, COM2,....), is it acceptable to use the description of these
> ports as provided by SPCR and DBGP tables even though Microsoft claims
> copyright on these tables and retains the option to modify these tables
> at any time? Would it be preferable to use a table defined as part of a
> standard like ACPI 2.0 or DIG64 (such a table does not exist at this
> time but with enough votes for it, it may be added)?
We already use other MS-defined tables and specs, like the
$PIR interrupt routing table.
Alan implemented the Simple Boot Flag Protocol in 2.4.5(?)-ac,
which is also from http://www.microsoft.com.
There are other ACPI-like tables that probably need to be
used for NUMA machines that are defined/specified only at
microsoft.com.
IOW, these represent "de facto" industry specs (I hesitate
to say "standards"), so use them.
--
~Randy
On Tue, Jul 31, 2001 at 10:34:35AM -0400, Stuart MacDonald wrote:
> That's very odd. That implies that serial consoles don't use the serial
> driver at all then, as the pci serial port setup is done at the same
> time as the regular serial port setups.
>
> If a serial console is using serial.c, the pci serial ports will also
> be available.
No. Console initialisation is done early, before PCI is setup. This
means that the serial driver is relying on a static array of IO port
addresses. At this time, the serial driver hasn't probed any ports at
all, so it doesn't really know what does and doesn't exist.
If, for example, you specify your console on ttyS25, (and you have
support for >=32 ports compiled in) I wonder what happens? I can
see one of two things happening:
1. Kernel locks up waiting for the non-existent "transmitter" to become
ready.
2. Kernel continues blindly writing to a non-existent port without
locking up and you get no messages at all.
Now, this static table is updated after PCI and PNP initialisation, when
the ports are actually probed. Your ttyS25 may now change port address
under the serial console! I wonder what baud rate the messages come out
at? 75 baud? ;(
The more I think about this, the more that I think we need to get rid
of this early console initialisation. I think Linus really wants early
console initialisation though, and to be honest, its an extremely useful
debugging tool for those pesky non-boots with blank displays.
[gratuitous plug]
I'm currently doing a lot of work on the serial drivers at the moment; the
ARM port currently has about 4 different uart based serial port types, and
I wasn't going to put up with 4 buggy copies of serial.c to drive each
type.
Therefore, I now have a set of serial drivers based around a serial core
(including the 16550 type) which I've been able to test out. It is (I
hope) functionally equivalent to what is in 2.4.7. It needs a little
more cleaning up, and a _lot_ more testing. People interested can get
it from:
:pserver:[email protected]:/mnt/src/cvsroot (no login password)
To access it:
cvs -d :pserver:[email protected]:/mnt/src/cvsroot login
cvs -d :pserver:[email protected]:/mnt/src/cvsroot co serial
Server note: If you want to use -z, please don't use anything above -z3.
(failure to follow this will result in anon cvs being withdrawn or
restricted). Thanks.
What isn't provided at the moment are the patches to the Makefiles and
Config.in files. I'll include a patch for that later this evening.
If someone would like to produce a patch which adds an option for early
console vs "normal" console initialisation... Otherwise I'll add it to
my (longish) "to do" list.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Stuart MacDonald writes:
> From: "Khalid Aziz" <[email protected]>
> > AFAIK, you can not have console on a PCI serial port at this time. I
> > looked at it few months back and found out that PCI initialization
> > happens much too late for a serial console. It would take quite a bit of
>
> That's very odd. That implies that serial consoles don't use the serial
> driver at all then, as the pci serial port setup is done at the same
> time as the regular serial port setups.
>
> A) Serial console support is mutually exclusive with the serial driver
> being a module.
Yes, because you want console support long before you get the root fs
mounted and have access to modules.
> C) serial.c contains a completely separate serial console driver,
> complete with its own init routine. Which meshes with the current
> suggestion that the "serial driver" isn't used, and pci init happens
> too late.
It _may_ be that Keith Owens (I think) will change this in 2.5. He has
talked about a big reorg of the serial layer to separate out the tty
handling from the serial I/O handling. Maybe at that point my idea of
having a console on a parallel port will work. I guess that it is just
not that easy right now.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
From: "Russell King" <[email protected]>
> No. Console initialisation is done early, before PCI is setup. This
I figured that out eventually. :-)
> means that the serial driver is relying on a static array of IO port
> addresses. At this time, the serial driver hasn't probed any ports at
> all, so it doesn't really know what does and doesn't exist.
Correct.
> If, for example, you specify your console on ttyS25, (and you have
> support for >=32 ports compiled in) I wonder what happens? I can
> see one of two things happening:
>
> 1. Kernel locks up waiting for the non-existent "transmitter" to become
> ready.
> 2. Kernel continues blindly writing to a non-existent port without
> locking up and you get no messages at all.
Well, the io address would be... <checks asm/serial.h>
{ 0, BASE_BAUD, 0x148, 12, BOCA_FLAGS }, /* ttyS25 */
on i386 builds. I guess it would depend on what is actually at
0x148. Nothing good would come of it if you didn't have a uart
there, I'm sure.
> Now, this static table is updated after PCI and PNP initialisation, when
> the ports are actually probed. Your ttyS25 may now change port address
> under the serial console! I wonder what baud rate the messages come out
> at? 75 baud? ;(
Correct. That entry would be overwritten by whatever dynamic ports
were discovered. Of course, if you only had one 8 port card, it'd
remain the same. But if you had enough 8 port cards, you'd get a serial
port. I think the effect would be that that serial port suddenly becomes
the console, at 9600 8n1. Hm.
> The more I think about this, the more that I think we need to get rid
> of this early console initialisation. I think Linus really wants early
> console initialisation though, and to be honest, its an extremely useful
> debugging tool for those pesky non-boots with blank displays.
There seems to be a serial console interface; perhaps we need
a general console interface that other code can make use of.
That might pave the way for an ethernet console, or a usb console,
etc.
..Stu
On Tue, Jul 31, 2001 at 10:39:38AM -0600, Andreas Dilger wrote:
> It _may_ be that Keith Owens (I think) will change this in 2.5. He has
> talked about a big reorg of the serial layer to separate out the tty
> handling from the serial I/O handling. Maybe at that point my idea of
> having a console on a parallel port will work. I guess that it is just
> not that easy right now.
Keith should contact me about it; I've got a lot of work in CVS to make
this transition easy, and I know Ted T'so's views on his intended direction
for this very subject (I discussed it with Ted at the 2.5 conference and
on odd occasions after).
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Tue, Jul 31, 2001 at 01:14:01PM -0400, Stuart MacDonald wrote:
> There seems to be a serial console interface; perhaps we need
> a general console interface that other code can make use of.
> That might pave the way for an ethernet console, or a usb console,
> etc.
We already have a generic console interface - struct console. Really,
the code between the various serial drivers isn't all that big once
you factor out the setup (which I've already done, including support
for consoles up to 460800 baud).
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Tue, 31 Jul 2001 10:39:38 -0600 (MDT),
Andreas Dilger <[email protected]> wrote:
>It _may_ be that Keith Owens (I think) will change this in 2.5. He has
>talked about a big reorg of the serial layer to separate out the tty
>handling from the serial I/O handling.
Not me, I try to keep clear of the serial code.
Russell King <[email protected]> writes:
> On Tue, Jul 31, 2001 at 10:34:35AM -0400, Stuart MacDonald wrote:
> > That's very odd. That implies that serial consoles don't use the serial
> > driver at all then, as the pci serial port setup is done at the same
> > time as the regular serial port setups.
> >
> > If a serial console is using serial.c, the pci serial ports will also
> > be available.
>
> No. Console initialisation is done early, before PCI is setup. This
> means that the serial driver is relying on a static array of IO port
> addresses. At this time, the serial driver hasn't probed any ports at
> all, so it doesn't really know what does and doesn't exist.
Hmm. I hadn't realized it was poking in the dark.
> The more I think about this, the more that I think we need to get rid
> of this early console initialisation. I think Linus really wants early
> console initialisation though, and to be honest, its an extremely useful
> debugging tool for those pesky non-boots with blank displays.
I think I both agree and disagree with you. I think it might make sense
to seperate out the debugging console drivers from the normal kernel drivers.
I have had several times where I have had to hack up a serial driver that
is initialized very early so I could see why my kernel is crashing.
If we seperated out the console drivers and modified them so they would
build for specific hardware, and would be initialized immediately upon
transition to C code. There would be a major debugging benefit.
Then we could probably afford to use the normal serial code for a more
normal serial console.
Does this sound like a reasonable direction to go? You've torn open
the code and familiar with what it's guts look like.
> If someone would like to produce a patch which adds an option for early
> console vs "normal" console initialisation... Otherwise I'll add it to
> my (longish) "to do" list.
I might have to look. I have done some preliminary work, in getting a
very, very early serial console built so I'm not completely in the
dark. If you like the idea of splitting the console code in two half
that uses normal routines and another have that does very, very, very
early initialization I'm more likely to :)
Eric
On 31 Jul 2001, Eric W. Biederman wrote:
> Russell King <[email protected]> writes:
>
> > No. Console initialisation is done early, before PCI is setup. This
> > means that the serial driver is relying on a static array of IO port
> > addresses. At this time, the serial driver hasn't probed any ports at
> > all, so it doesn't really know what does and doesn't exist.
>
> Hmm. I hadn't realized it was poking in the dark.
At least some PCI serial cards are just UARTs at a specific I/O address and
interrupt, and the I/O adress and interrupt are (more or less) constant each
boot. Could the values of these be passed to the kernel via command-line?
--
Ignacio Vazquez-Abrams <[email protected]>