Discussion:
Howto redirect serial console
Dach Miroslaw
2009-06-20 18:01:21 UTC
Permalink
I have a ppc405 based board with one serial interface which I use as a console.
I would like to redirect or suppress, at run time, the console in order to use the
serial port to control external serial devices.

I have tried (busybox) setconsole program to redirect the console to /dev/null
but it did not work. What would be the elegant way to redirect or suppress the serial console.

M.
Baruch Siach
2009-06-20 18:30:17 UTC
Permalink
Hi Dach,
Post by Dach Miroslaw
I have a ppc405 based board with one serial interface which I use as a console.
I would like to redirect or suppress, at run time, the console in order to use the
serial port to control external serial devices.
I have tried (busybox) setconsole program to redirect the console to /dev/null
but it did not work. What would be the elegant way to redirect or suppress the serial console.
I encountered a similar situation before. My solution was to pass console=tty1
to the kernel.

baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Dach Miroslaw
2009-06-20 19:53:30 UTC
Permalink
Hi Baruch,

Thanks for your hint. Your solution refers to the change of the command line arguments
used at boot-up. I am however looking for a possibility to redirect console device at run time.

Best Regards

Mirek




-----Original Message-----
From: Baruch Siach [mailto:baruch at tkos.co.il]
Sent: Sat 6/20/2009 8:30 PM
To: Dach Miroslaw
Cc: busybox at busybox.net
Subject: Re: Howto redirect serial console

Hi Dach,
Post by Dach Miroslaw
I have a ppc405 based board with one serial interface which I use as a console.
I would like to redirect or suppress, at run time, the console in order to use the
serial port to control external serial devices.
I have tried (busybox) setconsole program to redirect the console to /dev/null
but it did not work. What would be the elegant way to redirect or suppress the serial console.
I encountered a similar situation before. My solution was to pass console=tty1
to the kernel.

baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Matthew Hiles
2009-06-20 21:32:49 UTC
Permalink
Post by Dach Miroslaw
Hi Baruch,
Thanks for your hint. Your solution refers to the change of the command line arguments
used at boot-up. I am however looking for a possibility to redirect console device at run time.
Best Regards
Mirek
-----Original Message-----
From: Baruch Siach [mailto:baruch at tkos.co.il]
Sent: Sat 6/20/2009 8:30 PM
To: Dach Miroslaw
Cc: busybox at busybox.net
Subject: Re: Howto redirect serial console
Hi Dach,
Post by Dach Miroslaw
I have a ppc405 based board with one serial interface which I use as a console.
I would like to redirect or suppress, at run time, the console in order to use the
serial port to control external serial devices.
I have tried (busybox) setconsole program to redirect the console to /dev/null
but it did not work. What would be the elegant way to redirect or suppress the serial console.
I encountered a similar situation before. My solution was to pass console=tty1
to the kernel.
baruch
Could you not setup different run levels? The default run level could
use the serial port for console (which runs getty on it). You could have
another init level setup that doesn't have getty running on the serial
port. Switch between the run levels via init #. Or you could not have
init handle starting getty on the serial port. Instead, you could have a
boot script start getty but then you kill it when you want to use it for
something else.

~Matthew
Dach Miroslaw
2009-06-22 10:52:30 UTC
Permalink
Hi Matthew,
Post by Matthew Hiles
Could you not setup different run levels? The default run level could
use the serial port for console (which runs getty on it). You could have
another init level setup that doesn't have getty running on the serial
port. Switch between the run levels via init #. Or you could not have
init handle starting getty on the serial port. Instead, you could have a
boot script start getty but then you kill it when you want to use it for
something else.
Thanks for your suggestion.

I use standard busybox init which does not use runlevels. getty is not started on the
serial console. When I type ps I get the following:
PID USER VSZ STAT COMMAND
1 root 1812 S init
2 root 0 SW [keventd]
3 root 0 SWN [ksoftirqd_CPU0]
4 root 0 SW [kswapd]
5 root 0 SW [bdflush]
6 root 0 SW [kupdated]
7 root 0 SW [mtdblockd]
14 root 1804 S klogd
70 root 0 SW [rpciod]
73 root 1832 S udhcpc -i eth1 -p /etc/udhcpc/udhcpc-eth1.pid -s /usr
76 root 1808 S /usr/sbin/inetd
77 root 1816 S /bin/sh
79 root 1808 R ps

When I type cat /proc/tty/drivers I get as following:
serial /dev/cua 5 64-65 serial:callout
serial /dev/ttyS 4 64-65 serial
pty_slave /dev/pts 136 0-255 pty:slave
pty_master /dev/ptm 128 0-255 pty:master
pty_slave /dev/ttyp 3 0-255 pty:slave
pty_master /dev/pty 2 0-255 pty:master
/dev/ptmx /dev/ptmx 5 2 system
/dev/console /dev/console 5 1 system:console
/dev/tty /dev/tty 5 0 system:/dev/tty

It is somehow interesting to see:
/dev/console /dev/console 5 1 system:console

My /dev/console has however major and minor numbers the same
as /dev/ttyS0:
/dev/ttyS0 4 64

When I use the command setconsole:
setconsole /dev/ttyS0 #I get no error first time
setconsole /dev/ttyS0 #when I type it 2nd .... times I get
-> setconsole: ioctl 0x80047478 failed: Device or resource busy

I have spent some time to search on the net for the solution and still without any success.

Any suggestion?

Best Regards

Mirek

Rob Landley
2009-06-21 16:16:48 UTC
Permalink
Post by Dach Miroslaw
Hi Baruch,
Thanks for your hint. Your solution refers to the change of the command
line arguments used at boot-up. I am however looking for a possibility to
redirect console device at run time.
This is a kernel issue, not a busybox issue. You can change which console
your userspace processes use, but if you get a broadcast message (such as
"timing source $BLAH unstable, falling back to $BLAH", "too much work for IRQ
$X", or all sorts of others) it'll still go to /dev/console.

By the way, when you say "at run time", do you mean after the system has
booted and potentially spawned multiple processes, each of which independently
has stdin/stdout/stderr? Or are you just referring to changing what PID 1
thinks the console is and new child processes spawned after that point? (I
note that switch_root has a -c option, since it runs at a convenient
bottleneck point for changing that parameter.)

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
Loading...