What does "console [ttyS0] enabled mean?

5
votes

I am trying to communicate between a single board computer and a PC over COM ports. On the single board computer I am running Debian Linux and there are two UARTs that I can use. On one of the UARTs (ttyS1) I can communicate (send and receive) with no problems. When I try to communicate on the other UART (ttyS0) the send works perfectly however the receive loses the 1st byte in (sends an error message to the console on the PC saying that the character that is typed is not a command) and then all future characters are received correctly.

If I switch from receiving to sending and then back to receiving the same occurs. If I stay in receive mode I can receive characters for as long as I want with no data loss. It appears that the transitioning from send to receive is causing this to happen.

As I mentioned earlier I do not see this issue on the other UART (ttyS1). I started looking for reasons why the two ports are different. I used the same program to set up send and receive for both UARTS so the problem is not in the program setup. One thing that I did find when I typed the command dmesg |grep tty I get the following:

[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 roo twait loglevel=8 panic=10
[    0.446780] sunxi-uart.1: ttyS0 at MMIO 0x1c28400 (irq = 2) is a U6_16550A
[    1.114996] console [ttyS0] enabled
[    1.154643] sunxi-uart.3: ttyS1 at MMIO 0x1c28c00 (irq = 4) is a U6_16550A

I see that ttyS0 has the "console [ttyS0] enabled" associated with it where the ttyS1 does not. I was wondering what the "console [ttyS0] enabled means?

Also, is there a way to disable it to see if this is what is causing my 'first byte of data loss'? I see in my setup for the single board computer that ttyS0 is designated the "debug port'.

I was also wondering if that is analogous to console?

Can someone please explain what having the console enabled implies?

2
linuxserial-portuart
I assume the first UART, you meant that ttyS0 works fine in send and receive? - Sunny Patel
Actually, ttyS1 works fine, ttyS0 loses the first byte. - mikenycz
Appreciate the correction. - Sunny Patel
"the send works perfectly however the receive loses the 1st byte" -- This is ambiguous. When the problem occurs, which side is transmitting and which side is receiving? "It appears that the transitioning from send to receive is causing this to happen." -- There is no Tx or Rx "mode" (aka half duplex). The 16550A USART should be setup for full duplex, and capable of simultaneous transmitting and receiving at all times. The "console enabled" message is not the cause of the problem. I have used the "debug" ports as the console w/o any issues. What terminal emulator are you using? - sawdust
"however the receive loses the 1st byte" -- That seems to be a conclusion on your part. Please provide the raw data or evidence to support this (screen capture or program code?)/ - sawdust

2 Answers

3
votes

The console is the tty where the kernel logs go to.

You select a specific one through kernel parameters when booting, it is seen in the log you provided, in the line "Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 roo twait loglevel=8 panic=10"

You can select another console (if available in your platform) so ttyS0 will not get any bytes on kernel boot.

-1
votes

I see that ttyS0 has the "console [ttyS0] enabled" associated with it where the ttyS1 does not. I was wondering what the "console [ttyS0] enabled means?

I think this is because of unix history. Originally, as this is well explained in that mail, there was two kind of serial port: the /dev/tty* and the /dev/cu*. Long story short, the tty ones are for incoming connections over the serial port, and the cu ones are for outgoing connections over the serial ports. And at the other end, there was unix consoles, the serial terminals.

As your single board computer is communicating using a console over a serial port and has no "real" console (I mean display and keyboard) to bind the console to as a pseudo tty (the /dev/tty), chances are that your /dev/ttyS0 is indeed used by the kernel as a console for input and output, waiting patiently for a terminal to connect and assert the DTR line. But there you start sending data and not respecting that 40 year old protocol.

To solve your situation, chances are that you need to change the kernel boot line in the bootloader so that you change console=/dev/ttyS0. You may also want to look at /dev/inittab and check around the getty lines.