This flag was introduced to ignore bad firmware values. These were
present in older versions of EDK-II that many devices (both Ampere and
Amazon) used. QEMU also used this value, but fixed it. But since it's
tied to the firmware bug not the device name ID it doesn't make sense to
have it flagged there.
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47947
Some veresions of EDK-II and QEMU reported the wrong values for the
register shift and the region I/O size. Detect those and set it to the
correct values. In general, anything other than a shift of 2 and a
regio width of 4 (bytes, or 32 bits) is a mistake. However, allow
for overrides in the future by only overriding the buggy values.
Otherwise, we will fail to boot.
PR: 282936
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47946
A long cable attached to the UART can act as an antenna if disconnected
from the other end. This can cause noise on the receive side, possibly
as reflections from the transmit side, leading to an interrupt storm.
Filter this by adding a threshold of received characters without TX
ready, above which characters are dropped. This is disabled by default,
but has been tested with a threshold of 1000+. A high threshold is
recommended to avoid dropping characters during, for instance, a large
copy/paste from the other end.
Sponsored by: Juniper Networks, Inc.
If we have a new enough SPCR, then use it when it provides a
PreciseBaudrate and/or a UartClkFreq.
Sponsored by: Netflix
Reviewed by: andrew,adrian
Differential Revision: https://reviews.freebsd.org/D47097
Two reasons for this: we know it's a uart after we call probe and it
returns successfully. Second, uart passes data between probe and attach
with softc. As it is now, we call probe twice, once in the bidding
process and once after bidding id done. However, the probe process for
uart isn't completely idempotent (we change state of the uart
sometimes). The second call can result in odd behavior (though so far
only in buggy version of other code I've not committed). The bigger
problem is the softc: newbus creates it, we populate it, then frees it
when we don't return 0 to claim the device. It then calls us again, we
repopulate it, and this time it doesn't free it before calling attach.
Returning 0 avoids both of these issues. The justification for doing it
in the commit that changed it was 'while I'm here', so there doesn't
seem to be a use case for it.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47095
When instructed to do so, compute the rclk (baud rate generator clock)
based on the currently programmed divisor and the communicated baud
rate. We only do this once and only for consoles that tell us the
configured rate and flag we can likely safely compute rclk.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47077
This allows one to specify dt:XXXX when the default class isn't compiled
into the kernel. It's not an error to not have a class until we're done
parsing the spec, so defer checking until then.
Sponsored by: Netflix
Reviewed by: adrian, andrew, markj
Differential Revision: https://reviews.freebsd.org/D47078
When instructed to do so, compute the rclk (baud rate generator clock)
based on the currently programmed divisor and the communicated baud
rate. We only do this once and only for consoles that tell us the
configured rate and flag we can likely safely compute rclk.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47076
Disable interrupts before we set the parameters for the UART. Usually,
it makes no difference, but it's possible that setting the baud rate, etc
could create problems if there's data pending, so move the interrupt
disabling ealier.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47075
We have two copies (soon to be three) of reading the divisor. Since it's
a complicated tricky process, abstract it to its own routine.
Sponsored by: Netflix
Reviewed by: andrew, markj
Differential Revision: https://reviews.freebsd.org/D47074
It can be confusing when the ns8250 driver prints error messages with
just ns8250 as the prefix. Add uart: to the live and commented out
printfs.
Sponsored by: Netflix
Reviewed by: andrew, markj
Differential Revision: https://reviews.freebsd.org/D47073
With newer, more diverse hardware designs, the rclk can be
unknown. Currently deployed systems have no standard way to discover the
baud-clock generator frequency. However, sometimes we have a fairly good
idea that the firmware programmed the UART to be the baud rate that it's
telling us it's at. Create a way to instruct the uart class drivers to
compute the baud clock frequency the first time their init routines are
called. Usually the 'divisors' are relatively small, meaning we will
likely have a fairly large error (goes as 1 / (divisor + 1). However,
we also know that the baud-generator clock needs to be divided down
to the baud-rate +/- about 5% (so while the error could be large for
an arbitrary baud-clock, standard baud rates generally will give
an error of 5% or less).
Often, the console speed and the getty-configured speed are the same, so
this heuristic allows boot messages and login sessions to work.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47072
To help debugging, export the rclk a uart is using as
dev.uart.X.rclk. It can be opaque when it is wrong since any error
messages printed to the system console using the wrong rclk aren't
informative.
Sponsored by: Netflix
Reviewed by: andrew, markj
Differential Revision: https://reviews.freebsd.org/D47070
If rclk is set in sysdev, then it was set during the boot process and is
intended to override the defaults. By prefering the sysdev one over the
class, xo=XXXX in hw.uart.console can give the user a usable console for
non-traditional UARTs, especially on !x86 platforms. The default rclk
generally only is good for I/O mapped UARTS or PCI ones that we can do a
table lookup on. Other times, it can be hard to know what a good default
is without more information.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47069
This uart has the requirement for 32-bit sized and aligned memory
accesses. It is also described in the Serial Port Console Redirection
Table (SPCR) with a different interface type value.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45834
The Debug Port Table 2 (DBG2) contains information on which devices
can be used for debugging purposes.
Add support to the uart driver to use the DBG2 table when enabled from
loader.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44359
The StarFive VisionFive 2 has a Synopsys DesignWare ABP UART, whose
driver uses UART_FDT_CLASS rather than UART_FDT_CLASS_AND_DEVICE as it
has its own separate newbus driver. This UART is driven by a 24MHz clock
as specified in the FDT, but we don't currently look at the property
here, instead passing down 0 and letting the default value be used in
the 8250 driver (~1.8MHz). As a result the divisor is misconfigured for
the current baud rate for the entire kernel boot process. Once the
newbus driver attaches the correct frequency is saved in the softc, but
that does not take effect until the next time ns8250_param is called and
the divisor is recalculated, namely when userspace runs and /dev/console
is opened (note that ns8250_init does not get called when the newbus
device corresponding to the current console attaches).
Fix this issue by attemmpting to get the current clock frequency as for
the UART_FDT_CLASS_AND_DEVICE_CASE, but falling back to 0 rather than
failing on error.
Reviewed by: imp, mhorne
Differential Revision: https://reviews.freebsd.org/D45159
This is useful for other drivers to be able to find the UART (such as
the case of UARTs where hardware flow control lines are handled by
another device.)
Sponsored by: Juniper Networks, Inc.
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44532
In preperation for adding debug port support add a generic function
to setup the uart from ACPI tables.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44358
Split out the common parts of building the uart devinfo from ACPI
tables from the SPCR parser. This will be used when we support the DBG2
table to find the debug uart to be used by the kernel gdb stub.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44357
Use the macro "UART_CLASS()" for the newly created data set
'uart_class_set' as we do for other data sets.
This further hides the data set name.
Also add UART_CLASS for quicc, which was previously not done.
MFC after: 1 week
Improves: 949670f8f4 dev/uart: Use a linker set to find uart classes
Obtained from: jhb, 269e99ac86
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D43981
While we only support 4-byte registers in the uart code the physical
access may be to an 8-byte register. Support this as an option on
non-i386. On i386 we lack the needed 8-byte bus_space functions.
ACPI has an option for 8-byte register io width, and FDT can be given
any size. Support these sizes, even if we don't expect to see hardware
with an 8-byte io width.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43374
Add the pl011 uart to the list of supported uarts for use by
hw.uart.console. This is commonly found in Arm based devices, and a
variant is standardised in the Arm SBSA.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43363
Some uarts require a specific register width. Support setting this in
the kernel environment.
Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43362
When the uart is configured via the environment we need to find the
uart class with a specified name. Currently to do this with an
incomplete list of uarts. As we may not have included all uarts in the
kernel each class is defined as weak.
Switch to a linker set so the list is always up to date based on what
is included in the kernel, and the class can be static.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43361
Support selecting the early uart with "options EARLY_PRINTF=foo" in
the kernel configuration file. This allows us to not have to change
source files when enabling EARLY_PRINTF, simplifying enabling it.
New uart drivers can be enabled by defining a new early_printf_foo
value to be unique, then using "#if CHECK_EARLY_PRINTF(foo)" to decide
when to enable the uart.
While here add pl011 early printf support.
Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43360
In 9750d9e5, I brought the equivalent of the TS_BUSY flag back in a
mostly hardware-agnostic way in order to fix tty_drain() and, thus,
TIOCDRAIN for UARTs with TX FIFOs. This proved to be sufficient for
fixing the regression reported. So in light of the release cycle of
FreeBSD 10.3, I decided that this change was be good enough for the
time being and opted to go with the smallest possible yet generic
(for all UARTs driven by uart(4)) solution addressing the problem at
hand.
However, at least for the NS8250-class the above isn't a complete
fix as these UARTs only trigger an interrupt when the TX FIFO became
empty. At this point, there still can be an outstanding character
left in the transmit shift register as indicated via the LSR. Thus,
this change adds the 3rd (besides the tty(4) and generic uart(4) bits)
part I had in my tree ever since, adding a uart_txbusy method to be
queried in addition for tsw_busy and hooking it up as appropriate
for the NS8250-class.
As it turns out, the exact equivalent of this 3rd part later on was
implemented for uftdi(4) in 9ad221a5.
While at it, explain the rational behind the deliberately missing
locking in uart_tty_busy() (also applying to the generic sc_txbusy
testing already present).
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43192
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43191
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
Since ingenic JZ4780 SOC support has been removed there is no need
to support ingenic quirks in the UART driver.
Invert of commit b192bae67e
Reviewed by: imp, manu
Approved by: imp, manu (mentor)
Differential Revision: https://reviews.freebsd.org/D42497
Support early printf for the ns8250 uart driver. Adding
options UART_NS8250_EARLY_PORT=0xYYY
options EARLY_PRINTF
to your kernel config will enable it. The code is rather simple minded,
so caveat emptor. This will enable printf before cninit. cninit
automatically disables this and switches to the real routine. It only
works for port-mapped COM ports, and only if you know the port's address
at compile time. It's intended for be a debugging aide, not a general
purpose thing.
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D42306
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
This reverts commit d1b6271118.
I've received multiple reports of machines failing to boot with
this hardware; back it out for now until we can fix it.
PR: 271147
MFC after: Morning coffee
A signed one-bit wide bit-field can take only the values 0 and -1. Clang
16 introduced a warning that "implicit truncation from 'int' to a
one-bit wide bit-field changes value from 1 to -1". Fix the warnings by
using C99 bool.
Reported by: Clang 16
Reviewed by: emaste, jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D39705
Azure setup does not like it when FreeBSD overrides the settings of the
UART device. When Hyper-V is detected, don't do this and also don't
throttle putc() output. This is a workaround for the early boot hang
of FreeBSD on Azure.
Tested on Azure, ESXi (VM with serial port), and SG-8200
PR: 264267
Reviewed by: kevans, whu
Tested by: whu
Obtained from: Rubicon Communications, LLC (Netgate)
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
Historically the ACPI _HID for both the Arm PL011 and Generic UARTs
was ARMH0011. In the Arm Base Boot Requirements 2.0 the Generic UART
_HID is changed to ARMHB000. Use this new value in the PL011 driver
where we support both UART types.
This has been observed in some recent EDK2 builds.
Sponsored by: Arm Ltd
