#3858 new defect

PC386 BSP serial console outputs garbage on real hardware

Reported by: Lou Woods Owned by:
Priority: normal Milestone:
Component: bsps Version: 5
Severity: normal Keywords: console, serial, pc386, corruption
Cc: Blocked By:
Blocking:

Description

Problem description

When the RTEMS ticker test, possibly others, is started with the -–console=/dev/com1 command line argument the output to COM1 using the pc386 BSP on real hardware the console output is invalid/garbage characters instead of the expected ticker output. The serial output looks like a baud rate mismatch.

Ticker works as expected when left to output to the VGA console.

Test configuration

Hardware tested

Winsystems EBC-855 (Intel® Celeron-M ZC Dothan 1GHz)
Dell Optiplex 755 (Intel Core 2 Duo)

Hardware configuration

*The PC386 target COM1 is connected to a Raspberry Pi 3 with a Keyspan RS232 serial to USB converter. (This hardware combination works with other boards)
*The PC386 is connected via a network to the Raspberry Pi 3 running a TFTP server that provides the boot images.

Software configuration

  • RTEMS Master e22554535796fc29a7ed7c5e2338128e324a621d
  • RTEMS configuration
    ../rtems/configure --target=i386-rtems5 --enable-rtemsbsp=pc386 IDE_USE_PRIMARY_INTERFACE=0 --prefix=/home/woods/pc386/bsp-install/ --disable-networking --enable-posix --disable-smp --disable-multiprocessing --enable-tests --enable-cxx --enable-maintainer-mode
    
  • The BSP defaults COM1 to 9600bps 8-N-1 with no flow control.
  • The Raspberry Pi serial host is running Debian (Raspian) Stretch
  • The executable is booted from the Raspberry Pi TFTP host by chain loading RTEMS via IPXE

General Notes

The test setup's serial connection was verified to work using the Optiplex 755 running Windows and the same hardware components with a simple Foxterm serial session.

Things attempted one at a time

  • sweeping the baud rate on the serial host while holding the board at 9600 8N1
  • trying different baud rates in lock-step, target and serial host.
  • various combination of hardware flow control, parity, word size, stop bits.
  • Winsystems board talking to a Windows PC running Foxterm.
  • Running RTEMS 4.11 branch with current i386 toolschain – exe hangs; currently haven’t tracked down the error.
  • COM2 port on the Winsystems board.
  • Changing the clock rate for the baud-rate divisor in RTEMS
  • 3 wire serial communications with RX, TX, and GND

Change History (3)

comment:1 Changed on Jan 30, 2020 at 12:06:34 AM by Chris Johns

The PC uses the shared driver. Was there a patch for this code on the devel list for the Pi. Could this be related?

comment:2 Changed on Jan 30, 2020 at 4:59:07 PM by Lou Woods

Unless I'm missing it, I don't believe it is directly related. The commit log for the raspberry pi console update didn't modify the shared code.

comment:3 Changed on Jan 30, 2020 at 5:25:58 PM by Joel Sherrill

Any chance this change broke it and no one noticed?

commit 143c8d0d948b31f7c4b40e3d7eb7ebe0b80b4915
Author: Sebastian Huber <sebastian.huber@…>
Date: Wed Oct 17 09:43:55 2018 +0200

serial/ns16550: Fix precision clock synthesizer


The precision clock synthesizer support broke the driver on the QorIQ
P1020. On this device the Alternate Function Register is accessed with
DLAB == 1 instead of the FIFO Control Register (FCR). Restructure the
code to account for this.

Note: See TracTickets for help on using tickets.