1. Messages
  2. Access problem of mtimercmp in a platform with multiple MTIMER devices

Re: Access problem of mtimercmp in a platform with multiple MTIMER devices

Allen Baum
 

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 parameterized based on HartID, but that would greatly simplify the work.

On Tue, Sep 6, 2022 at 8:14 PM Tianyi Xia via lists.riscv.org <tianshi.xty=alibaba-inc.com@...> wrote:

each "cluster" can have its own unique mmio address for mtimecmp (which may or may not be accessible to other "clusters")

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 this:

Cluster0

    Core0: base0+0x0000_0000

    Core1: base0+0x0000_0008

Cluster1

    Core0: base1+0x0000_0000

    Core1: base1+0x0000_0008

Base0 is the MTIER device base address of cluster0, Base1 is the MTIER device base address of cluster0. the mtimecmp of cluster0 core0 may or maynot be accessible to cluster1,  depending on the implementation. If core try to access mtimecmp of other cluster, the action of the access may be write ignore read zero.


The latter sounds like it would be difficult for SW

I think in a platform with multiple MTIMER devices, the mmio address of mtimecmp should be unique to distinguish different MTIMER devices. The hardware can set regular base address to different Mtimer devices. In the above example, assuming base is 0, then base1 may be set to 0x0000_0010. If cluster0 has four cores, then base1 may be set to 0x0000_0020.Then from a software perspective, all mtimecmp registers are addressed consecutively.

 


 
Join {tech-unixplatformspec@lists.riscv.org to automatically receive all group messages.