sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

riscv: S-mode extension parsing

There are now several Supervisor-mode extensions that have entered the
'ratified' status, so begin parsing and reporting a few of these.

Recognize the following exte

riscv: S-mode extension parsing

There are now several Supervisor-mode extensions that have entered the
'ratified' status, so begin parsing and reporting a few of these.

Recognize the following extensions:
- Sstc: stimecmp/vstimecmp CSR
- Svnapot: NAPOT* translation contiguity
- Svpbmt: page-based memory types
- Svinval: fine-grained TLB invalidation instructions
- Sscofpmf: performance counter overflow

*i.e. "naturally aligned power-of-2" page granularity

For now, provide globals for Sstc and Sscofpmf, as we will make use of
these in the near future.

Plus, update the copyright statement after my recent work on this file.

Reviewed by: jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40240

show more ...

riscv: Print less CPU info

Change the reporting strategy to more closely follow what arm64
implements:
- Always print the one-line CPU summary when a core comes online
- Only print the additional

riscv: Print less CPU info

Change the reporting strategy to more closely follow what arm64
implements:
- Always print the one-line CPU summary when a core comes online
- Only print the additional fields (e.g. ISA) when they differ from the
CPU before it

In the common case of identical CPUs this results in informative but
non-repetitive output. For example, in QEMU:

CPU 0 : Vendor=Unspecified Core=Unknown (Hart 0)
marchid=0x80032, mimpid=0x80032
MMU: 0x7<Sv39,Sv48,Sv57>
ISA: 0x112d<Atomic,Compressed,Double,Float,Mult/Div>
real memory = 8589934592 (8192 MB)
avail memory = 8332300288 (7946 MB)
FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs
CPU 1 : Vendor=Unspecified Core=Unknown (Hart 1)
CPU 2 : Vendor=Unspecified Core=Unknown (Hart 2)
CPU 3 : Vendor=Unspecified Core=Unknown (Hart 3)

Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40024

show more ...

riscv: MMU detection

Detect and report the supported MMU for each CPU. Export the
capabilities to the rest of the kernel and use it in pmap_bootstrap() to
check for Sv48 support.

Reviewed by: markj

riscv: MMU detection

Detect and report the supported MMU for each CPU. Export the
capabilities to the rest of the kernel and use it in pmap_bootstrap() to
check for Sv48 support.

Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39814

show more ...

riscv: Print ISA extensions

Report the CPU's single-letter ISA extensions in printcpuinfo().

Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https:

riscv: Print ISA extensions

Report the CPU's single-letter ISA extensions in printcpuinfo().

Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39813

show more ...

riscv: Rework CPU identification (second part)

Modify when and how we perform parsing and reporting. Most notably,
everything now executes on CPU 0.

The de-facto standard way to enumerate CPU featu

riscv: Rework CPU identification (second part)

Modify when and how we perform parsing and reporting. Most notably,
everything now executes on CPU 0.

The de-facto standard way to enumerate CPU features (ISA extensions) on
RISC-V is by parsing each CPU's ISA string. We currently obtain this
information from the device tree, and in the future will be able to pull
it from ACPI tables.

Eliminate the SYSINIT from identcpu.c. We still need to walk the /cpus
list in the device tree, but now do this one CPU at a time, as a step in
the identify_cpu() procedure. This is slightly less error prone, and
allows us to parse ISA features for CPU 0 much earlier.

Make use of the SMP hooks cpu_mp_start() and cpu_mp_announce() to
identify and print secondary CPU info, respectively. This causes
secondary processor identification to be printed much earlier in boot;
everything is done by SI_SUB_CPU, SI_ORDER_THIRD. Adjust some other
printf() calls so that we get enough useful info to debug under
bootverbose.

Reviewed by: markj (slightly earlier version)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39811

show more ...

riscv: Call identify_cpu() earlier for CPU 0

It is advantageous to have knowledge of ISA features as early as
possible. For example, the presence of newer virtual memory extensions
may be useful to

riscv: Call identify_cpu() earlier for CPU 0

It is advantageous to have knowledge of ISA features as early as
possible. For example, the presence of newer virtual memory extensions
may be useful to pmap_bootstrap().

To achieve this, split out the printf() parts of identify_cpu() into a
separate function, printcpuinfo(). This latter function will be called
later in boot after the console has been initialized.

Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39810

show more ...

riscv: Rework CPU identification (first part)

Make better use of the RISC-V identification CSRs: mvendorid, marchid,
and mimpid. This code was written before these registers were
well-specified, or

riscv: Rework CPU identification (first part)

Make better use of the RISC-V identification CSRs: mvendorid, marchid,
and mimpid. This code was written before these registers were
well-specified, or even available to the kernel. It currently fails to
recognize any CPU or platform.

Per the privileged specification, mvendorid contains the JEDEC vendor ID,
or zero.

