New to using serial console and trying to log into embedded system

Question

I have two PC Engines Alix 2d2 which I've been given and I'm trying to install an (BSD or Linux based) OS on. Currently one has a version of openWRT (the other had openWRT until I formatted the CF card and put on a version of FreeDOS (I don't know if this works because no console)). Both boards were in working order before I began, allbeit working as openWRT systems. I did not test either of their serial ports before I started (although i have changed nothing about the second system so...)

In addition to the alix boards I have:

1. a Windows desktop without a built in serial port
2. a USB to serial adapter which I have been using with the Windows desktop
3. a Linux box which has a serial port on the motherboard
4. one serial cable (Startech branded, described as straight through)

I have connected each alix board to both computers 1 at a time trying to get, well, anything to come though the serial connection. I've read several articles and how-tos on the internet about the alix boards noting that the speeds mentioned either seem to be 9600 or 38400 so I've tried both.

On Windows I was using PuTTY's serial mode to connect (I double checked which com port I was using) and on Linux I was using minicom with the -D 9600/38400 -p /dev/ttyS0 (I also have ttyS1-3 but minicom would not connect to them).

So far I've had nothing from the boards, the how-tos describe a brief memory check when they boot, but I've not seen a single character. Never having used a console over serial before I'm at a loss as to what I should try next so any suggestions (or reading material) would be very welcome.

Answer 1

You need a null modem cable (or a null modem adapter attached to your serial cable) if both ends of the connection are implementing the DTE side of the RS-232 protocol.

Typically computers are DTE and peripherals like modems are DCE. Your embedded board is halfway is kind of a hybrid (runs OSes that also run on PCs, but intended for use as a peripheral possibly) so it's hard to be sure what kind of serial port they'd put on it.

The gender of the connectors would be a strong indicator. If you had to use a gender-changing adapter to get your cable plugged in, chances are good that what you really needed was a null modem. DCE ports are usually female, and DTE ports are usually male, so a straight-through cable will have one of each connector and a null-modem cable will have 2 female ends.

If RJ-45 connectors are involved, things get tougher. There are more cable configurations to choose from, and gender is no longer a guide.

Answer 2

I don't know if this is your whole problem or just a part, but as derobert commented above, /dev/ttyS0 isn't the right /dev node to use for a USB to RS-232 serial adapter. Under Linux, that refers to the first traditional PC on-board UART.

The right /dev node is most likely ttyUSB0, and if not that, it could also be ttyACM0.

Most serial to USB adapters I've used present themselves to Linux in such a way that they get called /dev/ttyUSB*.

The main alternative — ttyACM* — is for USB devices that present themselves to the bus using the Abstract Communications Model interface. ACM devices are most often modem-like devices, but I've used USB to serial adapters that presented themselves this way instead of as ttyUSB*.

Beware, sometimes you will be using a given device that presents one way, then they'll make a design change so that its successor device is the other way. Arduinos swing both ways, for example, and I think I've used USB modems that changed between product versions that way, too.

Bottom line, in today's modern dynamic /dev world, you can be pretty sure if either exists, it's the right one to use, because neither will show up if the OS doesn't recognize the adapter.

Because of that, one way to chase this is to plug the adapter in, then simply say ls -tr /dev | tail -20 or something like that to get a list of the 20 most recently-added /dev nodes. The last line is probably your device, and if not, it's probably close to the end of the list.