On Tue, Aug 20, 2019 at 8:38 PM liuzhiwei <zhiwei_...@c-sky.com> wrote: > > > On 2019/8/20 上午12:38, Chih-Min Chao wrote: > > > > On Mon, Aug 19, 2019 at 9:47 PM 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. >> >> Best Regards, >> Zhiwei >> >> >> As we have cpus using CLIC, I have to use the out of tree qemu code in >> >> SIFIVE >> >> a long time. Could you tell me when it will be upstreamed? >> >> >> >> Best Regards >> >> Zhiwei >> >> >> > > Hi Zhiwei, > > I think what Alistair point out is the latest clic version (or > https://github.com/riscv/riscv-qemu/tree/riscv-qemu-3.1). The two versions, > on pull request and 3.1 branch, should be similar. > > As far as I know, there is no concrete plan on CLIC patch in short term. > It is good to know that the clic patch has been run with real RTOS. > It is also great if you could update the implementation to latest spec and > send the patch again. > > chihmin > > Hi chihmin, > > Thanks for your reminding and approval. I will pull the latest clic version > code and send the patch about two or three weeks later.
Great! I'm glad to see more contributions! Alistair > > The RTOS is Rhino, which is the kernel of > AliOS-Things(https://github.com/alibaba/AliOS-Things). > > It is also the kernel of YOC(https://cop.c-sky.com). > > Best Regards > Zhiwei
