Hi Randy, On Sat, Jul 22, 2023 at 10:19 PM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > > 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/. Ok I change that, thanks. > > > +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"? I have to admit that I don't have the nuance between both words, if 'entry' is more appropriate, I'll change it. > > > + > > +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/ Done! > > > + > > +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 for the nice comments, @Conor Dooley (and others) really helped! I'll respin a new version today, Alex > > thanks. > -- > ~Randy
