qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Antony Pavlov <antonynpavlov@gmail.com>
To: Michael Clark <mjc@sifive.com>
Cc: qemu-devel@nongnu.org,
	Sagar Karandikar <sagark@eecs.berkeley.edu>,
	Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Subject: Re: [Qemu-devel] [PATCH v1 03/21] RISC-V CPU Core Definition
Date: Thu, 4 Jan 2018 20:53:53 +0300	[thread overview]
Message-ID: <20180104205353.30f96d3b75f8a0e0dbc22583@gmail.com> (raw)
In-Reply-To: <CAHNT7NvROn++kq96OZBwuGPhXk2DOFrCpCKycEUHTc2anR9V4w@mail.gmail.com>

On Thu, 4 Jan 2018 20:33:57 +1300
Michael Clark <mjc@sifive.com> wrote:

> On Thu, Jan 4, 2018 at 7:47 PM, Antony Pavlov <antonynpavlov@gmail.com>
> wrote:
> 
> > On Wed,  3 Jan 2018 13:44:07 +1300
> > Michael Clark <mjc@sifive.com> wrote:
> >
> > > Add CPU state header, CPU definitions and initialization routines
> > >
> > > Signed-off-by: Michael Clark <mjc@sifive.com>
> > > ---
> > >  target/riscv/cpu.c      | 338 +++++++++++++++++++++++++++++++++++++++
> > >  target/riscv/cpu.h      | 363 ++++++++++++++++++++++++++++++
> > ++++++++++++
> > >  target/riscv/cpu_bits.h | 411 ++++++++++++++++++++++++++++++
> > ++++++++++++++++++
> > >  3 files changed, 1112 insertions(+)
> > >  create mode 100644 target/riscv/cpu.c
> > >  create mode 100644 target/riscv/cpu.h
> > >  create mode 100644 target/riscv/cpu_bits.h
> > >
> > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> >
> > ...
> >
> > > +static void riscv_cpu_reset(CPUState *cs)
> > > +{
> > > +    RISCVCPU *cpu = RISCV_CPU(cs);
> > > +    RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(cpu);
> > > +    CPURISCVState *env = &cpu->env;
> > > +
> > > +    mcc->parent_reset(cs);
> > > +#ifndef CONFIG_USER_ONLY
> > > +    tlb_flush(cs);
> > > +    env->priv = PRV_M;
> > > +    env->mtvec = DEFAULT_MTVEC;
> > > +#endif
> > > +    env->pc = DEFAULT_RSTVEC;
> >
> > The RISC-V Privileged Architecture Manual v1.10 states that
> >
> >   The pc is set to an implementation-defined reset vector.
> >
> > But hard-coded DEFAULT_RSTVEC leaves no chance for changing reset vector.
> >
> > Can we add a mechanism for changing reset vector?
> >
> 
> That can be added very easily at some point when necessary.
> 
> All 5 RISC-V machines in the QEMU port currently have their emulated Mask
> ROMs at 0x1000 so its not necessary until we add a machine that needs a
> different value. I certainly wouldn't reject a patch that adds that
> functionality if we had a machine with a different reset vector, although
> given we have 5 machines using the same vector, it may remain a sensible
> default. I would think twice about adding a property that no machines sets,
> or duplicate code and have all machines set their reset vector even when
> they are all the same? Shall we add the functionality when we need it?

Actually it is me who needs this functionality.

At the moment my board code needs this dirty hack:

https://github.com/miet-riscv-workgroup/riscv-qemu/commit/bfc8221d89b9bb828f3742f17eb89d8513a75aae#diff-429448b1b26e0bc4256cc290758c0ab5

> 
> I'd categorise this as a feature request. #define DEFAULT_RSTVEC 0x00001000
> is the "implementation-defined reset vector"
> 
> Folk on the RISC-V mailing list are actually seeking guidance on the blanks
> in the RISC-V specification so it may be that a de-facto standard emerges
> for some of these "implementation defined" blanks, in which case it may
> become part of a platform spec (vs the ISA spec).
> 
> E.g. there is the "reset-hivecs" property in the ARM emulation code
> > so SoC-specific code can change reset vector.

-- 
Best regards,
  Antony Pavlov

  reply	other threads:[~2018-01-04 17:40 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-03  0:44 [Qemu-devel] [PATCH v1 00/21] RISC-V QEMU Port Submission v1 Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 01/21] RISC-V Maintainers Michael Clark
2018-01-03  5:30   ` Richard Henderson
2018-01-09 21:27   ` Alistair Francis
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 02/21] RISC-V ELF Machine Definition Michael Clark
2018-01-03  5:30   ` Richard Henderson
2018-01-09 21:33   ` Alistair Francis
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 03/21] RISC-V CPU Core Definition Michael Clark
2018-01-03  5:21   ` Richard Henderson
2018-01-03 22:30     ` Michael Clark
2018-01-08  6:55       ` Michael Clark
2018-01-04  6:47   ` Antony Pavlov
2018-01-04  7:33     ` Michael Clark
2018-01-04 17:53       ` Antony Pavlov [this message]
2018-01-05  5:59         ` Michael Clark
2018-03-03  1:41         ` Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 04/21] RISC-V Disassembler Michael Clark
2018-01-03  5:30   ` Richard Henderson
2018-01-03 22:12     ` Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 05/21] RISC-V CPU Helpers Michael Clark
2018-01-03  7:12   ` Richard Henderson
2018-01-03 22:59     ` Michael Clark
2018-01-03 23:25       ` Richard Henderson
2018-01-10 10:35     ` Stefan O'Rear
2018-01-10 17:04       ` Richard Henderson
2018-01-08 14:28   ` Christoph Hellwig
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 06/21] RISC-V FPU Support Michael Clark
2018-01-03 20:10   ` Richard Henderson
2018-01-23 21:37     ` Michael Clark
2018-01-24  0:01       ` Richard Henderson
2018-01-24  1:31         ` Michael Clark
2018-01-24 16:16           ` Richard Henderson
2018-01-24 17:35             ` Michael Clark
2018-01-23 23:15     ` Michael Clark
2018-01-23 23:35       ` Michael Clark
2018-01-24  0:03         ` Jim Wilson
2018-01-24  0:15       ` Richard Henderson
2018-01-24 18:58         ` Jim Wilson
2018-01-24 23:47           ` Richard Henderson
2018-01-29 20:33             ` Jim Wilson
2018-02-02  5:26               ` Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 07/21] RISC-V GDB Stub Michael Clark
2018-01-03 20:25   ` Richard Henderson
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 08/21] RISC-V TCG Code Generation Michael Clark
2018-01-03 21:35   ` Richard Henderson
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 09/21] RISC-V Physical Memory Protection Michael Clark
2018-01-03 23:03   ` Richard Henderson
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 10/21] RISC-V Linux User Emulation Michael Clark
2018-01-03 23:47   ` Richard Henderson
2018-01-05  6:51     ` Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 11/21] RISC-V HTIF Console Michael Clark
2018-01-04  0:00   ` Richard Henderson
2018-01-08 14:31   ` Christoph Hellwig
2018-02-04 20:19     ` Michael Clark
2018-02-04 21:29       ` Christoph Hellwig
2018-02-04 23:23         ` Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 12/21] RISC-V HART Array Michael Clark
2018-01-04  0:08   ` Richard Henderson
2018-01-05 21:41   ` Antony Pavlov
2018-01-05 21:44     ` Eric Blake
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 13/21] SiFive RISC-V CLINT Block Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 14/21] SiFive RISC-V PLIC Block Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 15/21] RISC-V Spike Machines Michael Clark
2018-01-04  0:14   ` Richard Henderson
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 16/21] RISC-V VirtIO Machine Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 17/21] SiFive RISC-V UART Device Michael Clark
2018-01-03 14:57   ` KONRAD Frederic
2018-01-05  6:38     ` Michael Clark
2018-01-04 21:07   ` Antony Pavlov
2018-01-05  6:03     ` Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 18/21] SiFive RISC-V PRCI Block Michael Clark
2018-01-03 15:02   ` KONRAD Frederic
2018-01-03 22:07     ` Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 19/21] SiFive Freedom E300 RISC-V Machine Michael Clark
2018-01-05 21:54   ` Antony Pavlov
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 20/21] SiFive Freedom U500 " Michael Clark
2018-01-03  0:44 ` [Qemu-devel] [PATCH v1 21/21] RISC-V Build Infrastructure Michael Clark
2018-01-03 23:23   ` Eric Blake
2018-01-05  6:47     ` Michael Clark
2018-01-05 14:49       ` Eric Blake
2018-01-08  9:29         ` Markus Armbruster
2018-01-04 17:09   ` Antony Pavlov
2018-01-05  6:22     ` Michael Clark
2018-02-03 22:36       ` Michael Clark
2018-01-03  1:28 ` [Qemu-devel] [PATCH v1 00/21] RISC-V QEMU Port Submission v1 no-reply
2018-01-03  1:46   ` Michael Clark
2018-01-03  2:00     ` Michael Clark
2018-01-03  2:41       ` Fam Zheng
2018-01-03  2:54         ` Michael Clark
2018-01-03  3:05           ` Fam Zheng
2018-01-05 11:49             ` Alex Bennée
2018-01-05 12:25               ` Fam Zheng
2018-01-05 12:39                 ` Alex Bennée
2018-01-05 22:11                 ` Paolo Bonzini
2018-01-03 11:35 ` Richard W.M. Jones
2018-01-03 21:50   ` Michael Clark
2018-01-03 22:06     ` Richard W.M. Jones
2018-01-08 15:45       ` Andrea Bolognani
2018-01-08 14:24 ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180104205353.30f96d3b75f8a0e0dbc22583@gmail.com \
    --to=antonynpavlov@gmail.com \
    --cc=kbastian@mail.uni-paderborn.de \
    --cc=mjc@sifive.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sagark@eecs.berkeley.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).