Our standard boot method for arm64 is via UEFI, so install the man page
that describes the boot process.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
FreeBSD and industry has been inconsistent in the use of UEFI and EFI.
They are essentially just different versions of the same specification
and are often used interchangeably. Make it easier for users to find
information by making efi(8) an alias for uefi(8).
Reported by: imp, jhb
- EFI support appeared in 5.0 for ia64
- arm64 UEFI support added in 11.0
The AUTHORS section included the folks responsible for the bulk of the
work to bring UEFI support to amd64, but missed those who did the
original work on ia64, the initial port to i386, the ports to arm64 and
arm, and have generally maintained and improved general UEFI support
since then. It's unwieldly to include everyone and would quickly become
outdated again anyhow, so just remove the AUTHORS section.
Reviewed by: manu
Discussed with: jhb
Differential Revision: https://reviews.freebsd.org/D14033
possible to change string and numeric vendor and product identifiers,
as well as anything else there might be to change for a particular
device side template, eg the MAC address.
Reviewed by: hselasky@
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13920
This matches directory structure used commonly in Linux-land, and it's
cleaner than mixing overlays into the existing module paths. Overlays are
still mixed in by specifying fdt_overlays in loader.conf(5).
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D13922
r314467 introduced hw.usb.wsp.enable_single_tap_clicks to enable/disable
single-tap left click behavior. Update the man page to reflect the new
sysctl.
PR: 196624
MFC after: 3 days
X-MFC-With: r314467
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
There's a report of some regression in ports. Revert for now for an
exp run for this change in isolation (previous lld exp run also included
switching the linker used for ports to lld).
Also revert the src.conf.5 regeneration in r327824.
Reported by: antoine
Sponsored by: The FreeBSD Foundation
Additionally, move the overflow check logic out to WOULD_OVERFLOW() for
consumers to have a common means of testing for overflowing allocations.
WOULD_OVERFLOW() should be a secondary check -- on 64-bit platforms, just
because an allocation won't overflow size_t does not mean it is a sane size
to request. Callers should be imposing reasonable allocation limits far,
far, below overflow.
Discussed with: emaste, jhb, kp
Sponsored by: Dell EMC Isilon
(I missed the Reviewed by and review link from r327783.)
Reviewed by: brooks, dim, bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D13827
We currently use a set of subroutines in kern_gzio.c to perform
compression of user and kernel core dumps. In the interest of adding
support for other compression algorithms (zstd) in this role without
complicating the API consumers, add a simple compressor API which can be
used to select an algorithm.
Also change the (non-default) GZIO kernel option to not enable
compressed user cores by default. It's not clear that such a default
would be desirable with support for multiple algorithms implemented,
and it's inconsistent in that it isn't applied to kernel dumps.
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D13632
Similar to calloc() the mallocarray() function checks for integer
overflows before allocating memory.
It does not zero memory, unless the M_ZERO flag is set.
Reviewed by: pfg, vangyzen (previous version), imp (previous version)
Obtained from: OpenBSD
Differential Revision: https://reviews.freebsd.org/D13766
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
Enable the hardclock-based watchdog previously conditional on the
SW_WATCHDOG option whenever hardware watchdogs are not found, and
watchdogd attempts to enable the watchdog. The SW_WATCHDOG option
still causes the sofware watchdog to be enabled even if there is a
hardware watchdog. This does not change the other software-based
watchdog enabled by the --softtimeout option to watchdogd.
Note that the code to reprime the watchdog during kernel core dumps is
no longer conditional on SW_WATCHDOG. I think this was previously a bug.
Reviewed by: imp alfred bjk
MFC after: 1 week
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D13713
This copies changes from NetBSD into FreeBSD's man page. I compared the
proposed changes against FreeBSD headers and modified them to match.
PR: 214602
Submitted by: fehmi noyan isi <fnoyanisi@yahoo.com>
Introduce new set of loader tunables kern.vt.color.N.rgb, where N is a
number from 0 to 15. The value is either comma-separated list decimal
numbers ranging from 0 to 255 that represent values of red, green, and
blue components respectively (i.e. "128,128,128") or 6-digit hex triplet
commonly used to represent colors in HTML or xterm settings (i.e. #808080)
Each tunable overrides one of the 16 hardcoded palette codes and can be set
in loader.conf(5)
Reviewed by: bcr(docs), jilles, manu, ray
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13645
A comment in Makefile.inc1 has long stated that LOCAL_DIRS are built last,
after the base system. Incremental improvements in parallel building over
the years have led to LOCAL_DIRS being built in parallel with base system
directories. This change allows the .WAIT directive to appear in LOCAL_DIRS
and LOCAL_LIB_DIRS lists to give the user some control over parallel
building of local additions.
Differential Revision: https://reviews.freebsd.org/D13622
