Is there a USB module that can act as a "pseudo" serial console device?

English Install/Boot/Login
1

I have a machine on which, AFAIK, in general principle, Xen should
work, but will not boot. This has been true for the last few versions
of openSUSE, up through 12.1. Typically, there doesn’t appear to be
anything in the logs that would explain why Xen doesn’t boot. The CPU is
an AMD Phenom X4. The hardware virtualization support is
enabled. I let YAST install Xen. So I’m not configuring Xen myself.

Often someone will suggest that there might be messages during the boot,
which might not make it into the logs. They’ll suggest I try to use an
RS232 serial console to capture boot messages into a file on another
machine, by connecting RS232 serial ports, between two machines.

Unfortunately, there is no RS232 serial port on this machine, and I am
not in a position to add one, at a hardware level.

I’m wondering, is there a module that I can obtain which would,
at boot time, appear to be an RS232 serial port, and allow sending serial
console data via USB to some other machine?

2

On 2012-01-23 23:36, toes wrote:

> Often someone will suggest that there might be messages during the boot,
> which might not make it into the logs. They’ll suggest I try to use an
> RS232 serial console to capture boot messages into a file on another
> machine, by connecting RS232 serial ports, between two machines.

Right.

Although the feature is currently a little bit broken (systemd).

> Unfortunately, there is no RS232 serial port on this machine, and I am
> not in a position to add one, at a hardware level.

Bad luck.

Although… many boards do have a serial port, but the boxes do not have a
connector. That’s my case, I specifically bought a board with serial port,
I searched for it. I had to wire the connector myself.

> I’m wondering, is there a module that I can obtain which would,
> at boot time, appear to be an RS232 serial port, and allow sending serial
> console data via USB to some other machine?

Not to my knowledge.

That is, there are serial converters plugged to an usb connector, yes. You
may be able to send console text to an usb device, yes. During boot? No.
Because the serial port is an antique it is also very low level, and can be
used very early in the boot process. Even before booting. You only need a
simple write instruction to an i/o port of the processor to print a byte.
It gets more complicated if you add flow control, but at the base it is
terribly simple.

However… I suggest you ask in the kernel mailing list at openSUSE, they
should know more about this.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

3

…]

…]

While it’s true that often a UART is integrated into a computer’s design as
being accessed via the port address space of a CPU, are you suggesting
that at boot time there is no canonical processing of the serial console,
for example, there is no XON/XOFF flow control support?

4

On 2012-01-25 01:26, toes wrote:

> While it’s true that often a UART is integrated into a computer’s design as
> being accessed via the port address space of a CPU, are you suggesting
> that at boot time there is no canonical processing of the serial
> console, for example, there is no XON/XOFF flow control support?

Hardware flow control is a part of the uart, but if you are writing debug
messages to it while booting and have to wait till ack, the coding gets
complicated. What do you do, wait the booting? Or have two threads that
early in the boot process? Or a buffer and interrupts?

I do not know how they manage to do it. I have used the serial port in
assembler, long ago, I know it gets tricky. If they have flow control, I
must lift my hat :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)

5

Having worked with a variety of different types of UART’s, AFAIK what the UART does
depends on the UART, they are not all made the same. Some communications
protocols use a dynamic change in parity as a flag for different portions of the
communications stream, since it has been shown, in some contexts, to be more
resistant to noise than some other mechanisms. Some UART’s will buffer bytes
but even though the parity was different when different bytes were sent to the
UART, all bytes will be sent out with whatever parity is set when a byte
finally goes out. Other UART’s will associate parity and other settings with each
byte as it was sent to the UART.

Since it seemed that at one point in your initial response you were talking about
port I/O, but then went on to mention flow control, which I would usually think of
as a software concept, it wasn’t clear to me, what type of flow control you meant.
I didn’t know if you meant XON/XOFF as in Control-S/Control-Q, or flow control in
the sense of preventing data collisions over USB, since I was asking about USB
modules, or what exactly.

Ultimately, it was my own curiosity more than anything else, I suppose, strictly
speaking it may all be, beside the point.

It’s a good issue you raise about what would someone do if the output, during boot,
did allow suspension. Yet on the other hand, even while getting messages from the
BIOS before any disk based boot loader has been read, you can hit the “Pause”
key on the keyboard, and “pause” things, so maybe something could be done…

Anyway, since it looks as if it’s OK to ask questions of the openSUSE Kernel Mailing
List, I suppose I will pursue my original question there. Thanks for the info.

6

On 2012-01-25 04:46, toes wrote:

…

> Anyway, since it looks as if it’s OK to ask questions of the openSUSE Kernel Mailing
> List, I suppose I will pursue my original question there. Thanks for the info.

Welcome :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)