software time controller

[Sebastian Sumpf]

Hi Menno,

On 02/18/2016 01:17 PM, Menno Valkema wrote:
> 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.
> 

We are thinking about a kernel timer mechanism as well. In my opinion,
the way to go would be to implement something similar to the Nova
approach (have a look at 'repos/os/src/drivers/timer/spec/nova'), where
you have a generic semaphore and can perform a down operation with a
given timeout. It does not have to be a semaphore, but could also be a
signal with a timeout. This way all base-hw platforms could take
advantage of this feature. I think the scheduler might be the right
place to implement this (in generic code).

@Martin: Any thoughts about this?

Regards,

Sebastian




-- 
Sebastian Sumpf
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth