software time controller

Menno Valkema menno.genode at ...9...
Thu Feb 18 13:17:50 CET 2016


Hi Everyone,

We're porting the Genode timer to the riscv architecture. We've
created a prototype which works, however we have some concerns regarding
the integration with Genode, and whether timer features may or may not
work correctly.

Looking at the examples from other architectures the common  way to
port the timer is through a hardware time controller which is available
through memio.

The riscv core does not have a time controller available in its default
configuration. (riscv offers a register based approach, however those
registers are not accessible by the timer process since it does not run
with the right cpu privileges).

In order to get the the timer working on riscv we created a software
time controller which works via memio. The time operations are
performed by the scheduler which does have the right privileges to
access the riscv core's timer registers.

This is the approach we took:
- Declare a region of normal memory as io-memory (our virtual/software
time controller).
 ( through modification of base-hw/src/core/spec/riscv/platform_support.cc )
- Give the timer process MEM_IO and IRQ access, and access the memory
region, to 1) read the time from a specific address, 2) set the alarm
time and sleep waiting for a signal to be woken up by setting the timer
process to wait for an unused irq with number IRQ#.
- Modify the scheduling function which is executing with Supervisor
privileges, to perform the following tasks whenever the job scheduler is
called: 1) read the time from the register write it to the io-memory
region 2) read the alarm value from another address in the io-memory
region, and if it's set: compare this to the current time and and if the
alarm time has expired signal User_irq with number IRQ#.
( through modifications in base-hw/src/core/kernel/cpu.cc )
- Timer wakes up and continues to-do whatever timers do.

This approach works in the spike simulator: We can run the run/hello
target, where the process blocks for a while, and wakes up by the timer
again.

Our concern is with the following items:
- Will this support all the features a timer needs? Did we take the
right approach here?
- Can we be sure the memory we now allocated for our software time
controller, won't be allocated for other uses later?
- 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.

Regards, Menno






More information about the users mailing list