Issues when adding a multi-port PCI serial card

[dufault at hda.com]

> On Mar 13, 2020, at 08:42 , Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:

Thanks for replying.

> 
> 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.

The fact that all recent drivers have major and minor numbers of 0 is confusing.  I wanted a minor number in order to enumerate the serial ports.  I don't mind that RTEMS goes away from major and minor numbers, but doing an "ls -l" and seeing all those "0" entries is, as I said, confusing.

* Does that happen on FreeBSD?

>> 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.

Are you indirectly replying to my previous comment about wanting a minor number for serial device enumeration reasons?

>> 
>> 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".

I put the driver in "bsps/shared/dev/serial", I decided that was better than "/dev/pci".  I don't know what goes in "cpukit" versus "bsps".

* What distinguishes where a shared code should go? Should much of what is "bsps/shared" be in "cpukit" instead?

>> 
>> 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"?

I don't want that because I just don't want that, I want generic serial ports to have generic names such as "/dev/ttySX".
 
* Can you explain why "/dev/pci-serial-XXX" is a good option for the end-user?

> 
>> 
>> 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

Thanks, I will review this.  I didn't see an explanation of the ordering.
> 
>> 
>> 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.

I don't need the shell spawned on one of the added serial ports.  I thought it would be an easy way to test the driver, but it isn't.  Obviously the "telnet" daemon does some monkeying around with "stdin" and "stdout" in order that it works via telnet.

* It would be great if it worked but I'm not going to investigate it.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email is delivered through the public internet using protocols subject to interception and tampering.