* [Qemu-devel] RISCV: when will the CLIC be ready? @ 2019-08-16 3:34 ` liuzhiwei 0 siblings, 0 replies; 18+ messages in thread From: liuzhiwei @ 2019-08-16 3:34 UTC (permalink / raw) To: Palmer Dabbelt Cc: Bastian Koppelmann, Alistair Francis, qemu-devel, Sagar Karandikar, qemu-riscv 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. 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [Qemu-riscv] RISCV: when will the CLIC be ready? @ 2019-08-16 3:34 ` liuzhiwei 0 siblings, 0 replies; 18+ messages in thread From: liuzhiwei @ 2019-08-16 3:34 UTC (permalink / raw) To: Palmer Dabbelt Cc: Sagar Karandikar, Alistair Francis, Bastian Koppelmann, qemu-devel, qemu-riscv [-- Attachment #1: Type: text/plain, Size: 413 bytes --] 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. 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 [-- Attachment #2: Type: text/html, Size: 588 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] RISCV: when will the CLIC be ready? 2019-08-16 3:34 ` [Qemu-riscv] " liuzhiwei @ 2019-08-16 17:29 ` Alistair Francis -1 siblings, 0 replies; 18+ messages in thread From: Alistair Francis @ 2019-08-16 17:29 UTC (permalink / raw) To: liuzhiwei Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei <zhiwei_liu@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 > > 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 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-riscv] [Qemu-devel] RISCV: when will the CLIC be ready? @ 2019-08-16 17:29 ` Alistair Francis 0 siblings, 0 replies; 18+ messages in thread From: Alistair Francis @ 2019-08-16 17:29 UTC (permalink / raw) To: liuzhiwei Cc: Palmer Dabbelt, Bastian Koppelmann, Alistair Francis, qemu-devel@nongnu.org Developers, Sagar Karandikar, open list:RISC-V On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei <zhiwei_liu@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 > > 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 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] RISCV: when will the CLIC be ready? 2019-08-16 17:29 ` [Qemu-riscv] " Alistair Francis @ 2019-08-19 13:39 ` liuzhiwei -1 siblings, 0 replies; 18+ messages in thread From: liuzhiwei @ 2019-08-19 13:39 UTC (permalink / raw) To: Alistair Francis Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis On 2019/8/17 上午1:29, Alistair Francis wrote: > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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 >> ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [Qemu-riscv] [Qemu-devel] RISCV: when will the CLIC be ready? @ 2019-08-19 13:39 ` liuzhiwei 0 siblings, 0 replies; 18+ messages in thread From: liuzhiwei @ 2019-08-19 13:39 UTC (permalink / raw) To: Alistair Francis Cc: Palmer Dabbelt, Bastian Koppelmann, Alistair Francis, qemu-devel@nongnu.org Developers, Sagar Karandikar, open list:RISC-V On 2019/8/17 上午1:29, Alistair Francis wrote: > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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 >> ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [Qemu-riscv] RISCV: when will the CLIC be ready? 2019-08-19 13:39 ` [Qemu-riscv] " liuzhiwei @ 2019-08-19 16:38 ` Chih-Min Chao -1 siblings, 0 replies; 18+ messages in thread From: Chih-Min Chao @ 2019-08-19 16:38 UTC (permalink / raw) To: liuzhiwei Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis, Alistair Francis On Mon, Aug 19, 2019 at 9:47 PM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > > On 2019/8/17 上午1:29, Alistair Francis wrote: > > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-riscv] [Qemu-devel] RISCV: when will the CLIC be ready? @ 2019-08-19 16:38 ` Chih-Min Chao 0 siblings, 0 replies; 18+ messages in thread From: Chih-Min Chao @ 2019-08-19 16:38 UTC (permalink / raw) To: liuzhiwei Cc: Alistair Francis, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis [-- Attachment #1: Type: text/plain, Size: 3430 bytes --] On Mon, Aug 19, 2019 at 9:47 PM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > > On 2019/8/17 上午1:29, Alistair Francis wrote: > > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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 [-- Attachment #2: Type: text/html, Size: 4553 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [Qemu-riscv] RISCV: when will the CLIC be ready? 2019-08-19 16:38 ` [Qemu-riscv] [Qemu-devel] " Chih-Min Chao @ 2019-08-21 3:33 ` liuzhiwei -1 siblings, 0 replies; 18+ messages in thread From: liuzhiwei @ 2019-08-21 3:33 UTC (permalink / raw) To: Chih-Min Chao Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis, Alistair Francis On 2019/8/20 上午12:38, Chih-Min Chao wrote: > > > On Mon, Aug 19, 2019 at 9:47 PM liuzhiwei <zhiwei_liu@c-sky.com > <mailto:zhiwei_liu@c-sky.com>> wrote: > > > On 2019/8/17 上午1:29, Alistair Francis wrote: > > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@c-sky.com > <mailto:zhiwei_liu@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. 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-riscv] [Qemu-devel] RISCV: when will the CLIC be ready? @ 2019-08-21 3:33 ` liuzhiwei 0 siblings, 0 replies; 18+ messages in thread From: liuzhiwei @ 2019-08-21 3:33 UTC (permalink / raw) To: Chih-Min Chao Cc: Alistair Francis, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis [-- Attachment #1: Type: text/plain, Size: 4168 bytes --] On 2019/8/20 上午12:38, Chih-Min Chao wrote: > > > On Mon, Aug 19, 2019 at 9:47 PM liuzhiwei <zhiwei_liu@c-sky.com > <mailto:zhiwei_liu@c-sky.com>> wrote: > > > On 2019/8/17 上午1:29, Alistair Francis wrote: > > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@c-sky.com > <mailto:zhiwei_liu@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. 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 [-- Attachment #2: Type: text/html, Size: 7376 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] [Qemu-riscv] RISCV: when will the CLIC be ready? 2019-08-21 3:33 ` [Qemu-riscv] [Qemu-devel] " liuzhiwei @ 2019-08-22 22:38 ` Alistair Francis -1 siblings, 0 replies; 18+ messages in thread From: Alistair Francis @ 2019-08-22 22:38 UTC (permalink / raw) To: liuzhiwei Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Chih-Min Chao, Alistair Francis On Tue, Aug 20, 2019 at 8:38 PM liuzhiwei <zhiwei_liu@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_liu@c-sky.com> wrote: >> >> >> On 2019/8/17 上午1:29, Alistair Francis wrote: >> > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-riscv] [Qemu-devel] RISCV: when will the CLIC be ready? @ 2019-08-22 22:38 ` Alistair Francis 0 siblings, 0 replies; 18+ messages in thread From: Alistair Francis @ 2019-08-22 22:38 UTC (permalink / raw) To: liuzhiwei Cc: Chih-Min Chao, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis On Tue, Aug 20, 2019 at 8:38 PM liuzhiwei <zhiwei_liu@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_liu@c-sky.com> wrote: >> >> >> On 2019/8/17 上午1:29, Alistair Francis wrote: >> > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] RISCV: when will the CLIC be ready? 2019-08-19 13:39 ` [Qemu-riscv] " liuzhiwei @ 2019-08-19 18:56 ` Alistair Francis -1 siblings, 0 replies; 18+ messages in thread From: Alistair Francis @ 2019-08-19 18:56 UTC (permalink / raw) To: liuzhiwei Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > > > On 2019/8/17 上午1:29, Alistair Francis wrote: > > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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. Alistair > > 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 > >> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-riscv] [Qemu-devel] RISCV: when will the CLIC be ready? @ 2019-08-19 18:56 ` Alistair Francis 0 siblings, 0 replies; 18+ messages in thread From: Alistair Francis @ 2019-08-19 18:56 UTC (permalink / raw) To: liuzhiwei Cc: Palmer Dabbelt, Bastian Koppelmann, Alistair Francis, qemu-devel@nongnu.org Developers, Sagar Karandikar, open list:RISC-V On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > > > On 2019/8/17 上午1:29, Alistair Francis wrote: > > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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. Alistair > > 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 > >> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] RISCV: when will the CLIC be ready? 2019-08-19 18:56 ` [Qemu-riscv] " Alistair Francis @ 2019-08-20 1:21 ` Bin Meng -1 siblings, 0 replies; 18+ messages in thread From: Bin Meng @ 2019-08-20 1:21 UTC (permalink / raw) To: Alistair Francis Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis, liuzhiwei On Tue, Aug 20, 2019 at 3:09 AM Alistair Francis <alistair23@gmail.com> wrote: > > On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > > > > > > On 2019/8/17 上午1:29, Alistair Francis wrote: > > > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-riscv] [Qemu-devel] RISCV: when will the CLIC be ready? @ 2019-08-20 1:21 ` Bin Meng 0 siblings, 0 replies; 18+ messages in thread From: Bin Meng @ 2019-08-20 1:21 UTC (permalink / raw) To: Alistair Francis Cc: liuzhiwei, open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis On Tue, Aug 20, 2019 at 3:09 AM Alistair Francis <alistair23@gmail.com> wrote: > > On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: > > > > > > On 2019/8/17 上午1:29, Alistair Francis wrote: > > > On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-devel] RISCV: when will the CLIC be ready? 2019-08-19 18:56 ` [Qemu-riscv] " Alistair Francis @ 2019-08-21 3:01 ` liuzhiwei -1 siblings, 0 replies; 18+ messages in thread From: liuzhiwei @ 2019-08-21 3:01 UTC (permalink / raw) To: Alistair Francis Cc: open list:RISC-V, Sagar Karandikar, Bastian Koppelmann, Palmer Dabbelt, qemu-devel@nongnu.org Developers, Alistair Francis On 2019/8/20 上午2:56, Alistair Francis wrote: > On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: >> >> On 2019/8/17 上午1:29, Alistair Francis wrote: >>> On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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. > > Alistair > OK, I'd like to. As the vector extension patch has already been under data disclosure review, I will forward move on to this work and send the patch about two or three weeks later. Best Regards, Zhiwei >> 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 >>>> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Qemu-riscv] [Qemu-devel] RISCV: when will the CLIC be ready? @ 2019-08-21 3:01 ` liuzhiwei 0 siblings, 0 replies; 18+ messages in thread From: liuzhiwei @ 2019-08-21 3:01 UTC (permalink / raw) To: Alistair Francis Cc: Palmer Dabbelt, Bastian Koppelmann, Alistair Francis, qemu-devel@nongnu.org Developers, Sagar Karandikar, open list:RISC-V On 2019/8/20 上午2:56, Alistair Francis wrote: > On Mon, Aug 19, 2019 at 6:44 AM liuzhiwei <zhiwei_liu@c-sky.com> wrote: >> >> On 2019/8/17 上午1:29, Alistair Francis wrote: >>> On Thu, Aug 15, 2019 at 8:39 PM liuzhiwei<zhiwei_liu@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. > > Alistair > OK, I'd like to. As the vector extension patch has already been under data disclosure review, I will forward move on to this work and send the patch about two or three weeks later. Best Regards, Zhiwei >> 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 >>>> ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-08-22 22:44 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-16 3:34 [Qemu-devel] RISCV: when will the CLIC be ready? liuzhiwei 2019-08-16 3:34 ` [Qemu-riscv] " liuzhiwei 2019-08-16 17:29 ` [Qemu-devel] " Alistair Francis 2019-08-16 17:29 ` [Qemu-riscv] " Alistair Francis 2019-08-19 13:39 ` liuzhiwei 2019-08-19 13:39 ` [Qemu-riscv] " liuzhiwei 2019-08-19 16:38 ` [Qemu-devel] [Qemu-riscv] " Chih-Min Chao 2019-08-19 16:38 ` [Qemu-riscv] [Qemu-devel] " Chih-Min Chao 2019-08-21 3:33 ` [Qemu-devel] [Qemu-riscv] " liuzhiwei 2019-08-21 3:33 ` [Qemu-riscv] [Qemu-devel] " liuzhiwei 2019-08-22 22:38 ` [Qemu-devel] [Qemu-riscv] " Alistair Francis 2019-08-22 22:38 ` [Qemu-riscv] [Qemu-devel] " Alistair Francis 2019-08-19 18:56 ` Alistair Francis 2019-08-19 18:56 ` [Qemu-riscv] " Alistair Francis 2019-08-20 1:21 ` Bin Meng 2019-08-20 1:21 ` [Qemu-riscv] " Bin Meng 2019-08-21 3:01 ` liuzhiwei 2019-08-21 3:01 ` [Qemu-riscv] " liuzhiwei
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.