Issues when adding a multi-port PCI serial card

[Sebastian Huber]

On 12/03/2020 21:44, Peter Dufault wrote:

> I've added an 8-port RS232 PCI Mezzanine Card to the "beatnik" BSP.  The console (aka serial port) code is confusing.
>
> I decided I should use what is in "bsp/console-termios.h"  as opposed to the "legacy console" approach, *even though* "legacy console" is used in many recent BSPS.
What is a recent BSP for you? I would call all BSPs which still use this 
major/minor number drivers a legacy BSP.
>
> * Is that correct?
>
> That approach went well, I created a replacement shared PowerPC console in "bsps/powerpc/shared/console/console-config.c" with only 129 lines of code and half of it comments.
This is probably all right. What we don't have in RTEMS is a generic 
device enumeration framework.
>
> Where does the driver go:  Next I had to add the PCI multi-port serial card driver.  I put it in "bsps/shared/dev/pci/mp_serial.c".  The other directory choice was "bsps/shared/dev/serial".  I didn't like either, the "dev/pci" is very associated with PCI discovery and the "dev/serial" is very associated with the generic low-level serial driver support, even thought it has the "legacy-console" cruft in it.
>
> * Where should it go?
The serial drivers which are not specific to a BSP should go to 
"bsps/shared/dev/serial" or even "cpukit/dev/serial".
>
> Difficulty in assigning common TTY names: Since my new shared PowerPC "console-config.c" created "/dev/ttyS0" and "/dev/ttyS1" I wanted to name the new serial devices with a number that started at 2, i.e., "/dev/ttyS2".
>
> * Is there a way in the "console-termios" framework to know what the highest "minor number" for a serial port is?  I searched, gave up, and made it a configuration item.

No, we don't have a framework for unit number assignments. It is not 
that easy if you look at the FreeBSD code. Why don't use use driver 
specific names, e.g. "/dev/pci-serial-XXX"?

>
> Next I had to figure out the best way to probe and discover the board.
>
> * I wanted to add an RTEMS_SYSINIT_ITEM that would call a probe routine to discover the multiport cards at the appropriate time, after "/dev/console" was discovered but before I wanted to spawn my shell.  I had trouble figuring out what level and order I should use for the probe routine.  I never got this working, my probe routine kept getting called much later then I expected it to.  I need a pointer to the documentation to RTEMS_SYSINIT_ITEM ordering.

I would initialize this in the Init task. The system initialization is 
documented here:

https://docs.rtems.org/branches/master/c-user/initialization.html#initializing-rtems

>
> Finally, after initial successful loop-back testing, I tried to start an RTEMS shell on one of the new ports.
>
> *Here I'm trying hard to avoid all-caps because this took the most time of all (it should have been easiest), and I gave up!*
>
> * HOW (sorry) do you spawn a shell on a serial port?  The documentation, at https://docs.rtems.org/branches/master/shell/configuration_and_init.html that suggests just setting the shell device name to "/dev/console", or in my case "/dev/ttyS9", is incorrect.  The shell startup is intent on using "stdin" and "stdout".
I don't know this off hand.