Console on a Serial Port

[parky_dw]

I'm trying to get Tiny Core running on a system where the Video (currently) doesn't work so I'm trying to use the serial port as a console - something I've done successfully in the past.  However this time I'm having problems which I hope someone here can help me solve.

My starting point was the current release with kernel 2.6.33.3 and the microcore gz file.  I've rebuilt the kernel and remastered the initrd file with the matching modules.  I do get a kernel "oops" if tce-setup runs but that's for another day once I get past my current problem....(including base in the command line solves that for now).

My command line includes:
earlyprintk=serial,ttyS0,19200n8
console=ttyS0,19200n8
base

When the kernel starts I get all the usual stuff squirted out of the serial port until the kernel frees up unused memory and the moves on to running init .  At that point it all stops.  I get nothing.  However I know all is still running as I added a printk to the execve function in the kernel.   Why is the console entry being ignored?

Here's some of what is printed as the system boots:

Linux version 2.6.33.3-tinycore (thin@mantaray) (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #34 Tue Aug 16 16:32:07 BST 2011
BIOS-provided physical RAM map:
 BIOS-e801: 0000000000000000 - 000000000009f000 (usable)
 BIOS-e801: 0000000000100000 - 0000000003b80000 (usable)
bootconsole [earlyser0] enabled
..........
Kernel command line: kmap=uk earlyprintk=serial,ttyS0,19200n8 console=ttyS0,19200n8 base  
.......
CPU: NSC Geode(TM) Integrated Processor by National Semi stepping 01
.........
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
.......
NET: Registered protocol family 17
NET: Registered protocol family 15
Freeing unused kernel memory: 172k freed
Running /init base (null)
Running /bin/mount proc (null)
Running /bin/grep -qw multivt
Running /bin/grep -qw embed
.........
Running /bin/rm -f /etc/hostname
Running /bin/hostname -F /etc/hostname
Running /bin/grep -q inet addr
Running /sbin/ifconfig eth0 (null)
Running /bin/rm -f /etc/hosts
Running /bin/sleep 1 (null)
Running /bin/hostname (null) USER=tc
Running /bin/cat (null)
Running /sbin/udhcpc -b -i
Running /sbin/getty -L ttyS0
Running /sbin/getty -L ttyS1

Note:  My hack only prints out a couple of arguments to whatever is being invoked.

So in summary I can see that the serial port is working fine - all the kernel printk stuff comes out there.  init is started and runs all the tc startup scripts. For some reason /dev/console is not being connected to ttyS0  Also at the end when the gettys are started neither serial port appears to have a console on it.  I assume that solving the /dev/console connectivity issue will also solve that - but lets take one step at a time.

Any thoughts?

David

[maro]

IIRC you'll have to amend '/etc/inittab' (and therefore re-master the initd once more). I found some old notes of mine that an entry of

Code: [Select]

ttyS1::respawn:/sbin/getty 38400 ttyS1 did once work for a test I did with QEMU.

This test was done ca. 1.5-2 years ago, but it's a bit late here for me to undertake a fresh test. So you might just want to give that a try.

[parky_dw]

The last thing that init does is read inittab to set up the consoles for logging on.  You can see that it has done that in the last two lines above.  Up to then the output (as I understand it) is going to /dev/console.  The command line should have associated that with ttyS0.

FYI: In my kernel configuration file I have set Console on 8250/16550 and compatible serial port on in the serial drivers section.

David

[Rich]

Hi parky_dw
I believe the following thread as the information you need
http://forum.tinycorelinux.net/index.php/topic,11088.msg58088.html#msg58088
One of the things mentioned is that you have to change your getty.

[parky_dw]

If only it were that easy....  My problem is nothing to do with the inittab settings.  A restating of my problem.  Broadly the boot process is:

• The kernel runs and sorts itself out and creates /dev/console for system messages
• The kernel then runs the init process which starts off by running initialisation scripts
• After running the initialisation scripts init spawns gettys to handle user logons

During phase 1 all the kernel messages are coming out of the serial port as I requested.
At the end of phase 1 the kernel has setup /dev/console.  My command line switch requests that this be connected to /dev/ttyS0.
In phase 2 when the startup scripts are running, their output goes to /dev/console.
One of the last acts of init is to spawn the logon processes as defined in the table at the end of inittab. (This is where the thread referenced above applies).

My issue is with phase 2.  I know the serial port is working as I get the kernel's printk messages quite happily, but the output from the system initialisation scripts - /etc/init.d/rcS et al - that is being sent to /dev/console is NOT going to /dev/ttyS0 as I requested.  It's just vanishing into a black hole somewhere. Why isn't going to the serial port?  The answer probably lies in my kernel .config file as I can't see anything wrong with the syntax of my command line switch console=ttyS0,19200n8, but I can't find anything obvious.  Any ideas anyone?

David

[maro]

I was curious what might be the problem here and so I undertook my own experiments. As usual I used QEMU to emulate a system that was restricted to only communicate via a serial interface (using the 'Ctrl-Alt-3' key combination to change over that serial terminal).

As a first step I wanted to be sure that only one terminal is used in this exercise. I therefore changed all occurrences of 'tty1' in '/etc/inittab' to 'ttyS0' and ensured that this terminal was enabled in '/etc/securetty'. So all remastering steps together were:

Code: (bash) [Select]

# extract the initrd
sudo rm -rf extr
mkdir extr
( cd extr ; zcat ../microcore.gz | sudo cpio -idm )
# enable 'ttyS0' in '/etc/securetty'
sudo sed -i '/^# ttyS0$/s#^..##' extr/etc/securetty
# change '/etc/inittab' to use 'ttyS0'
sudo sed -i '/^tty1:/s#tty1#ttyS0#g' extr/etc/inittab
# create a new initrd
( cd extr ; find | sudo cpio -odm -H newc ) | gzip -c > mc_ttyS0.gzThis assuming of course that 'minicore.gz' had already been downloaded to the current directory, as well as the kernel file that would be needed to test the result via:
    qemu -m 32 -kernel bzImage -initrd mc_ttyS0.gz -append "console=ttyS0"
where the required boot code to redirect all "action" to the serial interface gets specified through the 'append' option.

This test already showed much of the hoped for outcome: The kernel boot messages appeared in the serial terminal (i.e. "phase 1"), the MC boot process got under way and produced more output (i.e. "phase 2") and finally a login prompt showed up in the serial terminal and allowed the user 'tc' to run an interactive shell (i.e. "phase 3").

So far so good, but what was not working was the automated login (as expected due to the 'rungetty ttyS0 --autologin root' part of  the changed '/etc/inittab'.

To understand this issue better the source code of rungetty had to be checked. As it turns out by default it is hard coded to limit the 'autologin' to '/dev/tty1'. But it is pretty simple to overcome this, as the following comment explains:

/* AUTO_TTY is the tty on which autologins will be accepted.  If set
   to an empty string, autologins will be accepted on any tty. */

So after downloading the sources (and installation of 'compiletc.tcz') a new version of '/sbin/rungetty' was created by:

Code: (bash) [Select]

# create a slightly different version of '/sbin/rungetty'
rm -rf rungetty-1.2
tar xf rungetty-1.2.tar.gz
sed -i '/AUTO_TTY/s#tty1##' rungetty-1.2/rungetty.c
( cd rungetty-1.2 ; make )
sudo cp rungetty-1.2/rungetty extr/sbin
sudo chmod 755 extr/sbin/rungettyfollowed by another creation of the initrd.

The next test with QEMU lead to a successful autologin of 'root', which itself created the login shell for user 'tc'.

Obviously my test did not involve "real hardware", but I'm pretty optimistic that it should work there as well.


EDIT: As alternative to recompiling '/sbin/rungetty' I've just posted a different option. This might be seen as an "easier" way to achieve the goal.

[Rich]

Hi parky_dw

My issue is with phase 2.  I know the serial port is working as I get the kernel's printk messages quite happily, but the output from the system initialisation scripts - /etc/init.d/rcS et al - that is being sent to /dev/console is NOT going to /dev/ttyS0 as I requested.

I could be mistaken, but I believe this is /init executing:

Running /bin/mount proc (null)
Running /bin/grep -qw multivt
Running /bin/grep -qw embed

and this is /etc/init.d/rcS which is a link to /etc/init.d/tc-config executing:

Running /bin/rm -f /etc/hostname
Running /bin/hostname -F /etc/hostname
Running /bin/grep -q inet addr
Running /sbin/ifconfig eth0 (null)
Running /bin/rm -f /etc/hosts
Running /bin/sleep 1 (null)
Running /bin/hostname (null) USER=tc
Running /bin/cat (null)
Running /sbin/udhcpc -b -i

[cast-fish]

hello

i was confused about  "Linux serial console".

You say you have a system (computer) where the video image
does not work.

SO did it break?

I presume Linux had already been installed earlier to that faulty system when the video was actually working on the computer?

(or have you simply got a hard drive with a working Linux on it and installed
Linux serial console and plugged it into the computer that has faulty video?)

So how do you now go about setting up a "Linux serial console" if you
can't directly see any video coming from the faulty computer?

Do you connect a serial cable to the faulty computer and then
the other end to a working computer with a screen. Then, on the
fully functional computer, you start the work on "talking" to the
faulty computer to set up the "Linux serial console"?

V.

[Lee]

I'm trying to get Tiny Core running on a system where the Video (currently) doesn't work so I'm trying to use the serial port as a console - something I've done successfully in the past.  However this time I'm having problems which I hope someone here can help me solve.

Hi parky_dw, I'm not sure what your end result needs to be - if you need to see all the bootup messages, then maybe the serial console is the way to go.  And if you're using an actual serial terminal... don't see much of -that- these days.      But if it doesn't -have- to use the "cereal" port, using the net instead might be more satisfying...

I have a headless system (Toshiba Magnia SG20 - no video nor keyboard) that I just installed Micro Core 3.8.2 on.  I did it by
*) taking the HD out and using a USB thingy to attach it to my regular PC
*) installed grub4dos and Micro Core
*) Copied /opt/eth0.sh from my regular PC and tweaked it for a unique IP address
*) Made sure I could boot the thing (on the PC) and see the internet, then installed openssh.tcz and configured it
*) set a password for tc and for root
*) made a backup including
-     the password stuf from /etc
-     etho0.sh from /opt
-     the ssh set ip stuff from /usr/local/etc/ssh
*) Reboot again on the PC and make sure I can ssh to it without any additional tweaking
*) Stuff the HD back into the Magnia and all done.

