sys: Build arm64 per-thread SSP with GCC

It has been supported since GCC 9. It is unlikely anything older than
that will build the kernel so mark it as supported by GCC.

Reviewed by: brooks, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45267

sys: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by: Netflix

arm: Introduce MK_KERNEL_BIN to control generation of kernel.bin

It's sometimes desirable to generate kernel.bin and install it. While
the mainstream has moved on to UEFI booting on arm, some specialized
gear can't support it. For that gear, we unconditionally generate
kernel.bin. Add a knob so that WITH_KERNEL_BIN or WITHOUT_KERNEL_BIN
control its generation and installation. config files should add
'makeoptions WITH_KERNEL_BIN=t' to enable it. Since its use is
specialized, it is off by default now since the arm world has largely
moved on to UEFI.

It only affects arm and arm64 (since those are the only two that support
it).

Sponsored by: Netflix
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D39013

sys: Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

arm64: Use FULLKERNEL instead of .ALLSRC in .bin target

Using .ALLSRC may get additional arguments that we may not want
and could cause the objcopy to fail.

Reviewed by: emaste
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D39639

Clarify DTR_ENABLED make variable

Rename it to DTRACE_ENABLED.

Suggested by: jhb
MFC after: 3 days
Sponsored by: The FreeBSD Foundation

arm64: Don't rely on host readelf for u-boot booti image generation

readelf is not a bootstrap tool and so cannot be relied upon to exist.
On macOS there is no system readelf, and even on Linux or FreeBSD where
it does exist, BUILD_WITH_STRICT_TMPPATH builds won't be able to use it.
Instead of making it a bootstrap tool, just use nm as that suffices and
already is a bootstrap tool.

Fixes: 28482babd08a ("arm64: Use new arm_kernel_boothdr script for generating booti images.")
Reviewed by: emaste, mmel
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32734

Per-thread stack canary on arm64

With the update to llvm 13 we are able to tell the compiler it can find
the SSP canary relative to the register that holds the userspace stack
pointer. As this is unused in most of the kernel it can be used here
to point to a per-thread SSP canary.

As the kernel could be built with an old toolchain, e.g. when upgrading
from 13, add a warning that the options was enabled but the compiler
doesn't support it to both the build and kernel boot.

Discussed with: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33079

arm64: Check dtb version against the one we're expecting to find

Do for arm64 what was done for armv7 in e63faa9ba832b6

Switch to the new device-tree vendor tree

The old vendor tree was never fully merged and doing partial merge isn't
supported with git subtree merge so a new one was created.
Switch the build to use the new DTS from sys/contrib/device-tree
This also bump the DTS used to be in sync with Linux 5.9
While here change the way to get the linux version, simply hardcode
the value in sys/dts/freebsd-compatible.dts and use awk to get that
to put it in the CFLAGS.
As a bonus we now have the bindings docs available
in sys/contrib/device-tree/Bindings/ so no need to link to the Linux repo
or to the vendor tree.

arm64: Add the dts include directory to the includes dir

We do that for arm so we can directly #include <dt-bindings/...>

Create a stack frame when needed in the arm64 kernel

When building the arm64 kernel for use with dtrace or hwpmc we need
to include a stack frame so they can extract a stack trace.

As with amd64 also build a stack frame in modules.

Sponsored by: Innovate UK

arm64: Use new arm_kernel_boothdr script for generating booti images.

Eliminate the generated ldscript for arm and arm64, and strip $a/$d marker
symbols from the linked kernel.

The main thrust of this change is to generate a kernel that has the arm
"marker" symbols stripped. Marker symbols start with $a, $d, $t or $x, and
are emitted by the compiler to tell other toolchain components about the
locations of data embedded in the instruction stream (literal-pool
stuff). They are used for generating mixed-endian binaries (which we don't
support). The linked kernel has approximately 21,000 such symbols in it,
wasting space (500K in kernel.full, 190K in the final linked kernel), and
sometimes obscuring function names in stack tracebacks.

This change also simplifies the way the kernel is linked. Instead of using
sed to generate two different ldscript files to generate both an elf kernel
and a binary (elf headers stripped) kernel, we now use a single ldscript
that refers to a "text_start" symbol, and we provide the value for that
symbol using --defsym on the linker command line.

Add support for booting kernel directly from U-Boot using booti command.

In some cases, like is locked bootstrap or device's inability to boot from
removable media, we cannot use standard boot sequence and is necessary to
boot kernel directly from U-Boot.

Discussed with: jhibbits
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D13861

revert r354714 "Boot arm64 kernel using booti command from U-boot."

After discussing with mmel@, it was clear this is insufficient to address
all the needs. mmel@ will commit his original patch, from
https://reviews.freebsd.org/D13861, and the additions needed from r354714
will be made afterward.

Requested by: mmel
Sponsored by: Juniper Networks, Inc.

Boot arm64 kernel using booti command from U-boot.

Summary:
Boot arm64 kernel using booti command from U-boot. booti can relocate initrd
image into higher ram addresses, therefore align the initrd load address to 1GiB
and create VA = PA map for it. Create L2 pagetable entries to copy the initrd
image into KVA.
(parts of the code in https://reviews.freebsd.org/D13861 was referred and used
as appropriate)

Submitted by: Siddharth Tuli <siddharthtuli_gmail.com>
Reviewed by: manu
Sponsored by: Juniper Networks, Inc
Differential Revision: https://reviews.freebsd.org/D22255

Revert r336353 completely based on protest; compatibility shims incoming

Revert 336358 and step away fron machine for the day...

VERSREQ < 7.+ physically will not work with new config(8) due to major bump,
which is why I bumped it in the first place... Back to the original version

Partially revert r336353: sys/conf/* %VERSREQ bumps

The changes made in r335998 don't strictly require a newer config(8),
though it is advised. The %VERSREQ bumps were premature.

config(8): Bump major version after r335998

config-generated hints.c/env.c from r335998 and later are incompatible with
earlier kernels due to no longer setting envmode/hintmode. A minor bump for
this is insufficient, as matching major version with a later minor version
is still viewed as backwards-compatible.

This was an MI kernel change, soo all VERSREQ's are bumped.

Build changes that allow the modules on arm64.
- Move the required kernel compiler flags from Makefile.arm64 to kern.mk.
- Build arm64 modules as PIC; non-PIC relocations in .o for shared object
output cannot be handled.
- Do not try to install aarch64 symlink.
- A hack for arm64 to avoid ld -r stage. See the comment for the explanation.
Some functionality is lost, like ctf handling, but hopefully will be
restored after newer linker is available.

Reviewed by: andrew, emaste
Tested by: andrew (on real hardware)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3796

Bring in the start of the arm64 kernel.

This is only the minimum set of files needed to boot in qemu. As such it is
missing a few things.

The bus_dma code is currently only stub functions with a full implementation
from the development tree to follow.

The gic driver has been copied as the interrupt framework is different. It
is expected the two drivers will be merged by the arm intrng project,
however this will need to be imported into the tree and support for arm64
would need to be added.

This includes code developed by myself, SemiHalf, Ed Maste, and Robin
Randhawa from ARM. This has been funded by the FreeBSD Foundation, with
early development by myself in my spare time with assistance from Robin.

Differential Revision: https://reviews.freebsd.org/D2199
Reviewed by: emaste, imp
Relnotes: yes
Sponsored by: The FreeBSD Foundation