Serial console output on non-standard port number?

dyener

I'm wondering if any FreeBSD gurus here might be able to advise about getting the serial console to work on my hardware. The device is a Compulab Fitlet2, which has a built-in serial port. I suspect the problem is that this serial port is not the "first serial port" as viewed by pfSense/FreeBSD. I see four hypothetical serial ports in the software:

# ls /dev/cuau?
/dev/cuau2 /dev/cuau3 /dev/cuau4 /dev/cuau5
# ls /dev/ttyu?
/dev/ttyu2 /dev/ttyu3 /dev/ttyu4 /dev/ttyu5

Apparently there is a known problem in Linux where the actual physical serial port is assigned a strange name. I'm suspecting the same is the case here in FreeBSD. But in the pfSense GUI, the option to enable the serial console only allows you to use the "first serial port", which I'm guessing is #2 in this case, but maybe I should be using 3, 4 or 5.

Is there a way I can change this from the command line, to test the different options? For example, in Linux I know how to define the serial console port in the GRUB config file and update the bootloader; but I have no idea where to start in FreeBSD.

Incidentally, I also have the earlier-generation Fitlet1 device running pfSense, same configuration, and its console works perfectly, with the same cable. But it has a different BIOS and CPU and shows only one serial port (cuau0/ttyu0). So I'm able to rule out other causes of the problem, like the cable or other configuration factors.

Thanks very much!

stephenw10

Hmm, does it actually have 6 com ports (including cuau0 and cuau1)? IIRC the fitlet could have expansion modules including com ports?

How do the com ports appear in the boot log?

How are they referenced in the BIOS?

If the available console port is actually MMIO only you will need to set a loader value. You can try that at the boot loader prompt like:

set hw.uart.console="mm:0x7ffff10000"
boot

That assumes you can see the boot loader on the console?

Some experimentation needed!

Steve

dyener

@stephenw10 Thanks so much Steve! There is only the one physical port, but the manufacturer documentation references a second theoretical port on the board that is not externally accessible, and there are only four ports in the /dev directory, neither six nor two nor one, just the ones I listed (cuau2, 3, 4 and 5). There is definitely no cuau0 or 1. The expansion module in this unit is a dual-gigabit NIC module, no extra serial ports.

The device also has two HDMI ports (!) where I usually access the BIOS, so I will look at that tomorrow when I go to the office. I just need to get the serial console working because it will be deployed at a remote site with no video or USB access.

Meanwhile, is there something specific I can search for in the boot log that would be helpful?

I really appreciate your help!

Devren

stephenw10

I'd look for any uart references. But also for any unknown devices.

But how the port is shown in the BIOS is probably more telling.

dyener

@stephenw10 OK Steve, I found a lot of relevant information, but I might be in over my head! My new suspicion is I might need to recompile my FreeBSD kernel to get it to work. Let me see if I can summarize things accurately!

First of all, I found in the BIOS menu an option to enable Serial Console Redirection. Enabling this has the major effect of making the BIOS menu visible on my terminal screen as well as the HDMI monitor. There are a lot of different serial settings in this menu, but I could find no mention at all of a port number or device name, to select from or to correlate with the info I saw in pfSense.

After some monkeying with the settings, although the BIOS console works, the pfSense console still does not work. However, I do get some output that I know is from pfSense instead of the BIOS! First of all, sometimes there is a line that prints the boot options -S115200 -D which I learned is from FreeBSD. Second, sometimes it tries to print the pfSense splash screen, but it is garbled and prints very slowly. Here is an example:

ERROR: Class:0; Subclass:10000; Operation: 1
 *********** Weti user [Enter]__|/ _ \                                          
   | |_) |  _\__ \  __/ | | \__ \  __/                                          
   | |_) |  _\__ \  __/ | | \__ \  __/                                          
   | .__/|_| |___/\___|_| |_|___/\___|                                          
   |_|                                                                          
                                                                               
                                                                               
 *********** Welcome to pfSense ************      __________________________    
 *                                         *     /                       ___\  
 *  1. Boot Multi user [Enter]             *    |                      /`      
 *  2. Boot Single user                    *    |                     /    :-|  
 *  3. Escape to loader prompt             *    |      _________  ___/    /_ |  
 *  4. Reboot                              *\   |    /` ____  /    /   /     |

