This existing helper function is preferable to the hand-rolled
calculation of the kstack bounds.
Make some small style improvements while here. Notably, rename every
instance of "r", the return address, to "ra". Tidy the includes in the
affected files.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39909
TI support is in a sad state for years.
We haven't been able to keep up with all the breaking changes that
upstream do in the DTS. This requires a lot of new drivers to handle the
new buses that they create and all the new clocks that they expose.
Keep the code for now in case somebody is interested in reviving this
platform but stop bloating GENERIC with code that don't work.
Reviewed by: imp, mmel
MFC after: never
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39843
There is now assertion which requires all memory allocations of positive size.
Negative and zero-sized allocations lead to panic, so plug them off.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D39846
This was needed before INTRNG was in place and handling the push of
curthread->td_intr_frame. Since INTRNG now handles this, there is no
longer and need for playing around with the frame inside IPI interrupts.
This was needed when intr_ipi_dispatch() was called by hardware-specific
IPI interrupt routines which didn't save the trap frame. Now all ARM
interrupts pass through INTRNG which will have already saved the trap
frame and disabled preemption.
Remove the conditional trapframe/argument passing to the handlers.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D37938
When vm_map_remove() is called from vm_swapout_map_deactivate_pages()
due to swapout, PKRU attributes for the removed range must be kept
intact. Provide a variant of pmap_remove(), pmap_map_delete(), to
allow pmap to distinguish between real removes of the UVA mappings
and any other internal removes, e.g. swapout.
For non-amd64, pmap_map_delete() is stubbed by define to pmap_remove().
Reported by: andrew
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D39556
NETLINK is going to replace rtsock and a number of other ioctl/sysctl interfaces.
In-base utilies such as route(8), netstat(8) and soon ifconfig(8)
are being converted to use netlink sockets as a transport between
kernel and userland.
In the current configuration, it still possible have the kernel
without NETLINK (`nooptions NETLINK`) and use the aforementioned
utilies by buidling the world with `WITHOUT_NETLINK` src.conf knob.
However, this approach does not cover the cases when person unintentionally
builds a custom kernel without netlink and tries to use the standard userland.
This change adds `option NETLINK` to the default options for each
architecture, fixing the custom kernel issue.
For arm, this change uses `std.armv6` and `std.armv7` (netlink already in)
instead of DEFAULTS.
Reviewed By: imp
Differential Revision: https://reviews.freebsd.org/D39339
Make a pass at the various nexus implementations, fixing some very minor
style issues, obsolete comments, etc.
The method declaration section has become unwieldy in many respects.
Attempt to tame it by:
- Using generated method typedefs
- Grouping methods roughly by category, and then alphabetically.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D38495
We had GENERIC for a while now so anyone still interested in those boards
should make sure that we can boot on them with it and with upstream DTS files.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: br
Differential Revision: https://reviews.freebsd.org/D39088
There is nothing hdmi related in this interface, it's just a generic interface
for crt controller so rename it.
This also remove the 'hdmi' device used in arm kernel config. 'vt' now controls
if we build this interface (sc(4) isn't supported on arm).
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39120
device 'hdmi' is too generic (and will be used later in a new device) so rename
the arm TI devices to some proper name.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39119
device 'hdmi' is too generic (and will be used later in a new device) so rename
the arm IMX devices to some proper name.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39118
It was disconnected 5 years ago in 4573cd3914
("arm: allwinner: Disconnect A10/A20 HDMI driver") as it wasn't working.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39117
All devices are in GENERIC and GENERIC is known to boot on those SoCs.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39090
We had GENERIC for a while now so anyone still interested in those boards
should make sure that we can boot on them with it and with upstream DTS files.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39089
We had GENERIC for a while now so anyone still interested in those boards
should make sure that we can boot on them with it and with upstream DTS files.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39087
It reference to a non-existant dts file apalis-imx6.dts so unlikekly to compile.
Aldo IMX6 support is in GENERIC so anyone interested in this board should
make it work with GENERIC kernel (if that's not already the case).
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D39086
The order of the interrupt array doesn't matter. Store the described
interrupts at the start of the array to simplify iterating over them.
Reviewed by: imp, kevans
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D39094
To allow bhyve manage the virtual timer while in a guest have FreeBSD
use the virtual timer only when bhyve will be unavailable due to not
starting at EL2 where the hypervisor switcher will run.
Reviewed by: imp, kevans
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D39093
Eliminate a redundant resource array allow possible use by bhyve later.
Reviewed by: kevans
Sponsored by: Arm Ltd
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37424
We always have it, some languages assume it's present, e.g. go
before 1.20. Enable it by default on arm and arm64.
PR: 269070
Reviewed by: kevans
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D39059
Offsets for all of thse can be a bit complicated as not all interrupts
will be present, only phys and virt are actually required, and sec-phys
could optionally be specified before phys. Push idx/name pairs into
a new config struct and maintain the old indices while still getting the
correct timers.
Split fdt/acpi attach out independently and allocate interrupts before
we head into the common attach(). The secure physical timer is also
optional there, so mark it so to avoid erroring out if we run into
problems.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D38911
On arm64 PCI config memory is expected to be mapped with a non-posted
device type. To handle this use the new bus_map_resource support in
arm64 to map memory with the new VM_MEMATTR_DEVICE_NP attribute. This
memory has already been allocated and activated, it just needs to be
mapped.
Reviewed by: kevans, mmel
Differential Revision: https://reviews.freebsd.org/D30079
All drivers are already either in GENERIC or in the other arches LINT
so no need to build this one too.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38851
All drivers are already either in GENERIC or in the other arches LINT
so no need to build this one too.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38850
All drivers are already either in GENERIC or in the IMX51 kernel config
so no need to build this one too.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38849
Specific devices are in LINT so no need to build this one as part
of make universe.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38848
Reviewed by: imp
This file defines a small API to be used by other drivers. If any of
these functions are called before the bcm_dma device has attached we
should handle the error gracefully. Fix a formatting quirk while here.
Reviewed by: manu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38756
The sdhci_bcm driver attach routine relies on bcm_dma already being
attached, in order to allocate a DMA channel. However, both drivers
attached at the default pass so this is not guaranteed. Newer RPI
firmware exposes this assumption, and the result is a NULL-dereference
in bcm_dma_allocate().
To fix this, use BUS_PASS_SUPPORTDEV for bcm_dma.
PR: 268835
Reviewed by: mhorne
MFC after: 1 week
Most options in kernel config files use "options<space><tab>OPTION".
This allows the option to be commented out without shifting columns.
A few options had two tabs, and some had spaces. Make them consistent.
Make sure that pcb_vfpsaved is always initialized.
Create a vfp_new_thread helper that is heavily based on the arm64 logic.
While here remove un unnecessary assigment and add an assertion
to make sure that it's been properly initialized before we return
from a VFP exception.
Reported by: Mark Millard <marklmi@yahoo.com>
Tested by: Mark Millard <marklmi@yahoo.com>
Differential Revision: https://reviews.freebsd.org/D38698
Contrary to arm64, on armv7 get_vfpcontext/set_vfpcontext can be called
from cpu_ptrace. This can be triggered when gdb hits a breakpoint
in a userspace program.
Relax td == currthread assertion to account for that situation.
While here update an outdated comment in vfp_discard.
Reported by: Mark Millard <marklmi@yahoo.com>
Tested by: Mark Millard <marklmi@yahoo.com>
Differential Revision: https://reviews.freebsd.org/D38696
When adding kernel VFP support on arm a comparison instruction was
removed, however the branch to vfp_save_state was still conditional.
Remove the conditional check and always call into vfp_save_state as
it could cause unexpected results otherwise.
Sponsored by: Arm Ltd
They don't provide any value and are quite arbitrary.
Note arm64 GENERIC-MMCCAM was already excluded, just not the NODEBUG
variant.
The option is already build-tested with arm64 LINT kernel.
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D38458
Rather than using the DEVICE_IDENTIFY method, let's have other
ofwbus-using platforms add ofwbus0 explicitly in nexus, like arm64. This
gives them the same flexibility, e.g. if riscv starts supporting ACPI,
and cleans up the #ifdefs.
We were doing this already on riscv, but adjust the 'order' parameters.
Reviewed by: andrew, jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D38492
The architecture nexus should handle allocation and release of memory and
interrupts. This is to ensure that system-wide resources such as these
are available to all devices, not just children of ofwbus0.
On powerpc this moves the ownership of these resources up one level,
from ofwbus0 to nexus0. Other architectures already have the required
logic in their nexus implementation, so this eliminates the duplication
of resources. An implementation of nexus_adjust_resource() is added for
arm, arm64, and riscv.
As noted by ian@ in the review, resource handling was the main bit of
logic distinguishing ofwbus from simplebus. With some attention to
detail, it should be possible to merge the two in the future.
Co-authored by: mhorne
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D30554
Allow the nexus bus to own and manage interrupt resources. Currently,
interrupt resources on this architecture are managed completely by
ofwbus, but it is desirable that system-wide memory and interrupt
resources be managed by the top-level bus.
This is a pre-requisite to moving this resource management out of
ofwbus.
Reviewed By: ian, Elliott Mitchell <ehem+freebsd@m5p.com>
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D32357
