Hi Sergio,
to start off, I haven't done anything with the vtimer in quite some time,
so I might be wrong in certain areas. Also, from my few experiences with
OKL4 3.0 I think it's using the old OKL4 2.1 driver framework. This one
is automated in some ways through the build process, but also puts a
number of restrictions on the use.
You've run into some of these limitations already:
- The drivers identify "requests" by handles, and due to the size limita-
tions of the underlying data structures these are limited to 4. I'm not
sure if increasing their size (i.e. 8 entries instead of 4) will work.
- The build system expects you to set "required_vdevs" in the SConscript,
which in turn leads to an autogeneration of the above mentioned handles.
In OKL4 2.1 it's possible to require a device multiple times, which
results in multiple handles being allocated for the same client. However,
retrieving the handle information stored within the clients environment
isn't working properly in that case anymore.
- As said above, requests are identified by their handles. If you want
to run 3 different timers, you need 3 different handles (out of the 4
provided at max by default).
To sum it up: If you want to run more than 4 timers in your userland,
you can either try to hack the limits and up them or get an own driver
implementation working.
About the actual implementation on the PXA platform (from OKL4 2.1): If
I remember correctly the vtimer actually uses 2 hardware timers; one
handled the actual tick management and the other was just set for overflow
checking. I never understood the reasoning behind the latter. Also, the
vtimer implementation from 2.1 has a very serious issue due to the doubled
management of the total tick count in both the upper and the lower half
of the driver; if they run out of sync (which actually did happen here),
timer based things got to a grinding halt (the timer hardware is running
in this case, but with an insane timeout).
Greets,
Robert
Sergio Ruocco wrote:
> Hi,
>
> both me and some students of mine are venturing, for different projects,
> in the OKL4 timer/Iguana (v)timers APIs (when running on XScale PXA250
> hw), but we are a bit confused by what we read.
>
> Before reverse-engineering all the code to learn how to use it properly,
> and understand what's going on in general, we decided to first try ask
> to the list.
>
> We briefly looked at:
>
> - the "physical" driver:
> okl4_3.0/drivers/pxa250_timer/
>
> - L4 uK using an hw timer for thread scheduling:
> okl4_3.0/platform/pxa/pistachio/src/timer.c
>
> - the Iguana timer and vtimer implementations:
> okl4_3.0/iguana/timer
> okl4_3.0/iguana/vtimer
>
> and finally at the small vtimer example in
> okl4_3.0/iguana/example/drivers/src/drivers_example.c
>
>
> In all of this, it is not clear to us:
>
> - how can we place multiple outstanding requests (eg. for 10, 12 and 15
> ms in the future)
>
> - once that is done, how can we identify which request we have been
> notified of?
>
> - what is the actual role of the vtimer(s) objects
> are they (just) client timer requests?
>
> If so, why exactly four virtual timers are declared and initialised in
> the server ("timer_server.c") and called "instances"? Instances of what?
>
> static struct virtual_timer virtual_device_instance[4] = { { 1 }
> }; /* valid but unused instances are ok */
>
> Are they (virtual) _devices_, then ?
> Isn't a vtimer a virtual device already?
>
> Why only two instances are available after the vtimer server
> initialization ?
>
> I can see that a XScale CPU has 4 timer match registers triggering
> interrupts on matches, one of them is used by the microkernel itself,
> the other (probably) by the roll-over code saw somewhere in the code.
>
> Thus, on XScale, just 2 timers irqs are free. Still, having only two hw
> timer match registers left shouldn't affect the number of outstanding
> requests we can enqueue to a (v)timer...
>
>
> There is more, but this is enough to start...
>
> Thanks in advance for any clarification.
>
> Ciao
> Sergio
>
>
>
>
>
>
> _______________________________________________
> Developer mailing list
>
[hidden email]
>
https://lists.okl4.org/mailman/listinfo/developer>
_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer
