starfive-tech/linux.git/Documentation/arm64/booting.rst, branch rt-linux-release

arm64: Document the requirement for SCR_EL3.HCE

2021-08-24T15:44:23+00:00

It is amazing that we never documented this absolutely basic requirement: if you boot the kernel at EL2, you'd better enable the HVC instruction from EL3. Really, just do it. Signed-off-by: Marc Zyngier Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20210812190213.2601506-6-maz@kernel.org Signed-off-by: Catalin Marinas

arm64/sme: Document boot requirements for SME

2021-08-02T10:05:24+00:00

Document our requirements for initialisation of the Scalable Matrix Extension (SME) at kernel start. While we do have the ability to handle mismatched vector lengths we will reject any late CPUs that can't support the minimum set we determine at boot so for clarity we document a requirement that all CPUs make the same vector length available. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210720204220.22951-1-broonie@kernel.org Signed-off-by: Catalin Marinas

arm64: Document requirement for access to FEAT_HCX

2021-05-25T18:05:28+00:00

v8.7 of the architecture introduced FEAT_HCX which adds an additional hypervisor configuration register HCRX_EL2. Even though Linux does not currently make use of this feature let's document that the EL3 trap for access to the register should be disabled so that we are able to make use of it in future. Signed-off-by: Mark Brown Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/20210512162350.20349-1-broonie@kernel.org Signed-off-by: Will Deacon

arm64: Explicitly document boot requirements for SVE

2021-04-30T17:53:43+00:00

We do not currently document the requirements for configuration of the SVE system registers when booting the kernel, let's do so for completeness. We don't have a hard requirement that the vector lengths configured on different CPUs on initial boot be consistent since we have logic to constrain to the minimum supported value but we will reject any late CPUs which can't support the current maximum and introducing the concept of late CPUs seemed more complex than was useful so we require that all CPUs use the same value. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210412151955.16078-4-broonie@kernel.org Signed-off-by: Catalin Marinas

arm64: Explicitly require that FPSIMD instructions do not trap

2021-04-30T17:53:43+00:00

We do not explicitly require that systems with FPSIMD support and EL3 have disabled EL3 traps when the kernel is started, while it is unlikely that systems will get this wrong for the sake of completeness let's spell it out. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210412151955.16078-3-broonie@kernel.org Signed-off-by: Catalin Marinas

arm64: Relax booting requirements for configuration of traps

2021-04-30T17:53:42+00:00

Currently we require that a number of system registers be configured to disable traps when starting the kernel. Add an explicit note that the requirement is that the system behave as if the traps are disabled so transparent handling of the traps is fine, this should be implicit for people familiar with working with standards documents but it doesn't hurt to be explicit. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210412151955.16078-2-broonie@kernel.org Signed-off-by: Catalin Marinas

arm64: Require that system registers at all visible ELs be initialized

2021-04-08T17:39:18+00:00

Currently we require that software at a higher exception level initialise all registers at the exception level the kernel will be entered prior to starting the kernel in order to ensure that there is nothing uninitialised which could result in an UNKNOWN state while running the kernel. The expectation is that the software running at the highest exception levels will be tightly coupled to the system and can ensure that all available features are appropriately initialised and that the kernel can initialise anything else. There is a gap here in the case where new registers are added to lower exception levels that require initialisation but the kernel does not yet understand them. Extend the requirement to also include exception levels below the one where the kernel is entered to cover this. Suggested-by: Catalin Marinas Signed-off-by: Mark Brown Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20210401180942.35815-4-broonie@kernel.org Signed-off-by: Catalin Marinas

arm64: Document requirements for fine grained traps at boot

2021-04-08T17:39:17+00:00

The arm64 FEAT_FGT extension introduces a set of traps to EL2 for accesses to small sets of registers and instructions from EL1 and EL0, access to which is controlled by EL3. Require access to it so that it is available to us in future and so that we can ensure these traps are disabled during boot. Signed-off-by: Mark Brown Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20210401180942.35815-2-broonie@kernel.org Signed-off-by: Catalin Marinas

Merge tag 'docs-5.8' of git://git.lwn.net/linux

2020-06-01T22:45:27+00:00

Pull documentation updates from Jonathan Corbet: "A fair amount of stuff this time around, dominated by yet another massive set from Mauro toward the completion of the RST conversion. I *really* hope we are getting close to the end of this. Meanwhile, those patches reach pretty far afield to update document references around the tree; there should be no actual code changes there. There will be, alas, more of the usual trivial merge conflicts. Beyond that we have more translations, improvements to the sphinx scripting, a number of additions to the sysctl documentation, and lots of fixes" * tag 'docs-5.8' of git://git.lwn.net/linux: (130 commits) Documentation: fixes to the maintainer-entry-profile template zswap: docs/vm: Fix typo accept_threshold_percent in zswap.rst tracing: Fix events.rst section numbering docs: acpi: fix old http link and improve document format docs: filesystems: add info about efivars content Documentation: LSM: Correct the basic LSM description mailmap: change email for Ricardo Ribalda docs: sysctl/kernel: document unaligned controls Documentation: admin-guide: update bug-hunting.rst docs: sysctl/kernel: document ngroups_max nvdimm: fixes to maintainter-entry-profile Documentation/features: Correct RISC-V kprobes support entry Documentation/features: Refresh the arch support status files Revert "docs: sysctl/kernel: document ngroups_max" docs: move locking-specific documents to locking/ docs: move digsig docs to the security book docs: move the kref doc into the core-api book docs: add IRQ documentation at the core-api book docs: debugging-via-ohci1394.txt: add it to the core-api book docs: fix references for ipmi.rst file ...

arm64: docs: Mandate that the I-cache doesn't hold stale kernel text

2020-04-28T13:24:10+00:00

Although we require that the loaded kernel Image has been cleaned to the PoC, we neglect to spell out the state of the I-cache. Although this should be reasonably obvious, it doesn't hurt to be explicit. Require that the I-cache doesn't hold any stale entries for the kernel Image at boot. Acked-by: Mark Rutland Acked-by: Catalin Marinas Cc: Mark Rutland Cc: Catalin Marinas Link: https://lore.kernel.org/r/20200423093658.10602-1-will@kernel.org Signed-off-by: Will Deacon