Pack3tL0ss / ConsolePi

Raspberry Pi Based Serial Console Server, with PushBullet Notification of IP changes, Automatic VPN termination, custom menu, Power Outlet Control, and a lot more
MIT License
178 stars 15 forks source link

Hardware-Serial via PCI not detected. #197

Open Gandalf1783 opened 2 months ago

Gandalf1783 commented 2 months ago

Hey, I got a serial pci controller having 2 ports:

01:00.0 Serial controller: Nanjing Qinheng Microelectronics Co., Ltd. Device 3253 (rev 10)

This is the dmesg output: root@dns:~# dmesg | grep 0:01:00 [ 0.131872] pci 0000:01:00.0: [1c00:3253] type 00 class 0x070005 [ 0.131892] pci 0000:01:00.0: reg 0x10: [io 0xe000-0xe0ff] [ 0.131903] pci 0000:01:00.0: reg 0x14: [mem 0xd0100000-0xd0107fff pref] [ 0.131914] pci 0000:01:00.0: reg 0x18: [io 0xe100-0xe103] [ 0.131953] pci 0000:01:00.0: reg 0x30: [mem 0xfe500000-0xfe507fff pref] [ 0.132013] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold [ 0.696294] 0000:01:00.0: ttyS0 at I/O 0xe0c0 (irq = 16, base_baud = 115200) is a XR16850 [ 0.696389] 0000:01:00.0: ttyS1 at I/O 0xe0c8 (irq = 16, base_baud = 115200) is a XR16850

Its running on a HP MT 3500. ConsolePi does not see the console at ttyS0 and ttyS1.

Can you add support for these?

Pack3tL0ss commented 2 weeks ago

@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 commented 2 weeks ago

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 commented 2 weeks ago

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

Pack3tL0ss commented 2 weeks ago

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.