These are missing changes after 1228b93b41 when ref_count was
removed from bus_dma_tag_common and 1e3f42b6ba, when the address
arguments were switched to pointers.
Reviewed by: jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D45289
Since config(8) searches sys/conf by default, there's no need to specify
the full relative path here; replace it by the filename alone.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1124
The new sys/conf/std.debug contains the list of debugging options
enabled by default in -CURRENT, so they don't need to be listed
individually in every kernel config.
The enabled options are the set of all debug options which were enabled
for the GENERIC kernel on any platform. This means some architectures
now have debugging options enabled in GENERIC which weren't previously
enabled:
- amd64: [1]
- arm64: [2]
- arm: [2]. [3]
- i386: [1], [2]
- powerpc: [1], [2], [3]
- riscv: [2]
[1] ALT_BREAK_TO_DEBUGGER is now enabled.
[2] BUF_TRACKING, FULL_BUF_TRACKING, and QUEUE_MACRO_DEBUG_TRASH are now
enabled.
[3] DEADLKRES is now enabled.
While here, move the documentation for the (commented out) K*SAN options
for amd64 from GENERIC to NOTES.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1124
Require both "efirt" and "efidev" in order to build in efidev
Require both "efirt" and "efirtc" in order to build in efirtc
Update FIRECRACKER, GENERIC, and NOTES for amd64
Update NOTES and std.arm for arm64
Reviewed by: imp
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D44745
While here, adjust the sample setting for NVME_USE_NVD to use a
non-default setting as is typical in entries in NOTES.
Discussed with: imp
Reviewed by: manu
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44691
Move the core dwc(4) file entries to the MI conf/files.
Platform-specific versions e.g. rk_dwc are retained in their current
position. On arm64 this necessitates adding an additional 'device dwc'
option.
This hardware is found on several available/emerging RISC-V SoCs, so we
will soon need it on this architecture.
Reviewed by: manu
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D44103
Allows the development, testing and deployment of netmap(4)-based code
on arm64 without having to recompile the kernel. netmap(4) is already
in the amd64 and powerpc64 default configs, so it does not seem
unreasonable to also provide it on arm64 by default.
Note that netmap(4) is useful even on systems without NIC that fully
support it.
Reviewed by: vmaffione
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D43702
we leave `options CAMDEBUG` enabled, so that when needed, CAM debugging
can be enabled *as needed*, rather than setting a default of everything.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/798
Armv8.5 adds an optional random number generator. This is implemented
as two special registers one to read a random number, the other to
re-seed the entropy pool before reading a random number. Both registers
will set the condition flags to tell the caller they can't produce a
random number in a reasonable amount of time.
Without a signal to reseed the entropy pool use the latter register
to provide random numbers to the kernel pool. If at a later time we
had a way to tell the provider if it needs to reseed or not we could
use the former.
On an Amazon AWS Graviton3 VM this never failed, however this may not
be the case on low end CPUs so retry reading the random number 10 times
before returning an error.
Reviewed by: imp, delphij (csprng)
Sponsored by: The FreeBSD Foundation
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D35411
Use it wherever COMPAT_FREEBSD13 is currently specified.
Reviewed by: brooks, zlei
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D42100
This IP is found in Xilinx SoC, it only been tested on ZynqMP (arm64)
so only enable it there for now.
Differential Revision: https://reviews.freebsd.org/D41994
The M1 uses FDT, and has bge to start with. Add a SOC_* option for
the first SoC we'll be supporting.
IOMMU is added commented out because it does have it, but IOMMU is not
well-tested on aarch64. An initial version of the DART driver will be
upstreamed that just puts the DARTs that support bypass mode into bypass
mode -- we'll be missing some functionality, but we at least still end
up with some USB ports.
Reviewed by: karels, manu
Input from: jrtc27 (IOMMU)
Differential Revision: https://reviews.freebsd.org/D39823
This basic version of the driver obtains properties of the "sff,sfp"
compatible devices and implements a simple interface to provide an I2C
bus device for the rest of the drivers (e.g. to implement SIOCGI2C).
Both of the interface and driver are subjects for a further
generalization to be used in case of non-FDT and non-arm64 platforms.
Reviewed by: bz, manu
Approved by: bz (mentor)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D41440
Add a driver to connect vt to the VirtIO GPU device in 2D mode. This
provides a output on the display when a qemu virtio gpu device is
added, e.g. with -device virtio-gpu-pci.
Tested on qemu using UTM, and a Hetzner arm64 VM instance.
Reviewed by: bryanv (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D40094
It is a simple RTC found in some Arm SoCs, e.g. the Arm Juno.
Reviewed by: manu
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D41267
Fix a boot-time panic in qcom_mdio_ipq4018 due to a missing bus function
and hook the file up to the build so that it will not rot away.
Test booted on an ipq807x in 2022.
X-Differential Revision: extracted from D37882
Match other platforms, include the kernel config in the build.
Reviewed by: emaste
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D41284
This allows us to support this hardware and, in the future, use clocks
so they are enabled past the initial kernel boot process.
Reviewed by: ray
Differential Revision: https://reviews.freebsd.org/D30103
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
Hyper-V does not provide Mellanox hardware, some of Azure's instances
do, thus the configuration to enable them does not belong in the generic
std.hyperv config.
Fixes: 15e7fa83ef ("arm64: Hyper-V: Add vPCI and Mellanox driver modules into build")
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.
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
This is a followup of 692e19cf51 (add netlink to GENERIC@amd64).
Netlink is a communication protocol defined in RFC 3549. It is async,
TLV-based protocol, providing 1-1 and 1-many communications between kernel
and userland. Netlink is currently used in Linux kernel to modify, read and
subscribe for nearly all networking states. Interface state, addresses, routes,
firewall, rules, fibs, etc, are controlled via Netlink.
Netlink support was added in D36002. It has got a number of improvements and
first customers since then:
* net/bird2 got netlink support, enabling route multipath in FreeBSD
* netlink-based devd notifications are being worked on ( D37574 ).
* linux(4) fully supports and depends on Netlink
Enabling Netlink in GENERIC targets two goals.
The first one is to provide stability for the third-party userland applications,
so they can rely on the fact that netlink always exists since 14.0 and potentially 13.2.
Loadable module makes life of the app delepers harder. For example, `net/bird2` can be
either build with netlink or rtsock support, but not both.
The second goal is to enable gradual conversion of the base userland tools
to use netlink(4) interfaces. Converting tools like netstat (D36529), route,
ifconfig one-by-one simplifies testing and addressing the feedback.
Othewise, switching all base to use netlink at once may be too big of a leap.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D37783
The scmi driver in its current form requires the arm_doorbell
driver to communicate with the firmware.
The arm_doorbell is only found in ARM Juno reference board (and
apparently on Morello too).
If we want to use scmi on other platform (like some rockchip or imx
soc), the driver needs to be updated to support svc/shmem communication
with the firmware.
For now since it can be only used with arm_doorbell move the device to
std.arm otherwise kernel configs like ALLWINNER or ROCKCHIP fails to build.
Reviewed by: br, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37953
The SCMI specification describes a set of standard interfaces for power,
performance and system management.
SCMI is extensible and provides interfaces to access functions which are
often implemented in firmwares in the System Control Processor (SCP).
This implements Shared Memory-based transfer, which is one of the ways on
how messages are exchanged between agents and the platform.
This includes a driver for ARM Message Handling Unit (MHU) Doorbell, which
is a mechanism that the caller can use to alert the callee of the presence
of a message.
The support implements clock management interface. For instance this allows
us to control HDMI pixel clock on ARM Morello Board.
Tested on ARM Morello Board.
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D37316
Reviewed by: manu
Sponsored by: UKRI
This reverts commit fe36346a89.
The arm64 Hyper-v code now checks it is running under Hyper-v before
calling into the hypervisor.
Sponsored by: The FreeBSD Foundation
Mostly to document basic harware present on the platform; knowing that
Graviton exposes an ns8250 uart alone is quite helpful.
Reviewed by: andrew, imp, manu
Seems accurate: cperciva
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D36776
This is the last part for ARM64 Hyper-V enablement. This includes
commone files and make file changes to enable the ARM64 FreeBSD
guest on Hyper-V. With this patch, it should be able to build
the ARM64 image and install it on Hyper-V.
Reviewed by: emaste, andrew, whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D36744
