On Sun, Aug 30, 2020 at 12:43 AM Nathan Chancellor
<natechancel...@gmail.com> wrote:
>
> On Sun, Aug 30, 2020 at 08:24:15AM +0100, Mark Cave-Ayland wrote:
> > On 30/08/2020 07:49, Nathan Chancellor wrote:
> >
> > > Unfortunately, it does not. I applied it on top of latest
> > > git (ac8b279f13865d1a4f1958d3bf34240c1c3af90d) and I can still
> > > reproduce my failure. Is it possible that type of fix is needed
> > > in a RISC-V specific driver?
> > >
> > > Would you like me to comment on the Launchpad bug as well?
> >
> > Hi Nathan,
> >
> > I came up with a quick patch to enable some logging to catch memory
> > accesses being
> > refused for a similar bug report at
> > https://bugs.launchpad.net/qemu/+bug/1886318/comments/13.
> >
> > Can you apply the same change to your tree and report any messages on
> > stderr as you
> > do your board reboot test?
> >
> >
> > ATB,
> >
> > Mark.
>
> Thanks Mark, that helped.
>
> ...
> [ 3.807738] reboot: Power down
> invalid size: riscv.sifive.test addr 0 size: 2
> sbi_trap_error: hart0: trap handler failed (error -2)
> sbi_trap_error: hart0: mcause=0x0000000000000007 mtval=0x0000000000100000
> sbi_trap_error: hart0: mepc=0x000000008000d4cc mstatus=0x0000000000001822
> sbi_trap_error: hart0: ra=0x000000008000999e sp=0x0000000080015c78
> sbi_trap_error: hart0: gp=0xffffffe000e765d0 tp=0xffffffe0081c0000
> sbi_trap_error: hart0: s0=0x0000000080015c88 s1=0x0000000000000040
> sbi_trap_error: hart0: a0=0x0000000000000000 a1=0x0000000080004024
> sbi_trap_error: hart0: a2=0x0000000080004024 a3=0x0000000080004024
> sbi_trap_error: hart0: a4=0x0000000000100000 a5=0x0000000000005555
> sbi_trap_error: hart0: a6=0x0000000000004024 a7=0x0000000080011158
> sbi_trap_error: hart0: s2=0x0000000000000000 s3=0x0000000080016000
> sbi_trap_error: hart0: s4=0x0000000000000000 s5=0x0000000000000000
> sbi_trap_error: hart0: s6=0x0000000000000001 s7=0x0000000000000000
> sbi_trap_error: hart0: s8=0x0000000000000000 s9=0x0000000000000000
> sbi_trap_error: hart0: s10=0x0000000000000000 s11=0x0000000000000008
> sbi_trap_error: hart0: t0=0x0000000000000000 t1=0x0000000000000000
> sbi_trap_error: hart0: t2=0x0000000000000000 t3=0x0000000000000000
> sbi_trap_error: hart0: t4=0x0000000000000000 t5=0x0000000000000000
> sbi_trap_error: hart0: t6=0x0000000000000000
>
> With this diff, I can successfully shut down the board. No idea if that
> is valid or not though.
The SiFive test is not a real device, so there is no documentation to
check against, at least none that I can find.
If the mainline Linux kernel does a 16-bit write then that should be
correct as it does the same thing on hardware and SiFive's
simulations.
Do you mind sending a patch?
Alistair
>
> Cheers,
> Nathan
>
> ============================================================
>
> diff --git a/hw/riscv/sifive_test.c b/hw/riscv/sifive_test.c
> index 0c78fb2c93..8c70dd69df 100644
> --- a/hw/riscv/sifive_test.c
> +++ b/hw/riscv/sifive_test.c
> @@ -59,7 +59,7 @@ static const MemoryRegionOps sifive_test_ops = {
> .write = sifive_test_write,
> .endianness = DEVICE_NATIVE_ENDIAN,
> .valid = {
> - .min_access_size = 4,
> + .min_access_size = 2,
> .max_access_size = 4
> }
> };
>
>