No remastering required.

As a bonus, with one little tweak to my internet router I can access it from internet.

[maro]

In addition to what I wrote in reply#5 I've now done a test with "real" hardware (more details here) and I'm now pretty certain that what I wrote above stacks up also in the "real" world.

[parky_dw]

I've been away for a few days - thanks to those who have responded in my absence.

You say you have a system (computer) where the video image does not work.

SO did it break?

I presume Linux had already been installed earlier to that faulty system when the video was actually working on the computer?

.....

A bit more detail on the hardware:  I'm (trying to) build a kernel to run on a Wyse WT3125SE thin client.  This is based on a SC2200 Geode system-on-a-chip (core is Geode GX1 CPU).  This WT3125SE does not really have a conventional BIOS.  It has a 266MHz CPU, 32MB flash, 64MB RAM.  The WT3125SE can be persuaded to boot from the network and uses something it calls NETXFER.  I have a programme that wraps up the bzImage and initrd files along with a loader program that lets me easily test builds via a network boot.  Once things are working I can program the result into the onboard flash.  In the past I have successfully built kernels for other Wyse thin clients based on the Geode GX1 and CS5530 chipset.

Currently, for a SC2200 integrated system, the Geode video drivers do not produce any output on the screen - the lasting thing on the screen is a Booting Linux message from my loader.  I haven't really looked into this as, being stuck with 64MB of RAM, I'm happy to run such systems headless.  There may be subtle differences between the SC2200 and GX1 + CS5530 that just need sorting out - but that is for another day.

