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 ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
