You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems there is not a good platform independent way to determine what drives mtime and timer interrupts. From examples I've read, it seems people tend to #define the target board's timebase for mtime. However, this info does appear to be in the dts files, but just needs to be propagated to an API endpoint. For example, lfrclk drives mtime on the HiFive1-RevB, and lfrclk defines it's frequency in the dts.
A new entrypoint metal_cpu_get_mtime_timebase would be quite useful here to allow platform independent timer behavior.
A potential approach to this could be to have the platform's CPU driver direct this to the applicable subsystem that handles timers (clint0 for FE310), and this can then source the clockbase. Continuing this example on FE310, clint0 then knows that lfrclk would supply the clock here, and its node in the devicetree could hold a reference to the lfrclk node to supply the frequency to clint0
Would that scale to other platforms as well?
The text was updated successfully, but these errors were encountered:
Addendum: there is already an API for getting the CPU's timebase, but this appears to be the baseclock for cpu/mcycle and not for mtime (eg, on FE310, this returns the 16 MHz base clock vs the 32.768 KHz RTC that is connected to mtime)
It seems there is not a good platform independent way to determine what drives
mtime
and timer interrupts. From examples I've read, it seems people tend to#define
the target board's timebase formtime
. However, this info does appear to be in the dts files, but just needs to be propagated to an API endpoint. For example,lfrclk
drivesmtime
on the HiFive1-RevB, and lfrclk defines it's frequency in the dts.A new entrypoint
metal_cpu_get_mtime_timebase
would be quite useful here to allow platform independent timer behavior.A potential approach to this could be to have the platform's CPU driver direct this to the applicable subsystem that handles timers (
clint0
for FE310), and this can then source the clockbase. Continuing this example on FE310, clint0 then knows thatlfrclk
would supply the clock here, and its node in the devicetree could hold a reference to thelfrclk
node to supply the frequency toclint0
Would that scale to other platforms as well?
The text was updated successfully, but these errors were encountered: