software time controller

Martin Stein martin.stein at ...1...
Fri Feb 19 17:45:26 CET 2016

Hi Menno, Sebastian,

> On 02/18/2016 01:17 PM, Menno Valkema wrote:
>> - Will this support all the features a timer needs? Did we take the
>> right approach here?

I think yes. AFAIK, there must be a way to install a timeout that
provides asynchronous feedback (it's not necessary to use IRQs for that)
and it must be possible to sample the timer value plus the according
overrun status. The overrun status is the information whether the last
installed timeout was expired at the time of the sample. The overrun
status is reset when a new timeout gets installed.

>> - Can we be sure the memory we now allocated for our software time
>> controller, won't be allocated for other uses later?

Yes. If you provide your IO memory through the IOMEM service and try to
open a second session to it, the server complains like ...

I/O memory [x,y) not available
Local MMIO mapping failed!

... and sends a Genode::Parent::Service_denied exception to the client.

>> - We've made some riscv-specific changes in non risc-v source code. Is
>> the scheduler the best place to make these changes? Is there a
>> possibility to move these changes to a riscv specific directory and call
>> these with a callback, so that the code still works for other platforms.

As Sebastian said, we're playing with the idea to move to a
kernel-driven timer in general or at least in base-hw. But it is not
clear now whether this idea actually brings the benefits we're hoping
for and by now, there's also no one working at it. Thus, I would suggest
to move the RISCV-specific implementation into separate files for now.
You can do this by declaring the hooks in the generic header [1] and
implementing them in a new RISCV-specific unit [2]. You would then have
to add the unit to 'SRC_CC' in [3].


[1] base-hw/src/core/include/kernel/cpu_scheduler.h
[2] base-hw/src/core/spec/riscv/kernel/
[3] base-hw/lib/mk/spec/riscv/

More information about the users mailing list