The marchid register denotes the CPU microarchitecture. This is either
one of the globally allocated open-source implementation IDs, or the
field has a custom encoding. Therefore, for known vendors (SiFive) we
can also maintain a list of known marchid values. If we can not give a
name to the CPU but marchid is non-zero, then just print its value in
the report.

The mimpid (implementation ID) could be used in the future to more
uniquely identify the micro-architecture, but it really remains to be
seen how it gets used. For now we just print its value.

Thank you to Danjel Qyteza <danq1222@gmail.com> who submitted an early
version of this change to me, although it has been almost entirely
rewritten.

MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39809

show more ...

riscv: retire the FPE kernel option

We always build the kernel floating point support. Now that the
riscv64sf userspace variant has been removed the option is required for
correct operation.

Review

riscv: retire the FPE kernel option

We always build the kernel floating point support. Now that the
riscv64sf userspace variant has been removed the option is required for
correct operation.

Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39851

show more ...

Allow sysctl hw.machine/hw.machine_arch in capability mode

There's no harm in reading strings like 'amd64'.

Reviewed by: emaste, manu
Sponsored by: https://www.patreon.com/valpackett
Differential R

Allow sysctl hw.machine/hw.machine_arch in capability mode

There's no harm in reading strings like 'amd64'.

Reviewed by: emaste, manu
Sponsored by: https://www.patreon.com/valpackett
Differential Revision: https://reviews.freebsd.org/D28703

show more ...

riscv: improve parsing of riscv,isa property strings

This code was originally written under the assumption that the ISA
string would only contain single-letter extensions. The RISC-V
specification h

riscv: improve parsing of riscv,isa property strings

This code was originally written under the assumption that the ISA
string would only contain single-letter extensions. The RISC-V
specification has extended its description of the format quite a bit,
allowing for much longer ISA strings containing multi-letter extension
names.

Newer versions of QEMU (7.1.0) will append to the riscv,isa property
indicating the presence of multi-letter standard extensions such as
Zfencei. This triggers a KASSERT about the expected length of the
string, preventing boot.

Increase the size of the isa array significantly, and teach the code
to parse (skip over) multi-letter extensions, and optional extension
version numbers. We currently ignore them completely, but this will
change in the future as we start supporting supervisor-level extensions.

MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36601

show more ...

riscv: clean up empty lines in .c and .h files

riscv: Use global mimpid in identify_cpu()

sbi_init() sets mimpid, we can use that value.

Reviewed by: philip (mentor), kp (mentor)
Approved by: philip (mentor), kp (mentor)
Sponsored by: Axiado
Di

riscv: Use global mimpid in identify_cpu()

sbi_init() sets mimpid, we can use that value.

Reviewed by: philip (mentor), kp (mentor)
Approved by: philip (mentor), kp (mentor)
Sponsored by: Axiado
Differential Revision: https://reviews.freebsd.org/D26092

show more ...

RISC-V: add support for SBI spec v0.2

The Supervisor Binary Interface (SBI) specification v0.2 is a backwards
incompatible update to the SBI call interface for kernels running in
supervisor mode. Th

RISC-V: add support for SBI spec v0.2

The Supervisor Binary Interface (SBI) specification v0.2 is a backwards
incompatible update to the SBI call interface for kernels running in
supervisor mode. The goal of this update was to make it easier for new
and optional functionality to be added to the SBI.

SBI functions are now called by passing an "extension ID" and a
"function ID" which are passed in a7 and a6 respectively. SBI calls
will also return an error and value in the following struct:

struct sbi_ret {
long error;
long value;
}

This version introduces several new functions under the "base"
extension. It is expected that all SBI implementations >= 0.2 will
support this base set of functions, as they implement some essential
services such as obtaining the SBI version, CPU implementation info, and
extension probing.

Existing SBI functions have been designated as "legacy". For the time
being they will remain implemented, but it is expected that in the
future their functionality will be duplicated or replaced by new SBI
extensions. Each legacy function has been assigned its own extension ID,
and for now we simply probe and assert for their existence.

Compatibility with legacy SBI implementations (such as BBL) is
maintained by checking the output of sbi_get_spec_version(). This
function is guaranteed to succeed by the new spec, but will return an
error in legacy implementations. We use this as an indicator of whether
or not we can rely on the new SBI base extensions.

For further info on the Supervisor Binary Interface, see:
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc

Reviewed by: kp, jhb
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D22326

show more ...

RISC-V: skip cpu-map when parsing elf_hwcap

The fill_elf_hwcap() function expects to find only cpu nodes under the
/cpus entry of the device tree. Newer versions of QEMU insert a cpu-map
node which

RISC-V: skip cpu-map when parsing elf_hwcap

The fill_elf_hwcap() function expects to find only cpu nodes under the
/cpus entry of the device tree. Newer versions of QEMU insert a cpu-map
node which describes the CPU topology, breaking this function. To fix
this, simply skip any non-cpu entries.

