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
uart(4) backends currently detect RX FIFO overrun errors and report
them to the uart(4) core layer. They are then reported to the generic
TTY layer which promptly ignores them. As a result, there is
currently no good way to determine if a uart is experiencing RX FIFO
overruns. One could add a generic per-tty counter, but there did not
appear to be a good way to export those. Instead, add a sysctl under
the uart(4) sysctl tree to export the count of overruns.
Reviewed by: brooks
MFC after: 2 weeks
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24368
Shifting right by 1 is not the same as dividing by 2 for signed
values. In particular, dividing a signed value by 2 gives the integer
ceiling of the (e.g. -5 / 2 == -2) whereas shifting right by 1 always
gives the floor (-5 >> 1 == -3).
An embedded board with a 25 Mhz base clock results in an error of
-30.5% when used with a baud rate of 115200. Using division, this
truncates to -30% and is permitted. Using the shift, this fails and
is rejected causing TIOCSETA requests to fail with EINVAL and breaking
getty(8).
Using division gives the same error range for both over and under baud
rates and also makes the code match the behavior documented in the
existing comment about supporting boards with 25 Mhz clocks.
Reported by: imp
MFC after: 2 weeks
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24367
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.
Mark all obvious cases as MPSAFE. All entries that haven't been marked
as MPSAFE before are by default marked as NEEDGIANT
Approved by: kib (mentor, blanket)
Commented by: kib, gallatin, melifaro
Differential Revision: https://reviews.freebsd.org/D23718
Most keyboard drivers are using the genkbd implementations as it is;
formally use them for any that aren't set and make
genkbd_get_fkeystr/genkbd_diag private.
A future change will provide default implementations for some of these where
it makes sense and most of them are already using the genkbd
implementation (e.g. get_fkeystr, diag).
o Remove All Rights Reserved from my notices
o imp@FreeBSD.org everywhere
o regularize punctiation, eliminate date ranges
o Make sure that it's clear that I don't claim All Rights reserved by listing
All Rights Reserved on same line as other copyright holders (but not
me). Other such holders are also listed last where it's clear.
Since TX interrupt is generated when THRE is set, wait for TEMT set means
wait for full character transmission time. At low speeds that may take
awhile, burning CPU time while holding sc_hwmtx lock, also congested.
This is partial revert of r317659.
PR: 240121
MFC after: 2 weeks
This fixes (userspace) console on the Marvell MACCHIATObin in ACPI mode with
latest TianoCore EDK2 firmware.
Submitted by: Greg V <greg@unrelenting.technology>
Reviewed by: mw, bcran
Differential Revision: https://reviews.freebsd.org/D20765
asserted. Some development boards for example will reset on DTR,
and some radio interfaces will transmit on RTS.
This patch allows "stty -f /dev/ttyu9.init -rtsdtr" to prevent
RTS and DTR from being asserted on open(), allowing these devices
to be used without problems.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D20031
This takes the SPCR code currently in uart_cpu_arm64.c, moves it into
a new uart_cpu_acpi.c (with some associated refactoring), and uses it
from both arm64 and x86.
An SPCR serial port address AccessWidth field value of 0 ("reserved")
is now treated as 1 ("byte access") in order to work around a buggy
SPCR table on Amazon EC2 i3.metal instances.
Reviewed by: manu, Greg V
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D20357
From 7d8dc6544c
"The mcbin (and likely others) have a nonstandard uart clock. This means
that the earlycon programming will incorrectly set the baud rate if it is
specified. The way around this is to tell the kernel to continue using the
preprogrammed baud rate. This is done by setting the baud to 0."
Our drivers (uart_dev_ns8250) do respect zero, but SPCR would error. Let's
not error.
Submitted by: Greg V <greg@unrelenting.technology>
Reviewed by: mw, imp, bcran
Differential Revision: https://reviews.freebsd.org/D19914
The SPCR table on the Lenovo HR330A Ampere eMAG server indicates 8-bit
access, but 32-bit access is required for the PL011 to work.
PL011 on SBSA platforms always supports 32-bit access (and that was
hardcoded here before my EC2 fix), let's use 32-bit access for PL011
and 32BIT interface types.
Tested by emaste on Ampere eMAG and Cavium/Marvell ThunderX2.
Submitted by: Greg V <greg@unrelenting.technology>
Reviewed by: andrew, imp (earlier)
Differential Revision: https://reviews.freebsd.org/D19507
This value was being used uninitialized, resulting in predictable issues
on systems with memory-mapped UART registers.
A case could be made that memmap_bus should be declared in a header
rather than being declared in each .c file which needs to refer to it,
but that's a broader style question.
This commit unbreaks hw.uart.console="mm:..." on ARM64.
Submitted by: Greg V
The "access width" value was hard-coded as 2, indicating 32-bit accesses;
instead, use the value specified in the SPCR table.
This unbreaks the console on EC2 "A1" family instances.
Submitted by: Greg V
as an NS8250 UART.
This is the same as the UART found in EC2 "bare metal" instances,
except that the card vendor shows up as 0x0000 rather than 0x1d0f.
This seems like a bug in the EC2 firmware; but we might as well support
it anyway.
Reported by: Greg V
The only source of documentation for this device is verilog,
so driver is minimalistic.
Reviewed by: Dr Jonathan Kimmitt <jrrk2@cam.ac.uk>
Approved by: re (kib)
Sponsored by: DARPA, AFRL
Recent changes in Linux updated Marvell Armada 38x
UART compatible string. As a result the FreeBSD driver
(uart_dev_snps) does not probe. This commit fixes the
situation, however not applying any functional modification
to the driver methods.
Approved by: re (kib)
Obtained from: Semihalf
Remove unused and easy to misuse PNP macro parameter
Inspired by r338025, just remove the element size parameter to the
MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to
have correct pointer (or array) type. Since all invocations of the macro
already had this property and the emitted PNP data continues to include the
element size, there is no functional change.
Mostly done with the coccinelle 'spatch' tool:
$ cat modpnpsize0.cocci
@normaltables@
identifier b,c;
expression a,d,e;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,d,
-sizeof(d[0]),
e);
@singletons@
identifier b,c,d;
expression a;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,&d,
-sizeof(d),
1);
$ rg -l MODULE_PNP_INFO -- sys | \
xargs spatch --in-place --sp-file modpnpsize0.cocci
(Note that coccinelle invokes diff(1) via a PATH search and expects diff to
tolerate the -B flag, which BSD diff does not. So I had to link gdiff into
PATH as diff to use spatch.)
Tinderbox'd (-DMAKE_JUST_KERNELS).
Approved by: re (glen)
This is an amalgam of a patch by Doug Ambrisko to
generalize uart_acpi_find_device, imp moving the
ACPI table to uart_dev_ns8250.c and advice by jhb
to work around a bug in the EPYC 3151 BIOS
(the BIOS incorrectly marks the serial ports as
disabled)
Reviewed by: imp
MFC after: 8 weeks
Differential Revision: https://reviews.freebsd.org/D16432
I was not aware Warner was making or planning to make forward progress in
this area and have since been informed of that.
It's easy to apply/reapply when churn dies down.
Inspired by r338025, just remove the element size parameter to the
MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to
have correct pointer (or array) type. Since all invocations of the macro
already had this property and the emitted PNP data continues to include the
element size, there is no functional change.
Mostly done with the coccinelle 'spatch' tool:
$ cat modpnpsize0.cocci
@normaltables@
identifier b,c;
expression a,d,e;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,d,
-sizeof(d[0]),
e);
@singletons@
identifier b,c,d;
expression a;
declarer MODULE_PNP_INFO;
@@
MODULE_PNP_INFO(a,b,c,&d,
-sizeof(d),
1);
$ rg -l MODULE_PNP_INFO -- sys | \
xargs spatch --in-place --sp-file modpnpsize0.cocci
(Note that coccinelle invokes diff(1) via a PATH search and expects diff to
tolerate the -B flag, which BSD diff does not. So I had to link gdiff into
PATH as diff to use spatch.)
Tinderbox'd (-DMAKE_JUST_KERNELS).
This change allows one to set the busy_detect flag
required by the synopsys UART at the loader prompt.
This is needed by the EPYC 3000 SoC.
This will give users a working console up to the point where getty is required:
hw.uart.console="mm:0xfedc9000,rs:2,bd:1"
Reviewed by: imp
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D16399
This change adds a new optional console method cn_resume and a kernel
console interface cnresume. Consoles that may need to re-initialize
their hardware after suspend (e.g., because firmware does not care to do
it) will implement cn_resume. Note that it is called in rather early
environment not unlike early boot, so the same restrictions apply.
Platform specific code, for platforms that support hardware suspend,
should call cnresume early after resume, before any console output is
expected.
This change fixes a problem with a system of mine failing to resume when
a serial console is used. I found that the serial port was in a strange
configuration and an attempt to write to it likely resulted in an
infinite loop.
To avoid adding cn_resume method to every console driver, CONSOLE_DRIVER
macro has been extended to support optional methods.
Reviewed by: imp, mav
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D15552
Move the allwinner early printf support to the snps driver as it
should work with all implementation.
While here add instruction for enabling it on 64bits SoCs.
opt_compat.h is mentioned in nearly 180 files. In-progress network
driver compabibility improvements may add over 100 more so this is
closer to "just about everywhere" than "only some files" per the
guidance in sys/conf/options.
Keep COMPAT_LINUX32 in opt_compat.h as it is confined to a subset of
sys/compat/linux/*.c. A fake _COMPAT_LINUX option ensure opt_compat.h
is created on all architectures.
Move COMPAT_LINUXKPI to opt_dontuse.h as it is only used to control the
set of compiled files.
Reviewed by: kib, cem, jhb, jtl
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14941
It calls OF_* functions to check if it needs to implement workarounds.
This may not be the case on arm64 where we support both FDT and ACPI.
Fix this by checking if we are booting on FDT before calling these checks.
Reviewed by: ian
Sponsored by: DARPA, AFRL
Sponsored by: Cavium (Hardware)
Differential Revision: https://reviews.freebsd.org/D14515
the Server Base System Architecture to be a subset of the pl011 r1p5. As
we don't use the removed features it is safe to just attach to the existing
driver as is.
Sponsored by: DARPA, AFRL
