Help registering memory-mapped UART8250/16550
 

Here is brief summary of my situation:
I have two identical x86 boards, connected via an FPGA<->FPGA UART. The FPGAs have some memory-mapped registers which are supposed to implement UART8250/16550. The FPGA SDK provides some user-space driver that can facilitate communication via API calls, but I was hoping to use standard Linux 8250/16550 drivers and have a device file that I can use with picocom or something similar.

My question is, how would I register this UART console with the kernel and have a /dev/ttyS# to use?

I tried putting this in my kernel boot line with the memory-mapped offset of the 8250/16550 registers:
console=uart8250,mmio32,0x908030a0,115200n8

I don't think it quite accomplishes what I want. Seems like just some kind of early console that doesn't carry on after boot.
[ 0.000000] earlycon: Early serial console at MMIO32 0x908030a0 (options '115200n8')
[ 0.000000] bootconsole [uart0] enabled
...
[ 9.589154] bootconsole [uart0] disabled

The first thing I would say is that the 8250 and 16550 are very different animals. The 8250 was primitive; you want the 16550 if you're offered the choice, 16550A actually.

The kernel loads modules for what it detects. Do your serial ports show in dmesg/syslog?

Thanks - the FPGA implements a 16550 UART. It doesn't show up in dmesg unless I use that earlycon/console flag shown in my initial post, but then it disables itself after kernel boots and disappears (I think this is expected behavior). I believe the issue is that the UART implementation right now is just a range of registers in memory mapped PCI space and kernel has no way to detect it as a UART without being informed that it is. Most people I see online use some kind of device tree for this situation but I don't know if that is really the only solution.

When you use the boot mode option, does the output show up on this console? Are you able to receive anything on the FPGA? If yes, the UART is compatible with the generic driver. If it doesn't, it might mean that the register set is different and you'll have to look which hardware block it is and if there's another driver in Linux to support it.

When you're done with finding out if the port is compatible, it should be possible to create the right device tree so that you have the console all the time.

I am not really looking at this console yet since it is an FPGA<->FPGA UART and I don't have a driver working on the Rx side to see.

But, if we assume UART is compatible with the generic driver, and the kernel just doesn't know about it, is device tree the only way to resolve this? I know very little about device trees but my platform is not currently using one and it doesn't seem that common on x86. I wonder if this is something BIOS/UEFI might be able to establish before kernel gets loaded.

Just answering my own question in case anyone in the future finds this,

I was able to add my FPGA's PCI/UART IP information in the drivers/tty/serial/8250/8250_pci.c data structures so that the kernel could detect it at boot & create /dev/ttySN for each UART channel.