Mechanisms to stop serial console accepting input on a Linux system?

Question

I am working on a simple embedded system based around an Olinuxino board. This has a serial console header onboard. TX and RX are both connected to the respective pins on the microcontroller (i.e. this isn't a hardware issue).

When connected, I can see the normal output from a booting Linux system, but at no point am I presented with a login. No other input seem

What mechanisms can be used to stop a serial console accepting input on a Linux system?

Specific situation

The device is using busybox, and inittab looks like so:

# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

# The default runlevel.
id:5:initdefault:

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~~:S:wait:/sbin/sulogin

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
S:2345:respawn:/sbin/getty 115200 ttyAMA0
# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#  <id>:<runlevels>:<action>:<process>
#

1:2345:respawn:/sbin/getty 38400 tty1

/sbin/getty links to /sbin/getty.tinylogin which links to /bin/tinylogin

The options passed to the kernel are:

[    0.000000] Kernel command line: console=ttyAMA0,115200 root=/dev/mmcblk0p2 rw rootwait ssp1=mmc lcd_panel=lms430 no_console_suspend

Not sure if the difference in speed could cause this not to work.

Answer 1

You don't stop the serial console from accepting input; you make it accept input by placing an appropriate getty entry into /etc/inittab. If that entry is missing, no one will ever start a login process on the serial console.

(That's for classical systems that use classic init to start and respawn background processes. Desktop systems have moved to a new method named upstart that doesn't use /etc/inittab any more. But on a simple embedded system I'd rather expect inittab to be still in use.)

So to answer your question: your manufacturer didn't do anything to stop your Linux from running a login on the serial console (that you can reverse). Instead, they probably didn't do anything to make it run a login at all. Possibly they didn't even provide the getty binary that initiates login.