Gilles Chanteperdrix <[email protected]> wrote on
01/24/2013 04:03:54 AM:
> As said in the porting guide, it means that you have a timer issue. What
> happens when you load a skin module is that Xenomai takes over the
> control of the timer. So, that is where you should look. Do not assume
> anything about the TWD code, it is not because it works on other
> platforms that it works on this one.
I modified the xttcpss code to support the ipipe_timer structure and got
some interesting results:
If I simply register this device with ipipe, there is largely no
difference-- this is because the twd timer has a higher rating, and is
registered by the time xenomai loads
If I increase the rating of the xttcpss timer, the system is able to boot
and run the xenomai sample applications
CPU0 uses the xttcpss timer as it's timer
CPU1 uses the twd timer as it's timer
latency test is able to run on both cores (though CPU1 gets
considerably better numbers-- likely because the twd timer runs at a much
higher frequency)
This seems to indicate there is some problem on this platform with the twd
code (maybe the sharing of the twd interrupt between linux and xenomai?).
Of note-- when both cores are using the twd (the still broken case), if I
turn on CONFIG_IPIPE_DEBUG_INTERNAL and enable the __ipipe_serial_debug
message in twd_hrtimer_debug, I see far more interrupts on CPU1 than on
CPU0. Is this to be expected?
In general, do is there any advice for debugging where the twd_smp.c code
is falling over on my platform?
Best Regards,
Matt Fornero
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
