patch-2.1.71 linux/Documentation/serial-console.txt

• Lines: 153
• Date: Wed Dec 3 15:21:57 1997
• Orig file: v2.1.70/linux/Documentation/serial-console.txt
• Orig date: Tue May 13 22:41:00 1997

diff -u --recursive --new-file v2.1.70/linux/Documentation/serial-console.txt linux/Documentation/serial-console.txt
@@ -1,48 +1,67 @@
                        Linux Serial Console
 
-These examples are valid if you want to use /dev/ttyS1 (COM2)
-as the serial console. Replace as needed.
+It is possible to specify multiple devices for console output. You can
+define a new kernel command line option to select which device(s) to
+use for console output.
 
-1. Tell LILO to use the serial port.
+The format of this option is:
+
+	console=device,options
+
+	device:		tty0 for the foreground virtual console
+			ttyX for any other virtual console
+			ttySx for a serial port
+
+	options:	depend on the driver. For the serial port this
+			defines the baudrate/parity/bits of the port,
+			in the format BBBBPN, where BBBB is the speed,
+			P is parity (n/o/e), and N is bits. Default is
+			9600n8. The maximum baudrate is 115200.
+
+You can specify multiple console= options on the kernel command line.
+Output will appear on all of them. The first device will be used when
+you open /dev/console. So, for example:
+
+	console=tty0 console=ttyS1,9600
+
+defines that opening /dev/console will get you the current foreground
+virtual console, and kernel messages will appear on both the VGA
+console and the 2nd serial port (ttyS1 or COM2) at 9600 baud.
+
+Note that you can only define one console per device type (serial, video).
+
+If no console device is specified, the first device found capable of
+acting as a system console will be used. At this time, the system
+first looks for a VGA card and then for a serial port. So if you don't
+have a VGA card in your system the first serial port will automatically
+become the console.
+
+You will need to create a new device to use /dev/console. The official
+/dev/console is now character device 5,1.
+
+Here's an example that will use /dev/ttyS1 (COM2) as the console.
+Replace the sample values as needed.
+
+1. Create /dev/console (real console) and /dev/tty0 (master virtual
+   console):
+
+   cd /dev
+   rm -f console tty0
+   mknod -m 622 console c 5 1
+   mknod -m 622 tty0 c 4 0
+
+2. LILO can also take input from a serial device. This is a very
+   useful option. To tell LILO to use the serial port:
    In lilo.conf (global section): 
 
    serial  = 1,9600n8 (ttyS1, 9600 bd, no parity, 8 bits)
 
-2. Adjust to kernel flags for the new kernel,
+3. Adjust to kernel flags for the new kernel,
    again in lilo.conf (kernel section)
 
-   append = "console=1,9600,n8" 
-
-   (Note the extra comma needed if you want to supply parity/framing 
-   information.)
-
-3. Link /dev/console to the serial port.
+   append = "console=ttyS1,9600" 
 
-   Your probably want to save your old /dev/console (the "master" virtual
-   console). Check if it is a symbolic link first. If not, `mv' it to
-   `/dev/tty0':
-
-   ls -l /dev/console
-   mv /dev/console /dev/tty0
-
-   Now link the serial port you are going to use as the console to
-   /dev/console, for example ttyS1:
-
-   ln -s /dev/ttyS1 /dev/console
-
-   On some systems you might want to edit your bootup scripts to make sure
-   they don't reset this arrangement on boot. (On Debian, check
-   /etc/rc.boot/console and /etc/default/console). You probably also want
-   to put a getty on either /dev/console or /dev/ttyS1.
-
-4. Init and /dev/console.
-   Sysvinit will open /dev/console on boot. If this does not point
-   to the serial console device, the startup messages will be printed
-   to the wrong device. The kernel also passes the environment variable
-   "CONSOLE" to the init program. sysvinit-2.64 reckognizes this, and
-   opens that device instead. Boot scripts as mentioned in (3) can
-   also check this variable to see what device the system console is.
-   If CONSOLE is not set you can assume the console is /dev/tty0.
+4. Init and /etc/ioctl.save
 
    Sysvinit remembers its stty settings in a file in /etc, called
    `/etc/ioctl.save'. REMOVE THIS FILE before using the serial
@@ -51,28 +70,25 @@
 
 5. /dev/console and X
    Programs that want to do something with the virtual console usually
-   open /dev/console. XF86 does this, and probably SVGALIB as well.
-   IMO this is wrong; they should open /dev/tty0.
-   I have binary patched /usr/bin/X11/XF86_SVGA to use "tty0"
-   instead of "console".
-
-6. Notes.
-
-   If you compile the next little program, you will be able
-   to really "halt" the system. It will enter a little
-   monitor :)
-
-   main() { reboot(0xfee1dead, 672274793, 0xCDEF0123); }
-
-   This is just a call to the new "halt" function that later
-   kernels have. This is included the "halt" command of
-   the recent sysvinit versions.
-
-   The monitor will also be entered at a kernel panic, or
-   when you press "break". That last function does not
-   work at the moment I think, but it would be useful for
-   kernel debugging.  You don't have alt-scrollock on a serial
-   console to find out the current EIP...
+   open /dev/console. If you have created the new /dev/console device,
+   and your console is NOT the virtual console some programs will fail.
+   Those are programs that want to access the VT interface, and use
+   /dev/console instead of /dev/tty0. Some of those programs are:
+
+   Xfree86, svgalib, gpm, SVGATextMode
+
+   I have binary patched the above mentioned programs to use "tty0"
+   instead of "console".  This will be reported to the maintainers of
+   said programs.
+
+   Note that if you boot without a console= option (or with
+   console=/dev/tty0), /dev/console is the same as /dev/tty0. In that
+   case everything will still work.
+
+6. Thanks
+
+   Thanks to Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
+   for porting the patches from 2.1.4x to 2.1.6x for taking care of
+   the integration of these patches into m68k, ppc and alpha.
 
-Miquel van Smoorenburg <miquels@cistron.nl>, 21-Jun-1996
-Stephen C. Tweedie <sct@dcs.ed.ac.uk>, 23-Dec-1996
+Miquel van Smoorenburg <miquels@cistron.nl>, 03-Dec-1997