default-configs/riscv32-softmmu.mak | 2 + default-configs/riscv64-softmmu.mak | 2 + hw/riscv/sifive_e.c | 99 +++++++++++++++++------- hw/riscv/sifive_plic.c | 6 +- hw/riscv/sifive_u.c | 148 +++++++++++++++++++++++++++++------- hw/riscv/virt.c | 4 +- include/hw/riscv/sifive_e.h | 16 +++- include/hw/riscv/sifive_plic.h | 1 - include/hw/riscv/sifive_u.h | 25 +++++- 9 files changed, 235 insertions(+), 68 deletions(-)
The following changes since commit cee35138b59c6d6b0808c5fa644e3f063832860f:
Merge remote-tracking branch 'remotes/stsquad/tags/pull-code-coverage-and-build-tweaks-050718-3' into staging (2018-07-05 18:24:28 +0100)
are available in the Git repository at:
git@github.com:alistair23/qemu.git tags/pull-riscv-pull-20180705
for you to fetch changes up to 5a7f76a3d47a75290868968682c0585d380764a4:
hw/riscv/sifive_u: Connect the Cadence GEM Ethernet device (2018-07-05 15:24:25 -0700)
----------------------------------------------------------------
RISC-V: SoCify SiFive boards and connect GEM
This series has three tasks:
1. To convert the SiFive U and E machines into SoCs and boards
2. To connect the Cadence GEM device to the SiFive U board
3. Fix some device tree problems with the SiFive U board
After this series the SiFive E and U boards have their SoCs split into
seperate QEMU objects, which can be used on future boards if desired.
The RISC-V Virt and Spike boards have not been converted. They haven't
been converted as they aren't physical boards, so it doesn't make a
whole lot of sense to split them into an SoC and board. The only
disadvantage with this is that they now differ to the SiFive boards.
This series also connect the Cadence GEM device to the SiFive U board.
There are some interrupt line changes requried before this is possible.
----------------------------------------------------------------
Alistair Francis (7):
hw/riscv/sifive_u: Create a SiFive U SoC object
hw/riscv/sifive_e: Create a SiFive E SoC object
hw/riscv/sifive_plic: Use gpios instead of irqs
hw/riscv/sifive_u: Set the soc device tree node as a simple-bus
hw/riscv/sifive_u: Set the interrupt controller number of interrupts
hw/riscv/sifive_u: Move the uart device tree node under /soc/
hw/riscv/sifive_u: Connect the Cadence GEM Ethernet device
default-configs/riscv32-softmmu.mak | 2 +
default-configs/riscv64-softmmu.mak | 2 +
hw/riscv/sifive_e.c | 99 +++++++++++++++++-------
hw/riscv/sifive_plic.c | 6 +-
hw/riscv/sifive_u.c | 148 +++++++++++++++++++++++++++++-------
hw/riscv/virt.c | 4 +-
include/hw/riscv/sifive_e.h | 16 +++-
include/hw/riscv/sifive_plic.h | 1 -
include/hw/riscv/sifive_u.h | 25 +++++-
9 files changed, 235 insertions(+), 68 deletions(-)
On 6 July 2018 at 02:22, Alistair Francis <alistair.francis@wdc.com> wrote: > The following changes since commit cee35138b59c6d6b0808c5fa644e3f063832860f: > > Merge remote-tracking branch 'remotes/stsquad/tags/pull-code-coverage-and-build-tweaks-050718-3' into staging (2018-07-05 18:24:28 +0100) > > are available in the Git repository at: > > git@github.com:alistair23/qemu.git tags/pull-riscv-pull-20180705 > > for you to fetch changes up to 5a7f76a3d47a75290868968682c0585d380764a4: > > hw/riscv/sifive_u: Connect the Cadence GEM Ethernet device (2018-07-05 15:24:25 -0700) > > ---------------------------------------------------------------- > RISC-V: SoCify SiFive boards and connect GEM > > This series has three tasks: > 1. To convert the SiFive U and E machines into SoCs and boards > 2. To connect the Cadence GEM device to the SiFive U board > 3. Fix some device tree problems with the SiFive U board > > After this series the SiFive E and U boards have their SoCs split into > seperate QEMU objects, which can be used on future boards if desired. > > The RISC-V Virt and Spike boards have not been converted. They haven't > been converted as they aren't physical boards, so it doesn't make a > whole lot of sense to split them into an SoC and board. The only > disadvantage with this is that they now differ to the SiFive boards. > > This series also connect the Cadence GEM device to the SiFive U board. > There are some interrupt line changes requried before this is possible. Applied, thanks. -- PMM
What is the state of the sifive_u emulation? When I tried to boot a bbl with an included kernel I get these errors: qemu-system-riscv64: plic: invalid register write: 00002090 qemu-system-riscv64: plic: invalid register write: 00002094 qemu-system-riscv64: plic: invalid register write: 00002098 qemu-system-riscv64: plic: invalid register write: 0000209c qemu-system-riscv64: plic: invalid register write: 000020a0 qemu-system-riscv64: plic: invalid register write: 000020a4 qemu-system-riscv64: plic: invalid register write: 000020a8 qemu-system-riscv64: plic: invalid register write: 000020ac qemu-system-riscv64: plic: invalid register write: 000020b0 qemu-system-riscv64: plic: invalid register write: 000020b4 Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On Mon, Jul 9, 2018 at 3:00 AM, Andreas Schwab <schwab@suse.de> wrote: > What is the state of the sifive_u emulation? When I tried to boot a bbl > with an included kernel I get these errors: > > qemu-system-riscv64: plic: invalid register write: 00002090 > qemu-system-riscv64: plic: invalid register write: 00002094 > qemu-system-riscv64: plic: invalid register write: 00002098 > qemu-system-riscv64: plic: invalid register write: 0000209c > qemu-system-riscv64: plic: invalid register write: 000020a0 > qemu-system-riscv64: plic: invalid register write: 000020a4 > qemu-system-riscv64: plic: invalid register write: 000020a8 > qemu-system-riscv64: plic: invalid register write: 000020ac > qemu-system-riscv64: plic: invalid register write: 000020b0 > qemu-system-riscv64: plic: invalid register write: 000020b4 I see those as well. I haven't investigated but I assume we are just not completely modelling the PLIC. In saying that it should still boot. Do you not see the kernel booting? Alistair > > Andreas. > > -- > Andreas Schwab, SUSE Labs, schwab@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different."
On Tue, Jul 10, 2018 at 9:52 AM, Alistair Francis <alistair23@gmail.com> wrote: > On Mon, Jul 9, 2018 at 3:00 AM, Andreas Schwab <schwab@suse.de> wrote: > > What is the state of the sifive_u emulation? When I tried to boot a bbl > > with an included kernel I get these errors: > > > > qemu-system-riscv64: plic: invalid register write: 00002090 > > qemu-system-riscv64: plic: invalid register write: 00002094 > > qemu-system-riscv64: plic: invalid register write: 00002098 > > qemu-system-riscv64: plic: invalid register write: 0000209c > > qemu-system-riscv64: plic: invalid register write: 000020a0 > > qemu-system-riscv64: plic: invalid register write: 000020a4 > > qemu-system-riscv64: plic: invalid register write: 000020a8 > > qemu-system-riscv64: plic: invalid register write: 000020ac > > qemu-system-riscv64: plic: invalid register write: 000020b0 > > qemu-system-riscv64: plic: invalid register write: 000020b4 > > I see those as well. I haven't investigated but I assume we are just > not completely modelling the PLIC. In saying that it should still > boot. Do you not see the kernel booting? It could be a PLIC bug or it could be a Linux interrupt controller driver bug. We can see from the memory map docs for the U54 whether these memory addresses are in bounds based on the number of configured interrupt sources. I'm not sure how many sources we have configured on sifive_u. Last time I booted Linux on sifive_u I did not see these errors. I'd need your kernel config and to know what tree and branch you are building from. I will be able to look when I get time... The PLIC however seems stable in the 'virt' board at least... Sorry I've been incommunicado for several weeks. I have been working on a CLIC model (Core Local Interrupt Controller) which replaces the CLINT and has a CLINT backwards compatibility mode. It is a Core Local vs the PLIC which is the Platform Level router. Here is the "draft" spec. It will be a candidate proposed to the RISC-V Fast Interrupts working group for potential standardisation, however in any case it will be available from SiFive so we may eventuall want to include our implementation in QEMU: - https://github.com/sifive/clic-spec/blob/master/clic.adoc When i'm done with modelling the first iteration of the CLIC I'll go through my pending patch queue and make a PR for the Reviewed patches. I'll also do some testing on master to make sure we have not regressed anything in RISC-V QEMU given QEMU 2.12 and the riscv-qemu trees are both stable. BTW - with respect to 'sifive_e' and 'sifive_u' SOC changes, we'll have to see how the model matches SiFive's plans for these virtual machines. We want to avoid a proliferation of boards, and as I've mentioned before we want to be able to model the HiFive1, HiFiveU and other SiFive E Series and U Series Coreplex configurations. There are many permutations from SiFive's SOC generator so our goal is to avoid hardcoding all of the different SOC combinations (hence the removal of model numbers in my initial review of your patches). How we achieve this I do not know. We obviously want to invest our time in something that is acceptable to upstream, while also meeting the goal of modelling SiFive's many hardware configurations, given these boards also model softcore IP such as the e31 arty and u54 on Xilinx VC707. i.e. they are SiFive models. I'm not too concerned with the SOC changes assuming we don't regress any function, as we can always evolve the code in the future to match configurations from SiFive's SOC generator. At present the models are like a union of a subset of the real hardware as we are still missing many emulation models for various parts of the SOCs. After i've finished up this CLIC work, I'll go back through the list of things we still need to model. Adding the Cadence GEM to the SiFive U Series is really nice, and so is adding Xilinx PCI to the SiFive U and GPEX to virt (as discussed, given virt is generic, we want to use GPEX there). Thanks, Michael. > > > Andreas. > > > > -- > > Andreas Schwab, SUSE Labs, schwab@suse.de > > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > > "And now for something completely different." >
On Mon, 09 Jul 2018 16:04:48 PDT (-0700), Michael Clark wrote: > On Tue, Jul 10, 2018 at 9:52 AM, Alistair Francis <alistair23@gmail.com> > wrote: > >> On Mon, Jul 9, 2018 at 3:00 AM, Andreas Schwab <schwab@suse.de> wrote: >> > What is the state of the sifive_u emulation? When I tried to boot a bbl >> > with an included kernel I get these errors: >> > >> > qemu-system-riscv64: plic: invalid register write: 00002090 >> > qemu-system-riscv64: plic: invalid register write: 00002094 >> > qemu-system-riscv64: plic: invalid register write: 00002098 >> > qemu-system-riscv64: plic: invalid register write: 0000209c >> > qemu-system-riscv64: plic: invalid register write: 000020a0 >> > qemu-system-riscv64: plic: invalid register write: 000020a4 >> > qemu-system-riscv64: plic: invalid register write: 000020a8 >> > qemu-system-riscv64: plic: invalid register write: 000020ac >> > qemu-system-riscv64: plic: invalid register write: 000020b0 >> > qemu-system-riscv64: plic: invalid register write: 000020b4 >> >> I see those as well. I haven't investigated but I assume we are just >> not completely modelling the PLIC. In saying that it should still >> boot. Do you not see the kernel booting? FWIW, I see similar looking messages on QEMU master but get a booting kernel. Thanks to some of the WD guys our Linux port is rapidly approaching "bootable on master", so we should start pushing on the QEMU patch queue a bit as well. Is there anything in particular I can do to help get patches reviewed? Michael has taken most of the burden here, but I'm trying to schedule much more time for code review on my end (which I say while replying to a thread that's been dead for a month... :)).
On Jul 09 2018, Alistair Francis <alistair23@gmail.com> wrote: > On Mon, Jul 9, 2018 at 3:00 AM, Andreas Schwab <schwab@suse.de> wrote: >> What is the state of the sifive_u emulation? When I tried to boot a bbl >> with an included kernel I get these errors: >> >> qemu-system-riscv64: plic: invalid register write: 00002090 >> qemu-system-riscv64: plic: invalid register write: 00002094 >> qemu-system-riscv64: plic: invalid register write: 00002098 >> qemu-system-riscv64: plic: invalid register write: 0000209c >> qemu-system-riscv64: plic: invalid register write: 000020a0 >> qemu-system-riscv64: plic: invalid register write: 000020a4 >> qemu-system-riscv64: plic: invalid register write: 000020a8 >> qemu-system-riscv64: plic: invalid register write: 000020ac >> qemu-system-riscv64: plic: invalid register write: 000020b0 >> qemu-system-riscv64: plic: invalid register write: 000020b4 > > I see those as well. I haven't investigated but I assume we are just > not completely modelling the PLIC. In saying that it should still > boot. Do you not see the kernel booting? I don't see those errors when using the qemu from github:riscv/riscv-qemu. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
On Tue, Jul 10, 2018 at 12:25 AM, Andreas Schwab <schwab@suse.de> wrote: > On Jul 09 2018, Alistair Francis <alistair23@gmail.com> wrote: > >> On Mon, Jul 9, 2018 at 3:00 AM, Andreas Schwab <schwab@suse.de> wrote: >>> What is the state of the sifive_u emulation? When I tried to boot a bbl >>> with an included kernel I get these errors: >>> >>> qemu-system-riscv64: plic: invalid register write: 00002090 >>> qemu-system-riscv64: plic: invalid register write: 00002094 >>> qemu-system-riscv64: plic: invalid register write: 00002098 >>> qemu-system-riscv64: plic: invalid register write: 0000209c >>> qemu-system-riscv64: plic: invalid register write: 000020a0 >>> qemu-system-riscv64: plic: invalid register write: 000020a4 >>> qemu-system-riscv64: plic: invalid register write: 000020a8 >>> qemu-system-riscv64: plic: invalid register write: 000020ac >>> qemu-system-riscv64: plic: invalid register write: 000020b0 >>> qemu-system-riscv64: plic: invalid register write: 000020b4 >> >> I see those as well. I haven't investigated but I assume we are just >> not completely modelling the PLIC. In saying that it should still >> boot. Do you not see the kernel booting? > > I don't see those errors when using the qemu from github:riscv/riscv-qemu. There are extra patches in that fork. One of them must fix the messages for the PLIC. I think a fair few of them have been reviewed on list, they just need a PR to be merged. Alistair > > Andreas. > > -- > Andreas Schwab, SUSE Labs, schwab@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different."
© 2016 - 2024 Red Hat, Inc.