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
When flushing the UART, we need to drain manually if LSR_TEMT is
*not* asserted, aka. if the transmit FIFO is not empty.
Reported by: void <void@f-m.fm>
Fixes: c4b68e7e53 "ns8250: Check if flush via FCR succeeded"
Differential Revision: https://reviews.freebsd.org/D37185
The emulated UART in the Firecracker VMM (aka the implementation in the
rust-vmm/vm-superio project) includes FIFOs but does not implement the
FCR register, which is used by ns8250_flush to flush the FIFOs.
Check the LSR to see if there is still data in the FIFOs and call
ns8250_drain if necessary.
Discussed with: emaste, imp, jrtc27
Sponsored by: https://patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36979
It can be static within uart_tty.c. It is an open question whether there
remains any real benefit to having uart instances share a swi thread.
Reviewed by: imp, markj, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36938
In virtual machines with virtual UARTs which have fictitious baud
rates, it may be possible to drain the receive queue very quickly,
without needing to DELAY after each character. Attempt to read
(and discard) the receive queue as fast as possible, stopping for
a DELAY only when LSR_RXRDY is no longer asserted; assume that we
have finished draining the queue when LSR_RXRDY is asserted both
before and after a DELAY.
This speeds up the boot process in FreeBSD/Firecracker by 27 ms.
Reviewed by: imp, jrtc27
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D36184
The "uart_bus_probe" function is used as a generic part of uart probe
logic. It returns a driver priority(negative number) if successful and
an error code otherwise.
Fix the error checking condition to account for that.
Also, while here return "BUS_PROBE_VENDOR", instead of "0".
This fixes uart on clearfog pro with recent DT.
PR: 266657
Reviewed by: mw
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D36880
clang 14 doesn't properly determine that we're unconditionally returning
if we have ACPI but not FDT. Push FDT setup entirely into a new
function, much like we currently do with ACPI, and just return ENXIO if
that doesn't succeed.
Reviewed by: andrew, manu (earlier version)
Differential Revision: https://reviews.freebsd.org/D36788
It is stored in the clock-frequency property.
In case of failure, fallback to the harcoded value stored in the
compat data.
Also, while here improve style.
Tested on LS1046ARDB and x86 PC.
Reviewed by: mw
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D36326
NXP defines unique name for LS1046A UART - "NXP0018".
It is ns8250 compatible, adding a new uart compat data entry is enough
to make it work.
Tested on LS1046ARDB.
Approved by: mw(mentor)
Reviewed by: mw, kd
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D36260
On x86 systems, the debug.late_console tunable makes it possible to set
up the console before we call pmap_bootstrap. (The tunable is turned
on by default; setting late_console=0 results in consoles being probed
early.)
Unfortunately this is not compatible with using the ACPI SPCR table to
find the console, since consulting ACPI tables requires mapping memory
addresses. As such, we skip the call to uart_cpu_acpi_spcr from
uart_cpu_x86 in the !late_console case.
Reviewed by: imp
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D35794
FreeBSD detects serial ports twice: First, very early in the boot
process, in order to obtain a usable console; and second, during
the device probe/attach process. When a UART is discovered during
device probing, FreeBSD attempts to determine whether it is a
device which was already being used as a console; without this,
the console doesn't work in userland.
Unfortunately it's possible for a UART to be mapped to a different
location in memory when it is discovered on a bus than it has when
it is announced via the ACPI SPCR table; this breaks the matching
process, which relies on comparing bus addresses.
To address this, we introduce a concept of "unique" serial devices,
i.e. devices which are guaranteed to be present *only once* on any
system. If we discover one of these during device probing, we can
match it to a same-PCI-vendor-and-device-numbers console which was
announced via the ACPI SPCR table, regardless of the differing bus
addresses.
At present, the only unique serial device is the "Amazon PCI serial
device" (vendor 0x1d0f, device 0x8250) found in some EC2 instances.
This unbreaks the serial console on those systems.
Reviewed by: imp
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D34703
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33828
EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33826
Match the PCI simple comm devices (or try to). Be conservative and use
legacy interrupts rather than msi messages by default for this 'catch
all' since it matches what Linux does (it has opt-in generally for MSI,
but also matches more devices because it does a catch-all like
implemented in this commit).
Sponsored by: Netflix
Reviewed by: kbowling
Differential Revision: https://reviews.freebsd.org/D32228
Some setups claim to have one MSI, but they don't actually work. Allow
these to be flagged.
Sponsored by: Netflix
Reviewed by: kbowling
Differential Revision: https://reviews.freebsd.org/D32229
These ones were unambiguous cases where the Foundation was the only
listed copyright holder (in the associated license block).
Sponsored by: The FreeBSD Foundation
The problem is that ns8250_bus_probe() accesses a field from the
ns8250_softc, which embeds the generic UART softc, but the ns8250_softc
hasn't yet been allocated because we're still probing.
This is a regression from commit 0aefb0a63c. This fixed a problem
where one of the upper four IER bits, which are usually reserved, needs
to be set in order to get RX interrupts before the RX FIFO is full. At
the same time, we avoid clearing those reserved bits (see commit
58957d8717, though other UART drivers I looked at do not bother with
this).
So, copy what ns8250_init() does to disable interrupts, since we don't
know what the "right" mask is at this point.
Reported by: syzbot+f256beefd0df9eb796e7@syzkaller.appspotmail.com
Reviewed by: imp
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31124
DBG2 ACPI table description [1] specifies three subtypes
related to 16550 UART:
0x0 - 16550 compatible
0x1 - 16550 subset
0x12 - 16550 compatible with parameters defined in Generic Address Structure (GAS)
It turned out however, that the Windows OS treats 0x0 subtype as
legacy x86 UART with 8-bit access. ARM SoCs can use types 0x1 (16550 with
fixed mmio32 access) or 0x12 (16550 with fully respected GAS contents).
Switch Marvell SoCs ACPI UART subtype to 0x1 - thanks to that the same firmware
can run properly with UART output in FreeBSD, Windows 10, Linux and ESXI
hypervisor. Tests showed the older firmware versions that use 0x0
UART subtype in SPCR table continue to display output properly.
[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table
Obtained from: Semihalf
Sponsored by: ARM
Differential revision: https://reviews.freebsd.org/D30386
MFC after: 2 weeks
With this patch:
% dmesg | grep -i uart
uart2: <Intel Gemini Lake SIO/LPSS UART 0> mem 0xa1426000-0xa1426fff,0xa1425000-0xa1425fff irq 4 at device 24.0 on pci0
uart3: <Intel Gemini Lake SIO/LPSS UART 1> mem 0xa1424000-0xa1424fff,0xa1423000-0xa1423fff irq 5 at device 24.1 on pci0
uart4: <Intel Gemini Lake SIO/LPSS UART 2> mem 0xfea10000-0xfea10fff irq 6 at device 24.2 on pci0
uart5: <Intel Gemini Lake SIO/LPSS UART 3> mem 0xa1422000-0xa1422fff,0xa1421000-0xa1421fff irq 7 at device 24.3 on pci0
PR: 256101
Submitted by: Daniel Ponte <amigan@gmail.com>
MFC after: 1 week
Add PCI IDs for Intel Apollo Lake Series HSUARTs:
# pciconf -ll
drv selector class rev hdr vendor device subven subdev
uart0@pci0:0:24:0: 118000 0b 00 8086 5abc 8086 7270
uart1@pci0:0:24:1: 118000 0b 00 8086 5abe 8086 7270
uart2@pci0:0:24:2: 118000 0b 00 8086 5ac0 8086 7270
uart3@pci0:0:24:3: 118000 0b 00 8086 5aee 8086 7270
NB (Intel Document Number 336256-004US):
1. The E3900 and A3900 Series Processors support four LPSS_UART ports,
while the N- and J- Series Processors support only LPSS_UART [2:1]
ports.
2. The LPSS_UART1 port is dedicated for discrete Global Navigation
Satellite System (GNSS). This port can be used for generic UART
functionality if GNSS is not used.
3. The LPSS_UART2 port is dedicated for host OS debug.
4. The LPSS_UART0 and LPSS_UART3 ports are for generic UART functionality.
5. Only UART [1:0] ports support DMA.
PR: 255556
Submitted by: Jose Luis Duran <jlduran@gmail.com>
MFC after: 1 week
It has been observed that some systems are often unable to resume from
ddb after entering with debug.kdb.enter=1. Checking the status further
shows the terminal is blocked waiting in tty_drain(), but it never makes
progress in clearing the output queue, because sc->sc_txbusy is high.
I noticed that when entering polling mode for the debugger, IER_TXRDY is
set in the failure case. Since this bit is never tracked by the softc,
it will not be restored by ns8250_bus_ungrab(). This creates a race in
which a TX interrupt can be lost, creating the hang described above.
Ensuring that this bit is restored is enough to prevent this, and resume
from ddb as expected.
The solution is to track this bit in the sc->ier field, for the same
lifetime that TX interrupts are enabled.
PR: 223917, 240122
Reviewed by: imp, manu
Tested by: bz
MFC after: 5 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29130
This updates r311987/fb1d9b7f4113d which allowed any number of vectors to be
used. Since we're just attaching one instance, the meaning of more than one
vector is not clear and seems to cause problems. Fall back to old methods for
these cards.
PR: 235016
Submitted by: David Cross
Print warning when we can't parse a console specification (this may
not appear on the console, but will appear in dmesg).
Also, accept key:value and key=value. There's no reason not to
and it makes this more forgiving of mistakes.
Reviewed by: rpokala@
Differential Revision: https://reviews.freebsd.org/D28168
Allow fdt devices to be used as debug ports for gdb(4).
A debug console can be specified with the "freebsd,debug-path" property
in the device tree's /chosen node, or using the environment variable
hw.fdt.dbgport.
The device should be specified by its name in the device tree, for
example hw.fdt.dbgport="serial2".
PR: 251053
Submitted by: Dmitry Salychev <dsl@mcusim.org>
Submitted by: stevek (original patch, D5986)
Reviewed by: andrew, mhorne
Differential Revision: https://reviews.freebsd.org/D27422
Re-implement clocks for these SoC by using now standard extres/clk framework.
This is necessary for future expansion of these. The new implementation
is (due to the size of the patch) only the initial (minimum) version.
It will be updated/expanded with a subsequent set of particular patches.
This patch is also not tested on OMAP4 based boards (BeagleBone),
so all possible issues should be (and will be) fixed by ASAP once
identified.
Submited by: Oskar Holmlund (oskar.holmlund@ohdata.se)
Differential Revision: https://reviews.freebsd.org/D25118
- Add CCM driver and clocks implementations for i.MX 8M
- Add GPC driver for iMX8
- Add clock tree for i.MX 8M Quad
- Add clocks support and new compat strings (where required) for existing i.MX 6 UART, I2C, and GPIO drivers
- Enable aarch64-compatible drivers form i.MX 6 in arm64 GENERIC kernel config
- Add dtb/imx8 kernel module with DTBs for Nitrogen8M and iMX8MQ EVK
With this patch both Nitrogen8M and iMX8MQ EVK boot with NFS root up to multiuser login prompt
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D25274
The ACPI Specification defines a Generic Address Structure (GAS),
which is used to describe UART controller register layout in the
SPCR table. The driver responsible for parsing it (uart_cpu_acpi)
wrongly associates the Access Size field to the uart_bas's regshft
and the register BitWidth to the regiowidth - according to
the definitions it should be opposite.
This problem remained hidden most likely because the majority of platforms
use 32-bit registers (BitWidth) which are accessed with the according
size (Dword). However on Marvell Armada 8k / Cn913x platforms,
the 32-bit registers should be accessed with Byte granulity, which
unveiled the issue.
This patch fixes above by proper values assignment and slightly improved
parsing.
Note that handling of the AccessWidth set to EFI_ACPI_6_0_UNDEFINED is
needed to work around a buggy SPCR table on EC2 x86 "bare metal" instances.
Reviewed by: manu, imp, cperciva, greg_unrelenting.technology
Obtained from: Semihalf
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25373
