hw/riscv/sifive_u.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Correct mmu-type property of sifive_u harts from Sv48 to Sv39 in 64-bit
mode since it's the only supported SATP mode.
Signed-off-by: Zejun Zhao <jelly.zhao.42@gmail.com>
---
hw/riscv/sifive_u.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index d69f942cfb..3e1ed209ca 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -176,7 +176,7 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry *memmap,
if (is_32_bit) {
qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv32");
} else {
- qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv48");
+ qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv39");
}
riscv_isa_write_fdt(&s->soc.u_cpus.harts[cpu - 1], fdt, nodename);
} else {
--
2.43.0
On Tue, Oct 14, 2025 at 1:00 AM Zejun Zhao <jelly.zhao.42@gmail.com> wrote:
>
> Correct mmu-type property of sifive_u harts from Sv48 to Sv39 in 64-bit
> mode since it's the only supported SATP mode.
>
> Signed-off-by: Zejun Zhao <jelly.zhao.42@gmail.com>
Thanks!
Applied to riscv-to-apply.next
Alistair
> ---
> hw/riscv/sifive_u.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index d69f942cfb..3e1ed209ca 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -176,7 +176,7 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry *memmap,
> if (is_32_bit) {
> qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv32");
> } else {
> - qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv48");
> + qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv39");
> }
> riscv_isa_write_fdt(&s->soc.u_cpus.harts[cpu - 1], fdt, nodename);
> } else {
> --
> 2.43.0
>
>
On 10/13/25 10:32 AM, Zejun Zhao wrote:
> Correct mmu-type property of sifive_u harts from Sv48 to Sv39 in 64-bit
> mode since it's the only supported SATP mode.
>
> Signed-off-by: Zejun Zhao <jelly.zhao.42@gmail.com>
> ---
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
> hw/riscv/sifive_u.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index d69f942cfb..3e1ed209ca 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -176,7 +176,7 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry *memmap,
> if (is_32_bit) {
> qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv32");
> } else {
> - qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv48");
> + qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv39");
> }
> riscv_isa_write_fdt(&s->soc.u_cpus.harts[cpu - 1], fdt, nodename);
> } else {
(Ccing Max)
On 10/13/25 10:32 AM, Zejun Zhao wrote:
> Correct mmu-type property of sifive_u harts from Sv48 to Sv39 in 64-bit
> mode since it's the only supported SATP mode.
>
> Signed-off-by: Zejun Zhao <jelly.zhao.42@gmail.com>
> ---
> hw/riscv/sifive_u.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
> index d69f942cfb..3e1ed209ca 100644
> --- a/hw/riscv/sifive_u.c
> +++ b/hw/riscv/sifive_u.c
> @@ -176,7 +176,7 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry *memmap,
> if (is_32_bit) {
> qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv32");
> } else {
> - qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv48");
> + qemu_fdt_setprop_string(fdt, nodename, "mmu-type", "riscv,sv39");
Just checked the SATP mode of the SIFIVE_U cpu in target/riscv/cpu.c:
DEFINE_ABSTRACT_RISCV_CPU(TYPE_RISCV_CPU_SIFIVE_U, TYPE_RISCV_VENDOR_CPU,
.misa_ext = RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU,
.priv_spec = PRIV_VERSION_1_10_0,
.cfg.max_satp_mode = VM_1_10_SV39, <=================
But the documentation I found [1] seems to indicate that it should support sv48. Maybe
we're modelling the wrong satp mode in the CPU. Max, can you comment on it?
As for the patch it looks fine, assuming that we're always going to run a sv39 CPU with
it. Otherwise we could do what we're doing in the 'virt' board:
(in create_fdt_socket_cpus(): )
if (satp_mode_max != -1) {
sv_name = g_strdup_printf("riscv,%s",
satp_mode_str(satp_mode_max, is_32_bit));
qemu_fdt_setprop_string(ms->fdt, cpu_name, "mmu-type", sv_name);
}
I.e. we would use the CPU satp mode instead of hardcoding it in the board.
Thanks,
Daniel
[1] https://starfivetech.com/uploads/u54_core_complex_manual_21G1.pdf , Table 9
> }
> riscv_isa_write_fdt(&s->soc.u_cpus.harts[cpu - 1], fdt, nodename);
> } else {
On Mon, 13 Oct 2025 11:38:48 -0300, Daniel wrote: > But the documentation I found [1] seems to indicate that it should > support sv48. The second paragraph after the referenced Table 9 from [1] states: > For RV64 architectures on SiFive designs,satp.MODE=8 is used for Sv39 > virtual addressing, and no other modes are currently supported. And here is the same statement from [1]: > The U5 has support for virtual memory through the use of a Memory > Management Unit (MMU). The MMU supports the Bare and Sv39 modes as > described inThe RISC‑V Instruction Set Man-ual, Volume II: Privileged > Architecture, Version 1.10. So I believe we should not try to support Sv48 for this hart. Hardcoding it to Sv39 should be fine and correct. Regards, Zejun [1] https://starfivetech.com/uploads/u54_core_complex_manual_21G1.pdf
On 10/13/25 12:43 PM, Zejun Zhao wrote: > On Mon, 13 Oct 2025 11:38:48 -0300, Daniel wrote: >> But the documentation I found [1] seems to indicate that it should >> support sv48. > > The second paragraph after the referenced Table 9 from [1] states: >> For RV64 architectures on SiFive designs,satp.MODE=8 is used for Sv39 >> virtual addressing, and no other modes are currently supported. > > And here is the same statement from [1]: >> The U5 has support for virtual memory through the use of a Memory >> Management Unit (MMU). The MMU supports the Bare and Sv39 modes as >> described inThe RISC‑V Instruction Set Man-ual, Volume II: Privileged >> Architecture, Version 1.10. > > So I believe we should not try to support Sv48 for this hart. Hardcoding > it to Sv39 should be fine and correct. Makes sense. I believe we can proceed with the changes then. Thanks, Daniel > > Regards, > > Zejun > > [1] https://starfivetech.com/uploads/u54_core_complex_manual_21G1.pdf
© 2016 - 2025 Red Hat, Inc.