I've got a board based on the Vortex86DX CPU which is an x86 based microcontroller. It has five 16550A UARTS, four (COM1-COM4) of which are at the usual io port addresses (0x3f8, 0x2f8, 0x3e8, 0x2e8) but the fifth (COM9) is at 0x010, irq 9.


The first four UARTS are detected, I have no problem with them. The problem is that I can't get the fifth one (COM9) to work in Linux. COM9 works in a stand alone DOS application, but I can't even detect it from Linux.

What I've done so far:

Result: the kernel failed to probe the UART at address 0x010

So I wrote an io port probing utility to directly read from io port 0x010, and I could not detect any 16550A registers in the 0x010 to 0x017 region. It appears there is nothing there. I have been trying to write and read back data from the scratch register (offset +7), but I get nothing at address 0x017.

The datasheet for the CPU doesn't say much. It indicates there is a control bit in a Southbridge register that does "something" for COM9. I wrote a PCI utility that wrote to this bit, but it didn't seem to enable the COM port or change anything when I did the io port probing.

Any help would be appreciated at this point!


I don't see why you've gone to all the trouble to change the kernel source code to add support for this nonstandard serial I/O port and IRQ. The setserial(8) program should be able to configure it for you. Something like this:

# setserial ttyS4 address 0x10 irq 9

See the Linux Serial HOWTO for more details.

  • Nope, setserial doesn't work. The kernel still does the same autoconfig and scanning as setserial does. # setserial /dev/ttyS4 port 0x10 irq 9 uart 165 50A ttyS4: LSR safety check engaged! – Mr Stinky Jul 9 '12 at 7:32
  • An attempt to do a setserial autoconfig fails with: ttyS4: autoconf (0x0010, 0x (null)): IER test failed (0f, 0f) type=16550A ttyS4: LSR safety check engaged! ttyS4: LSR safety check engaged! Which is what the kernel fails with as well. – Mr Stinky Jul 9 '12 at 7:40
  • If you look in the Serial HOWTO I pointed you to for "LSR safety check" you find that it means there is no serial port at that address. (It can also mean the UART has a buggy implementation, but that's probably not what's going on here.) You've run into the limits of the "Linux" part of the problem, so I suggest you re-post this question on electronics.SE to chase the low-level parts. The programming guide on the page you point to is near-useless for answering this, but maybe you'll get lucky and find someone who has programmed this SoC before. – Warren Young Jul 9 '12 at 13:12
  • I've since got the UART part working. Now I'm working on getting the Linux part working. My driver enables the correct settings in the Southbridge now, but Linux doesn't associate the /dev/ttyS4 with a tty. e.g. # stty -F /dev/ttyS4 9600 stty: /dev/ttyS4: Input/output error – Mr Stinky Jul 9 '12 at 14:05
  • Just to add. Linux detects my COM9 as ttyS4 in dmesg. e.g. serial8250.11: ttyS4 at I/O 0x10 (irq = 9) is a 16550A. udev/mdev will automatically create a node for it in /dev. So AFAIK the kernel knows about this node, but it doesn't seem to work as a tty device. e.g. # picocom -b 9600 /dev/ttyS4 ... FATAL: failed to add device /dev/ttyS4: Filedes is not a tty. Possibly there's a problem in my driver, but it all looks fairly straight forward how I am supposed to add a basic 8250 compatible device. – Mr Stinky Jul 9 '12 at 14:17

It appears that either the BIOS or Linux disables the COM9 port in the Southbridge registers.


  • "Internal UART9 Control Register" must be reset to its default value of: 0x00810010
  • "On-Chip Device Control Register" must have bit 9 cleared to re-enable COM9.

I don't know why or where these are disabled.

When I set them to sane values in my device driver I was able to detect the COM9 UART.

Linux requires a new x86 chip type for the Vortex86DX. It is not 100% compatible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.