| Age | Commit message (Collapse) | Author |
|---|
|
A regression in the u-boot-provided JH7110 device tree leaves the uart
incorrectly configured.
The issue arises when a baud rate is specified ('current-speed'
property), but the rclk value is not ('clock-frequency'). Previous
releases, e.g. v2025.04, provided both.
The alternative way to retrieve this value is to query the parent clock,
but our clk framework is not available during early console probing and
configuration.
In this instance, we end up defaulting to DEFAULT_RCLK in ns8250_init(),
which is the wrong value. The relevant uart class (uart_snps) should
provide a default rclk in its definition, but it does not. Add a new
variant class with the correct default rclk of 24000000.
Finally, uart_cpu_fdt_probe() needs to be updated to actually query this
default value when it does not find a 'clock-frequency' property. This
was simply missing; the ACPI uart bus behaves identically, see
uart_acpi_probe().
PR: 289978
Reported by: rdunkle@smallcatbrain.com
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53119
|
|
The Systembase SB16C1054 and SB16C1058 are PCI quad- and octal-UART
complexes, based on multiple Systembase SB16C1050 cores, which appear to
be compatible with the NS8250 family (except for the "enable interrupts"
bit in the other BAR).
The SB16C105x family are one of two families of PCIe UART complexes on
cards by StarTech.com, such as the PEX4S1050 and PEX8S1050. (Other
StarTech.com serial offerings use the ASIX AX99100 or ASIX MCS990x.)
This is derived from the NetBSD driver.
Reviewed by: imp
Tested by: Jashank Jeremy <jashank@rulingia.com.au>
Obtained from: Jashank Jeremy <jashank@rulingia.com.au>
MFC after: 1 week
Differential Revision: <https://reviews.freebsd.org/D52150
|
|
Summary:
SPCR rev 2 adds a series of new device types, with 0x12 being
"16550-compatible with parameters defined in the Generic Address
Structure". Since we look for the parameters already in the GAS there's
nothing extra for us to do beyond adding the entry so that it probes
successfully.
Reviewed by: imp, andrew
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D51771
|
|
This is now unused. It was used for the SPCR interface type, but that
has now been split out into a new struct.
Reviewed by: imp, jhibbits
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D51879
|
|
We don't care about most of acpi_uart_compat_data in the spcr code.
Split out the mapping from the SPCR interface type to uart class into
a new struct. This allows new SPCR interface types to be added that
don't have an entry in the DSDT, e.g. some PCI uarts may not.
Reviewed by: imp, jhibbits
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D51878
|
|
It's unused, we can remove it.
Reviewed by: imp, jhibbits
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D51877
|
|
Switch to using sys/stdarg.h for va_list type and va_* builtins.
Make an attempt to insert the include in a sensible place. Where
style(9) was followed this is easy, where it was ignored, aim for the
first block of sys/*.h headers and don't get too fussy or try to fix
other style bugs.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
|
|
LSR_TEMT bit is set if both transmit hold and shift registers are
empty, but the flush command flushes only the hold register.
While here, update the diagnostic message to report which registers
could not be flushed.
MFC after: 2 weeks
|
|
This is a revival of the old exynos4210 driver, with some additional
bits to configure the apple "s5l" uart (which is actually slightly
different to operate).
This hasn't been tested on anything that would hit the non-s5l path, so
banish it off to the apple/ domain until someone cares to confirm that
none of the other hardware is broken -- it may be that nobody does, but
the complexity isn't too bad: mostly the driver1 construct added to the
uart_bas that we use to avoid having a whole bunch of shims for uart
driver methods and hardcoded references to the cfg structs.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D48120
|
|
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
|
|
PR: 283226
Reported by: Cameron Williams
|
|
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 code is parsing the DBG2 ACPI table, not the SPCR table, so tweak
the comment.
Sponsored by: Netflix
|
|
Add a one-liner description of rw - Register Width added in eae36de826cc.
Fixes: eae36de826cc
Sponsored by: Netflix
|
|
Use if (err == 0) rather than if (!err) to follow stlye(9) and also the
rest of the file.
Sponsored by: Netflix
|
|
While we really should infer this baud-clock rate in some cases, use the
right baud-clock for this device.
Sponsored by: Netflix
|
|
Reviewed by: imp
Obtained from: CheriBSD
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D46490
|
|
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
|
|
No functional change intended.
MFC after: 1 week
|
|
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
|
|
PR: 278316
Signed-off-by: Henrich Hartzer <henrichhartzer@tuta.io>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1164
|
|
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: 949670f8f466 dev/uart: Use a linker set to find uart classes
Obtained from: jhb, https://github.com/freebsd/freebsd/commit/269e99ac86902127bfaee1500d8747a3c7be5912
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 b192bae67ea835b7e431225bad375b5d5fe4297f
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
|
|
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