Currently I have a kernel which boots, starts up dropbear, and one which I can log into remotely using putty.  I still have various issues to sort out with the IDE interface (the SC1200 drivers almost work) and USB pen drives.  Some of this may lie in the hardware initialisation my loader program does (or does not!) do.

It would help if I could see the output that init and /sbin/init are producing.  The thing that has me flummoxed is why the kernel boot messages are happily squirted out of the serial port whilst those from init and then /sbin/init aren't.  I guess I'll have to wade through the kernel sources to see exactly how the serial ports and /dev/console are set up.  I think the answer must lie there somewhere.

[cast-fish]

Hello

ahh right

I see.

V.

[parky_dw]

I just thought that I'd report that, having just revisited this, I've solved the problem. 

It would appear that the kernel actually uses two different serial drivers.  The one used by printk for the kernel debug messages is a simple driver that just 'polls' the "tx register empty?" bit in the chip. The main console driver is interrupt driven.  What goes as a BIOS in the WT3125SE was not enabling the interrupts on the LPC interface to the SuperIO chip.  I modified my loader code to flip 1 bit on this interface to enable interrupts and the serial console burst into life.

A bit confusing really as, during boot, the kernel does put out two messages about the Console being switched to /dev/ttyS0..... So you'd think from that point that the kernel printk messages and the system console were using the same driver - but they don't!