After this, it becomes completely unresponsive, and prints nothing else until the system is rebooted.

I consider this evidence that PF/FreeBSD is trying to use the right port, and the port number is probably not the reason for the problem.

Then I found this FreeBSD bug report which seems to address exactly what I'm looking for, and unfortunately leads me to believe there may be a bug in the FreeBSD kernel that will prevent this from working.

Comparing the Bugzilla thread with the Github commit, it seems the first poster in the thread was writing in Feb 2021 before this CPU had any support in the FreeBSD serial driver. Then the second poster had made a commit to FreeBSD in May 2021, to support this CPU, but apparently hadn't read the bug report in detail until he responded there in July.

The commit utilizes this number 24 * DEFAULT_RCLK, but the first poster Tommy had already in February suggested that this number is wrong, and produces the wrong baud rate. He recommends removing the 24 * so as to pass the value DEFAULT_RCLK instead. The second poster Jose says he will try this change; but no further changes have been made since then in the FreeBSD source code.

It makes total sense to me that the behavior I'm seeing is due to an incorrect baud rate. However, since I don't know how to recompile my own kernel for pfSense, I don't know how I might test Tommy's version of the code. :)

I did try Jose's suggestion, similar to your own, to add a line hw.uart.console="mm:0xfea10000,rs:2" to the /boot/loader.conf file. As far as I can tell, it makes no difference for good or ill, compared to not setting this value.

Here is the actual data from my boot log:

# dmesg | grep uart
uart2: <Intel Apollo Lake SIO/LPSS UART 0> mem 0x7ffff0c000-0x7ffff0cfff,0x7ffff0b000-0x7ffff0bfff irq 4 at device 24.0 on pci0
uart3: <Intel Apollo Lake SIO/LPSS UART 1> mem 0x7ffff0a000-0x7ffff0afff,0x7ffff09000-0x7ffff09fff irq 5 at device 24.1 on pci0
uart4: <Intel Apollo Lake SIO/LPSS UART 2> mem 0xfea10000-0xfea10fff irq 6 at device 24.2 on pci0
uart5: <Intel Apollo Lake SIO/LPSS UART 3> mem 0x7ffff08000-0x7ffff08fff,0x7ffff07000-0x7ffff07fff irq 7 at device 24.3 on pci0

And here is my pciconf output as suggested in the bugzilla thread:

uart2@pci0:0:24:0:      class=0x118000 rev=0x0b hdr=0x00 vendor=0x8086 device=0x5abc subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller'
    class      = dasp
uart3@pci0:0:24:1:      class=0x118000 rev=0x0b hdr=0x00 vendor=0x8086 device=0x5abe subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller'
    class      = dasp
uart4@pci0:0:24:2:      class=0x118000 rev=0x0b hdr=0x00 vendor=0x8086 device=0x5ac0 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller'
    class      = dasp
uart5@pci0:0:24:3:      class=0x118000 rev=0x0b hdr=0x00 vendor=0x8086 device=0x5aee subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Celeron N3350/Pentium N4200/Atom E3900 Series HSUART Controller'
    class      = dasp

Do I have the right bootloader option, or is it worthwhile trying some different numbers? Based on the numbers, it looks like they're suggesting that the real serial port is uart4.

I also tried multiplying and dividing the baud rate in my terminal emulator by 24, but it doesn't help.

I can always post something to bugzilla or github, but it's all theoretical unless I have some way to test the modified code. Let me know what you'd recommend. :) Thanks for your patience!

stephenw10

OK that bug has the info we need. But the bug itself is already fixed as evidenced by the fact your system recognises the HSUART devices.

You need to add that loader line to /boot/loader.conf.local otherwise it will be overwritten by the system. Create that file.
You might also need to add to that file the line: console=efi

Otherwise the standard console type applies and defaults the hw.uart.console value.