[PATCH v5 2/3] Documentation: riscv: Add early boot document

[Randy Dunlap]

Hi,

On 7/22/23 04:34, Alexandre Ghiti wrote:
> This document describes the constraints and requirements of the early
> boot process in a RISC-V kernel.
> 
> Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
> Reviewed-by: Björn Töpel <bjorn at rivosinc.com>
> Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
> Reviewed-by: Sunil V L <sunilvl at ventanamicro.com>
> Reviewed-by: Andrew Jones <ajones at ventanamicro.com>
> Reviewed-by: Palmer Dabbelt <palmer at rivosinc.com>
> Reviewed-by: Atish Patra <atishp at rivosinc.com>
> Reviewed-by: Song Shuai <songshuaishuai at tinylab.org>
> Acked-by: Palmer Dabbelt <palmer at rivosinc.com>
> ---
> - Changes in v5:
>   * Rebase on top of docs-next
> 
>  Documentation/riscv/boot-image-header.rst |   3 -
>  Documentation/riscv/boot.rst              | 169 ++++++++++++++++++++++
>  Documentation/riscv/index.rst             |   1 +
>  3 files changed, 170 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/riscv/boot.rst
> 

> diff --git a/Documentation/riscv/boot.rst b/Documentation/riscv/boot.rst
> new file mode 100644
> index 000000000000..f890ac442c91
> --- /dev/null
> +++ b/Documentation/riscv/boot.rst
> @@ -0,0 +1,169 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===============================================
> +RISC-V Kernel Boot Requirements and Constraints
> +===============================================
> +
> +:Author: Alexandre Ghiti <alexghiti at rivosinc.com>
> +:Date: 23 May 2023
> +
> +This document describes what the RISC-V kernel expects from bootloaders and
> +firmware, but also the constraints that any developer must have in mind when

I would s/but/and/.

> +touching the early boot process. For the purposes of this document, the
> +``early boot process`` refers to any code that runs before the final virtual
> +mapping is set up.
> +
> +Pre-kernel Requirements and Constraints
> +=======================================
> +
> +The RISC-V kernel expects the following of bootloaders and platform firmware:
> +
> +Register state
> +--------------
> +
> +The RISC-V kernel expects:
> +
> +  * ``$a0`` to contain the hartid of the current core.
> +  * ``$a1`` to contain the address of the devicetree in memory.
> +
> +CSR state
> +---------
> +
> +The RISC-V kernel expects:
> +
> +  * ``$satp = 0``: the MMU, if present, must be disabled.
> +
> +Reserved memory for resident firmware
> +-------------------------------------
> +
> +The RISC-V kernel must not map any resident memory, or memory protected with
> +PMPs, in the direct mapping, so the firmware must correctly mark those regions
> +as per the devicetree specification and/or the UEFI specification.
> +
> +Kernel location
> +---------------
> +
> +The RISC-V kernel expects to be placed at a PMD boundary (2MB aligned for rv64
> +and 4MB aligned for rv32). Note that the EFI stub will physically relocate the
> +kernel if that's not the case.
> +
> +Hardware description
> +--------------------
> +
> +The firmware can pass either a devicetree or ACPI tables to the RISC-V kernel.
> +
> +The devicetree is either passed directly to the kernel from the previous stage
> +using the ``$a1`` register, or when booting with UEFI, it can be passed using the
> +EFI configuration table.
> +
> +The ACPI tables are passed to the kernel using the EFI configuration table. In
> +this case, a tiny devicetree is still created by the EFI stub. Please refer to
> +"EFI stub and devicetree" section below for details about this devicetree.
> +
> +Kernel entrance
> +---------------

How about "entry" instead of "entrance"?

> +
> +On SMP systems, there are 2 methods to enter the kernel:
> +
> +- ``RISCV_BOOT_SPINWAIT``: the firmware releases all harts in the kernel, one hart
> +  wins a lottery and executes the early boot code while the other harts are
> +  parked waiting for the initialization to finish. This method is mostly used to
> +  support older firmwares without SBI HSM extension and M-mode RISC-V kernel.
> +- ``Ordered booting``: the firmware releases only one hart that will execute the
> +  initialization phase and then will start all other harts using the SBI HSM
> +  extension. The ordered booting method is the preferred booting method for
> +  booting the RISC-V kernel because it can support cpu hotplug and kexec.

preferably s/cpu/CPU/

> +
> +UEFI
> +----

[snip]

I can't say how correct the documentation is, but it is well-written
and has no issues with punctuation, grammar, or spelling AFAICT, so
you can take this if you want it:

Reviewed-by: Randy Dunlap <rdunlap at infradead.org>

thanks.
-- 
~Randy