Reviewed by: markj, kp, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22151

show more ...

riscv: Add missing header

r352218 missing an include statement, causing the build to fail.

Submitted by: Nicholas O'Brien (nickisobrien_gmail.com)
Sponsored by: Axiado

riscv: Small fix to CPU compatibility identification

fdt_is_compatible_strict() inspects the first compatible property.
We need to inspect the following properties for 'riscv'.
ofw_bus_node_is_compa

riscv: Small fix to CPU compatibility identification

fdt_is_compatible_strict() inspects the first compatible property.
We need to inspect the following properties for 'riscv'.
ofw_bus_node_is_compatible() does a recursive search.

This patch fixes "Can't find CPU" error message when bootverbose = true.

Submitted by: Nicholas O'Brien (nickisobrien_gmail.com)
Reviewed by: philip, kp
Sponsored by: Axiado
Differential Revision: https://reviews.freebsd.org/D21576

show more ...

RISC-V: expose extension bits in AT_HWCAP

AT_HWCAP is a field in the elf auxiliary vector meant to describe
cpu-specific hardware features. For RISC-V we want to use this to
indicate the presence of

RISC-V: expose extension bits in AT_HWCAP

AT_HWCAP is a field in the elf auxiliary vector meant to describe
cpu-specific hardware features. For RISC-V we want to use this to
indicate the presence of any standard extensions supported by the CPU.
This allows userland applications to query the system for supported
extensions using elf_aux_info(3).

Support for an extension is indicated by the presence of its
corresponding bit in AT_HWCAP -- e.g. systems supporting the 'c'
extension (compressed instructions) will have the second bit set.

Extensions advertised through AT_HWCAP are only those that are supported
by all harts in the system.

Reviewed by: jhb, markj
Approved by: markj (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20493

show more ...

o Remove operation in machine mode.
Machine privilege level was specially designed to use in vendor's
firmware or bootloader. We have implemented operation in machine
mode in FreeBSD as part of

o Remove operation in machine mode.
Machine privilege level was specially designed to use in vendor's
firmware or bootloader. We have implemented operation in machine
mode in FreeBSD as part of understanding RISC-V ISA, but it is time
to remove it.
We now use BBL (Berkeley Boot Loader) -- standard RISC-V firmware,
which provides operation in machine mode for us.
We now use standard SBI calls to machine mode, instead of handmade
'syscalls'.
o Remove HTIF bus.
HTIF bus is now legacy and no longer exists in RISC-V specification.
HTIF code still exists in Spike simulator, but BBL do not provide
raw interface to it.
Memory disk is only choice for now to have multiuser booted in Spike,
until Spike has implemented more devices (e.g. Virtio, etc).

Sponsored by: DARPA, AFRL
Sponsored by: HEIF5

show more ...

Update RISC-V port to Privileged Architecture Version 1.9.

Sponsored by: DARPA, AFRL
Sponsored by: HEIF5

Welcome the RISC-V 64-bit kernel.

This is the final step required allowing to compile and to run RISC-V
kernel and userland from HEAD.

RISC-V is a completely open ISA that is freely available to ac

Welcome the RISC-V 64-bit kernel.

This is the final step required allowing to compile and to run RISC-V
kernel and userland from HEAD.

RISC-V is a completely open ISA that is freely available to academia
and industry.

Thanks to all the people involved! Special thanks to Andrew Turner,
David Chisnall, Ed Maste, Konstantin Belousov, John Baldwin and
Arun Thomas for their help.
Thanks to Robert Watson for organizing this project.

This project sponsored by UK Higher Education Innovation Fund (HEIF5) and
DARPA CTSRD project at the University of Cambridge Computer Laboratory.

FreeBSD/RISC-V project home: https://wiki.freebsd.org/riscv

Reviewed by: andrew, emaste, kib
Relnotes: Yes
Sponsored by: DARPA, AFRL
Sponsored by: HEIF5
Differential Revision: https://reviews.freebsd.org/D4982

show more ...

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

riscv: S-mode extension parsing

There are now several Supervisor-mode extensions that have entered the
'ratified' status, so begin parsing and reporting a few of these.

Recognize the following exte

riscv: S-mode extension parsing

There are now several Supervisor-mode extensions that have entered the
'ratified' status, so begin parsing and reporting a few of these.

Recognize the following extensions:
- Sstc: stimecmp/vstimecmp CSR
- Svnapot: NAPOT* translation contiguity
- Svpbmt: page-based memory types
- Svinval: fine-grained TLB invalidation instructions
- Sscofpmf: performance counter overflow

*i.e. "naturally aligned power-of-2" page granularity

For now, provide globals for Sstc and Sscofpmf, as we will make use of
these in the near future.

Plus, update the copyright statement after my recent work on this file.

Reviewed by: jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40240

show more ...