Enable more than 6 serial ports on BeagleBone Black w/ Debian?

All,

How do I increase the number of serial interfaces from 6 to 9 on a BeagleBone Black running Debian?

Current state:
We’re using 9 USB to serial interface adapters attached to a powered USB hub that is plugged into the single USB-A port on the BeagleBone. Only 6 can have connections opened simultaneously. On the 7th, we get an “Input/output error.” We can mix and match whichever specific connections are opened, but it’s always the 7th that will error, which seems to indicate it’s a system limit.

Verified max number of UARTS enumerated
dmesg: “Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled”
/boot/config-5.10.168-ti-r72:
CONFIG_SERIAL_8250_NR_UARTS=6
CONFIG_SERIAL_8250_RUNTIME_UARTS=6

Things attempted:

Changing Debian distribution. These are all sourced from the BeagleBone pages:
Debian 10.3
Debian 11.7
Debian 12.2

All 3 versions are by default limited to 6 for both NR and RUNTIME UARTS. I tried increasing the kernel boot line in uBoot by appending to cmdline “8250.nr_uarts=9” and/or “nr_uarts=9”. The number of enumerated ports stayed at 6, as evidenced by dmesg Serial line. To ensure the parameters were being seen, I tried decreasing it to 5, and, of course, 1 of the 6 errored out during boot.

For comparison on a RHEL7.9 x64 virtual machine, I see the below info, and it is responsive to the kernel command 8250.nr_uarts=16.
/boot/config-3.10.0-1160.el7.x86_64:
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4

I suspect we will need to recompile the kernel - or perhaps there is a hardware limitation? I appreciate any insights.

What USB chipset are these USB serial adapters? There is always a chance your running out of USB 2.0 bandwidth. That kernel config is specific to 8250 internal devices. USB serial adapters have a different limit.

Regards

Thanks for your reply, Robert.

I didn’t realize that USB serial interfaces don’t use the 8250 driver. I don’t know precisely what chipset the devices (Signalhound model VSG25A) are using. They are using the cdc_acm driver and addressed as ttyACMx.

I don’t believe the USB bus is saturated. All that we’re doing as a test is to opening 8 connections simultaneously - no data traffic. It fails on the 7th one with an Input/Output error.

I am struggling to find any information on how to increase the limit of these ttyACMx devices.

See below for system output.

Error we receive when trying to connect to 8 devices simultaneously.


root@beaglebone:~# python3 /home/pi/eight_sh_connection.py
Connected to 1
Connected to 2
Connected to 3
Connected to 4
Connected to 5
Connected to 6
Traceback (most recent call last):
File “/usr/local/lib/python3.7/dist-packages/serial/serialposix.py”, line 322, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
OSError: [Errno 5] Input/output error: ‘/dev/ttyACM6’


Listing of ports, lsusb, dmesg, messages file output


root@beaglebone:/home/pi# ls -l /dev/ttyACM*
crw-rw---- 1 root dialout 166, 0 Nov 11 12:22 /dev/ttyACM0
crw-rw---- 1 root dialout 166, 1 Nov 11 12:22 /dev/ttyACM1
crw-rw---- 1 root dialout 166, 2 Nov 11 12:22 /dev/ttyACM2
crw-rw---- 1 root dialout 166, 3 Nov 11 12:22 /dev/ttyACM3
crw-rw---- 1 root dialout 166, 4 Nov 11 12:22 /dev/ttyACM4
crw-rw---- 1 root dialout 166, 5 Nov 11 12:22 /dev/ttyACM5
crw-rw---- 1 root dialout 166, 6 Nov 11 12:22 /dev/ttyACM6
crw-rw---- 1 root dialout 166, 7 Nov 11 12:22 /dev/ttyACM7
root@beaglebone:/home/pi# lsusb
Bus 001 Device 012: ID 2817:0101
Bus 001 Device 011: ID 2817:0101
Bus 001 Device 009: ID 2817:0101
Bus 001 Device 007: ID 2817:0101
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 010: ID 2817:0101
Bus 001 Device 008: ID 2817:0101
Bus 001 Device 006: ID 2817:0101
Bus 001 Device 005: ID 2817:0101
Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@beaglebone:/home/pi# lsusb -v

