[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] riscv: sifive_test: Add reset functionality
From: |
Bin Meng |
Subject: |
Re: [Qemu-devel] [PATCH] riscv: sifive_test: Add reset functionality |
Date: |
Sun, 14 Jul 2019 11:38:05 +0800 |
On Tue, Jul 9, 2019 at 5:48 PM Palmer Dabbelt <address@hidden> wrote:
>
> On Fri, 14 Jun 2019 08:15:51 PDT (-0700), address@hidden wrote:
> > This adds a reset opcode for sifive_test device to trigger a system
> > reset for testing purpose.
> >
> > Signed-off-by: Bin Meng <address@hidden>
> > ---
> >
> > hw/riscv/sifive_test.c | 4 ++++
> > include/hw/riscv/sifive_test.h | 3 ++-
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/riscv/sifive_test.c b/hw/riscv/sifive_test.c
> > index 24a04d7..cd86831 100644
> > --- a/hw/riscv/sifive_test.c
> > +++ b/hw/riscv/sifive_test.c
> > @@ -21,6 +21,7 @@
> > #include "qemu/osdep.h"
> > #include "hw/sysbus.h"
> > #include "qemu/module.h"
> > +#include "sysemu/sysemu.h"
> > #include "target/riscv/cpu.h"
> > #include "hw/riscv/sifive_test.h"
> >
> > @@ -40,6 +41,9 @@ static void sifive_test_write(void *opaque, hwaddr addr,
> > exit(code);
> > case FINISHER_PASS:
> > exit(0);
> > + case FINISHER_RESET:
> > + qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
> > + return;
> > default:
> > break;
> > }
> > diff --git a/include/hw/riscv/sifive_test.h b/include/hw/riscv/sifive_test.h
> > index 71d4c9f..c186a31 100644
> > --- a/include/hw/riscv/sifive_test.h
> > +++ b/include/hw/riscv/sifive_test.h
> > @@ -34,7 +34,8 @@ typedef struct SiFiveTestState {
> >
> > enum {
> > FINISHER_FAIL = 0x3333,
> > - FINISHER_PASS = 0x5555
> > + FINISHER_PASS = 0x5555,
> > + FINISHER_RESET = 0x7777
> > };
> >
> > DeviceState *sifive_test_create(hwaddr addr);
>
> Poking around the hardware side, it looks like we're silently ignoring all
> codes aside from 0x3333 and 0x5555. As a result there's really no way to test
> if this added reset is going to work, so this should be a "sifive,test1"
> instead of a "sifive,test0". It's backwards compatible, so the compat string
> in the device trees should look something like
>
> compatible = "sifive,test1", "sifive,test0";
>
> With that it should be fine, pending the change to our hardware to reserve
> this
> as an error code within "sifive,test0" devices.
>
> Do you mind also submitting a device tree binding to Linux that describes this
> device? That way we can all stay on the same page about what the pair of
> interfaces do.
Thanks for the confirmation. I will try to create a device tree
binding for Linux.
Regards,
Bin