[SOLVED] Help registering memory-mapped UART8250/16550
Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.