Select if you want MMU-based virtualised addressing space support by paged memory management. If unsure, say 'Y'.
This selects the base ISA that this kernel will target and must match the target platform.
This enables support for systems with more than one CPU. If you say N here, the kernel will run on single and multiprocessor machines, but will use only one CPU of a multiprocessor machine. If you say Y here, the kernel will run on many, but not all, single processor machines. On a single processor machine, the kernel will run faster if you say N here. If you don't know what to do here, say N.
Say Y here to experiment with turning CPUs off and on. CPUs can be controlled through /sys/devices/system/cpu. Say N if you want to disable CPU hotplug.
Enable NUMA (Non-Uniform Memory Access) support. The kernel will try to allocate memory used by a CPU on the local memory of the CPU and add some more NUMA awareness to the kernel.
Specify the maximum number of NUMA Nodes available on the target system. Increases memory reserved to accommodate various tables.
Adds "C" to the ISA subsets that the toolchain is allowed to emit when building Linux, which results in compressed instructions in the Linux binary. If you don't know what to do here, say Y.
A base PMU that serves as a reference implementation and has limited feature of perf. It can run on any RISC-V machines so serves as the fallback, but this option can also be disable to reduce kernel size.
Say N here if you want to disable all floating-point related procedure in the kernel. If you don't know what to do here, say Y.
This config allows kernel to use SBI v0.1 APIs. This will be deprecated in future once legacy M-mode software are no longer in use.
kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot but it is independent of the system firmware. And like a reboot you can start any kernel with it, not just Linux. The name comes from the similarity to the exec system call.
Generate crash dump after being started by kexec. This should be normally only set in special crash dump kernels which are loaded in the main kernel with kexec-tools into a specially reserved region and then later executed after a crash by kdump/kexec. For more details see Documentation/admin-guide/kdump/kdump.rst
For most platforms, the arguments for the kernel's command line are provided at run-time, during boot. However, there are cases where either no arguments are being provided or the provided arguments are insufficient or even invalid. When that occurs, it is possible to define a built-in command line here and choose how the kernel should use it later on.
Choose how the kernel will handle the provided built-in command line.
Use the built-in command line as fallback in case we get nothing during boot. This is the default behaviour.
The command-line arguments provided during boot will be appended to the built-in command line. This is useful in cases where the provided arguments are insufficient and you don't want to or cannot modify them.
Always use the built-in command line, even if we get one during boot. This is useful in case you need to override the provided command line on systems where you don't have or want control over it.
This option provides support for runtime services provided by UEFI firmware (such as non-volatile variables, realtime clock, and platform reset). A UEFI stub is also provided to allow the kernel to be booted as an EFI application. This is only useful on systems that have UEFI firmware.
This is the physical address of RAM in the system. It has to be explicitly specified to run early relocations of read-write data from flash to RAM.
Execute-In-Place allows the kernel to run from non-volatile storage directly addressable by the CPU, such as NOR flash. This saves RAM space since the text section of the kernel is not loaded from flash to RAM. Read-write sections, such as the data section and stack, are still copied to RAM. The XIP kernel is not compressed since it has to run directly from flash, so it will take more space to store it. The flash address used to link the kernel object files, and for storing it, is configuration dependent. Therefore, if you say Y here, you must know the proper physical address where to store the kernel image depending on your own flash memory usage. Also note that the make target becomes "make xipImage" rather than "make zImage" or "make Image". The final kernel binary to put in ROM memory will be arch/riscv/boot/xipImage. SPARSEMEM is required because the kernel text and rodata that are flash resident are not backed by memmap, then any attempt to get a struct page on those regions will trigger a fault. If unsure, say N.
This is the physical address in your flash memory the kernel will be linked for and stored to. This address is dependent on your own flash usage.