On Thu, Mar 25, 2021 at 11:40 AM Bin Meng <bmeng...@gmail.com> wrote: > > On Thu, Mar 25, 2021 at 11:32 AM Dylan Jhong <dy...@andestech.com> wrote: > > > > On Wed, Mar 24, 2021 at 10:59:55PM +0800, Alistair Francis wrote: > > > On Tue, Mar 23, 2021 at 5:15 AM Dylan Jhong <dy...@andestech.com> wrote: > > > > > > > > Although the AE350 has not been upstream (preparing for v2), > > > > the reset vector of the AE350 is known to be at the 2G position, > > > > so this patch is corrected in advance. > > > > > > > > Signed-off-by: Dylan Jhong <dy...@andestech.com> > > > > Signed-off-by: Ruinland ChuanTzu Tsai <ruinl...@andestech.com> > > > > --- > > > > target/riscv/cpu.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c > > > > index 2a990f6253..0236abf169 100644 > > > > --- a/target/riscv/cpu.c > > > > +++ b/target/riscv/cpu.c > > > > @@ -137,7 +137,7 @@ static void set_feature(CPURISCVState *env, int > > > > feature) > > > > env->features |= (1ULL << feature); > > > > } > > > > > > > > -static void set_resetvec(CPURISCVState *env, int resetvec) > > > > +static void set_resetvec(CPURISCVState *env, uint64_t resetvec) > > > > > > resetvec in env is a target_ulong so this should be as well (instead > > > of a uint64_t). > > > > > > Alistair > > > > > > > Hi Alistar, > > > > Thanks for your comments. > > > > Indeed resetvec should use target_ulong instead of uint64_t. > > resetvec being target_ulong means that rv32 cannot have a reset vector > beyond 4GiB. I don't think the spec disallow this.
Ah, I was wrong. The spec says: "the pc is set to an implementation-de ned reset vector" and pc is XLEN wide. So for rv32 the reset vector cannot beyond 4GiB. We should change it to target_ulong. Regards, Bin