First the serial, in this context generally refers to EIA RS-232C serial interface, or at least something more-or-less compatible with that (most notably electrically). Per standard, this would be DB-25 M for DTE (Data Terminal Equipment - e.g. the terminal itself), and F for DCE (Data Communication Equipment - e.g. the serial phone modem). The specification was written primarily to standardize the communication between terminal and modem. E.g. one would have terminal, connect that to modem, connect the modem to phone line (might be acoustic coupled, or possibly direct connection), phone would generally dial up some computer - well, actually a modem on the other end, which would go to serial port on another computer - and even that often not directly, but through, e.g. port sharing equipment (e.g. to allow one to select which computer at a location that one wanted to connect to).
Also beware that just because it's, e.g. DB-25 or DE-9, doesn't necessarily mean it's at all RS-232C or signal compatible with such, so connecting the wrong things together could cause damage. However RS-232C specification is such that improperly interconnecting two RS-232C interfaces, regardless of how they're miswired between each other and/or themselves, shouldn't cause any electrical damage (in about 40 years experience, I've only seen one fail in such a case). So, e.g., DB-25 and DE-9 may be Centronics parallel, or SCSI, or video (e.g. MDA or CGA), among many possibilities other than RS-232C, so interconnecting electrically incompatible could be quite bad and damaging. However, even early on, the specification wasn't always strictly followed, e.g. though DTE calls for M, many terminal manufacturers would in fact make their connectors F rather than M (my guess is to not have to deal with servicing bent pins on the connector for the terminal itself - easier to replace an external cable if the pins get bent on the cable end instead). And, though the IBM PC and PC-XT followed the standard, using DB-25M for their DTE ports that they supplied via adapter card(s), when it came to the PC-AT, they switched to DE-9 M for DTE, so in subsequent years, that became more common - especially on the computer end, though most modems still used DB-25F. The full RS-232C specification supports two full sets of communication lines. Most of the time only one set is used, so between that, and some other rarely used connections, that made use of DE-9 feasible for most of the more common purposes. In fact if software flow control is used, communication can be done with as few as three for basic serial communication, but that may drop some functionality - e.g. like RI for Ring Indicator/Indication signal from the modem. Though many modems can or will send the string RING to indicate line is RINGing, that may not be distinguished from transmission of such characters that isn't an actual RINGing telephone line - hence, e.g. a separate RI signal line for that. Other hardware may further modify things, e.g. with original specification and staying within it, maximum achievable distance would be 15m/50ft., and maximum speed of 19200 bps. But with some tweaking of hardware specifications/tolerances, and low cap(acitance) wiring, that could be extended up to 200' in many cases, and speeds could also potentially go much higher, so about 56K is the limits on what could be handled over a typical analog phone line (due to its signal characteristics and limitations), but with direct wired connection, significantly higher speeds can be achieved, and notably including newer standards that are also generally backwards compatible. 153600 or something close to that is probably the highest that's typically supported on any such interfaces, and not all such hardware necessarily supports such higher speeds. In fact relatively early modems had a top speed of 300 bps - for text, that's generally far below the speed most people can read at. So, that's the serial bit - originally primarily aimed for between data/computer terminal (e.g. vt-100, Teletype 33-ASR, etc.) and modem (or directly to computer), but has been used more generally for a fair amount of communication beyond that (e.g. two computers can directly communicate with each other over a serial connection - e.g. UUCP worked as dial-up based networking, or could likewise work over directly connected serial lines). But because of its popularity and (relative) standardization, it got used for many additional things (e.g. serial printer). And console - notably computer console. That concept goes way back. Generally referred to the primary input/output/display on the computer itself, intended for computer operator. Notably to be used to control the computer to view status, start and boot it and control that, stop it, etc. On older computers it may be nothing more than a bunch of lights and toggle switches (e.g. early DEC PDP-11 series). Some would have a hex keypad for input, and might have some type of digital display. As hardware became more capable, most systems moved to the console being some type of terminal or terminal-like device, perhaps with additional controls and functionality, but mostly looking and acting like a terminal. And, many computer systems evolved so they'd use a serial terminal as their console device - so that would serve as the input and output to control basic operations such as boot, etc. For many computers, this is still an option. E.g. Raspberry Pi can do this - it has a serial-like interface ... 3 pins ... but at TTL rather than RS-232C levels, but a simple hardware circuit can shift that, or one could connect as-is to use such for two Raspberry Pis to be able to directly communicate over such. In the land of Linux, though there may be more serial devices, the first two are /dev/ttyS0 and /dev/ttyS1. Those are the first and second serial ports, and can be used as serial console. In fact Linux can do quite a variety of consoles, and can even output to more than one - though it will only use one as console input. Linux can do display adapter console (e.g. whatever the typical screen built-in to the computer is, or the display that's connected to it via cable - and likewise keyboard for input), it can do serial console (e.g. for terminal), it can do console over network, and if I recall correctly, it even has parallel port console capabilities. So, Linux, compiled in and/or from hardware detection, or from arguments passed when booting kernel, it will pick console device(s), it will use only one for input, but can use more than one for output. Many boot loaders, notably including GRUB, can also deal with at least some different types of consoles (e.g. the typical built-in or installed graphics card and connected keyboard, or serial). So, tty1-tty63 are virtual consoles on Linux, and one can switch among them, though commonly tty1-tty4 are used, possibly more up to tty12, but most commonly additional beyond tty12 aren't activated. There's also tty0, which is always the current active virtual console. So, that's what Linux will typically use by default, if it has relevant hardware for that. Here are example arguments from a running kernel: console=tty0 console=ttyS0,9600n8 That first specifies the more typical console - that would be via display adapter and attached keyboard. The second is for serial, and also specifies additionally some communication parameters to set on the interface. In the case when more than one such console= argument is present, the last is used to specify what is used for console input, and all are used for console output. Now, that particular host happens to be VM, so that serial is virtual rather than physical, but within the VM infrastructure there are ways to connect to and use that virtual serial port, including for input and output, quite as if one were using it via an actual physical serial terminal. And I do also have physical host hardware where I've set them up to be able to use actual serial terminal for console, though I don't have them doing that presently. Note also that enabling login in regular multi-user mode on serial ports is different than serial console. May use same port for both, but if, e.g., login isn't enabled on the serial port - even if it's serial console, once the host is up and running in regular multi-user mode, there's no login prompt there nor listening process to allow login there. On Wed, Jul 30, 2025 at 4:59 PM mick.crane <[email protected]> wrote: > > I've never really known what a serial console is. > Say in relation to a Raspberry Pi or Arduino > I assumed a serial console was a device with a screen and keyboard. > When people talk about a serial console they are talking about > connecting a Debian PC to a device with a parallel, wired cable to a > parallel port or an adaptor on a PC and emulating this console thing > with software? > Like a telnet connection? > mick
