On Tue, Aug 20, 2019 at 3:09 AM Alistair Francis <alistai...@gmail.com> wrote: > > On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei <zhiwei_...@c-sky.com> wrote: > > > > > > On 2019/8/17 上午1:29, Alistair Francis wrote: > > > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_...@c-sky.com> wrote: > > >> Hi, Palmer > > >> > > >> When Michael Clark still was the maintainer of RISCV QEMU, he wrote in > > >> the mail list, "the CLIC interrupt controller is under testing, > > >> and will be included in QEMU 3.1 or 3.2". It is pity that the CLIC is > > >> not in > > >> included even in QEMU 4.1.0. > > > I see that there is a CLIC branch available here: > > > https://github.com/riscv/riscv-qemu/pull/157 > > > > > > It looks like all of the work is in a single commit > > > (https://github.com/riscv/riscv-qemu/pull/157/commits/206d9ac339feb9ef2c325402a00f0f45f453d019) > > > and that most of the other commits in the PR have already made it into > > > master. > > > > > > Although the CLIC commit is very large it doesn't seem impossible to > > > manually pull out the CLIC bits and apply it onto master. > > > > > > Do you know the state of the CLIC model? If it's working it shouldn't > > > be too hard to rebase the work and get the code into mainline. > > > > > > Alistair > > > > > Hi, Alistair > > > > In my opinion, the CLIC code almost works. > > > > Last year when my workmate ported an RTOS, I once read the CLIC > > specification and used the CLIC model code. It worked through all the > > tests after fixed two bugs. I also had sent the patch to Michael, but > > without response(maybe a wrong email address). > > > > diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c > > index 7bf6cbc..95d80ab 100644 > > --- a/target/riscv/cpu_helper.c > > +++ b/target/riscv/cpu_helper.c > > @@ -505,6 +505,9 @@ static target_ulong riscv_intr_pc(CPURISCVState *env, > > if (!(async || clic)) { > > return tvec & ~0b11; > > } > > + if (clic) { > > + cause &= 0x3ff; > > + } > > > > /* bits [1:0] encode mode; 0 = direct, 1 = vectored, 2 >= reserved */ > > switch (mode1) { > > @@ -645,6 +648,9 @@ void riscv_cpu_do_interrupt(CPUState *cs) > > riscv_cpu_set_mode(env, PRV_M); > > } > > > > + if (clic) { > > + env->exccode = 0; > > + } > > /* NOTE: it is not necessary to yield load reservations here. It is > > only > > necessary for an SC from "another hart" to cause a load reservation > > to be yielded. Refer to the memory consistency model section of the > > > > After that, the specification has updated and the code may changed. I > > didn't pull new code again. > > > > If the CLIC model may merged into the mainline, and no body maintain the > > code, I'd like to work on it, fixing the bugs and updating the code > > according to latest specification. > > Yes please! We will be happy to merge it! > > If you would like to it would be great if you could update the code, > fix the bugs and then send patches to this list. >
Is the spec here? https://github.com/sifive/clic-spec/blob/master/clic.adoc Which silicon is going to have this CLIC? Regards, Bin
