<tianshi.xty=alibaba-inc.com@...> wrote: This case is already handled by ACLINT device tree bindings. We just need two separate MTIMER DT nodes where the mtimecmp base address will be

That makes sense, but it does mean that discovery gets more complicated, and (maybe) you need to build separate device trees for each. But maybe that has to happen anyway? I don't know if DT can be

I think this description is better. Assume there are two clusters，each cluster have two cores，and each cluster have there own MTIMER device. The mmio address of mtimecmp for each hart may like

Hi All, Apologies for cross posting multiple lists. Just wanted to reach out to the maximum audience as this is a short notice to set up the first meeting. This is just a quick notice that the first

Hi All, The doodle poll indicates that the 8AM PDT Wednesday is the most preferred slot. This will probably conflict with hypervisor SIG meetings once in a while. We will reschedule that meeting

The implication of that is that either - there is an mmio address that can access different instantiations of mtime/mtimecmp for each requesting hart (depending on the "cluster") - each "cluster"

In the SiFive Core-Local Interruptor (CLINT) device , a core can access the mtimcmp register of all cores in the platform. In the ACLINT spec, If a platform implements multiple MTIMER devices, such

cross-posting for more visibility. ---------- Forwarded message --------- From: Atish Kumar Patra <atishp@...> Date: Thu, Sep 1, 2022 at 11:55 AM Subject: Call for Chair/Vice-Chair Candidates for

Hi All, We are pleased to announce the early formation of Platform Runtime Services(PRS) Task Group with Atish Patra from Rivos as the acting chair and Sunil VL from ventana as the acting vice chair.

Hi All, I received some feedback that they had some conflicts with the proposed time. I adjusted the calendar invite to be for Mon Sept 12th at 8am PT. I will still send out slides prior to that so we

Hi All, I put a meeting on the RISC-V calendar for Thursday September 1 @ 9am PT. I'll send the slides out earlier in the week for people to critique and add suggestions of topics. We'll go over the

Sounds good. As long as we don't annoy anyone with a stream ECR updates to the same table I think that's a fine approach.

Hi Aaron, I was under the impression that it is decided not to use the extension names mentioned in profile spec. Sorry I didn't know you are still working with TSC to conclude on this. In that

I don't think we should submit this one until we settle on how we convey behaviors outside of an ISA string. I suspect that will change so we should anticipate that. Right now we have ISA string plus

Hi All, Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ... The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing

Hi, There are two major issues in passing virtual address of string: 1) A rogue supervisor software can pass a virtual address mapped to a physical address not accessible to it. 2) To access a

Hi All, We plan to send below two ECRs to UEFI forum on 08/08/2022. These two ECRs don't have any dependency on any unfrozen specs. Getting these two ECRs accepted by UEFI forum would help us to

Hi Group, I have an idea on addr_lo and addr_hi combination. What will happen if we ask supervisor to provide the string address in a probable virtual address? In this way the supervisor won't need to

For SBI spec, we have avoided separate function signatures for RV32 and RV64 so better to prefer other options. If we want to combine "addr_lo" and "addr_hi" into one parameter then uint64_t is

It is really necessary to have two long parameters for a physical address on RV64? Clearly this is necessary for RV32, where the maximum physical address is greater than XLEN, but that is not the