1.\" 2.\" SPDX-License-Identifier: BSD-2-Clause 3.\" 4.\" Copyright (c) 2003 Marcel Moolenaar 5.\" All rights reserved. 6.\" 7.\" Redistribution and use in source and binary forms, with or without 8.\" modification, are permitted provided that the following conditions 9.\" are met: 10.\" 11.\" 1. Redistributions of source code must retain the above copyright 12.\" notice, this list of conditions and the following disclaimer. 13.\" 2. Redistributions in binary form must reproduce the above copyright 14.\" notice, this list of conditions and the following disclaimer in the 15.\" documentation and/or other materials provided with the distribution. 16.\" 17.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR 18.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES 19.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 20.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, 21.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 22.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 23.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 24.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 25.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 26.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 27.\" 28.Dd December 5, 2024 29.Dt UART 4 30.Os 31.Sh NAME 32.Nm uart 33.Nd Universal Asynchronous Receiver/Transmitter serial driver 34.Sh SYNOPSIS 35.Cd "device uart" 36.Pp 37.Cd "device puc" 38.Cd "device uart" 39.Pp 40.Cd "device scc" 41.Cd "device uart" 42.Pp 43In 44.Pa /boot/device.hints : 45.Cd hint.uart.0.disabled="1" 46.Cd hint.uart.0.baud="38400" 47.Cd hint.uart.0.port="0x3f8" 48.Cd hint.uart.0.flags="0x10" 49.Sh DESCRIPTION 50The 51.Nm 52device driver provides support for various classes of UARTs implementing the 53EIA RS-232C (CCITT V.24) serial communications interface. 54Each such interface is controlled by a separate and independent instance of 55the 56.Nm 57driver. 58The primary support for devices that contain multiple serial interfaces or 59that contain other functionality besides one or more serial interfaces is 60provided by the 61.Xr puc 4 , 62or 63.Xr scc 4 64device drivers. 65However, the serial interfaces of those devices that are managed by the 66.Xr puc 4 , 67or 68.Xr scc 4 69driver are each independently controlled by the 70.Nm 71driver. 72As such, the 73.Xr puc 4 , 74or 75.Xr scc 4 76driver provides umbrella functionality for the 77.Nm 78driver and hides the complexities that are inherent when elementary components 79are packaged together. 80.Pp 81The 82.Nm 83driver has a modular design to allow it to be used on differing hardware and 84for various purposes. 85In the following sections the components are discussed in detail. 86Options are described in the section that covers the component to which each 87option applies. 88.\" 89.Ss Core Component 90At the heart of the 91.Nm 92driver is the core component. 93It contains the bus attachments and the low-level interrupt handler. 94.\" 95.Ss Hardware Drivers 96The core component and the kernel interfaces talk to the hardware through the 97hardware interface. 98This interface serves as an abstraction of the hardware and allows varying 99UARTs to be used for serial communications. 100.\" 101.Ss System Devices 102System devices are UARTs that have a special purpose by way of hardware 103design or software setup. 104For example, Sun UltraSparc machines use UARTs as their keyboard interface. 105Such an UART cannot be used for general purpose communications. 106Likewise, when the kernel is configured for a serial console, the 107corresponding UART will in turn be a system device so that the kernel can 108output boot messages early on in the boot process. 109.\" 110.Ss Kernel Interfaces 111The last but not least of the components is the kernel interface. 112This component ultimately determines how the UART is made visible to the 113kernel in particular and to users in general. 114The default kernel interface is the TTY interface. 115This allows the UART to be used for terminals, modems and serial line IP 116applications. 117System devices, with the notable exception of serial consoles, generally 118have specialized kernel interfaces. 119.\" 120.Ss Pulse Per Second (PPS) Timing Interface 121The 122.Nm 123driver can capture PPS timing information as defined in RFC 2783. 124The API, accessed via 125.Xr ioctl 2 , 126is available on the tty device. 127To use the PPS capture feature with 128.Xr ntpd 8 , 129symlink the tty callout device 130.Va /dev/cuau? 131to 132.Va /dev/pps0. 133.Pp 134The 135.Va hw.uart.pps_mode 136tunable configures the PPS capture mode for all uart devices; 137it can be set in 138.Xr loader.conf 5 . 139The 140.Va dev.uart.0.pps_mode 141sysctl configures the PPS capture mode for a specific uart device; 142it can be set in 143.Xr loader.conf 5 144or 145.Xr sysctl.conf 5 . 146.Pp 147The following capture modes are available: 148.Bl -tag -compact -offset "mmmm" -width "mmmm" 149.It 0x00 150Capture disabled. 151.It 0x01 152Capture pulses on the CTS line. 153.It 0x02 154Capture pulses on the DCD line. 155.El 156.Pp 157The following values may be ORed with the capture mode to configure 158capture processing options: 159.Bl -tag -compact -offset "mmmm" -width "mmmm" 160.It 0x10 161Invert the pulse (RS-232 logic low = ASSERT, high = CLEAR). 162.It 0x20 163Attempt to capture narrow pulses. 164.El 165.Pp 166Add the narrow pulse option when the incoming PPS pulse width is small 167enough to prevent reliable capture in normal mode. 168In narrow mode the driver uses the hardware's ability to latch a line 169state change; not all hardware has this capability. 170The hardware latch provides a reliable indication that a pulse occurred, 171but prevents distinguishing between the CLEAR and ASSERT edges of the pulse. 172For each detected pulse, the driver synthesizes both an ASSERT and a CLEAR 173event, using the same timestamp for each. 174To prevent spurious events when the hardware is intermittently able to 175see both edges of a pulse, the driver will not generate a new pair of 176events within a half second of the prior pair. 177Both normal and narrow pulse modes work with 178.Xr ntpd 8 . 179.Pp 180Add the invert option when the connection to the uart device uses TTL 181level signals, or when the PPS source emits inverted pulses. 182RFC 2783 defines an ASSERT event as a higher-voltage line level, and a CLEAR 183event as a lower-voltage line level, in the context of the RS-232 protocol. 184The modem control signals on a TTL-level connection are typically 185inverted from the RS-232 levels. 186For example, carrier presence is indicated by a high signal on an RS-232 187DCD line, and by a low signal on a TTL DCD line. 188This is due to the use of inverting line driver buffers to convert between 189TTL and RS-232 line levels in most hardware designs. 190Generally speaking, a connection to a DB-9 style connector is an RS-232 191level signal at up to 12 volts. 192A connection to header pins or an edge-connector on an embedded board 193is typically a TTL signal at 3.3 or 5 volts. 194.Ss Special Devices 195The 196.Nm 197driver also supports an initial-state and a lock-state control 198device for each of the callin and the callout "data" devices. 199The termios settings of a data device are copied 200from those of the corresponding initial-state device 201on first opens and are not inherited from previous opens. 202Use 203.Xr stty 1 204in the normal way on the initial-state devices to program 205initial termios states suitable for your setup. 206.Pp 207The lock termios state acts as flags to disable changing 208the termios state. 209E.g., to lock a flag variable such as CRTSCTS, use 210.Em stty crtscts 211on the lock-state device. 212Speeds and special characters 213may be locked by setting the corresponding value in the lock-state 214device to any nonzero value. 215E.g., to lock a speed to 115200, use 216.Dq Li stty 115200 217on the initial-state device and 218.Dq Li stty 1 219on the lock-state device. 220.Pp 221Correct programs talking to correctly wired external devices 222work with almost arbitrary initial states and almost no locking, 223but other setups may benefit from changing some of the default 224initial state and locking the state. 225In particular, the initial states for non (POSIX) standard flags 226should be set to suit the devices attached and may need to be 227locked to prevent buggy programs from changing them. 228E.g., CRTSCTS should be locked on for devices that support 229RTS/CTS handshaking at all times and off for devices that do not 230support it at all. 231CLOCAL should be locked on for devices that do not support carrier. 232HUPCL may be locked off if you do not 233want to hang up for some reason. 234In general, very bad things happen 235if something is locked to the wrong state, and things should not 236be locked for devices that support more than one setting. 237The CLOCAL flag on callin ports should be locked off for logins 238to avoid certain security holes, but this needs to be done by 239getty if the callin port is used for anything else. 240.Ss Console Tuneable 241The 242.Nm 243driver can be designated as a system console. 244.Bl -tag -width indent 245.It Va hw.uart.console 246Contains a number of 247.Pa /etc/remote 248like tag:value pairs, separated by commas. 249.Bl -tag -width indent 250.It Cm \&bd 251Busy Detect. 252Enable the so-called 253.Dq Busy Detect 254quirk for the device. 255For NS 16550-compatible devices, this will use heuristics to ensure that the 256UART is no longer busy before manipulating line control. 257DesignWare-based UARTs need this due to a design flaw in the UART. 258.It Cm \&br 259Baudrate. 260The data rate (bits per second) used for communications on the serial port. 261When the device clock rate (see below) is set to 0, then the baud rate will be 262used with the divisor to compute the device clock rate the first time the device 263is initialized. 264Only the traditional baud rates are allowed. 265Rates larger than 19200 must be a multiple of 19200. 266Baud rates between 1200 and 19200 must be a multiple of 1200. 267Otherwise the baud rate must be a multiple of 75. 268A value of '0' instructs the 269.Nm 270driver to not program the baud rate divisor and use the hardware as-is. 271.It Cm \&ch 272Channel. 273Defaults to 0. 274Has no effect on UARTs with only one channel. 275.It Cm \&db 276Data bits. 277Defaults to 8. 278.It Cm \&dt 279Device type. 280Specify the uart class to use for this device. 281.Bl -tag -width indent 282.It ns8250 283Traditional PC UART National Semiconductor 16550 and compatible devices. 284.It pl011 285Common ARM UART, based on ARM Limited designs. 286.El 287.It Cm \&io 288I/O port address. 289Specifies the address of a UART in an Intel processor's I/O space. 290Mutually exclusive with 291.Sq mm . 292.It Cm \&mm 293Memory mapped I/O address. 294Specifies the physical address of a memory-mapped UART. 295Mutually exclusive with 296.Sq io . 297.It Cm \&pa 298Parity. 299The type of parity to use when sending data 300to the host. 301This may be one of ``even'', 302``odd'', ``none'', ``zero'' (always set bit 8 to zero), 303``one'' (always set bit 8 to 1). 304The default is even parity. 305.It Cm \&rs 306Register shift. 307Number of bits to shift left the base register offset. 308.It Cm \&rw 309Register width. 310Size of operations to read and write the registers of the device. 311.It Cm \&sb 312Stopbits. 313Defaults to 1. 314.It Cm \&xo 315Device clock (xtal oscillator). 316Base frequency of the oscillator to use for the device. 317When set to 0, and the baud rate is also set, the UART's initialization 318code will compute this the first time and use that after. 319Automatically computed values can be as large as 5% when the base 320frequency is a poor match to the traditional baud rates. 321.El 322.El 323.Sh HARDWARE 324The 325.Nm 326driver supports the following classes of UARTs: 327.Pp 328.Bl -bullet -compact 329.It 330NS8250: standard hardware based on the 8250, 16450, 16550, 16650, 16750 or 331the 16950 UARTs. 332.It 333SCC: serial communications controllers supported by the 334.Xr scc 4 335device driver. 336.El 337.\" 338.Sh DEVICE HINTS 339The 340.Ar flags 341are encoded as: 342.Bl -tag -compact -width 0x000000 343.It 0x00010 344device is potential system console 345.It 0x00080 346use this port for remote kernel debugging 347.It 0x00100 348set RX FIFO trigger level to ``low'' (NS8250 only) 349.It 0x00200 350set RX FIFO trigger level to ``medium low'' (NS8250 only) 351.It 0x00400 352set RX FIFO trigger level to ``medium high'' (default, NS8250 only) 353.It 0x00800 354set RX FIFO trigger level to ``high'' (NS8250 only) 355.El 356.\" 357.Sh FILES 358.Bl -tag -width "/dev/ttyu?.init" -compact 359.It Pa /dev/ttyu? 360for callin ports 361.It Pa /dev/ttyu?.init 362.It Pa /dev/ttyu?.lock 363corresponding callin initial-state and lock-state devices 364.Pp 365.It Pa /dev/cuau? 366for callout ports 367.It Pa /dev/cuau?.init 368.It Pa /dev/cuau?.lock 369corresponding callout initial-state and lock-state devices 370.El 371.Sh EXAMPLES 372.Dl hw.uart.console="io:0x2f8,br=115200" 373.Pp 374When the kernel is using a serial console port, it should use 375COM2 instead of COM1 and set the baud rate to 115200. 376.Sh SEE ALSO 377.Xr cu 1 , 378.Xr puc 4 , 379.Xr scc 4 , 380.Xr termios 4 , 381.Xr tty 4 , 382.Xr ttys 5 383.\" 384.Sh HISTORY 385The 386.Nm 387device driver first appeared in 388.Fx 5.2 . 389.Sh AUTHORS 390The 391.Nm 392device driver and this manual page were written by 393.An Marcel Moolenaar Aq Mt marcel@xcllnt.net . 394.Sh BUGS 395Before the Internet, serial ports were primarily used for inbound 396connections from terminals, either directly or through modems, these 397days serial ports are primarily used for outbound connections to 398devices, an evolution which unfortunately has spread the relevant 399documentation over three different manual pages: 400.Xr termios 4 , 401.Xr uart 4 and 402.Xr tty 4 . 403