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@xxxxxxxxxxxx> > Reviewed-by: Björn Töpel <bjorn@xxxxxxxxxxxx> > Reviewed-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> > Reviewed-by: Sunil V L <sunilvl@xxxxxxxxxxxxxxxx> > Reviewed-by: Andrew Jones <ajones@xxxxxxxxxxxxxxxx> > Reviewed-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx> > Reviewed-by: Atish Patra <atishp@xxxxxxxxxxxx> > Reviewed-by: Song Shuai <songshuaishuai@xxxxxxxxxxx> > Acked-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx> > --- > - 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@xxxxxxxxxxxx> > +: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@xxxxxxxxxxxxx> thanks. -- ~Randy