Bus 001 Device 012: ID 2817:0101
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x2817
idProduct 0x0101
bcdDevice 1.00
iManufacturer 1 Signal Hound
iProduct 2 VSG25A
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0042
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.20
CDC ACM:
bmCapabilities 0x02
line coding and serial state
INVALID CDC (Union): 04 24 06 00
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
can’t get device qualifier: Resource temporarily unavailable
can’t get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)


From dmesg:


[ 2.715626] usb 1-1.3.1: new full-speed USB device number 5 using musb-hdrc
[ 2.841023] usb 1-1.3.1: New USB device found, idVendor=2817, idProduct=0101, bcdDevice= 1.00
[ 2.841040] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.841048] usb 1-1.3.1: Product: VSG25A
[ 2.841055] usb 1-1.3.1: Manufacturer: Signal Hound

[ 56.656651] cdc_acm 1-1.3.1:1.0: ttyACM0: USB ACM device
[ 56.667108] cdc_acm 1-1.3.2:1.0: ttyACM1: USB ACM device
[ 56.689276] cdc_acm 1-1.4.1:1.0: ttyACM2: USB ACM device
[ 56.730413] cdc_acm 1-1.3.3:1.0: ttyACM3: USB ACM device
[ 56.737469] cdc_acm 1-1.4.2:1.0: ttyACM4: USB ACM device
[ 56.757647] cdc_acm 1-1.3.4:1.0: ttyACM5: USB ACM device
[ 56.765354] cdc_acm 1-1.4.3:1.0: ttyACM6: USB ACM device
[ 56.792679] cdc_acm 1-1.4.4:1.0: ttyACM7: USB ACM device
[ 56.803869] usbcore: registered new interface driver cdc_acm
[ 56.803886] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters


Sorry you were correct, i shouldn’t reply when waking up!

Let’s test: https://openbeagle.org/RobertCNelson/ti-linux-kernel-dev/-/commit/90f0937c43de4b958744dba2b15e29cff65fa1dd

Give our CI about 10 minutes for a testing debian package…

Okay give this a quick test:

wget https://openbeagle.org/RobertCNelson/ti-linux-kernel-dev/-/jobs/51257/artifacts/raw/deploy/linux-image-5.10.168-ti-r82.1_1xross_armhf.deb ; \
sudo dpkg -i linux-image*.deb

Regards,

Wow! Thanks for the quick response Robert.

I installed the linux-image-5.10.168-ti-r82.1_1xross_armhf.deb file.

The good news: The system would let me increase the 8250.nr_uarts to 9.

debian@BeagleBone:~$ cat /proc/cmdline
console=ttyS0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet 8250.nr_uarts=9 nr_uarts=9
root@BeagleBone:~# dmesg | grep -i serial
[ 10.587224] Serial: 8250/16550 driver, 9 ports, IRQ sharing disabled
[ 10.594117] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 20, base_baud = 3000000) is a 8250
[ 10.625097] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 27, base_baud = 3000000) is a 8250
[ 10.626969] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 28, base_baud = 3000000) is a 8250
[ 10.629166] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 43, base_baud = 3000000) is a 8250
[ 10.630836] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 44, base_baud = 3000000) is a 8250

The bad news: We still can’t get over 6 /dev/ttyACMx devices talking simultaneously. :cry:

debian@BeagleBone:~$ python3 eight_sh_connection.py
Connected to 1
Connected to 2
Connected to 3
Connected to 4
Connected to 5
Traceback (most recent call last):
File “/usr/local/lib/python3.11/dist-packages/serial/serialposix.py”, line 322, in open
self.fd = os.open(self.portstr, os.O_RDWR | os.O_NOCTTY | os.O_NONBLOCK)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 5] Input/output error: ‘/dev/ttyACM5’

(In this test we used an active USB extender, which seems to consume one of the ttyACM limited slots).

Side note: For comparison, we were able to simultaneously connect to all 8 devices using the same USB hub from a Windows 11 and Red Hat Enterprise Linux 9 laptop w/ no problems. The RHEL9 system also used the cdc_acm driver.

For posterity, in the interest of time, we moved on from the BeagleBone Black. I’m guessing it’s a hardware limitation.

We have tested 9 simultaneous USB serial connections to work on both of the following:
Raspberry Pi 3 B+
BeaglePlay

I speculate the much beefier CPUs (quad-core 1.4GHz) and possibly the 64-bit architecture on these two make this possible (as opposed to the BBB’s single-core 1GHz CPU and 32-bit architecture).