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