The FDT variant is called "gicv2m" too, and as both would try to register
on gic, only one of them would succeed, while we want them both in a
GENERIC kernel.
Reviewed by: andrew
significant source of cache line contention from vm_page_alloc(). Use
accessors and vm_page_unwire_noq() so that the mechanism can be easily
changed in the future.
Reviewed by: markj
Discussed with: kib, glebius
Tested by: pho (earlier version)
Sponsored by: Netflix, Dell/EMC Isilon
Differential Revision: https://reviews.freebsd.org/D14273
Remove most of the Atmel at91 boards. Most of them are no longer
relevant or used by people. Kept ATMEL since it should work on all the
boards that still work (I've not confirmed this, since I don't have
all these boards). Also kept SAM9G20EK, since I have several boards
that it is used on. If I've deleted a kernel in error, please let me
know.
On the OrangePi One at least, emac reset when an ethernet cable is not
plugged in seems to break ethernet. Soft reset will fail, even with
increasing the delay and retries to wait for up to 20 seconds. This can be
reproduced across at least two different OrangePi One's by simply leaving
ethernet cable unplugged when awg attaches. Whether it's plugged in or not
through u-boot process makes no difference.
Skipping the reset in this configuration doesn't seem to cause any problems,
tried across many many reboots with and without ethernet cable plugged in.
Tested on: OrangePi One
Tested on: Other boards (manu)
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D13974
global to per-domain state. Protect reservations with the free lock
from the domain that they belong to. Refactor to make vm domains more
of a first class object.
Reviewed by: markj, kib, gallatin
Tested by: pho
Sponsored by: Netflix, Dell/EMC Isilon
Differential Revision: https://reviews.freebsd.org/D14000
Similarly as we already do for arm64, for mitigation is necessary to
flush branch predictor when we:
- do task switch
- receive prefetch abort on non-userspace address
The user can disable this mitigation by setting 'machdep.disable_bp_hardening'
sysctl variable, or it can check actual system status by reading
'machdep.spectre_v2_safe'
The situation is complicated by fact that:
- for Cortex-A8, the BPIALL instruction is effectively NOP until the IBE bit
in ACTLR is set.
- for Cortex-A15, the BPIALL is always NOP. The branch predictor can be
only flushed by doing ICIALLU with special bit (Enable invalidates of BTB)
set in ACTLR.
Since access to the ACTLR register is locked to secure monitor/firmware on
most boards, they will also need update of firmware / U-boot.
In worst case, when secure monitor is on-chip ROM (e.g. PandaBoard),
the board is unfixable.
MFC after: 2 weeks
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D13931
the "power down" watchdog used by the ROM boot code is still active when the
regular watchdog is activated, turn off the power-down watchdog.
This adds support for the "fsl,ext-reset-output" FDT property. When
present, that property indicates that a chip reset is accomplished by
asserting the WDOG1_B external signal, which is supposed to trigger some
external component such as a PMIC to ready the hardware for reset (for
example, adjusting voltages from idle to full-power levels), and assert the
POR signal to SoC when ready. To guard against misconfiguation leading to a
non-rebootable system, the external reset signal is backstopped by code
that asserts a normal internal chip reset if nothing responds to the
external reset signal within one second.
bottom of the file, where it is in most imx5/6 drivers. Switch from an RD2
macro using bus_space_read_2() to an inline function using bus_read_2();
likewise for WR2. Use RESOURCE_SPEC_END to end the resource_spec list.
Net effect should be no functional changes.
instead of frobbing the registers directly.
As a hack the bcm2835_pwm kmod presently ignores the 'status="disabled"'
in the RPI3 DTB, assuming that if you load the kld you probably
want the PWM to work.
Uses of mallocarray(9).
The use of mallocarray(9) has rocketed the required swap to build FreeBSD.
This is likely caused by the allocation size attributes which put extra pressure
on the compiler.
Given that most of these checks are superfluous we have to choose better
where to use mallocarray(9). We still have more uses of mallocarray(9) but
hopefully this is enough to bring swap usage to a reasonable level.
Reported by: wosch
PR: 225197
Similarly as other extres pseudo-drivers, implement phy by using kobj model.
This detaches it from provider device, so single device driver can export
multiple different phys. Additionally, this allows phy to be subclassed to
more specialized drivers, like is USB OTG phy, or PCIe phy with hot-plug
capability.
Tested by: manu (previous version, on Allwinner board)
MFC after: 1 month
functionality on Raspberry Pi 0.
Reviewed by: hselasky@
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13924
(i386 and arm) that never implement them. This allows the removal of
#ifdef PHYS_TO_DMAP on code otherwise protected by a runtime check on
PMAP_HAS_DMAP. It also fixes the build on ARM and i386 after I forgot an
#ifdef in r328168.
Reported by: Milan Obuch
Pointy hat to: me
kernel by PHYS_TO_DMAP() as previously present on amd64, arm64, riscv, and
powerpc64. This introduces a new MI macro (PMAP_HAS_DMAP) that can be
evaluated at runtime to determine if the architecture has a direct map;
if it does not (or does) unconditionally and PMAP_HAS_DMAP is either 0 or
1, the compiler can remove the conditional logic.
As part of this, implement PHYS_TO_DMAP() on sparc64 and mips64, which had
similar things but spelled differently. 32-bit MIPS has a partial direct-map
that maps poorly to this concept and is unchanged.
Reviewed by: kib
Suggestions from: marius, alc, kib
Runtime tested on: amd64, powerpc64, powerpc, mips64
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
- Add a per compatible configuration struct
- Not all SoC uses the same size for DMA transfert, add this into the
configuration data
- Use new timing mode for some SoC (A64 mmc)
- Auto calibrate clock for A64 mmc/emmc
- A64 mmc controller need masking of data0
- Add support for vmmc/vqmmc regulator
- Add more capabilities, r/w speed is better for eMMC
- MMC_CAP_SIGNALING_180 gives weird result so do not enable it for now.
- Add new register documented in H3/A64 user manual
Tested-On: Pine64-LTS (A64), eMMC still doesn't work
Tested-On: A64-Olinuxino (A64), sd and eMMC are working
Tested-On: NanoPi Neo Plus2 (H5), sd and eMMC are working
Tested-On: OrangePi PC2 (H5), sd only (no eMMC)
Tested-On: OrangePi One (H3), sd only (no eMMC)
Tested-On: BananaPi M2 (A31s), sd only (no eMMC)
Attaching syscon_generic earlier than BUS_PASS_DEFAULT makes it more
difficult for specific syscon drivers to attach to the syscon node and to
get ordering right. Further discussion yielded the following set of
decisions:
- Move syscon_generic to BUS_PASS_DEFAULT
- If a platform needs a syscon with different attach order or probe
behavior, it should subclass syscon_generic and match on the SoC specific
compat string
- When we come across a need for a syscon that attaches earlier but only
specifies compatible = "syscon", we should create a syscon_exclusive driver
that provides generic access but probes earlier and only matches if "syscon"
is the only compatible. Such fdt nodes do exist in the wild right now, but
we don't really use them at the moment.
Additionally:
- Any syscon provider that has needs any more complex than a spinlock solely
for syscon access and a single memory resource should subclass syscon
directly rather than attempting to subclass syscon_generic or add complexity
to it. syscon_generic's attach/detach methods may be made public should the
need arise to subclass it with additional attach/detach behavior.
We introduce aw_syscon(4) that just subclasses syscon_generic but probes
earlier to meet our requirements for if_awg and implements #2 above for this
specific situation. It currently only matches a64/a83t/h3 since these are
the only platforms that really need it at the time being.
Discussed with: ian
Reviewed by: manu, andrew, bcr (manpages, content unchanged since review)
Differential Revision: https://reviews.freebsd.org/D13793
allocated with a tag to come from the specified domain if it meets the
other constraints provided by the tag. Automatically create a tag at
the root of each bus specifying the domain local to that bus if
available.
Reviewed by: jhb, kib
Tested by: pho
Sponsored by: Netflix, Dell/EMC Isilon
Differential Revision: https://reviews.freebsd.org/D13545
userspace to control NUMA policy administratively and programmatically.
Implement domainset based iterators in the page layer.
Remove the now legacy numa_* syscalls.
Cleanup some header polution created by having seq.h in proc.h.
Reviewed by: markj, kib
Discussed with: alc
Tested by: pho
Sponsored by: Netflix, Dell/EMC Isilon
Differential Revision: https://reviews.freebsd.org/D13403
Although these should have been 'emac', upstream DTS is going with using
'gmac' as the function name for the emac RGMII pins. Rename here to
accommodate.
emac support for the a83t should come in with the 4.16 DTS update, in
another couple of months.
For each we need to walk the MADT to find which we have, then add the
driver as needed. As each may have a child they will each walk the same
table to find these details.
Reviewed by: mmel
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8720
This adds a new acpi_bus interface with a map_intr method. This is similar
to the Open Firmware map_intr method and allows us to create the needed
mapping from ACPI space to INTRNG space.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8617
Highlights of the new bindings:
- ahb clock is specified as 'stmmaceth'
- The PHY to be used is now specified as phy-handle
- We must now check the parent of the node phy-handle points to in order to
discover if we're using internal PHY.
- The ephy clk/reset will be specified on the PHY node, not the emac node.
Care has been taken to ensure that we remain compatible with the older
bindings that we were previously using.
Tested on: Pine64 (A64, old bindings)
Tested on: Pine64-LTS (A64, new bindings) [manu]
Tested on: OrangePi-One (H3, internal PHY) [manu]
Tested on: NanoPi M1 Plus (H3, external PHY) [manu]
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D13777
The sid controller on the H3 is generally identical in location, size, and
efuse offset to the a64 and the a83t. The main difference is that the H3 has
a silicon bug that sometimes causes the rootkey (at least) to be garbled
unless first read by the prctl registers.
This device is currently not in our DTS and, as of now, is not yet present
in mainline Linux DTS.
Tested on: OrangePi One
Technically supported on the later SoCs, this will only really be used to
add support for the H3 sid. The H3 has a silicon bug that manifests itself
by returning garbled rootkeys unless first read via the prctl registers.
The emac bindings that are landing in Linux 4.15 specify a syscon property
on the emac node that point to /soc/syscon. Use this property if it's
specified, but maintain backwards compatibility with the old method.
The older method is still used for boards that we get .dtb from u-boot, such
as pine64, that did not yet have stable emac bindings.
Tested on: Banana Pi-M3 (a83t)
Tested on: Pine64 (a64)
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D13296
Newer Allwinner SoCs have nearly identical SID controllers with efuse space
starting at 0x200 into their register space and thermal data available at
0x234, making all of these fairly trivial additions.
The h3 will be added at a later time after some testing, due to a silicon
bug that causes the rootkey (at least) to be read incorrectly unless first
read via the control register.
Fully subclass the dwmmc driver and split every driver into multiple files.
There is still a few quirks in the dwmmc driver that will need some work.
Tested On: Pine64 Rock64
Differential Revision: https://reviews.freebsd.org/D13615
files that can use the default value.
It used to be required that the low-order bits of KERNVIRTADDR matched
the low-order bits of the physical load address for all arm platforms.
That hasn't been a requirement for armv6 platforms since FreeBSD 10.
There is no longer any relationship between load addr and KERNVIRTADDR
except that both must be aligned to a 2 MiB boundary.
This change makes the default KERNVIRTADDR value 0xc0000000, and removes the
options from all the platforms that can use the default value. The default
is now defined in vmparam.h, and that file is now included in a few new
places that reference KERNVIRTADDR, since it may not come in via the
forced-include of opt_global.h on the compile command line.
phy-mode can be one of: rgmii, rgmii-id, rgmii-txid, rgmii-rxid; as this was
written, any of these alternate -id configurations would break as we fail to
configure syscon for rgmii. Instead, simply check that phy-mode is
configured for rgmii and we'll let the PHY driver handle any internal delay
configuration.
The pine64 should eventually specify phy-mode = "rgmii-txid" to address
gigabit issues when rx delay is configured, motivating this change.
kernel VA mapping in the temporary page tables set up by locore-v6.S.
The number used to be hard-coded to 64MB, which is still the default if
the kernel option is not specified. However, 64MB is insufficient for
using a large mdroot filesystem. The hard-coded number can't be safely
increased because too large a number may run into memory-mapped IO space
on some SoCs that must not be mapped as ordinary memory.
