Hardware-Serial via PCI not detected. about consolepi

[Pack3tL0ss]

@Gandalf1783 Sorry for the delay, wasn't getting notifications on new issues.

I need investigate the best way to implement this. If the PCI card is presenting the serial device as /dev/ttyS0 ... this is typically the serial port tied to the kernel (on an rpi, and most other linux based systems). So it wouldn't be something you would want in the menu (it would just give you a shell to the device you are already on).

I currently support the additional UARTs available on the Pi4+ GPIO with a config option, I could do the same for ttyS0... That's probably the best way, as most systems will have a ttyS0, but it would be for incoming connections, and therefore not be useful in the menu.

Curious what the output of ls -l /dev | grep tty | grep ^l and ls -lhF /dev/serial/by-id/ is on that system.

[Gandalf1783]

Hm, as stated its a general x86 PC, so the kernel might just take control of the first serial console that seems available, surely that there is an option to tell the kernel to ignore specific serial devices?

I know thought that through C libraries in a previous usecase these have been able to output data, though it might be on an older debian version.

The first command returns no lines and the second fails because /dev/serial does not exist.

[Gandalf1783]

I am thinking if one could use udev rules to move the ports to different descriptors. Could this be an option?

[Pack3tL0ss]

ConsolePi uses udev rules to map the system device names to friendly aliases (so ttyUSB0 becomes some-device-name in the menu. That's what the rn (rename) option in the menu does.

You can tell the kernel what device to use (/boot/cmdline.txt on an rpi, or part of grub.cfg on many other systems).

Easiest way I think is to add an option to the config something like:
OTHERTTY: [ttyS0]
Then just for simplicity, I'll change the documentation and support the GPIO UARTs via the same config item, they are currently set like this:
TTYAMA: [ttyAMA1, ttyAMA2, ttyAMA3]
which would still work, but the following is what will be documented:
OTHERTTY: [ttyS0, ttyAMA1, ttyAMA2, ttyAMA3]

TTYAMA is an option currently for the same reason. I can't automatically detect that it's a useful thing to include, because the device is always going to exist (but doesn't do any good if they haven't set the boot options to use them, and don't have anything connected to the GPIO pins). ttyS0 is in the same boat, it's going to exist on most systems, but won't do any good if it's not setup to communicate with an externally connected device. The config option will just tell me to include it.

I'll add support for OTHERTTY (or something along those lines) as a config option in the next release. Hopefully pushed in the next week or so.