On Fri, Jan 5, 2018 at 7:22 PM, Michael Clark <m...@sifive.com> wrote:
> > On Fri, 5 Jan 2018 at 5:55 AM, Antony Pavlov <antonynpav...@gmail.com> > wrote: > >> On Wed, 3 Jan 2018 13:44:25 +1300 >> Michael Clark <m...@sifive.com> wrote: >> >> > This adds RISC-V into the build system enabling the following targets: >> > >> > - riscv32-softmmu >> > - riscv64-softmmu >> > - riscv32-linux-user >> > - riscv64-linux-user >> > >> >> ... >> >> > diff --git a/default-configs/riscv32-softmmu.mak >> b/default-configs/riscv32-softmmu.mak >> > new file mode 100644 >> > index 0000000..f9e7421 >> > --- /dev/null >> > +++ b/default-configs/riscv32-softmmu.mak >> > @@ -0,0 +1,4 @@ >> > +# Default configuration for riscv-softmmu >> > + >> > +CONFIG_SERIAL=y >> > +CONFIG_VIRTIO=y >> > diff --git a/default-configs/riscv64-linux-user.mak >> b/default-configs/riscv64-linux-user.mak >> > new file mode 100644 >> > index 0000000..865b362 >> > --- /dev/null >> > +++ b/default-configs/riscv64-linux-user.mak >> > @@ -0,0 +1 @@ >> > +# Default configuration for riscv-linux-user >> > diff --git a/default-configs/riscv64-softmmu.mak >> b/default-configs/riscv64-softmmu.mak >> > new file mode 100644 >> > index 0000000..f9e7421 >> > --- /dev/null >> > +++ b/default-configs/riscv64-softmmu.mak >> > @@ -0,0 +1,4 @@ >> > +# Default configuration for riscv-softmmu >> > + >> > +CONFIG_SERIAL=y >> > +CONFIG_VIRTIO=y >> > diff --git a/hw/riscv/Makefile.objs b/hw/riscv/Makefile.objs >> > new file mode 100644 >> > index 0000000..a0c31ae >> > --- /dev/null >> > +++ b/hw/riscv/Makefile.objs >> > @@ -0,0 +1,12 @@ >> > +obj-y += riscv_elf.o >> > +obj-y += riscv_htif.o >> > +obj-y += riscv_hart.o >> > +obj-y += sifive_e300.o >> > +obj-y += sifive_clint.o >> > +obj-y += sifive_prci.o >> > +obj-y += sifive_plic.o >> > +obj-y += sifive_u500.o >> > +obj-y += sifive_uart.o >> > +obj-y += spike_v1_09.o >> > +obj-y += spike_v1_10.o >> > +obj-y += virt.o >> >> According to https://www.sifive.com/products/freedom/ >> Freedom E300 Platform uses RV32IMAC Architecture >> and Freedom U500 Platform uses RV64GC Architecture. >> >> Which means that qemu-system-riscv32 has to have E300 support but not >> U500 support. >> qemu-system-riscv64 has to have U500 support but not E300 support. >> >> However please see this log: >> >> riscv-qemu$ ./riscv32-softmmu/qemu-system-riscv32 -M ? >> Supported machines are: >> none empty machine >> sifive_e300 RISC-V Board compatible with SiFive E300 SDK >> sifive_u500 RISC-V Board compatible with SiFive U500 SDK <<<<<< >> U500 in 32-bit mode >> spike_v1.10 RISC-V Spike Board (Privileged ISA v1.10) >> spike_v1.9 RISC-V Spike Board (Privileged ISA v1.9.1) (default) >> virt RISC-V VirtIO Board (Privileged spec v1.10) >> riscv-qemu$ ./riscv64-softmmu/qemu-system-riscv64 -M ? >> Supported machines are: >> none empty machine >> sifive_e300 RISC-V Board compatible with SiFive E300 SDK <<<<<< >> E300 in 64-bit mode >> sifive_u500 RISC-V Board compatible with SiFive U500 SDK >> spike_v1.10 RISC-V Spike Board (Privileged ISA v1.10) >> spike_v1.9 RISC-V Spike Board (Privileged ISA v1.9.1) (default) >> virt RISC-V VirtIO Board (Privileged spec v1.10) >> >> I propose at least this fixup: >> >> diff --git a/default-configs/riscv32-softmmu.mak >> b/default-configs/riscv32-softmmu.mak >> index f9e742120c..6a807f5f96 100644 >> --- a/default-configs/riscv32-softmmu.mak >> +++ b/default-configs/riscv32-softmmu.mak >> @@ -1,4 +1,5 @@ >> -# Default configuration for riscv-softmmu >> +# Default configuration for riscv32-softmmu >> >> CONFIG_SERIAL=y >> CONFIG_VIRTIO=y >> +CONFIG_SIFIVE_E300=y >> diff --git a/default-configs/riscv64-softmmu.mak >> b/default-configs/riscv64-softmmu.mak >> index f9e742120c..1a0349fe27 100644 >> --- a/default-configs/riscv64-softmmu.mak >> +++ b/default-configs/riscv64-softmmu.mak >> @@ -1,4 +1,5 @@ >> -# Default configuration for riscv-softmmu >> +# Default configuration for riscv64-softmmu >> >> CONFIG_SERIAL=y >> CONFIG_VIRTIO=y >> +CONFIG_SIFIVE_U500=y >> diff --git a/hw/riscv/Makefile.objs b/hw/riscv/Makefile.objs >> index a0c31ae25e..bac5faa603 100644 >> --- a/hw/riscv/Makefile.objs >> +++ b/hw/riscv/Makefile.objs >> @@ -1,11 +1,11 @@ >> obj-y += riscv_elf.o >> obj-y += riscv_htif.o >> obj-y += riscv_hart.o >> -obj-y += sifive_e300.o >> +obj-$(CONFIG_SIFIVE_E300) += sifive_e300.o >> obj-y += sifive_clint.o >> obj-y += sifive_prci.o >> obj-y += sifive_plic.o >> -obj-y += sifive_u500.o >> +obj-$(CONFIG_SIFIVE_U500) += sifive_u500.o >> obj-y += sifive_uart.o >> obj-y += spike_v1_09.o >> obj-y += spike_v1_10.o > > > I’ll check whether there are 64-bit E series chips. Actually the key > distinction is no MMU and we don’t yet disable the MMU in the machine. > > I’ll ask SiFive whether they want to restrict the “bitness”. There is > actually no reason why the machine can’t be invoked as 64-bit. > > As far as I know the RTL is parametiazable and the 32-bit cores are > generated from the same RTL source using the rocket chip generator however > that’s something i’ll have to check. i.e. we may not want to restrict the > options here. > > The machines are deliberately called E300 and U500 to refer to a generic > series and in future there will be a machine with the U54-MC which is a > particular instantiation. So in that respect the “series” machines are > generic. > > It’s on our todo list to add support to disable the MMU but HiFive1 > binaries will run anyway because they don’t touch the ‘satp’ CSR and take > the cpu out of Mbare adressing mode. I’d rank disabling the MMU on the E > series as a higher priority than restricting bitness. > > In any case i’ll check if SiFive can parameterize a 64-bit E series with > no MMU, tightly coupled memory, etc. I can’t tell that for sure until I ask. > > A HiFive1 machine of course should be 32-bit only, when we add one, but > the generic E series machine can run 32-bit HiFive1 binaries when invoked > using qemu-system-riscv32 > > I’ll ask... > - E series has no MMU and can be either 32-bit or 64-bit, however, E3xx is 32-bit and E5xx is 64-bit. There is a 64-bit E series here: - https://github.com/sifive/freedom-e-sdk/tree/master/bsp/env/coreplexip-e51-arty We'll have to think about naming these machines. We could either add a sifive_e500.c and add appropriate bit-width restrictions or make the boards more generic. Also, the current port has two distinct compile time targets for 32-bit and 64-bit, however, we may eventually handle runtime changes to MXL/SXL/UXL as the spec allows dual bit-width machines. If we support runtime bit-width changes, I wonder if we would still continue to have two separate targets e.g. qemu-system-riscv32 and qemu-system-riscv64 which also supports 32-bit mode via the misa.MXL and mstatus.SXL/UXL bits. I guess keeping the two targets is the path of least resistance (with qemu-system-riscv64 also supporting 32-bit) as many scripts already depend on these names. The user-mode simulators will of course not support runtime bit-width changes.
