Currently 256 bytes is used for the FDT expand size when fixing up
reserved memory node. Increase it to 1024 bytes with an estimated
size of 64 bytes per PMP memory region by 16 regions in total.
Signed-off-by: Bin Meng <bin.meng@windriver.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
This is achieved by removing the 'no-map' property from the
'reserved-memory' node when PMP is present, otherwise we keep it as it
offers a small protection if the OS does not map this region at all.
A new callback in platform_override is introduced and allows to fixup the
device-tree. It is used here to override this new default behaviour on
SiFive Fu540 platforms that has an erratum that prevents S-mode software
to access a PMP protected region using 1GB page table mapping.
If PMP is present, telling the OS not to map the reserved regions does not
add much protection since it only avoids access to regions that are already
protected by PMP. But by not allowing the OS to map those regions, it
creates holes in the OS system memory map and prevents the use of
hugepages which would generate, among other benefits, less TLB miss.
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Anup Patel <anup.patel@wdc.com>
It is not mandatory for a RISC-V systems to implement all PMP
regions so we have to check all PMPADDRx CSRs to determine excat
number of supported PMP regions.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
It makes more sense to have scratch pointer as parameter in
HART feature APIs because:
1. We already have scratch pointer at places where these APIs
are used.
2. This is consistent with lot of other APIs in sbi_hart.h
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
PMP & performance counters belong to a hart rather than a platform.
In addition to that, these features enable reading/writing from a
particular csr. Thus, they can be detected and set at runtime rather
than compile time.
Move PMP/MCOUNTEREN/SCOUNTEREN features to hart and detect them at runtime.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Tested-by: Jonathan Balkind <jbalkind@cs.princeton.edu>
Reviewed-by: Anup Patel <anup.patel@wdc.com>
As per RISC-V ISA, pmp is not mandatory. Currently, we only add reserved
memory node in DT only if PMP is present. That allows supervisor to access
the memory where OpenSBI continue to exist without realizing it for non-pmp
based platforms. It may result in corrupting OpenSBI. That's why OpenSBI
should at least let the supervisor know where it continue to exist.
This a best effort service provided by OpenSBI expecting that supervisor
software is not buggy and properly sets up its memory after parsing the
reserved-memory device tree node.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Anup Patel <anup.patel@wdc.com>
Parsing HART id from a CPU DT node is a common requirement for
RISC-V systems. The newly added fdt_parse_hart_id() also helps
reduce duplicate code between fdt_cpu_fixup() function and
fdt_parse_hart_count() function.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Currently, the fdt_cpu_fixup() implementation assumes:
1. We have one CPU DT for each HART under /cpus DT node
2. The CPU DT nodes are named sequentially (i.e cpu@0,
cpu@1, ...) which is not true for discontinuous and
sparse HART ids (i.e. cpu@0, cpu@4, cpu@5). Generally,
CPU DT node are named based on HART id and not HART
index
If any of the above assumptions are violated then the
fdt_cpu_fixup() will not work.
This improves fdt_cpu_fixup() implementation and makes
it independent of above assumptions.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Atish Patra <atish.patra@wdc.com>
FDT helper file contain both fdt fixup and parsing functions.
Split the fixup related functions to a separate file for a better code
organization.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Reviewed-by: Anup Patel <anup.patel@wdc.com>
