xref: /freebsd/share/man/man4/uart.4 (revision f9bc005b8ef3b507a5ecbc2d7fe4411ef70eff38)
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